Intake is a data-capture problem before it is an AI problem. The question worth asking is not whether software can answer the phone. It is whether the person who dispatches gets everything they need from the first contact, so the next step is a booked visit rather than three more calls to find out what the job actually is.
Answer that and the AI part becomes obvious. Skip it and you get a polite assistant that collects a name and a number, which is what your voicemail already does.
The dispatch record is the specification
Start from the other end of the process. Sit with whoever schedules the work and ask what makes a request bookable without a callback. That list is the specification for the whole system, and it is usually shorter and more specific than anyone expects.
Every trade needs the same core: the service, the address with any access constraint, urgency, whether an adult will be there, and a callback number that has been read back. Beyond that the fields diverge, and the divergence is where a generic intake tool stops being useful.
HVAC. System type and rough age, the brand on the outdoor unit label, whether it is blowing warm or nothing at all, what the thermostat reads against the setpoint, whether the unit is in an attic or a crawlspace, and whether they believe it is still under manufacturer warranty. Attic access in August is a scheduling fact, not a detail.
Plumbing. Whether water is currently running where it should not be, whether they have found the shutoff, which fixture, and whether there is visible damage to ceilings or floors. An active leak with no located shutoff is a different call from a slow drip, and the difference should be visible in the first line of the record.
Roofing. Active leak or not, storm date if there was one, whether an insurance claim is open, the number of stories, and roughly how old the roof is. Whether a claim is open changes the entire sales process, and finding out on site is expensive.
Electrical. What is tripping and how often, the panel brand and age, whether anything smells or looks burnt, and whether the work is likely to need a permit or a utility disconnect. A burning smell is not a scheduling request.
Capture the fields that change the dispatch decision. Everything else is a form nobody fills in.
Territory and capability rules are policy, not model behaviour
The rule that decides whether you serve an address, or whether you take that type of job, should live in a table the office can edit. Not in a prompt, not in a model's judgement, and not in a list somebody wrote once during setup.
Write down the served postcodes or the drive-time boundary, the border cases and what happens to them, the services you do not offer, the equipment brands you will not touch, minimum job conditions, and the licensing or permit limits that apply. Then let the system read the table.
Two reasons this matters. The rules change often, when you hire a crew, drop a manufacturer, or take on a second town, and the change has to be a five-minute edit rather than a support ticket. And when the system declines a job, you need to be able to say exactly which rule declined it. Business rules that only exist inside a model cannot be audited, and an intake system nobody can audit will eventually turn away work you wanted.
The three-line summary is the product
What the dispatcher should see is not a transcript. It is a summary they can act on in about five seconds:
- What the customer needs, in the customer's own terms.
- The facts that change the dispatch: urgency, address and access, and the one or two trade details that determine who goes and what is on the van.
- What is missing, named explicitly.
That third line is the part most implementations leave out and the part that saves the most time. "No shutoff located, no photo of the panel" tells the person calling back exactly what to ask. A summary that quietly omits what it did not learn is worse than no summary, because it looks complete.
Escalate rather than guess
Some calls should never sit in a queue. Write the list with your field staff and make it a hard rule, checked before anything else in the workflow:
- Gas smell, carbon monoxide alarm, or anything described as a burning smell.
- No heat or no cooling where somebody is elderly, an infant, or medically vulnerable, in genuinely dangerous weather.
- Water actively entering the property, or a sewage backup.
- Sparking, exposed conductors, or a panel that is hot to touch.
- Anyone who says they are unsafe, and anyone who asks for a person twice.
The last one is not a technicality. A customer who asks for a human and gets another automated question is a review you will be reading for two years.
After hours is where this pays, and where it hurts most
Overnight and weekend calls are the clearest case for automated intake, because the alternative is voicemail and voicemail loses. It is also where a mistake goes uncorrected for the longest.
Two rules. Never let the system make a commitment overnight that the morning schedule cannot honour, which means no confirmed appointment times unless it is reading a live calendar with real capacity rules in it. And route the emergency list to a phone that a person answers, every night, without exception. If you do not offer genuine emergency service, say so plainly rather than collecting the details of somebody who needs help now.
Keep the original one click away
Whatever the system captures, the person picking up the job needs the raw call recording, transcript, or form submission next to the summary. Not archived, not in another platform. Next to it.
Staff learn very quickly whether the summary can be trusted, and if they cannot check it, they will either trust it when they should not or ignore it entirely. Both outcomes waste the investment. Give them a way to correct a summary too, and make the correction go somewhere, because the corrections are the training data for how you tune the thing.
Measure fit, not speed
Response time will improve. It is the easy metric and it is not the one that tells you whether this worked.
The numbers that matter are booking quality and field fit: the share of booked jobs that were the job the record described, the truck rolls that should never have been dispatched, the second visits caused by the wrong parts or the wrong technician, and the reschedules caused by access problems nobody asked about. Track cancellations by reason. If unsuitable bookings go up while response time goes down, the system is converting your intake into a faster way of sending crews to the wrong houses.
Take those numbers before you build. Our AI readiness checklist covers what else should be true first, and the baseline question is the one people most often skip.
Start narrower than feels useful
One channel, one trade, one shift. Web forms are the easiest place to begin, because the input is already text and the stakes are lower than a live call. Prove the summary is accurate and the escalation rules fire correctly, then extend to calls, then to after hours.
That scope, one workflow with defined boundaries and a named owner, is what a focused AI implementation is meant to be. The related decisions sit in two other pieces: how to route and rank what comes in without silently discarding people, in our guide to AI lead qualification, and what to do with the calls nobody picks up, in missed-call text-back automation.
FAQs
Does intake AI replace the dispatcher?
No. It prepares information and can reduce delay, but the dispatcher or owner remains responsible for decisions.
Can it handle after-hours calls?
It can acknowledge, collect details, and route, but high-risk or urgent cases need clear escalation.
What should be measured?
Measure speed, booking quality, unsuitable bookings, cancellations, and staff handling time.