Field service: the schedule is a hypothesis the day disproves

At 8 a.m. the dispatch board is beautiful. Six technicians, twenty-two jobs, each one a tidy block on a map, drive times calculated, the whole day routed into a sequence that flows from the depot and back. It looks like a solved problem. By 2 p.m. it is a different document entirely. The 9 a.m. job ran two hours long because the part on site wasn't the part on the work order. Van three is sitting behind a road accident that no routing engine saw coming. The technician on the morning's emergency call is in a basement with two bars that drop to none, and the booking he just closed is queued on his phone, going nowhere. The schedule was a hypothesis. The day is busy disproving it.

That gap — between the plan the morning drew and the reality the afternoon delivered — is the entire product. It is also the one thing the demo never shows you, because a demo runs on a clean grid: full signal, open roads, and jobs that take exactly as long as the estimate said. Field-service software is not the map. It is what the software does when the map turns out to be wrong, which it does every single day, before lunch.

The pieces are real, and they are the easy part

Strip a field-service tool to the capabilities it joins, and none of them is novel. A vehicle's location comes from GPS or a telematics feed, so the dispatcher can see where the vans actually are rather than where the plan assumed. Drive times and the order to visit jobs in come from a maps and routing API — Google, Mapbox, one of the routing specialists — which will happily turn a list of addresses into an optimised sequence. The "your technician is on the way" and "running about an hour late" messages go out over a texting service like Twilio. And the appointments themselves live on a calendar, the spine the whole day hangs from.

Wire those four together and you have a week of ordinary integration work. That is worth saying plainly, because it sets the trap: the capabilities are so available, and they demo so cleanly, that the tool looks finished the moment they're connected. Location dot moving on a map, route drawn, text fired, slot booked — it all works, on the clean grid. The reason it isn't a product yet is that every one of those four capabilities answers the morning's question, and the product is paid to survive the afternoon's.

The capability chain, and where it bends

Follow a single job through the loop and watch where it stops being tidy.

A customer books a slot on the calendar → the routing engine slots that job into a technician's sequence and estimates the drive → the technician's phone shows the day's route → the location feed tracks the van against the plan → as the van approaches, the customer gets a text → the technician arrives, does the work, and closes the job. On the clean grid, that chain runs end to end without a hitch.

Now bend it the way a real day bends it. The job before this one overran, so the estimate is now wrong by ninety minutes — the routing engine needs to re-sequence what's left, not recompute from a blank slate. The text that should fire is no longer "on my way at 1:15" but "running late, now around 2:45," and it has to go out before the customer calls in to ask, not after. The technician closing the overrun job is underground with no signal, so the close has to be captured on the device and reconciled with the server whenever the signal comes back. Every interesting thing in that paragraph is a divergence from the plan — and the value of the product is precisely how gracefully it absorbs the divergence. The chain isn't the product. The bends are.

What it rides on

Named as the modules a real version needs, most of the chassis is ordinary infrastructure that a foundation already carries:

• Accounts and auth — so a dispatcher, a field technician, and an operations manager each see the view that's theirs, and a job belongs to a real, identified person.
• A calendar and a job store — the durable record of what was promised, to whom, when, and what state it's in right now.
• Background jobs — the steady offstage work: pulling location updates on a cadence, re-running routes when the day shifts, firing the "running late" texts on time, reconciling closures that came in from a phone that was offline an hour ago.
• An admin — where someone watching the whole fleet can see a stuck job, a van that's gone dark, or a route that no longer makes sense, and act on it without opening a database.
• A log — so when a customer says "no one ever told me you'd be late," there's a row that says the text was queued at 1:48 and accepted, and the conversation has an answer instead of a shrug.

That list is the recurring point of this whole site. Accounts, a scheduler for the offstage timing, an admin to watch the fleet, a log to answer "what happened" — those run in production today underneath CompanyGraph, which leans on a background batch runner to do scheduled work, surfaces an operator's admin to see and unstick what the batch is doing, sits behind real accounts, and writes to a central log when something fails. None of that is the field-service idea, and Smallbox has not built the field-service idea — but the chassis under it is not hypothetical. It is the same chassis that already carries unrelated products, which is the difference between starting this at a quarter of work and starting it at a week.

The two external capabilities sit on that chassis. The map calls underneath have a cost-and-caching discipline of their own that's easy to get wrong at fleet scale — why you cache and budget the map and geocoding calls rather than billing every route afresh is worth getting right before the routing volume climbs. And the "running late" text rides on the same kind of seam every outbound message does — the consent and the local send-record you own behind that text is the part that turns "we told them" from a claim into a row.

What you own, and what stays external

The discipline that keeps this product defensible is the same one every idea in this set comes back to: decide early what is rented and what is yours.

The location feed, the routing math, the SMS carrier — all rented, and rightly. You are not going to build a better routing optimiser than the people whose entire company is routing optimisation, and you shouldn't try. What must be yours is the layer those inputs feed: the jobs and their real state, the schedule and its history, the record of every promise made to a customer and every message sent about it, and — the quiet centre of the whole thing — the re-planning logic that decides what to do when reality and the plan disagree. That logic is the product. Two field-service tools can wire the identical GPS feed and the identical routing API and be completely different businesses, and the entire difference is in how each one handles the overrun, the dead zone, and the accident on the ring road. The APIs are shared. The judgment about a diverging day is not, and if it lives anywhere but your own system you don't have a product — you have a thin coat of paint over three vendors' dashboards.

The hard part

Two of them, and they are the same shape twice: the world refuses to behave like the demo.

The first is real-world routing. A routing API gives you an optimised plan against an idealised map, and the day immediately introduces what the map left out — traffic that builds while the van is already moving, a job that takes twice its estimate, an emergency call-out that has to be slotted in now and reshuffles everything after it, a one-way street the data didn't know had closed for resurfacing. Useful field-service software re-plans gracefully under all of that: it treats the route as something to continuously revise as the day reports back, not a sequence computed once at 8 a.m. and defended against reality until it breaks. That re-planning under churn is genuinely hard, and it is exactly the part the clean-grid demo skips.

The second is offline reality, and it is the one that humbles teams who only ever tested on office wifi. Field technicians work in basements, plant rooms, rural sites, lift shafts, underground car parks — places with no signal, sometimes for an hour at a stretch. The tool has to keep working with no connection: show the technician their route, let them update a job, capture a signature and a closure, and then reconcile all of it with the server when the signal returns — without losing an edit or double-applying one. Offline-first capture and clean later sync is a serious engineering discipline, the kind that doesn't show up in any demo because a demo always has signal, and then shows up on day one in the field when the most important job of the morning is closed somewhere with no bars.

The verdict

This is a full SaaS, and a high-value one — operations teams running fleets of vans pay real money, on multi-year contracts, for software that keeps a diverging day under control. But the value is not in the parts that demo. The GPS dot, the drawn route, the templated text — every competitor has those, and the APIs hand them to everyone equally. The product lives in the gap the demo hides: re-planning when the day refuses to match the plan, and working when the network isn't there. And the honest implication of that is a go-to-market fact more than a technical one — this sells to operations, not to engineers. The buyer is the dispatcher who lives the 2 p.m. reschedule and the operations manager who answers for the missed window, not the developer admiring how cleanly the route renders. A field-service tool wins by being demonstrably better at the bad afternoon than the customer's current whiteboard-and-phone-calls — which means the narrow versions win, the ones shaped to one trade's real day, where the generalists stay forever a little generic.

The way to find out whether a particular version is your business is the usual one, and it is cheaper than it looks once the chassis isn't the obstacle.

---

The accounts, the scheduled background work, the operator's admin, and the log this rides on already run in production under CompanyGraph, and they are the foundation a field-service tool would sit on — so the next sensible step is to take the narrowest version that owns its diverging day and build it on a chassis that already carries the boring parts, then watch what a real operations team does with it.