The instinct when building dispatch software is to automate the dispatcher away: jobs in, assignments out, humans supervise. It is the wrong target for anything but high-volume standardised work, and the reason is not sentiment about jobs. It is that dispatchers hold information the system does not have.
Which customer will tolerate a delay. Which technician is good with a difficult site. That the access road is closed this week. None of it is in the data, all of it is decision-relevant, and a system that takes the decision away has to be right about things it cannot see.
So the design goal is different: make the dispatcher faster at the thing they are uniquely good at, and automate the part that is genuinely mechanical.
Three views because there are three questions
The allocation console shows one day's work three ways, and the reason is that dispatchers ask structurally different questions during a shift.
Map answers where is everyone? — live technician positions, the paths they have travelled, and unassigned work in geographic context. This is the view for "who is near this emergency?"
Timeline answers does the day fit? — an intraday view where each person is a lane and each job occupies real time. Overcommitment is visible as overlap rather than inferred from a count. Dropping a job onto a lane schedules it.
Board answers what is unassigned, and who takes it? — a backlog rail and a column per person, where dragging assigns.
Forcing all three questions through one view is the most common design mistake here. A list can answer none of them well.
"Optimize day" is deliberately narrow
One action fills the day's unassigned backlog into free slots. It is the mechanical part: given jobs without owners and people with gaps, produce a workable arrangement.
What it does not do is override decisions a person has already made. The dispatcher's existing assignments stand; the action works on what is genuinely unallocated. That boundary is what makes it safe to press — a button that might rearrange the morning you spent arranging is a button nobody presses twice.
This is a general principle for assistive automation in an operational tool: act on the untouched, never on the decided. It converts the feature from a gamble into a time-saver.
Underneath: routing that knows more than distance
Behind the console, work is matched by omni-channel routing that considers queue, required skill, capacity and presence — with accept, decline, transfer and reassign as first-class operations rather than edge cases bolted on afterwards.
Decline matters more than it looks. A system where work can only be pushed produces a technician with six jobs and no mechanism to say the sixth is impossible, so the information arrives as a missed commitment instead of a decline. Making refusal a supported action is how the plan stays honest.
Capacity and presence do the quieter work: someone who is off shift or already at their limit is not a candidate, so the arrangement respects reality before a human has to notice.
The console is not only for field service
The same console allocates any record type — service orders, cases, visit plans. That generality came from noticing that "unassigned work, available people, a day to fit it into" is one problem wearing several costumes.
The practical benefit is that a business running field service and field sales does not learn two allocation tools, and a supervisor covering both sees one day rather than two.
Where it will not save you
Automated arrangement is only as good as job durations, and job durations are estimated optimistically almost everywhere. A day optimised against wrong durations looks efficient at 9am and has collapsed by 11am. Skills matrices go stale. Van stock is rarely accurate to the item.
None of that is an argument against the tooling; it is an argument for keeping the dispatcher in the loop, and for treating durations as data to be measured rather than assumed. The console shows the day as it actually stands — which is what lets a person notice at 11:20 that a two-hour job has become four, while there is still time to move the job that is now at risk.
What we would tell another team
Ask what your users do that a model cannot: in dispatch, it is holding context that was never written down. Build for that, automate the mechanical remainder, and give the automation a boundary narrow enough that pressing the button is never a risk.
Then show state, not just data. The difference between a list of jobs and a timeline where overlap is visible is the difference between a dispatcher who finds out at 16:05 and one who finds out at 11:20.
Related: What is field service dispatch? · The dispatcher's day, replanned · xMatix Field Service