Work Order Dispatch and Scheduling Software

Every field service operation has a person, or a small team, whose whole job is deciding who goes where next. Job dispatch systems have been sold for two decades on the promise of replacing that person with an algorithm, and after 22 years of watching CMMS, CAFM and field service implementations land in real operations, I can report that almost nobody has actually done it. What the good implementations did instead was give the dispatcher a far better dispatch board, a much tighter definition of what counts as a dispatchable job, and a daily rhythm disciplined enough that the board stays truthful. That combination, not the optimisation engine, is what turns a chaotic service day into a predictable one.

The message up front: the biggest cause of a failed service visit is not bad routing. It is a job that was dispatched before it was ready, so the engineer arrived without the part, without site access, without a permit, or without the right certification. Dispatch software earns its licence fee by enforcing readiness and making the day visible, not by shaving minutes off drive time.

1. What dispatch software actually is

Strip away the marketing and a dispatch system does four things. It holds a pool of work that needs to be attended by a person at a place. It holds a picture of who is available, when, with what skills and from where. It joins the two into an assignment with a time and a commitment attached. And it keeps that joined picture current as the day goes wrong, which it will.

That is a narrower definition than most vendors use, and I keep it narrow deliberately, because dispatch gets confused with three adjacent things that belong to other systems and other disciplines. It is not work order management: the lifecycle of raising, planning, executing and closing maintenance work sits in the work order software layer, and dispatch only touches the slice of that lifecycle where a job becomes someone's next stop. It is not intake: deciding what a request even is, who owns it and how urgent it really is belongs to intake and triage, upstream of the board. And it is not route optimisation: the mathematics of sequencing stops and minimising travel is a separate, genuinely hard problem covered in field service scheduling and route optimisation. I will stay off the algorithms here and talk about the board and the humans.

The practical consequence is worth stating: you can run a very good dispatch operation with unsophisticated routing, and you cannot rescue a bad one with excellent routing. Readiness and visibility come first.

2. The dispatch board as the central artefact

Every operation that dispatches well has one board that everyone trusts. Usually it is a gantt-style view with engineers down the left and time across the top, jobs rendered as blocks. Sometimes it is a map with pins. The format matters less than the fact that it is singular: one place where the truth about today lives, updated in near real time, visible to the dispatcher, the supervisor and ideally the engineers themselves.

The failure mode is a board that is one of several competing pictures. The dispatcher has the system, the supervisor has a spreadsheet, the engineers have a WhatsApp group, and the customer service desk has a third version it reads to callers. I have walked into operations running all four simultaneously, and the effort spent reconciling them exceeded the effort spent doing the work. If you are choosing a dispatch tool, the single most useful acceptance test is whether it can become the only board, which is mostly a question of whether the mobile app is good enough that engineers actually update it. That is a topic in its own right: see mobile field service apps for technicians.

Here is what a board has to show before it is useful, which I have used as a requirements checklist in selection exercises. Vendor demos show a beautiful board with four engineers and eight jobs; the interesting question is what it shows with sixty engineers and four hundred jobs.

3. The daily rhythm: four beats that make the board work

Dispatch is not a continuous activity at uniform intensity. In every well-run operation I have observed, it has a shape, four distinct beats with different purposes, and the operations that struggle are usually the ones that have collapsed all four into a single state of permanent reaction.

• The overnight plan. Done by the dispatcher or generated by the system and reviewed by a human, late in the previous day or overnight. This is where scheduled and planned work is placed into tomorrow's capacity, geography is considered, readiness is checked and the deliberate gaps for reactive work are left open. It is the only beat with time to think, and it is the beat most often skipped when the operation is under pressure, which is precisely backwards.
• The morning release. A short window, often 07:00 to 08:00, where the plan is released to engineers, absences are absorbed, and the first corrections are made. Engineers see their day. Anything that cannot be covered because of sickness or a vehicle off the road is reassigned now, not at 11:00. A good release includes a brief supervisor check on anything unusual: a long job, a job with a permit, a difficult customer.
• Intraday re-planning. The long middle of the day, where reality attacks the plan. Jobs overrun, parts turn out to be wrong, sites deny access, emergencies arrive. This is the beat that dispatch software genuinely helps with, because the alternative is a human holding a changing sixty-row picture in their head. The discipline here is to re-plan in small deliberate moves rather than continuous reshuffling: each change you push to an engineer's device has a cost in confusion and trust.
• End-of-day recovery. The beat almost everyone neglects. Between roughly 15:00 and the end of shift, the question stops being "what else can we fit" and becomes "what is not going to happen today, who needs to be told, and where does it go tomorrow." Jobs that will not be reached must be moved and the customer informed while someone is still at their desk to take the call. Operations without this beat generate their worst customer experience: the appointment that silently never happened.

The rhythm is cultural as much as technical, but software either supports it or fights it. Ask in a demo how the tool distinguishes the overnight plan from the released plan: you need to build tomorrow without tomorrow flickering onto sixty phones as you do it.

4. What makes a job dispatchable

This is the section I would put first if the SEO gods allowed it, because it is where most of the recoverable waste in field service lives. A job being urgent does not make it dispatchable. A job being assigned does not make it dispatchable. A job is dispatchable when the engineer arriving can actually complete it, and the honest observation from implementation work is that a large share of failed first visits are jobs that were sent out knowing, or not bothering to check, that one of these conditions was unmet.

The readiness gate below is the one I would build into any dispatch configuration. It is deliberately boring. Each condition is a flag the board can show and, where the platform allows it, a hard or soft block on assignment.

Two nuances matter when you implement this. First, not every condition applies to every job type, so the gate has to be configurable by work order type. A reactive lighting fault does not need a permit gate; a switchgear intervention certainly does. The work order type taxonomy is what carries that configuration, which is one of the underrated reasons to get the taxonomy right early.

Second, the gate must not become a way to hide work. If a job sits at "awaiting access" for three weeks, holding it out of the dispatch queue has just moved the failure from a wasted visit to a neglected customer. Every held job needs an owner, an age and a review. The cleanest pattern I have seen is a visible "not ready" column on the board, sorted by age, that the coordinator works through every morning as part of the release beat.

5. Emergency insertion and the capacity you deliberately waste

A perfectly optimised day is a fragile day. Pack every engineer to 100 percent with a clean geographic sequence and the first priority-one callout at 10:40 does not cost you one job, it cascades: the inserted job displaces one stop, that stop's travel assumption breaks, the committed window on the third stop becomes unachievable, and by mid-afternoon you are apologising to four customers because of one emergency.

The mature response is not better re-optimisation. It is holding capacity on purpose. That takes a few forms, and which one fits depends on the shape of your demand:

• Reserved percentage. Leave a fixed share of each engineer's day unscheduled, filled only intraday. The level is set from your own history of reactive volume by day of week, not from a vendor benchmark. If a quarter of your work arrives same-day, planning to 95 percent utilisation is a decision to fail.
• Dedicated reactive resource. One or more engineers per district carry no planned work and exist to absorb emergencies, rotating through the team so nobody spends every week firefighting. Cleaner to manage than reserved slots and easier for engineers to understand, at the cost of visible idle time that finance will question.
• Deferrable ballast. Fill the tail of each day with low-priority, no-commitment work that can be dropped without telling anyone. The emergency displaces ballast rather than a promise. This is the trick that requires least structural change and it works well if you genuinely maintain a backlog of flexible work.
• Geographic clustering as shock absorption. Days built as tight clusters rather than long loops are more resilient, because an insertion inside a cluster costs a few minutes of travel rather than an hour. This is where dispatch discipline and routing meet, and the routing detail belongs in the optimisation pillar.

Whatever the mechanism, the conversation to have with the operations director is that some deliberate slack is the price of keeping commitments. Utilisation and reliability trade against each other, and an organisation that measures dispatchers on utilisation alone will get high utilisation and broken appointment windows. That is a KPI design problem more than a dispatch problem: see field service KPIs, SLAs and contractor management.

6. Skills, certification and the competency matrix

Skill matching is the part of dispatch that looks like a data problem and turns out to be a governance problem. The software side is simple: engineers carry skill and certification records, jobs carry required skills, the board will not offer an engineer who lacks them. Most credible platforms, from IBM Maximo and Infor EAM at the heavy end to MaintainX, Limble, Fiix and UpKeep in the lighter tier, support some version of this.

The governance side is where it fails. Certifications expire, and a dispatch system whose competency records are not maintained is worse than one with no records, because it gives false assurance. The controls I would insist on:

• Expiry dates on every certification, with the record automatically becoming invalid on expiry rather than requiring someone to notice.
• A single owner for the competency matrix, normally the HSE or training function, not the dispatcher. Dispatchers must never be able to grant themselves a skill to make an assignment fit.
• Advance warning on expiry, at ninety, sixty and thirty days, so renewal is planned into the schedule as work rather than removing an engineer from the board without notice.
• A distinction between competency and authorisation. An engineer may be technically competent on a switchboard and not be the authorised person for that site. Both need to be modelled or you will dispatch someone who cannot legally proceed.
• An audited override path, because there will be a genuine emergency where a supervisor accepts the risk. Make it possible, make it logged, make it reviewed. A system with no override gets worked around entirely.

For competence frameworks in a maintenance and inspection context, the standards bodies are the right reference point rather than vendor documentation: the ISO asset management family and the NFPA codes for life safety systems both set expectations that translate directly into dispatch-time competency rules.

7. Committed windows and the promise you are making

There is a distinction inside every dispatch system that is worth labouring, because conflating the two causes a specific and very damaging kind of failure. The internal plan is where the dispatcher intends an engineer to be. The committed window is what a customer was told. They are not the same object and they must not share a field.

When they share a field, intraday re-planning silently rewrites promises. The dispatcher moves a job from 11:00 to 15:00 for good operational reasons, the customer who arranged to be present at 11:00 is not told, and the visit fails for a reason the board records as "no access". I have seen this produce an apparent access problem that was actually a communication problem, and no amount of chasing tenants fixed it, because the cause was in the scheduling model. What good practice looks like:

• Windows are as narrow as you can actually keep, and no narrower. A reliable three-hour window beats an unreliable one-hour window in every customer satisfaction measure I have seen. Promise what your completion data supports.
• Moving a committed window is an event, not a drag-and-drop. It should require a reason code and trigger a customer notification, ideally automatically.
• Windows and SLA response targets are different clocks. An SLA says "attend within four hours"; a window says "between 13:00 and 16:00 on Tuesday". Both can be live on one job and the board must show both. The contractual side of this is in SLA matrix design.
• Measure window adherence separately from SLA compliance. Many operations report strong SLA numbers alongside a customer base that experiences them as unreliable, and the gap is nearly always window adherence that nobody measures.

8. Travel, geography and the limits of the map

Geography constrains dispatch more than anything except readiness. A dispatcher who cannot see travel time is guessing, and the guess is systematically optimistic. Two specific things are worth insisting on from the software.

The first is travel time that reflects reality rather than straight-line distance. Distance-based estimates are badly wrong in any city with real traffic patterns: a nine-kilometre hop across a bridge at 07:30 and the same hop at 14:00 are different journeys. If the platform supports drive-time matrices with time-of-day profiles, use them; if not, accept that the board is approximate and lean on local knowledge.

The second is territory structure. Most operations run better with soft geographic territories: engineers primarily work a district, cross-boundary assignment is possible but visible and slightly discouraged. Hard territories create idle engineers next to unserved work on the other side of a line. No territories create days where someone crosses the city three times. Beyond that, sequencing and travel minimisation become an optimisation problem with real mathematics behind it, deliberately left in its own article: field service scheduling and route optimisation covers solver behaviour, objective functions and where the algorithms break down.

9. Real-time status and GPS: a trust question as much as a logistics one

Live job status is the input that makes intraday re-planning possible. Without it the dispatcher is planning against a morning snapshot. Status transitions that matter are few: accepted, travelling, on site, in progress, held with a reason, complete. Six states, captured from the mobile app, mostly automatically where geofencing is reliable.

Vehicle and engineer location tracking is the more loaded topic, and I think it deserves honesty rather than the usual efficiency framing. Location data genuinely improves dispatch: it lets you assign the nearest qualified person to an emergency, verify that an attendance actually happened, and give a customer a credible arrival estimate. It also tells an employer where a person is all day, and in every rollout I have been near, that is what engineers reacted to first.

What works is being explicit rather than quiet. Say what is collected, what it is used for and what it is not used for, restrict visibility to working hours, and hold to that. Do not let location data become the evidence base for performance management unless you said so from the start, because the moment engineers believe it will be, status updates turn defensive and the data quality you depend on degrades. An operation where engineers quietly stop pressing "on site" until they are ready to be seen arriving has lost more than it gained.

10. The dispatcher is a skilled role

The good dispatchers I have worked alongside were doing something more sophisticated than slotting jobs. They held a model of the operation in their heads: which engineer is fast on chillers and slow on paperwork, which site will keep you waiting forty minutes at reception, which customer escalates immediately and which will accept tomorrow if you call them yourself, which apprentice needs to be paired with someone patient this week. None of that is in the data model, and most of it is what makes a day work.

That is the honest reason software assists rather than replaces this role. The optimiser sees the encoded constraints. The dispatcher sees the unencoded ones. Where dispatch technology has genuinely helped is by removing the clerical load, keeping the picture current, and surfacing the things a human cannot hold in memory at scale: sixty engineers, four hundred jobs, an SLA clock on each.

Two practical implications. Involve the dispatcher in configuration, because they know which constraints actually bind. And treat the role as a career position with real training, because the difference between a competent dispatcher and an excellent one, on the same software, is larger than the difference between two platforms.

11. Why fully automated dispatch is usually rejected

Most field service platforms can run in fully automatic mode: the engine assigns everything, pushes it to devices, re-optimises continuously, no human in the loop. Very few operations run that way for long, and the reasons are consistent enough to be predictive.

• The constraint set is never complete. The engine optimises what it knows. It does not know that this tenant will not admit a contractor without the building manager present, or that this asset is under a warranty claim and must be attended by the OEM. Every missing constraint produces a confidently wrong assignment.
• Continuous re-optimisation destroys engineer trust. A plan that changes four times before lunch teaches engineers to ignore the plan. They start working from their own list, the board stops reflecting reality, and the automation is now optimising a fiction. Stability has value the objective function does not capture.
• Accountability does not transfer. When an automated assignment causes a breach or a safety incident, the question is who decided. "The system" is not an answer any operations director accepts, and correctly so.
• Data quality is rarely good enough. Automation is unforgiving of wrong durations, stale skills and missing asset locations. Manual dispatch quietly absorbs bad data because the human notices. Automated dispatch propagates it.
• Judgement calls have no objective function. Deciding whether to disappoint a large contract customer or a small one, whether to push an apprentice onto a difficult job, whether to accept an overrun to finish properly, these are not optimisation problems. They are management decisions.
• Engineers are not interchangeable units. The model treats an engineer with a skill code as equivalent to any other engineer with that code. Supervisors know they are not, and an allocation that ignores this produces work that technically matches and practically does not.

The pattern that does work, and that I would recommend, is assisted dispatch. The engine proposes, ranks candidates, flags readiness failures, warns on SLA risk and handles the arithmetic. The dispatcher confirms, overrides where they have knowledge the system lacks, and owns the outcome. Then you measure the override rate, because a high and persistent override rate on a particular constraint is the system telling you exactly which piece of reality is missing from the configuration. That feedback loop is how assisted dispatch gets better over time, and it is not available at all in full automation.

The honest exception: high-volume, low-variance, short-duration work in a dense geography, such as domestic meter exchanges or routine filter swaps across a single campus, does automate well, because the constraint set genuinely is small and the jobs genuinely are interchangeable. If that describes your work, automate it. If it does not, be sceptical of anyone who tells you it describes your work. Where AI is meaningfully changing the assist layer rather than replacing the human, see AI in workforce, route and dispatch optimisation.

The idea to walk away with

Dispatch software is a visibility and discipline instrument, not an optimisation product. Its value comes from having one board that everyone trusts, a readiness gate that stops unready work reaching an engineer, a daily rhythm with a real planning beat and a real recovery beat, deliberate reserved capacity for the emergencies you know are coming, and a clear separation between the internal plan and the promise made to a customer.

Get those five right and modest software will run a good operation. Get them wrong and the best optimisation engine on the market will sequence your failed visits very efficiently.

Final thoughts

If you are selecting a dispatch or scheduling platform, my advice is to spend the evaluation on the unglamorous things. Ask how readiness is modelled and whether assignment can be blocked. Ask how the board behaves with your real engineer count and job volume, not the demo dataset. Ask how a committed window is distinguished from an internal plan, and what happens to the customer when it moves. Ask what the mobile experience looks like to an engineer on a weak signal in a basement plant room, because a board nobody updates is not a board. The selection framework is in how to choose field service management software, and the wider operating picture in the practitioner's guide to field service management.

And before you buy anything, run the readiness table in section 4 against last month's failed visits. Count how many failed because the job was never dispatchable. In most operations I have looked at, that single count makes the business case, and it also tells you that the fix starts with process rather than procurement.

Related reading: Field service scheduling and route optimisation, Field service management: a practitioner's guide, Work order software for maintenance teams, Automating work order intake and triage, Mobile field service apps for technicians, Field service KPIs, SLAs and contractor management.