Scheduling a Field Crew When the 9am Job Runs to Noon

Every field service business runs on a schedule that is wrong by lunchtime. The 9am job was booked for two hours. It takes three and a half, because the part wasn’t where the customer said it would be, or the panel behind the wall wasn’t what the quote assumed. Now the 11am job is late, the 1pm job is in doubt, and the office has to decide, in real time, who gets called and who gets moved. This is not an edge case a schedule needs to tolerate occasionally. It is the normal operating condition of a field crew, and a scheduling system that only works when the day goes to plan is not actually a scheduling system.

What a real dispatch board looked like before this problem was solved

An HVAC contractor in southern Ontario, running 3-4 technicians out of one dispatch office, described their actual process in their own requirements brief before any of this was built. Technicians were assigned by memory and lookup, with no system check for double-booking at all. There was no live view of whether a technician had accepted a job, was on the way, was delayed, or had declined it, once a job was assigned, the office found out what was happening by calling the technician. Quarterly maintenance contracts, which is exactly the rhythm this kind of business runs on, didn’t surface on the schedule as due on their own; someone had to remember to check. None of that is a criticism of the office staff. It is what happens when a schedule lives in someone’s head and a wall calendar, not in a system built to hold it.

The conflict warning that doesn’t get in the way

The instinct when you build scheduling software is to stop a dispatcher from double-booking a technician. That instinct is usually wrong. On the HVAC build, the warning that fires when a technician is assigned into an overlapping window is deliberately non-blocking: it tells the dispatcher there’s a conflict, and lets them proceed anyway. The reasoning, straight from the project’s own acceptance notes, was that the office wanted the system to warn, not stop them, because a dispatcher can still make the judgment call a rigid system can’t.

That distinction matters more than it sounds like it should. A blocking conflict warning assumes every double-booking is a mistake. It usually isn’t. Sometimes a technician can genuinely run two nearby jobs back to back with a short overlap on paper but not in practice. Sometimes the dispatcher is deliberately overlapping two jobs because one is a five-minute drop-off and the other is the real work. A system that refuses to let a human override it, in a business where the human is the one standing in the truck bay looking at the map, is a system the office will start working around within a week, usually by not using the double-booking feature at all and going back to a side channel to coordinate.

The same board also treats a job card as a job, not a fixed assignment. Rescheduling a job means dragging it to a new technician or a new day, with a confirmation step before the change actually commits, rather than the schedule silently rewriting itself. That confirmation step exists for the same reason the conflict warning is non-blocking: the person moving the job is trusted to make the call, but the system still makes them see what they’re changing before it happens.

What “live enough” actually means for a small crew

A dispatch board only helps during an overrun if the office can see, without calling anyone, that the 9am job is still running at 11:15. The HVAC build answers that with technician status buttons: Accepted, On My Way, Delayed, Rejected, visible to the office in near-real time. That directly closes the gap the client described in their own brief, no way to see, once a job was assigned, whether the technician had accepted it or was even still coming.

The board itself polls for updates every five seconds rather than running a full push or websocket system. That was a deliberate choice, not a shortcut: for a four-person crew looking at one screen in one office, five-second polling is close enough to live to answer every question a dispatcher actually asks during the day, and it’s a much smaller, more reliable thing to build and keep running than a persistent live-update connection. The lesson generalises past this one build: “live enough” is a question about your crew size and how the office actually uses the screen, not a spec you should copy from a much larger operation’s dispatch tooling.

What re-dispatching an overrun actually requires

When the 9am job is still running at noon, the office needs three things in quick succession, and a paper schedule or a wall calendar gives none of them without a phone call:

• A current, trustworthy read on where every technician actually is in their day. Status buttons that update within seconds, not a guess based on when the job was supposed to finish.
• A way to move the next job without losing the record of why it moved. A dragged job card with a confirmation step, not a scratched-out time on a printed sheet, keeps the reschedule reason attached to the job instead of living only in someone’s memory.
• A fast way to tell the next customer before they call to ask where the technician is. This is the step that gets skipped most often under pressure, because it takes a deliberate action, not because it isn’t important. A dispatcher who can see a technician is genuinely running behind, in real time, has the lead time to make that call themselves instead of reacting to an angry one.

None of this requires predicting overruns. It requires making the actual state of the day visible fast enough that a person can react to it before the customer has to chase the office for an answer. That’s a lower bar than “smart scheduling,” and it’s the bar that actually gets missed in most field service operations, paper-based or not.

The maintenance jobs that get forgotten, not just the ones that overrun

The same visibility gap that hides an overrun also hides recurring work. On the HVAC brief, quarterly maintenance contracts had no automatic prompting; the office had to remember which customers were due and manually schedule them. A “due this week” filter surfacing recurring maintenance automatically, instead of relying on memory, was built directly against that gap. It sits next to the overrun problem for a reason: both are symptoms of a schedule that only exists in someone’s head until it’s typed onto a whiteboard, and both get fixed the same way, by making the actual state of obligations (who’s overdue, who’s overrun, who’s next) visible without anyone having to remember to check.

What this does not require

It’s worth being explicit about what a working dispatch board for a small crew does not need, because the temptation is always to build the bigger version. The HVAC build deliberately did not include a general pricing-rules engine, a customer login portal, SMS notifications, or a websocket-based live feed. None of those were missing features so much as scope a 3-4 technician office didn’t actually need to run its day. A dispatch board earns its keep by answering “who’s where, and what changed” fast enough for a human to act on it. Everything past that is optional, and optional features on a small crew’s schedule usually cost more in upkeep than they return in value.

The honest limit of any dispatch board

A conflict warning, a status button, and a five-second refresh don’t stop a job from running long. Nothing in software prevents the part being in the wrong place or the panel behind the wall being different from what the quote assumed. What a working dispatch board does is remove the lag between “this job is now running long” and “the office knows and can act.” That lag, not the overrun itself, is what turns one late job into an afternoon of angry phone calls. Fix the lag and the overruns become a normal, manageable part of the day instead of a crisis that compounds job after job.