Fieldshift

Most field-service teams do not run on software. They run on a whiteboard, a group chat, and a dispatcher who holds the whole day in their head. That works right up until a van breaks down at 09:40, two jobs slip, and the only way to rebuild the afternoon is eleven phone calls made while the phone is already ringing.

The bill arrives as second visits. A technician drives to a site with the wrong part because the fault description never got out of a voicemail. A customer books a half-day off work and phones at noon to ask where the van is. A signed job sheet sits in a glovebox for three days and holds up the invoice for a week. None of that is a people problem. It is a systems problem, and it is the one Fieldshift is being built to remove.

01 What is Fieldshift, and who is it for?

Fieldshift is a workflow-automation app for field-service teams — the dispatchers, technicians, and coordinators who keep work moving across sites rather than desks. It puts the schedule, the job cards, and the customer communication in one place, so a job exists once and everyone works from the same copy of it.

It is aimed at the size of operation where everyone still knows everyone: a handful of vans, one or two people coordinating, a back office that also raises the invoices. That band gets served badly. Enterprise field-service suites assume a rollout project, an administrator, and a budget line; the free tools assume a shared calendar is enough and leave you to phone the rest. We are building for the gap between them — the crew that has outgrown a spreadsheet but should not need a consultant to move two jobs.

Why the design starts from the van, not the office

Because the van is where the work happens, and it is the worst environment the software will ever run in. A dispatch board can afford to be dense and clever; a job card cannot. If a technician has to pinch-zoom a table while standing on a flat roof in the rain with one glove off, the card gets skipped and the information turns up as a text message at six in the evening. So the technician screen is designed first and the office views inherit from it, not the other way round. Every field on a job card has to earn its place by answering a question the technician genuinely has on site: what am I doing, where, what do I need with me, and what proof do I have to leave behind.

02 What happens when a technician has no signal?

The job card keeps working. Technicians get mobile job cards that work offline and sync when signal returns — capture is offline-first, so notes, readings, photos, parts used, and the customer sign-off are written to the device first and reconciled with the server afterwards.

That is not a nicety bolted on for edge cases. Plant rooms, basements, lift shafts, rural sites, and steel-framed buildings are exactly where field service happens. A tool that needs a connection before it will record a completed job quietly trains a crew to record nothing, and then the office is back to phoning people. The failure mode we design against is the job card that never synced: the work was done, the evidence is gone, and nobody can say for certain what happened.

What offline-first actually has to get right

Capturing offline is the easy half. Reconciling is the half that decides whether a crew trusts the app. The device is the honest record of what happened on site; the server is the honest record of what was scheduled. When those two disagree — a job reassigned while a technician was underground, a part logged twice — the app has to resolve it predictably and show its working, rather than silently picking a winner. Sync also has to be visible: a technician should be able to glance at a card and know whether it has landed, because "I thought it sent" is how a day's paperwork disappears.

03 How does dispatch see what is at risk?

On the board. Dispatchers get a board that shows who is where and what is at risk — the schedule and its live state in one view, so "will today land?" is a question you answer by looking rather than by reconstructing the morning from phone calls.

Risk in field service is rarely a surprise. It is a series of small signals that nobody had time to add up: a first job that started forty minutes late, a two-hour slot with an hour of driving in front of it, a return visit waiting on a part. Surfacing those while there is still room to move is most of the value. Once a customer has been stood up, the software is only helping you apologise faster.

04 What does each role actually see?

Different things, deliberately — one record per job, four honest views of it. The job is the spine; each role gets the slice it can act on and none of the noise it cannot.

05 Why do customers keep calling to ask where the van is?

Because nobody remembered to tell them, and because remembering is not a job anyone should have. Customers get status updates without anyone remembering to send them: the status change on the job is the trigger, so the update goes out when the work moves rather than when someone finds a gap between calls.

Those calls are more expensive than they look. Every one of them interrupts the person best placed to keep the day on track, which makes the day worse, which produces more calls. Automating the hand-offs that usually happen over a chain of phone calls is not about being clever with messaging — it is about giving the dispatcher back the slice of every hour they currently spend narrating the schedule to people who are already waiting.

06 Where do the parts, the history, and the sign-off live?

On the job, together. The parts, the history, and the sign-off travel with the job instead of living in three different systems — the stores list, the paper pad, and somebody's inbox — that only agree by accident.

This is the part that pays for itself twice. It pays once in the field, when a technician opens a card for a site they have never visited and can see what was done last time and what was fitted. It pays again in the office, because a job that carries its own parts and its own signature is a job you can invoice on the day rather than a week later. We took the same position when we built approval trails into Ledgerline, our finance-operations app: the record has to be a by-product of doing the work, never a second task bolted on afterwards.

07 Can you be a Fieldshift design partner?

Yes, and right now that is the only way in. Fieldshift is in active development. It is not open for general sign-up yet — we are onboarding a small group of design partners to shape it against real routes and real crews, because a dispatch board designed against imaginary jobs is a demo, not a product.

A design partner gives us the awkward truth: the site with no signal, the customer who insists on a phone call, the part that is always out of stock, the technician who will not use anything with more than two taps. In return you help set the defaults, and you get the build shaped around how your team already dispatches rather than how a product manager imagined it.

Fieldshift is built by the same team and to the same standards as the rest of our work — see how we approach SaaS product engineering and custom web application development, or browse the rest of the app portfolio. Join the waitlist and we will reach out as spots open, with a walkthrough tuned to how your team dispatches today. If you would rather talk it through first, tell us how you dispatch today and we will say honestly whether Fieldshift is close enough to help yet.