Your dispatcher is already a model
In most service businesses — heating and cooling, plumbing, electrical, elevators, medical equipment, commercial kitchen repair, fire protection — the schedule is produced by one person with a phone, a board and fifteen years of memory. When an owner says the business has outgrown that, they are usually right. What they get wrong is what to replace it with, because the mental model in that dispatcher's head is doing something much more interesting than minimizing miles.
Sit next to them for two days and write down every reason they gave for an assignment. The list will look something like this. Who has the part on the van. Who this customer asked for by name. Who is licensed for this equipment. Who can be pulled off a low-stakes job if the emergency call comes in at two. Who should not be sent back to that address after last month. Who needs the hours. Who will actually diagnose it rather than replacing a board and hoping.
That is a constraint problem with about nine terms in it, and only one of them is distance. A tool that solves for distance alone will produce a schedule that looks efficient and generates callbacks, and the dispatcher will start overriding it by Wednesday. Once they override it consistently, the system is decoration and the real schedule is back in a text thread.
You are probably here because
- Your dispatcher is the only person who can run a day and they want a vacation
- Too many jobs need a second visit and nobody tracks how many
- You bought a system last year and the crew still runs the day by text message
- You cannot answer how many hours your technicians spend driving
The first three are the same problem: the software was aimed at the wrong objective and the people routed around it.
Split the board: planned work and demand work
These are two different businesses that share a payroll, and trying to schedule them with one method is why most implementations disappoint.
Planned work is maintenance agreements, quarterly inspections, filter changes, annual certifications. It is known weeks ahead, geographically clusterable, and duration is predictable within twenty minutes. This is where routing optimization genuinely earns money. Building tight geographic routes for maintenance visits can take a real bite out of drive time, often in the range of ten to twenty percent, and drive time in a metro service business commonly consumes a quarter to a third of a paid day.
Demand work is what came in this morning. It has unknown duration, a customer waiting, and it preempts. Optimization contributes almost nothing here, because by the time you have solved the route the inputs have changed. What helps demand work is different: knowing who is genuinely free right now, what is on each van, and who is qualified.
Run planned work as routes built ahead and defended, and hold back capacity for demand. How much you hold back is the real decision, and it is an economic one: the cost of an idle technician against the cost of telling a maintenance customer with a broken unit that you can come Thursday.
First-time fix is the metric that pays
If you measure one thing, measure the fraction of jobs closed on the first visit. Rates in the seventy to eighty-five percent band are common depending on trade and equipment mix, and each point is a truck roll you did not have to make.
A second visit is not half a job. It is a full drive each way, a full setup, a customer who now has an opinion about you, a scheduling slot taken from new revenue, and in a maintenance agreement it is usually unbillable. Costed honestly, a return visit in a metro area lands somewhere between one hundred and fifty and four hundred dollars before anyone touches a tool.
Then look at why. Almost every failure to fix on the first visit falls into four buckets: the part was not on the van, the technician was not qualified for that equipment, the diagnosis was wrong, or the site was not accessible. Those are four different fixes — inventory, assignment, training, and the booking script — and only two of them are dispatch problems. Track the reason on the job or you will keep buying scheduling software to solve a parts problem.
Truck stock sets the ceiling on dispatch quality
Dispatch can only be as good as what is on the vehicle. A service van typically carries several hundred distinct items, and which ones are on it is the difference between a two-hour job and a two-visit job.
The useful analysis is unglamorous and pays quickly: take a year of work orders, list the parts consumed by equipment type, and find the ones that were needed but absent. There is nearly always a short list of ten to thirty items behind a large share of return visits, and stocking those is cheaper than any software you are considering.
Once you know what is on each van, the dispatch rule writes itself and it is worth more than a routing engine: prefer the qualified technician who has the likely part, even at more drive time. That single rule, applied consistently, moves first-time fix more than most system migrations do.
Arrival windows are a promise with a price
Customers hate four-hour windows and every competitor advertising two-hour windows knows it. Before you narrow yours, measure what you hit today.
The arithmetic is unforgiving. A four-hour window absorbs one job running long. A two-hour window absorbs almost nothing, so a single difficult diagnosis at nine in the morning cascades through the day. If you are at eighty percent on-time in a four-hour window you will not be at eighty percent in a two-hour one, until you either add capacity or cut jobs per technician per day.
The cheaper win is usually communication rather than compression. An automated message when the technician leaves the previous job, with an honest updated time, changes the customer's experience far more than the nominal width of the window — and it costs one integration rather than a restructured schedule.
| Capability | Packaged field-service systems | Where custom work is warranted |
|---|---|---|
| Work orders, scheduling, invoicing | Mature and inexpensive. Buy it | Essentially never |
| Route optimization | Good for planned routes, weaker under preemption | Only with unusual constraints such as crew pairing or permit windows |
| Contract terms and response clocks | Often shallow. One response time per customer, not per asset | Frequently. Penalty clauses and per-asset clocks are where packages break |
| Parts and truck stock | Basic counts, weak forecasting | Yes — replenishment models and part-to-symptom prediction |
| Accounting and payroll integration | Standard connectors, shallow mappings | Common. Job costing that matches your chart of accounts |
| Reporting across the whole business | Fixed reports, limited exports | Yes. A warehouse over the package answers questions it will not |
Buy the system. Build the edges
We build software and this is still the advice: do not build a field-service management system from scratch. The category is mature, the packages are inexpensive per technician per month, and rebuilding work orders and invoicing costs six figures to arrive somewhere behind where you started.
What is worth building sits at the edges, and it is where the money in a service business actually lives. A parts forecasting model that decides van replenishment. A contract engine that tracks per-asset response commitments and tells you which agreements are unprofitable. Job costing that reconciles labour, parts and subcontractors against your own accounts rather than the package's opinion of them. A reporting layer over the package's data so you can ask a question the vendor did not anticipate. Those are weeks of work, they integrate with what you bought, and they do not need to be replaced when you switch vendors.
What actually moves the numbers — our ranking
Our ordering by effect on first-time fix and revenue per truck. Judgement from service businesses we have worked with, not a survey.
Offline is not an edge case
Technicians work in basements, crawl spaces, mechanical rooms, elevator shafts, walk-in freezers and rural properties. Any application that needs a connection to close a job will be worked around, and the workaround is paper, and the paper reaches the office three days later with a coffee ring on it.
The requirement is that the whole job can be completed with no signal — notes, photos, parts used, signature, time stamps — and syncs when the van reaches the road. That is real engineering, not a checkbox: conflict rules when the office edited the same job, queued photo uploads that survive the app being killed, and clock times recorded on the device rather than at sync. If you are evaluating packages, test this in an actual basement rather than in airplane mode in a conference room.
The senior technician decides whether this survives
The person with twenty-two years and the best first-time fix rate in the company is both your biggest adoption risk and the source of everything the system needs to know. Bring them in during selection, pay them for the time, and let them break the workflow before it ships.
Two practical rules. Time spent in the app per job has to stay in the range of three to five minutes, or it gets skipped and the data quietly dies. And be straight with the crew about vehicle tracking from the first conversation. Every technician assumes it is there anyway; the resentment comes from finding out sideways, and a rollout that starts with a surprise about surveillance never fully recovers.
The first hot day is a capacity event, not a scheduling problem
Cooling businesses see call volume multiply on the first stretch of high temperatures, and heating businesses on the first hard freeze. No dispatch system creates technicians. What software can do is put the surge in your hands earlier — triage rules that separate no-cooling from noisy-fan, a maintenance-agreement priority that you actually honour, and a call-back list built the week before from equipment you already know is marginal. Decide the triage rules in April, not on the day.
When the whiteboard is still right
Under roughly six technicians with one dispatcher who knows everybody, a board and a group text will outperform a system, and every hour spent implementing one is an hour not spent selling maintenance agreements. That is a real answer, and we give it regularly.
The tipping points are concrete: a second location or a second dispatcher, so the schedule has to exist somewhere other than in one head. More than eight to fifteen technicians, where nobody can hold the board any more. Maintenance agreements with response commitments you can be held to. Or the moment you cannot answer how many jobs needed a second visit last month, because at that point you are running the business on impressions.
What we get called in to fix
- A routing engine optimizing drive time while the dispatcher overrides it every morning
- Planned and demand work on one board, so emergencies destroy the maintenance routes
- No callback reason recorded, so a parts problem gets treated as a scheduling problem
- Narrower arrival windows promised without measuring on-time performance first
- An application that requires signal, and a crew that has gone back to paper
- Vehicle tracking introduced without telling anyone, and a rollout that never recovered
- Response clocks tracked per customer when the contract sets them per asset
- Job costing that never reconciles to the accounting system, so profit per job is a guess
A rollout that does not get rejected
Eight weeks, in the order that matters
Step three is the one everyone wants to skip, and it is the one that pays for the project. It also changes what you need from the software, which is why it comes before selection rather than after.
Before you sign with a vendor
- You have written down the dispatcher's real assignment rules
- Baseline first-time fix and callback reasons are measured, not estimated
- Planned work and demand work are scheduled by different methods
- Offline job completion was tested in an actual building, not in airplane mode
- Time in the app per job is under five minutes for a real technician
- Response commitments can be tracked per asset, not just per customer
- Two technicians and the dispatcher sat in the selection
- You can export your own data, in full, without the vendor's help
- Vehicle tracking was discussed with the crew before it was configured
Bottom line
Dispatch is a constraint problem in which distance is one term and usually not the important one. Buy the packaged system for work orders and invoicing, split planned work from demand work, fix the vans before you fix the schedule, and spend your custom-build money on parts forecasting, contract terms and job costing — the places where every package is thin and where your margin actually sits. Then measure first-time fix and the reason for every second visit, because that one pair of numbers will tell you more about the business than any dashboard the vendor ships.
Frequently asked questions
Usually somewhere between eight and fifteen technicians, or earlier if there is a second location or a second dispatcher. Below about six technicians with one dispatcher who knows the crew, a whiteboard and a group text genuinely work, and implementing a system costs more attention than it returns.
On planned maintenance routes, yes — clustering visits geographically can take a meaningful bite out of drive time, often in the ten to twenty percent range, and drive time is commonly a quarter to a third of a paid day. On same-day demand work with emergencies preempting, it contributes very little, because the inputs change faster than the solution.
Almost certainly not. Work orders, scheduling and invoicing are a mature and cheap category, and rebuilding them costs six figures to land behind where you started. Build at the edges instead: parts forecasting, contract and response-clock logic, job costing that matches your accounts, and reporting over the package's data.
In our experience it is one of three things: the tool optimized something the dispatcher does not optimize, so they overrode it; it needed connectivity in places the work happens; or it took too long per job and technicians stopped entering data. All three end the same way, with the real schedule back in a text thread.
Record why every second visit happened, then act on the reason. The four causes are a missing part, a mismatched qualification, a wrong diagnosis and no site access, and they belong to inventory, assignment, training and the booking script respectively. Most businesses find a short list of ten to thirty parts responsible for a large share of return visits, and stocking those is cheaper than any software.