In most service businesses under a hundred people, dispatch is a person. They have a whiteboard, or a shared calendar, or a spreadsheet with one column per tech, and they know things that exist nowhere else: that this customer will not let anyone but Mike in the house, that the Thornton job always runs two hours long, that you do not send the new guy to a commercial roof alone.
That knowledge is the most valuable undocumented asset in the company, and it takes a two-week vacation every year, during which everything gets slower and something gets scheduled wrong. The point of dispatch software is not to replace that judgement with an algorithm. It is to write it down.
What actually decides an assignment
Ask a dispatcher why they put a particular job on a particular truck and you will get "because that's who's free". Watch them for a day and you will find seven constraints running at once. Almost every scheduling project that fails, fails because it modeled the first two and ignored the rest.
- Skill and certification. Not just trade but level — who can pull a permit, who is licensed for gas, who is signed off for confined space, whose certification expires next month.
- Geography and drive time. Real drive time on real roads at that hour, not straight-line distance. A twelve-mile job across a bridge at 4pm is not a twelve-mile job.
- Duration reality. The estimated duration and the actual duration for this job type at this customer. Both matter, and the gap between them is where the day falls apart.
- Parts and equipment. Whether the material is on the truck, at the warehouse, or at the supply house — and whether the truck with the lift is already committed.
- Customer constraints. Access windows, gate codes, the tenant who works nights, the property manager who must be present, the customer who has requested a specific tech or has asked never to see another one.
- Commitments already made. Contract response times, warranty callbacks that jump the queue, and the maintenance visits that have to land in a particular month to keep an agreement valid.
- Human factors. Overtime position for the week, who is on call, who has a hard stop for a school pickup, and the fact that the same tech has taken the three worst jobs in a row.
Why full automation is the wrong target
Optimal routing is a solved problem in the abstract and an unsolved one in a service business, because the objective function keeps changing. Some weeks you are optimizing for drive time. Some weeks you are optimizing for keeping one commercial client happy at the expense of everything else. In August you are optimizing for not losing your best tech.
An auto-scheduler that gets 85% of assignments right feels worse than a whiteboard, because the dispatcher now has to audit every decision to find the 15%, and they cannot tell which is which. Assisted scheduling inverts that: the system proposes, shows its reasoning, and the human commits. The dispatcher stays in charge and gets faster instead of getting overruled.
A suggestion you can see the reasoning for is useful at 70% accuracy. A decision you cannot inspect is useless at 95%.
What to build, in order
01
A board that shows the real day
Techs down one axis, time across the other, jobs as blocks with drive gaps drawn in. The single most common finding when a business first sees this is that the day was never as full as it looked — an hour of unbooked time was hiding between every pair of jobs.
02
Unscheduled work as a first-class queue
Everything not yet on the board, with age, promised date, priority, and source. If unscheduled work lives in someone's inbox, the board is lying about capacity.
03
Constraints as data, not code
Skills, certifications with expiry dates, service areas, customer preferences and exclusions, and equipment. All editable by the office. The moment a rule requires a developer to change, it stops reflecting reality.
04
Suggested assignments with reasons
For each unscheduled job, a short ranked list: this tech, because certified, twelve minutes away, has the part, no overtime. And the disqualifications shown too — that tech is closer but is not licensed for this.
05
The reschedule path
Cancellations, no-access, jobs running long, and emergency calls. This is the majority of a dispatcher's actual day and it is the part demo software always skips.
06
Notification on commit
The tech gets the job on their phone, the customer gets a window. Both from the same commit action, so the schedule cannot silently diverge from what people were told.
The reschedule path deserves its own design
Plans survive until about 9:40 in the morning. The job that mattered is not the initial assignment — it is what happens when the third call of the day runs two hours long and four downstream customers are now going to be told something different from what they were promised.
| Disruption | What the system should surface | Who decides |
|---|---|---|
| Job running long | Which downstream appointments are now at risk, and by how much | Dispatcher, immediately |
| No access on arrival | A recorded reason, a rebook option, and whether a trip charge applies | Tech in the field |
| Emergency call in | Who can be pulled with the least damage, including what gets bumped | Dispatcher |
| Tech calls out | The whole day's reassignment as one proposal, not job by job | Dispatcher |
| Part not available | Whether another truck has it, and the earliest date it can be sourced | Dispatcher with warehouse |
Notice that the system's job in every row is to surface consequences, not to choose. The choice is a business judgement about which customer relationship absorbs the damage today, and no software has the context to make it.
Where the data has to come from
A dispatch board is only as good as its inputs, and two of them are usually missing. The first is real job duration — if you have never recorded actual start and end times per job type, every estimate on the board is a guess, and the board will be wrong in a way that erodes trust in it fast. Start logging actuals before you build, even manually, because a month of real durations is worth more than any scheduling feature.
The second is incoming work. If requests arrive by phone, text, web form, and email, and only become schedulable after someone retypes them, the queue is permanently behind reality. That intake gap is worth closing first, and it is covered in turning inbound messages into scheduled jobs.
Frequently asked questions
Should dispatch software assign jobs automatically?
For most service businesses, no. Assisted scheduling — where the system proposes ranked assignments with visible reasoning and a person commits — outperforms full automation because the objective changes week to week and the dispatcher holds context the system does not. Automatic assignment works for high-volume, highly uniform work, which is rarely what a trades business does.
What data do we need before building a scheduling system?
Actual job durations by job type, your service areas, and a skills or certification list per tech. Actual durations matter most: without them the board is built on estimates, and a schedule that is consistently wrong loses the dispatcher's trust within two weeks. A month of manually logged start and end times is enough to start.
How do we handle emergency calls without wrecking the day?
Model the disruption explicitly. When an emergency arrives, the system should show which jobs can be moved and what each option costs — which customer gets bumped, whether it triggers overtime, whether a contract response window is breached — and let the dispatcher choose. The failure mode to avoid is silently reshuffling the board.
Can this work alongside our existing field service platform?
Usually yes. The common arrangement keeps the platform as the system of record for customers, jobs, and invoicing, while the custom layer owns the constraint model and the board, syncing job state both ways. That is a much smaller project than replacing a system that is currently billing your customers.