Dispatch software assigns work to technicians based on time, skill, and location. Most service companies own it and do not use it, because the rules that actually govern assignment were never written down. The software is not the failure. It is the visible edge of an undocumented process.
The workaround is the diagnosis
A dispatch board nobody trusts produces a specific pattern that is easy to recognize.
The board shows one schedule. The office runs a different one by phone. Technicians learn to call in rather than read the app, because the app has been wrong before. Changes propagate verbally, and by mid-morning, the system and reality have diverged permanently.
That is not a software problem in any useful sense. It is a rules problem wearing a software costume. The person doing dispatch holds the criteria in their head: which technician suits which job, who works well in which neighborhood, and which customer needs the experienced hand. None of that is in the system, so the system cannot produce an assignment anyone believes.
The trade is stable, and the demand is real. The Bureau of Labor Statistics counted 504,500 plumber, pipefitter, and steamfitter jobs in 2024 and projects 4 percent growth through 2034. The constraint in most shops is not enough work available. It is hours converted into billable work.
Drive time is the highest hidden cost
Every unbilled minute between jobs is paid labor producing nothing.
A technician doing five calls a day with poor sequencing can spend well over an hour driving. Better clustering removes most of it. Multiply by a crew and by a year, and it becomes a headcount, invisible because it never appears as a line item anywhere.
Drive time is also the cost most sensitive to the thing the dispatch software is supposed to do. Geographic clustering, sensible sequencing, and realistic job durations are exactly what an assignment engine handles well, provided someone told it the truth about how long work takes.
Most shops have never measured actual job duration by type. The system holds an estimate somebody entered once, the estimate is wrong, and every schedule built on it fails by mid-afternoon.
A worked example, run through a real tool
The company described below is fictional. It was invented for this article and run through two free assessment tools to show what the output looks like. No real client, company, or person is described. The figures are tool output on invented inputs, not market data or benchmarks.
The simulated profile is a residential plumbing and drain service company. Revenue between one and three million, six to fifteen staff, five to ten years in business, owner working fifty to sixty hours a week.
The weaknesses described are a business without operating discipline, rather than one without capability: revenue restarting each January, no maintenance plans, and a customer list never segmented.
What the assessment returned
The briefing benchmarks the profile against general SMB averages and top quartile performers. The page states the caveat: these are directional indicators rather than absolute standards.
Execution to Ambition Ratio: 0.76. Capacity roughly matches ambition, with a thin margin. Founder Dependency Index: 3.2 out of 10, moderate. Organizational Readiness: 54 out of 100.
Delegation is adequate here. The profile lacks a written process. Dispatch is where the missing process becomes most visible, because it fails publicly every day in front of customers.
Writing the assignment rules down
The work that makes dispatch software function is not configuration. It is documentation of decisions already being made.
Which job types require which skill level? What travel radius is acceptable for which job value? How emergency work displaces scheduled work, and what happens to the displaced job. Which customers have a named technician and why? What buffer sits between jobs by job type?
Each of those is a rule the dispatcher already applies. Writing them down does two things at once. It lets the software produce assignments that match what a human would have chosen, and it makes dispatch a role that a second person can perform.
The second is the larger prize. A shop where only one person can dispatch has a single point of failure at the center of daily operations.
Contractors working through operational documentation should start with ten strategies to streamline operations.
Does your board match what is actually happening? Sales Roadmaps writes the dispatch rules so the system and reality agree. Start with the operations roadmap.
First time fix rate changes the schedule
The metric that most affects dispatch is the one least often measured.
A job that requires a return visit consumes two slots, two drive times, and a customer conversation nobody wants. A shop with a low first-time fix rate is not simply less efficient. It is running a schedule in which a predictable share of the work booked today will reappear next week without generating new revenue.
The causes are usually parts availability, incomplete diagnostic information at booking, or a skill mismatch in the assignment. All three are dispatch-adjacent and fixable with information the shop already has.
Measuring it is straightforward. Any job at the same address for the same complaint within thirty days is a repeat. Track the rate by technician and by job type, and the pattern names its own cause.
Technician utilization, honestly defined
Utilization is frequently defined in a way that flatters the shop.
Hours on site divided by hours paid is the honest version. Excluding drive time, excluding shop time, excluding the morning meeting. That number is always lower than owners expect, and it is the only version that tells you whether adding a technician is warranted.
The useful comparison is not against an industry figure. It is against the same shop from last quarter. Utilization is moving up while revenue holds, indicating the schedule has improved. Revenue is up while utilization stays flat, meaning the shop grew by adding hours rather than using them more efficiently.
Capacity is a scheduling question before it is a hiring one
The decision most service owners get wrong is when to add a technician.
The instinct is to hire when the board looks full. But a full board built on wrong job durations, poor clustering, and a repeat-visit rate nobody measures is not evidence of capacity exhaustion. It is evidence of a schedule that wastes the capacity already paid for.
Fix the sequencing and the durations first, then look again. Shops routinely recover a meaningful share of the existing crew’s technicians. That is cheaper and faster than recruiting into a market where skilled trades are hard to find.
The order matters financially. A technician added to a broken schedule inherits the same inefficiency and increases the total cost.
What the office should see every morning
A functioning dispatch operation produces three numbers before the first van leaves.
Jobs booked against capacity for the day, so the office knows whether it is selling into a full board or an empty one. The completion rate from yesterday was so low that incomplete work was rescheduled deliberately rather than discovered. And any repeat visits scheduled today, flagged as repeats, so somebody looks at why.
None of that requires reporting infrastructure. It requires the board to be trusted enough that reading it tells you the truth, which returns to the same point. The rules have to be written down before the data means anything.
The sixty-second version
The same situation was typed, in plain language, into a second free tool that returns a written diagnosis rather than scores.
It is named “reactive operations masked by tools that exist but are not used,” and it describes the dispatch system sitting idle while the office runs manual workarounds.
Masked is the precise word. Owning the software creates a reasonable belief that the scheduling problem has been addressed, which delays the discovery that it has not.
Where new software is not the answer
If the current system is unused because the rules were never written, then buying a different system will reproduce the outcome at a higher cost. The tell is that nobody can state the assignment criteria out loud.
If the shop is short of work rather than short of schedule quality, better dispatch optimizes an empty board, and demand generation is the priority.
Both tools used here are free. The written one is at businessconsultant.services, and the scored briefing is at vwcg.app. Growth sequencing sits in how to grow an HVAC company.
The short version
Dispatch software fails when the assignment rules reside in one person’s memory. The board and reality diverge, technicians stop reading it, and the office runs a phone-based schedule alongside the system.
Write the rules, measure the actual job duration, track the first-time fix rate, and track honest utilization. Then the software has something true to work with, and dispatch becomes a role rather than a person.
Buying new software before fixing the rules? Sales Roadmaps documents the process first. Book a working session.
Frequently Asked Questions
Why does dispatch software go unused?
Because the assignment rules were never documented. The dispatcher holds criteria about skill, geography, and customer preference in memory, so the system cannot reproduce a decision anyone trusts. Technicians then rely on phone calls, and the board drifts from reality.
How much does drive time cost a service business?
Every unbilled minute between jobs is paid labor producing nothing. Poor sequencing can add well over an hour per technician per day. Across a crew and a year that amounts to a headcount which never appears as a line item on any report.
What rules does dispatch need documented?
Skill requirements by job type, acceptable travel radius by job value, and buffer time between jobs. It also covers how emergency work displaces scheduled work, what happens to the displaced job, and which customers expect a named technician.
How is the first-time fix rate measured?
Any job at the same address for the same complaint within thirty days counts as a repeat. Tracked by technician and by job type, the pattern usually points to parts availability, incomplete booking information, or a skill mismatch in assignment.
How should technician utilization be defined?
Hours on site divided by hours paid, excluding drive time, shop time, and meetings. That figure is always lower than owners expect and is the only version that indicates whether adding a technician is justified.
Will new dispatch software fix scheduling?
Not if the existing system is unused because rules were never written. A replacement reproduces the same outcome at a higher cost. The diagnostic test is whether anyone can state the assignment criteria out loud.
