Service dispatch is the decision of which technician goes to which call, in what order, and by when. In most shops it lives in one dispatcher’s head and on a whiteboard. A dispatch system holds the four things that decide an assignment — skill match, territory, current load, and the promised arrival window — checks them against every open call, and tells the dispatcher which constraint has to break when they cannot all hold.
Where the dispatch board falls apart
The board only exists in one person's head
Your dispatcher knows which tech can run a heat pump changeout, which van carries the right coil, and which customer will not have a particular tech back. None of it is written down. The week she is out, the day gets assigned by name recognition.
Skill mismatch surfaces after the truck arrives
A tech is sent to what the ticket called a no-cool. On site it becomes a line set replacement he is not certified to braze. The visit turns into a diagnostic, the part gets ordered, and one call becomes two nobody priced.
Arrival windows are promised before anyone looks at the day
Whoever answers the phone gives a window because the customer asks for one. The board is not consulted and drive time from the previous stop is not considered. The window is promised against a day already committed.
An emergency reshuffles the day and nobody tells the customers who moved
A no-heat call on a January morning outranks a filter change, so the filter change slides. That customer finds out when the window passes and calls in asking where the truck is.
The dispatch decision table and what happens when the rules disagree
Four constraints decide every assignment. They agree most of the time, and the interesting part of a dispatch system is what it does the rest of the time. This is what we build the assignment logic against.
| Constraint | What the system checks | How it is treated | What happens when it loses |
|---|---|---|---|
| Skill match | Certifications, license class, and van-mounted equipment against the call type and the equipment on file at that address | Hard gate. A failing tech is not offered | Never quietly. A dispatcher can force it, and the ticket is stamped as forced with the missing qualification named |
| Territory | Assigned zone against the service address, plus drive time from the previous stop | Soft. Ranked, not blocked | Loses to skill and to a promised window. Added drive time is shown, so the cost to the day is visible |
| Current load | Hours committed today, including on-site time by call type and the return-to-shop leg | Soft. A tech over capacity ranks last | Loses to an emergency. Overflow moves to the next open slot and those customers land on a notification list |
| Promised window | The window given at booking against projected arrival from the previous stop | Hard for same-day, soft for maintenance | Beats territory and load. A PM visit can slide; a window on a paid diagnostic does not, without a call out |
| Skill against window | The only qualified tech cannot make the window | Handed to the dispatcher, not settled by ranking | Both options are shown: qualified and late, or early and handed off, with the cost of a second truck roll |
| Territory against load | The in-zone tech is full, the out-of-zone tech is open | Compared on impact to the day, not distance | The board proposes the out-of-zone run and marks the extra drive non-billable, so it lands in job costing |
How we build the dispatch layer
The tech record is the source of truth for what a person can do
Certifications, license class, van-mounted equipment, and the call types a tech has actually run are attributes with their own expiry dates. When an EPA 608 card lapses, he stops being offered refrigerant work that morning, not at the next audit.
Call types carry their own duration and their own requirement
A drain camera inspection, a water heater swap, and a seasonal tune-up are not the same hour. Each call type holds a duration estimate and a required qualification, so the board schedules real time instead of uniform one-hour blocks.
The board proposes and a person assigns
For a shop under roughly fifteen trucks we do not build auto-dispatch. The system ranks candidates and shows why each one sits where it does. The dispatcher clicks, and the click is what commits the assignment.
Every assignment writes down its reason
When a call is assigned, moved, or forced, the system records who did it, when, and what the constraint picture looked like. That is the record that answers the trip charge dispute six weeks later.
A reschedule fires the customer notice, not a person's memory
When a call moves, the affected customer lands on a notification list before the dispatcher leaves the screen, and the message names the new window. Nobody learns their appointment moved by watching the window pass.
What the dispatch board talks to
- custom scheduling and dispatch applications — The board is usually a custom build, because constraint weighting is specific to how your shop runs.
- form automation for call intake — Intake captures address, equipment, and call type so the board has something to match against.
- CRM automation for customer notifications — Window confirmations and reschedule notices go out against the customer record, not a tech's phone.
Is this a fit for your business?
A good fit when
- Four or more trucks, and someone spends the first hour of the day building the board
- Your techs hold different certifications and a wrong assignment means a second trip
- You mix scheduled maintenance with same-day emergency calls
- Arrival windows get promised on the phone before anyone checks capacity
Probably not a fit when
- One or two trucks and the owner is driving one
- You need route optimization across fifty-plus vehicles doing dense stop-per-hour work
- Every call is the same type and any tech can run it
What to have ready
- Your call types and roughly how long each takes on site
- Each tech’s certifications, license class, and usual zones
- Whatever the board is today, even a photo of the whiteboard
Questions we get asked
Will this dispatch automatically, with no person in the loop?
It can, and for most shops we recommend against it at first. Auto-dispatch is only as good as the duration estimates behind it, and those are wrong until you have months of real on-site times. We build the ranking first and revisit automation once the durations are corrected by reality.
What happens when the only qualified tech is stuck on a job that ran long?
The system does not resolve that, and it should not. It shows the two options with their costs: hold the call and miss the window, or send someone who will have to hand it off. Which is right depends on the customer and the job, so the choice stays with the dispatcher. What changes is that you find out in the morning, not at three.
Does it account for drive time between calls?
Yes, using distance and a drive-time estimate between the previous stop and the next. It is an estimate, not live traffic routing. If you need turn-by-turn routing with live conditions across a large fleet, that is a routing product, and we would integrate one rather than rebuild it.
Our dispatcher does not want software telling her how to run her day.
That is usually the sign of a good dispatcher, and we build for it rather than around it. The board makes her knowledge visible to everyone else instead of replacing her judgement with a ranking. The difference shows up the week she is away, when whoever covers can see the constraints she carries in her head.
Related
- technician time and materials capture on site
- membership and service plan management
- custom application development for field operations
- workflow automation for construction and field service companies
Tell us what the process looks like now and we will map what a system would need to do. No obligation, and you keep the map either way.