← Reference builds

The phone that stopped going to voicemail

An AI voice agent answering overflow and after-hours calls, qualifying the job, and booking straight into the dispatch calendar — with a warm transfer to a human the moment anything is ambiguous.

Home services · HVAC and plumbing · 6 locations, 38 techs/7 weeks/Levelbrook reference build

About these write-ups. These are Levelbrook reference builds — the architecture, guardrails, failure modes and economics of the systems we build, documented as complete engagements. Client names are withheld and the figures are modelled from the operating assumptions stated in each build, not lifted from a named customer’s books. The two live demos are real and run in your browser: the approval queue and the call agent.

The situation

Six-location residential HVAC and plumbing company, 38 field technicians, three people answering phones during business hours and an answering service after 6pm. Inbound call volume averaged 310 a day, spiking above 500 on the first cold snap of the season and after any significant storm.

The owner's actual complaint was not about AI at all. It was this: the answering service took messages, those messages arrived as emails the next morning, and by the time someone called back, roughly half those callers had already booked with a competitor. He described paying a monthly fee for a service whose main product was a record of the business he had lost.

Measured over four weeks before we started anything:

MeasureBaseline
Calls offered, per day310
Answered live by staff62%
Abandoned in queue > 45s17%
To answering service / voicemail21%
Voicemails returned within 4 business hours54%
Callback-to-booking conversion31%
Live-answer-to-booking conversion58%

That table is the whole business case. The company converted live-answered calls nearly twice as well as returned ones, and it was failing to answer roughly 118 calls a day.

What got built

Where the agent sits in the call flow

We did not replace the humans on the phone, and we were explicit that we would not. The agent takes: overflow after 20 seconds of ringing, every call between 6pm and 7am, weekends, and all calls when the queue depth exceeds three. During business hours a caller who reaches a human never knows the system exists.

inbound
  ├─ business hours, agent free ......... human (unchanged)
  ├─ ringing > 20s or queue > 3 ......... AI agent
  ├─ 18:00–07:00, weekends, holidays .... AI agent
  └─ caller says "person" / distress .... warm transfer to on-call

The conversation, and what it is actually doing

The agent's job is not to be pleasant. It is to get to a booked appointment with enough structured detail that a dispatcher does not have to call back. It captures, in roughly this order: emergency triage, service type, property address and access notes, equipment detail where relevant, whether the caller is an existing customer, and the appointment window.

Three design decisions did most of the work:

  • Emergency triage happens in the first turn, before anything else. No gas smell, no active flooding, no CO alarm — those transfer immediately to the on-call technician with no further questions. Getting this wrong once would end the engagement, so it is the first thing the agent evaluates and it is deliberately over-sensitive.
  • The agent reads the real calendar and offers real slots. It checks technician skill, current route geography and the actual open capacity in the dispatch system, then offers two windows. Offering times that dispatch later has to move is worse than not booking at all — it converts a happy caller into an annoyed one.
  • Address is confirmed by read-back and validated against the service area. Out-of-area callers are told so honestly and immediately, which everybody prefers to a booked appointment that gets cancelled.

Latency, because it decides whether the thing works

Perceived naturalness on the phone is almost entirely a latency problem. We budgeted 700ms end of caller speech to start of agent speech, and hit a median of 610ms with a p95 of 940ms. The techniques were unremarkable and all necessary: streaming transcription with endpointing rather than waiting for silence, first-token streaming into speech synthesis, a small set of pre-synthesised acknowledgement phrases to cover the model's first 300ms, and barge-in that cuts the agent off mid-word the instant the caller speaks. That last one matters more than the voice quality. Nothing marks a call as robotic faster than an agent that keeps talking over you.

What lands in the CRM

Within about eight seconds of hang-up: the recording, a full transcript, a structured summary, the booked appointment, extracted fields written to their existing fields (not a custom object nobody looks at), and a tag if anything needed a human. Dispatchers see it in the tool they already use.

Where humans stay in the loop

This practice uses the same trust ladder, applied to call outcomes rather than tickets. Bookings for standard service calls reached level 3 — executed live, reversible, and reviewed in a morning digest. Three things never left human hands: quoting any price beyond the published diagnostic fee, anything involving a warranty claim, and any call where the agent's own confidence in the address or service type dropped below threshold. Those became warm transfers during hours, and a callback task with full context out of hours.

The rule we would give any voice deployment The agent must offer a human on the first ask, every time, with no retention attempt. Callers who feel trapped in a robot loop do not become customers, and the conversion data bore this out: the transfer path converted better than a forced completion ever did.

What broke

Failure 1 — the storm surge Week three brought a wind event and call volume tripled in ninety minutes. The agent handled the volume fine and booked 140 appointments into a schedule that physically could not absorb them, because it was reading calendar availability without any concept of surge capacity. Dispatch spent the next morning rescheduling. We added a capacity governor: past a configurable daily booking threshold per location, the agent switches from booking to a prioritised callback list and says so honestly.
Failure 2 — accents and addresses Street name recognition was materially worse for several regional and non-native accents, which is both a quality failure and a fairness one. Mitigation was structural rather than model-side: validate every captured address against a geocoder restricted to the service area, read it back, and fall back to spelling it out letter by letter on a second failure. Post-fix, address error rate equalised across the sample we could measure. We report this metric explicitly because it will not fix itself.
Failure 3 — the agent was too good at not transferring Early prompting rewarded completing the booking, so the agent gently deflected requests for a human. Callers hated it. We inverted the instruction: any request for a person, however phrased, transfers immediately. Transfer rate went up 4 points; booking conversion went up too.

Where it landed

MeasureBaselineWeek 7
Calls answered within 3 rings62%99%
Calls to voicemail / answering service21%0%
Abandoned in queue17%2%
After-hours calls resulting in a booked slot19%44%
Bookings requiring dispatcher rework6%
Human transfer rate (of AI-handled calls)13%
Answering service line item$2,100/mo$0

The economics of this practice are simpler than any other we do, which is why it is often the first thing we recommend to a service business. At the modelled figures — 118 unanswered calls a day, recovering 40% of them, converting at the after-hours rate, on this company's average ticket — the recovered revenue dwarfs both the build and the ~$0.19/minute running cost by a wide margin. You can run the same arithmetic on your own numbers:

Missed-call revenue calculator → Walk through the intake →

How many calls did you not answer yesterday?

Most businesses cannot say, which is itself the finding. We can have that number for you in a week.