Voice AI for home services: triage first, book second

In home services, a voice AI agent earns its place on the calls nobody can pick up: the plumber is under a sink, the office closed at six, or it's the first cold night of the year and the phones don't stop. On those calls the agent's first job is triage. Booking comes second.

The same opening sentence, "my heating's not working", can be a Tuesday appointment, tonight's emergency or a carbon monoxide risk. An agent built only to fill the calendar gives all three a slot on Thursday.

So build the call around four lanes: safety, emergency dispatch, routine booking, and not a new job. Decide the lane in the first few questions, then give each lane its own ending. The ending that breaks most often is the handoff to a person, so much of this playbook covers what Callaro's runtime does at that moment and where its limits are.

New to voice agents? Start with the complete guide to AI voice agents. The case for answering every call is in our 24/7 phone support playbook.

Why booking-first agents fail in the trades

Most "AI receptionist" setups are a booking flow with a greeting on top: take a name, an address and a problem, then offer a slot. That works for a dripping tap. It fails in two ways.

• False routine. A caller with water coming through the ceiling answers every question politely and accepts the first slot offered, because nobody mentioned a faster option. The damage grows by the hour, and so does the chance they ring another firm and cancel.
• A conversation where there should be none. Someone who smells gas is asked for their postcode, boiler model and preferred time window while standing in the kitchen.

Keyword routing is the usual patch. Jobber's receptionist, for example, lets you set words such as "no heat" or "burst pipe" that trigger a transfer or a text alert (Jobber). It's a fair start, but "there's a bit of water on the floor" needs a follow-up question before anyone learns it's coming through the ceiling light.

The four lanes

One set-up note first. Callaro routes an inbound call by the number dialled and the caller's history. It has no time-of-day rule. If the agent should take only after-hours and overflow calls, set that up in your phone system: forward on no answer, or on a schedule.

Lane 1: safety, the shortest call you take

A gas smell, a sounding carbon monoxide alarm, smoke, sparks, or a burning smell from wiring.

Official guidance explains why this call has to be short. Connecticut's utility regulator tells people who smell gas not to flip light switches or use a telephone near the smell, and to call the gas company from a phone away from it, leaving the building first if the smell is strong (PURA).

Carbon monoxide guidance published by the US Consumer Product Safety Commission is similar: get everyone to fresh air outdoors and call the fire department from there (NFPA and CPSC). A caller reporting a gas smell is often on the phone inside the building, and every extra question keeps them there.

• Ask the safety question first, before name or address: "Is there a smell of gas, an alarm sounding, or any smoke or sparks?"
• Use your authorities' wording. Write one instruction per hazard from your local gas network's and fire service's own guidance, with their emergency numbers. Tell the agent to use that wording and ask nothing further.
• Have the wording end the call. A Callaro agent won't hang up on a caller who hasn't closed the conversation, so the instruction itself should tell them to hang up, get out and phone the emergency line from outside.
• Offer a callback. Your engineer's visit comes after the gas company or fire service has made the property safe.

Callaro doesn't ship an emergency script. The wording is yours, and it belongs in the Guardrails section of the agent's prompt. If you run several brands or locations, put it in the workspace-wide rules applied ahead of every agent's own prompt, so no agent goes live without it.

A language model following an instruction can still drift, so audit it. Run a post-call analysis prompt with a yes-or-no answer on every call ("did the agent give any repair or handling advice about gas, wiring or an appliance?"), and have a person listen to every lane 1 call for the first few months.

Lane 2: emergency dispatch, a person now

Water that's still escaping, sewage backing up, a total loss of power, no heat in freezing weather with someone vulnerable at home. The right ending is a live conversation with whoever is on call. Four details decide whether that works.

Your system decides who's on call. Callaro's transfer tool dials only a number on the agent's allowlist, or one returned at that moment by your own routing endpoint. The endpoint receives what the agent has captured so far (trade, postcode, the issue), the caller's number and anything a pre-call lookup found, and replies with a phone number.

Your rota stays in one place, and a caller can't talk the agent into dialling a number they supply. If the endpoint fails or returns nothing, the call goes to the agent's default destination.

The runtime asks before it transfers on a shaky signal. We added a confirmation gate after reviewing calls where the model transferred on the caller's very first turn. In one, the "request" was a low-confidence transcript of a question about whether calls could be transferred at all.

Now a transfer attempted on the first turn, or on speech the recogniser scored poorly, is held while the agent asks one short yes-or-no question. Speech-to-speech models report no per-turn confidence, so only the first-turn rule applies there. The gate usually costs an emergency caller one exchange. The alternative is waking your on-call technician at 2 am for a wrong number.

Write the question yourself, so it does triage work too: "Is the water still coming in? I can connect you to our on-call plumber now, shall I?" When the agent's last sentence offered the connection and the caller says yes, the gate counts that as confirmed.

If the answer still isn't recognised after repeated attempts, the transfer goes through and an alert is logged on our side, so nobody is trapped in a loop.

Capture before you connect. Take the postcode before the transfer offer. It's one question, your routing endpoint needs it to pick the right person, and it catches an out-of-area emergency before anyone is woken.

The agent's data-capture tool saves each field in the same turn the caller gives it, so the details survive a dropped call or a failed handoff. On our full-duplex speech-to-speech path, fields are extracted from the transcript every few turns, so the endpoint may not have the latest answer yet.

The agent leaves at the handoff. It speaks your handoff line in its own voice, the platform waits for the line to finish, and the carrier dials the destination. From then on the agent is off the call. What makes the transfer warm is the data your technician receives, because the agent doesn't stay on to brief them.

The platform records that a transfer started. It doesn't know whether anyone picked up. Design for that limit:

1. Point the transfer at something that always answers: a hunt group, a rota line that rolls to a second person, or an answering service. Avoid a single mobile.
2. Subscribe your dispatch system to the transfer-started event, which carries the destination. Page the technician with the job before the phone rings.
3. Each morning, reconcile transfers started against jobs created. A transfer with no job may be a caller who reached voicemail.
4. Test transfers on your own lines, because support depends on the carrier. On a bring-your-own-telephony bridge that hasn't declared transfer support, the tool reports a failure and the agent stays on the call. Tell it what to do then: confirm the callback number and promise a call back within a time you can keep.

Lane 3: routine booking

Everything that can wait for a slot. The mechanics of safe booking (offering only slots read from the live calendar, resolving "next Friday", writing exactly once) are in our appointment scheduling playbook. Home services adds four things.

• Check the service area before the details. Once the call is routine, take the postcode and read it back character by character. Declining after one question beats declining after five.
• Confirm addresses instead of capturing them. Street names are among the hardest things for speech recognition. For existing customers, a pre-call lookup on the caller's number lets the agent ask "Is this for the house on Mill Lane?" For new ones, take postcode and house number, have your booking API resolve the street, and read it back.
• Offer arrival windows. Promise what dispatch can keep: "Thursday between eight and twelve".
• No diagnosis and no estimates. The agent can state the policies in its knowledge base, such as how a diagnostic visit is charged. It shouldn't guess what a repair will cost from a description over the phone, and your prompt should say so.

For a written confirmation, give the agent a custom tool that calls your own messaging provider, with the number bound from the call so the model never supplies it.

Lane 4: not a new job

Two groups land here. Existing-job calls (where's the technician, can we move Thursday, a complaint) need a lookup tool against your dispatch board, or a transfer to the office in opening hours. Out-of-area callers, trades you don't do, suppliers and wrong numbers need one polite sentence.

When a Callaro agent ends a call it attaches a reason code, and you can define your own codes for endings other than a completed request. Lane 4 then appears in reports under its own headings instead of looking like failed bookings.

The triage ladder

Ask in this order, and stop as soon as the lane is decided:

1. Any smell of gas, alarm sounding, smoke or sparks? Yes means lane 1.
2. Is water, sewage or power affected right now, and is it still happening or already shut off? Still happening means lane 2.
3. No heating or cooling: is anyone at home elderly, very young or unwell, and is the weather extreme? Yes means lane 2. These rules are yours to set, per trade and per season.
4. Otherwise lane 3, unless it isn't a new job at all.

Store the result as data. In Callaro that's an extraction schema: Lane and Trade as enums, Still active and Vulnerable occupant as true-or-false fields, Issue and Postcode as text. It's the typed-scorecard approach from our lead qualification playbook. The fields arrive typed in the post-call webhook, so your dispatch board can sort by lane without anyone reading a transcript.

The lane is the model's classification against your rules. Treat it as a strong signal and measure it.

What to measure

• False-routine rate. Each week, a person reviews a sample of lane 3 calls and counts the ones that should have been lane 2 or lane 1. This number matters most.
• Over-triage rate. Transfers that turned out to be routine. Each one cost your on-call technician an interruption.
• Transfer completion. Transfers started, against jobs your on-call team created.
• After-hours capture. Calls the agent answered in the hours when the line used to ring out, and how many became jobs.
• Unsupported statements. Calls where the agent estimated a repair cost or gave handling advice, flagged by an analysis prompt and confirmed by a person.

A value model, for your own figures:

Monthly value = (calls answered that used to go unanswered × share that were real job requests × share that became jobs × your average margin per job) − (agent minutes × your per-minute rate, plus telephony) − (mis-triaged calls × what one costs you).

Take the first input from your phone system's missed-call log by hour. Industry figures for how many callers never ring back are widely quoted and rarely sourced. For the per-minute side, see current pricing.

When this is the wrong tool

• You're one location on a field-service platform that already includes a receptionist. ServiceTitan's virtual agents take after-hours and overflow calls against its own capacity system, and Housecall Pro has CSR AI. Start there, because it's already wired to your dispatch board.
• You need a turnkey connector. Callaro has no native integrations with those platforms. It reaches your systems through API tools, MCP servers and webhooks, which suits a team that wants to own the triage rules and the routing endpoint, or runs several brands and languages. It doesn't suit a firm with nobody to build the other end.
• The owner's voice is the product. A two-van firm whose customers ring the owner's mobile may lose more than it gains.
• Nobody can say who's on call. If the rota lives in someone's head, fix that first.

Before you launch: six test calls

1. Report a gas smell in your second sentence. Expect your safety wording at once, and no booking questions.
2. Describe a leak without the word "emergency". Expect the "is it still happening" question, the postcode, then the transfer offer.
3. Accept the transfer, then let the on-call phone ring out. Expect a second person or an answering service, never a personal voicemail.
4. Ask for a routine service from outside your area. Expect a polite decline straight after the postcode.
5. Ask what a repair will cost. Expect your policy and no estimate.
6. Hang up mid-call. Expect the captured fields in your webhook anyway.

Judge a home-services agent first by the lane each call ended in, then by the calendar. See how Callaro works for home services.