Field service, dispatch, and routing on one platform

Three systems, one job

Walk into the back office of most field-service operations and you will find the same arrangement. The work order lives in a field-service package. The dispatch board — who is going where today — lives somewhere else, often a scheduling tool or a whiteboard someone photographs at 7 a.m. And routing, the actual question of which stops go on which van in what order, lives in a spreadsheet with a maps tab open beside it.

Each of those tools is defensible on its own. The problem is that they describe the same day's work in three incompatible vocabularies, and somebody has to keep them agreeing. That somebody is usually a dispatcher, and the work is invisible until it fails.

The cost here is not licence fees. Three mid-market tools is a manageable line item. The cost is the reconciliation tax — the continuous, unbudgeted human labour of keeping three pictures of reality in sync, plus the errors that leak through when it doesn't happen fast enough.

What actually breaks at the seams

The failures are specific, and if you run a field team you have lived all of them.

Parts don't move when the job does. A technician marks a call complete on their phone. They used a blower motor, two capacitors, and a length of line set out of the van. In a stitched stack, that completion is an event in the field app; the inventory decrement is a separate action somebody has to perform, usually from a paper note or a text message, usually days later. So van stock is wrong, the reorder point fires late, and the next tech gets dispatched to a job they can't finish.

ETA promises go stale silently. Dispatch re-sequences a route at 10:40 because a morning call ran long. The customer at the fourth stop already got a text saying "between 1 and 3." Nothing in the scheduling tool knows that the text was sent, or that the route it was derived from no longer exists. The customer finds out by waiting.

The second visit. The single most expensive event in field service is the return trip caused by a missing part — you pay for the drive, the labour hour, and the customer's patience, and you bill for none of it. Second visits are almost always an information failure rather than a diagnostic one: the part existed, somewhere, and nothing connected "this job needs it" to "that van has it."

Invoices that argue with the work. The invoice gets built from the work order. The work order says what was scheduled. The parts actually consumed live in the technician's head and the van's shelf. Everyone in the business knows the invoice is approximately right, which is a polite way of saying nobody can defend a line item when a commercial customer challenges it.

"What did the tech actually do on site?" This one arrives as a warranty question, a liability question, or a customer dispute, and it arrives months later. If the answer lives across three tools with three retention policies and a free-text notes field, the answer is effectively "we don't know."

Why one data model changes the arithmetic

The usual response to the above is integration: connect the field app to the inventory system, connect the scheduler to the messaging provider, run a nightly sync. That helps, and it introduces a new category of problem — the sync that silently stopped, the webhook that retried into duplicates, the recurring meeting where two teams argue about which system is authoritative.

FastYoke's answer is structurally different. The apps you install — Field Service, Inventory, CRM Suite, Accounting, and the free Logistics core underneath them — are not separate products connected by pipes. They are configured workflows on one engine, over one per-tenant database. CRM records, Field Service jobs, and the rest link to their related entities automatically.

The practical consequence is worth stating plainly: completing the job is the inventory movement and is the billable event. Not "triggers" them. Is them. There is no window in which the job is complete but stock hasn't moved, because there is no second system to propagate to. The customer record, the work order, the parts, and the route are the same entities being viewed from different angles.

That removes an entire class of question from your week. Not "did the sync run," not "which number is right," not "who owns fixing this."

The dispatch loop as an explicit state machine

At the core of the platform is a finite-state-machine workflow engine. A work order is a state machine: a defined set of states, connected by defined transitions, each governed by a condition you configure. It can only move along an edge that exists.

The happy path is easy — scheduled, dispatched, on site, complete. The value is in the exceptions, because exceptions are the actual job:

• Can't access. Nobody home, gate code wrong, building locked.
• Needs parts. Diagnosed on site, part not on the van.
• Callback. Same customer, same fault, within the warranty window.
• Quote required. Work exceeds the authorised amount.

In a stitched stack these live in a free-text status field, which means they are unqueryable, unenforceable, and unreportable. You cannot answer "what percentage of our calls fail on access" from a notes column. Modelling them as real states means each one can have its own rules — a "needs parts" job can require a part reference before it's allowed to close, a callback can be flagged non-billable automatically, an access failure can trigger its own follow-up path.

Every transition is written to an append-only event log with the actor and the timestamp. "What did the tech do on site, and when" is a query rather than an investigation. That is also what makes the invoice defensible.

Routing, honestly

Routing is an optimisation problem: assign stops to vehicles and order them, subject to constraints — time windows the customer agreed to, the skills or certifications a job requires, the parts actually on that van, and capacity. Solved well it saves real miles and real hours. FastYoke includes a routing engine that works against those constraints, with the objective and the rules under your control rather than frozen in a vendor's product.

Two honest caveats, because routing is oversold more than almost anything else in this category.

A route is only as good as its inputs. The dominant input is service time — how long a given job actually takes at a given site. Most operations do not measure this; they use a default, or a guess from the estimator. Feed an optimiser bad service times and it will return a confidently wrong plan, tightly packed and impossible, and your technicians will be behind by 10 a.m. Measuring real service times by job type and site is unglamorous work, and it is the prerequisite, not the follow-up.

Re-optimising mid-day has a human cost. Technically you can re-solve the whole board every time something changes. Operationally, churn is corrosive — a tech who has mentally planned their afternoon and gets re-sequenced twice stops trusting the system and starts working around it. Re-sequencing needs guardrails: a threshold below which you don't bother, a rule that the current and next stop are frozen, and a clear signal to the tech about what changed and why.

The field is where software goes to die

None of this matters if the technician can't use it. Basements, plant rooms, rural service areas, steel-framed commercial buildings — connectivity fails exactly where the work happens, and a tool that stalls on a spinner in a crawl space is a tool that gets replaced by a phone call to the office.

On the Edge tier, the routing algorithm can run on the technician's device. When dispatch adds a stop, the sequence is recomputed locally — a tech in a signal-dead area gets the updated order without waiting for a cloud round-trip. Proof of visit — signature, photo, geofence — buffers to on-device storage and syncs when connectivity returns. The record lands; the technician never waits for the network to admit the work happened.

What to watch out for

Don't model your existing broken process. The temptation when configuring a workflow engine is to reproduce today's states, including the ones that only exist because two systems disagreed. Map the process you want before you build the one you have.

The technician's phone is the real product surface. The dispatcher's view gets all the attention in evaluations because dispatchers sit in the demo. Adoption is decided by whether a tech with cold hands can complete a job in three taps.

Your dispatchers know things the optimiser doesn't. A good dispatcher carries years of unwritten heuristics — this customer is difficult before noon, that building's loading bay is a nightmare on delivery days. An optimiser will contradict those on day one, and sometimes the optimiser is wrong. Run it in advisory mode first, let the dispatcher override, and treat every override as a constraint you failed to encode rather than a user error.

Nothing here is free of configuration. The platform gives you the engine and the apps; you model your specific workflow. Apps cost nothing to install and aren't metered per app — you pay for platform usage above a free tier — but the modelling work is yours or a partner's.

Where this goes next

If your work orders, your dispatch board, and your routing are three tools that argue with each other, the fix isn't a fourth tool to reconcile them. See field service on FastYoke for the vertical view, Edge for how this behaves when connectivity doesn't cooperate, or logistics without the six-figure TMS for the same argument applied to freight. Plans are on pricing.