Field Service Dispatch Board: We Couldn't Find a Dispatch Tool That Fit, So I Built One on Top of Our CRM
When a customer calls with a broken appliance or a leaking pipe, how fast your dispatcher can say "someone can be there today between 2 and 4" decides whether you get the job or a competitor does. This post shows how a repair company built a dispatch board on top of the CRM it already used, so the dispatcher sees one recommended technician and one arrival window with a reason, based on how long jobs really take. It also covers what went wrong along the way, which is useful if you are choosing or building any scheduling tool.
A customer calls an appliance repair company. The fridge is warm, the food is going bad, and the dispatcher has about thirty seconds to answer one question: who can come, and when?
On paper that is a calendar question. In practice it is a geography question, a workload question and a sales question at the same time. Which technician is already working near this address? Who has a gap that day? How long will the job before it really run? And how do you say the answer so the customer books now instead of "calling back later", which in this business usually means calling a competitor?
This post is about the tool I built to answer that question for a multi-location appliance repair company with a team of field technicians across several metros. It is not a product pitch. It is an account of why we ended up building instead of buying, what the tool does, where it went wrong while I was building it, and how it was checked before a dispatcher ever used it.
Why did we need a dispatch tool at all?
The request came from the owner, and it was specific. When a customer calls, the dispatcher should see the nearest technician by location and the nearest free window, presented as a recommendation rather than a grid to study: a suggestion to read out loud and sell, such as "I can have someone there today between 2 and 4." Earlier is better. If the customer insists on their own time, the customer's time wins.
The dispatchers added their own requirements once they heard about it. When a technician is on vacation, his area should not go dark: someone from a neighboring ZIP should show up as an option. And they had a complaint that turned out to matter more than anyone expected: too many jobs were being stacked into the evening.
The company already ran everything through Housecall Pro: jobs, schedules, technicians, invoices. Nobody wanted a second system to keep in sync, and nobody wanted to migrate.
What did we look for, and why didn't anything on the market fit?
We wrote down what the tool had to do before looking at anything:
- Recommend, don't display. One technician, one day, one arrival window, earliest first. A calendar view leaves the thinking to the dispatcher, and the thinking is exactly what takes the thirty seconds.
- Explain the recommendation. "After his 10 AM job three miles away, about eleven minutes of driving." A dispatcher who can explain a window can sell it.
- Work on top of the existing CRM, read-only. No migration, no double entry, nothing that can break the live schedule.
- Use real drive times between real addresses, not straight-line distance.
- Fall back to neighboring areas when the usual technician is off or fully booked.
- Plan on how long jobs actually take, not on the length of the slot in the calendar.
Some of the tools we looked at came close. None did all six, and the ones that came closest assumed you would move your scheduling into them. For a company that already has years of jobs, customers and invoices in one CRM, that is not a small ask.
The sixth point is the one I want to spend time on, because it is the reason the board works and the thing I have not seen discussed anywhere.
How long does a repair job really take?
The calendar in this company books a job as a two-hour slot. The customer is promised a three-hour arrival window. Both numbers are reasonable, but neither describes what happens.
I pulled every completed job with timestamps and measured the time from the start of the arrival window to the moment the job was closed. Across 3,255 completed jobs:
| Minutes from window start to job closed | |
|---|---|
| 25th percentile (a quarter of jobs closed faster than this) | 74 |
| Median (half of jobs closed faster than this) | 126 |
| 75th percentile | 195 |
| 90th percentile | 302 |
Fewer than half the jobs (48%) were closed within two hours of their window opening, and 71% within three hours.
That one table changes how a recommendation has to be built. A scheduling tool that trusts the two-hour slot will happily offer the 2 to 4 PM window right after a job that starts at noon, and a large share of the time that window is already lost before the customer hangs up. The board instead treats each job as blocking the technician for its real median duration, and marks any window that starts too close behind a previous job as risky, in yellow, so the dispatcher knows to offer it carefully or not at all.
The evening complaint made sense after that. Jobs were being stacked into late windows on the assumption that earlier jobs would finish on time. A snapshot of the live schedule showed the same pattern from the other side: pairs of jobs booked into overlapping windows for the same technician, in different towns.
What does the dispatch board actually do?
The dispatcher types the customer's address, and optionally the day and hours the customer prefers. The board returns:
- One recommendation at the top, in plain words: technician, day, two-hour arrival window, and why. "Suggest this to the customer" is literally the label.
- Alternatives as small chips underneath, in case the customer says no.
- A grid of every technician for the next six days, each free window colored by what it costs: green if it adds fifteen minutes of driving or less, yellow if it adds more or the technician is already near his usual daily load, red for a long detour or a tight arrival.
- A "2nd visit" mark when the technician already has a job nearby in the same window, so the dispatcher knows this customer would be seen after that one.
Under the hood it pulls the schedule, the technicians and their time off from the CRM's API (its direct data connection for other software) every two minutes, geocodes the address (turns it into map coordinates), and computes real road drive times between consecutive jobs. It never writes back. Booking still happens in the CRM, the same way as before. The board only suggests.
If the usual technician for a ZIP has no window, or his earliest window is more than a day away, or there is nothing on the day the customer asked for, the board brings in technicians whose home areas are within 40 miles. A technician from the coverage table wins a tie, so the dispatcher's existing assignments are respected.
What went wrong while building it?
Most of what I learned came from mistakes, so here they are.
The board offered windows that did not exist. The technicians' working hours came from an old spreadsheet that said 8 AM to 8 PM for most of them. The dispatch lead corrected it: everyone works 8 to 6. For days, the board had been offering 6 to 8 PM windows nobody could fill. After cutting the hours, a replay showed 28 recommendations changing, almost all of them from a non-existent evening window to a real one, usually earlier in the day.
My first fix for job duration changed nothing. I set the job length to 75 minutes and the output was identical. The reason: 409 of 417 jobs in the window already had calendar slots of two hours or more, so "the later of slot end or start plus 75 minutes" was always just the slot end. I only caught it because I compared the board's output before and after the change instead of trusting that a code change means a behavior change. The real fix was the measured 126-minute median from the table above.
A job at 10 PM inflated the cost of a window at noon. The board was treating a late-evening job as the technician's "next stop" and adding that drive to the price of an afternoon window. Anything more than three hours after a window is now treated as the technician going home first.
An empty schedule looks like everyone is free. Right after a deploy, before the first pull from the CRM finished, the board briefly had no schedule loaded, and a schedule with no jobs reads as a fleet of idle technicians. It now refuses to answer until the schedule is loaded, and says so, instead of recommending a window that does not exist.
Days off hide in old records. The CRM's events endpoint (the address the board asks for calendar events) has no date filter. A recurring day off is a single record created once, sometimes a year ago, and it sits hundreds of records deep. A tool that reads only the most recent events never sees it. The board pages through every event on each refresh and expands recurring ones.
None of these were exotic. Every one of them would have produced a wrong recommendation that looked perfectly reasonable on screen, which is the dangerous kind of wrong.
How was it checked before dispatchers used it?
Before anyone used it, I replayed two days of real bookings: 77 jobs where the dispatcher had already chosen a technician and a time. For each one I took the job out of the schedule, pretended the dispatcher was booking it the morning before, and asked the board what it would recommend.
- It produced a recommendation for 75 of the 77.
- It picked the same technician as the dispatcher in 58 cases.
- It offered the same day or an earlier one in 69.
Agreement with the dispatcher is not the goal in itself, because dispatchers know things the board doesn't. But a tool that disagrees with experienced people most of the time is either broken or ignoring something real, and you want to know which before you put it in front of them. Where it disagreed, I read the cases one by one.
What makes it different from a scheduling calendar?
Being honest about it: no single feature here is new. Route optimization exists, and so do dispatch calendars and CRM integrations. What is different is the combination, and the fact that each piece is set from this company's own data rather than defaults:
- It answers the dispatcher's question, not a planner's. One window to say out loud, with a reason, instead of a board to interpret during a live call.
- Job durations come from the company's own completed jobs, and they are re-measured, not assumed.
- It sits on top of the CRM the team already lives in. Nothing to migrate, nothing to keep in sync, nothing it can break.
- Every change is replayed against real bookings before it ships. That habit caught more bugs than any test I wrote.
The same approach is behind the rest of the operational tooling I build: call analysis on recorded calls, lead attribution that reaches the invoice, and a paid-lead dispute pipeline. They are listed with their numbers on AI automation.
What comes next: who notices when a technician is running late?
Once the board was in use, the next gap was obvious. It helps the dispatcher book a job. It does nothing once the technician is on the road.
The CRM has two buttons that could tell you where a job stands. Over three weeks of jobs, technicians pressed "On my way" on 68% of them. They pressed "Start" on 2 jobs out of 569. So the only live signal is missing on a third of jobs, and the other one effectively doesn't exist.
The obvious fix is an alert: the window ended fifteen minutes ago, nobody pressed "On my way", the job isn't closed, so alert the dispatcher. I replayed that rule over twenty days before building it. It fired 9 times a day at the median. Of 187 alerts, 102 were jobs that had been done perfectly well; the technician simply never tapped the button. An alert that is wrong more than half the time gets muted within a week.
So the next tool asks the technician first. When a window ends with no sign of life, a bot messages the technician in Telegram with five buttons: on my way in 30, on my way in 60, on site, already done, can't make it. "Done" and "on site" never reach the dispatcher. "Running late", "can't make it" and fifteen minutes of silence do, together with the customer's address and phone number, so the customer hears about a delay from the company instead of discovering it.
Replayed over the same three weeks, roughly half the questions would have been closed by the technician with a single tap. It is built and goes into a shadow week first (a trial run where it works in the background without affecting anyone), where it reports only to me, before any technician sees a message. I will write up what the shadow week shows.
What to do with this
Before you buy or build any scheduling tool, measure how long your jobs actually take from the start of the arrival window to the job being closed, using the completed jobs already in your CRM. If the real median is longer than the slot your calendar books, your evening windows are probably being overbooked, which is the complaint this company's dispatchers had. Look for a tool that works on top of the CRM you already use, recommends one window with a reason, and can be tested against past bookings before anyone relies on it. If you want this kind of tool built on your own systems, see AI automation, with prices on the pricing page.
I build operational tooling for service businesses on top of the systems they already run: dispatch, call analysis, lead attribution, paid-lead disputes. Scope and prices are public on pricing. If your dispatchers are answering "who can come and when" from memory, let's talk.
Related:
- Conversation Intelligence for Home Services: What to Build Before You Buy a Platform
- The Website Produced 75 Real Leads Last Month. The CRM Knew Where Three of Them Came From.
- I Stopped Chasing Startup Ideas and Started Collecting Business Pains
- n8n Postgres Disk Full at 3 AM: How an AI Phone Bot Went Down and the Retention Settings That Prevent It