The situation
A family-owned HVAC business covering a three-county service area had expanded to 28 technicians and built a reasonably profitable maintenance agreement book representing about 40% of annual revenue. The other 60% came from break-fix work, about two-thirds of which arrived in roughly a ten-week window each summer.
Their problem was entirely a dispatch problem. During a heat wave, the phones rang faster than the three-person dispatch team could triage. Dispatchers were asked to simultaneously judge severity ('is this an immediate safety issue or a 48-hour wait?'), assign the right technician (based on territory, current location, and whether the job likely needed the refrigerant-certified tech or the general), and honor maintenance agreement priority without alienating non-agreement callers.
In practice, what happened during a heat wave was that calls queued, some callers gave up and called a competitor, dispatch made rushed assignments that caused technicians to drive past each other in opposite directions, and maintenance agreement holders occasionally waited longer than non-agreement holders because no one noticed the tag on the inbound. The owner could see revenue walking out the door during the best-margin weeks of his year, and there was nothing he could do fast enough in real time.
What we did
On the Nano-Pilot, we shadowed two 8-hour dispatch shifts during a late-May warm stretch. We counted call volume, categorized each inbound by what decision the dispatcher had to make, and timed how long each decision took. The bottleneck was not call volume in absolute terms. It was a specific cluster of decisions, severity classification plus territory match, that took 45-90 seconds on average and could not be made in parallel.
The Implementation Sprint built a triage assistant that sat between the inbound and the dispatcher. It listened to the call (with a clear notice to the caller), pulled the customer record, identified maintenance agreement status and equipment history, proposed a severity classification and a suggested technician, and displayed all of this on the dispatcher's screen by the time the greeting finished. The dispatcher made the final call; the assistant just prepared the decision.
We deliberately did not build an autonomous scheduler. Two reasons: the dispatchers caught real edge cases the system would have missed, and the owner wanted a human voice on every emergency call regardless. The AI removed the lookup and preparation overhead; the humans kept the judgment.
What it was worth
First full cooling season after launch, the company captured 37% more same-day emergency jobs than the prior season, measured call-for-call, not revenue-for-revenue, because the price per call varied. Revenue during the peak ten-week window was up 29% year over year after controlling for a modest price increase. Dispatcher overtime during peak weeks went down 40% because they were no longer making decisions under panic conditions.
More importantly, maintenance agreement holders stopped occasionally getting deprioritized. The assistant tagged agreement status prominently on the dispatcher's screen and the dispatch team reported it became nearly impossible to miss. Agreement renewal rate for the following year went up 6 percentage points, which the owner credited largely to the reduction in 'why did I wait so long?' calls from holders.
The total build ran 11 weeks including the Nano-Pilot. The cost paid back in the first three weeks of the first real heat wave after launch.
What we'd tell another business in this industry
- Do not replace the dispatcher. The judgment calls that matter, reading caller tone, spotting a neighbor-wants-a-favor call, flagging the customer who has threatened a Yelp review, are not automatable. Reduce their overhead instead.
- Identify the actual bottleneck. Call volume was not the bottleneck. A specific decision type was. Seeing that required shadowing in a real heat wave, not a spreadsheet analysis.
- For seasonal businesses, launch outside the season. We went live in early June after a May ramp, which meant the team was trained and the system debugged before the first serious heat wave. Launching into a crisis would have failed.