The work schedules itself
An asset at a site carries a service interval, and the job falls due without anybody asking it to. Nobody has to keep a spreadsheet of what is nearly overdue, which is the spreadsheet that is always out of date.
Product
Pascoe Field Service
Field operations and workforce management - jobs, scheduling, engineers on site, checklists, photographs, signatures, and the recurring compliance work that has to happen whether or not anybody remembers it.
In development. Pascoe Field Service is not available yet. Nothing is deployed, there is nothing to sign up to, and there is no date because none has been committed to. Where each of our products stands is stated plainly.
The chain it is built around
Most of that description is a feature list. One part of it is a promise — that the recurring work happens whether or not anybody remembers it — and that is the part built end to end first.
A visit, given to an engineer
The due job becomes a scheduled visit belonging to a named engineer, so the question "who is going" has an answer that is not a phone call.
A checklist on a phone
Configurable, and completed on site rather than written up afterwards. One platform configured per contract — not a different application per trade.
Evidence captured against the visit
Photographs and a signature, attached to the visit they were taken on. The evidence is the record, not an email somebody sent later.
When the job closes, the asset's next due date moves. That is the loop closing — the reason the recurring work does not need remembering.
Built for a signal that comes and goes
A plant room, a basement, a rural site. The engineer's phone is going to lose signal, and the software has to be honest about what that means.
Nothing is quietly discarded
Work captured offline is queued, and the queue's refusals say what is being held and why. An engineer is never told something was saved when it was not, and never told it was lost when it is still waiting.
A job will not close on missing evidence
A refused checklist step, a missing signature or a refused photograph holds the close, and the engineer is told which one and in their own terms — "arriving on site", not a queue identifier. Two problems are counted as two, not as the first one.
How far along it actually is
Early, and worth saying so. It is a working prototype of the chain above, not a product you could run a department on this year.
What has been proved
Against a real database: tenants cannot see each other's work, roles and anonymous access are enforced where the data is, the scheduler raises the job on its own, a visit will not close without its evidence, and captured evidence cannot afterwards be altered or deleted — not by the engineer, not by an administrator, not by the owner. Thirty-five assertions, run from a database built only from the migrations and the seed. Without a database: the offline queue's refusal rules, and the checks that keep the shipped application honest.
What has not been proved here
The full phone journey, including the offline capture cycle, has not been run on our own machine. Until it has, we do not count it and neither should you. What is proved is proved against a real database, not described.
If this is the work you run
There is nothing to sign up to. Tell us what you maintain, how the recurring work is tracked now, and what happens when an engineer has no signal — and we will tell you honestly whether this is going to fit and when.