DEV Community: Abe

Answering Service for Plumbers: What Your Intake Has to Capture Before You Send a Truck

Abe — Mon, 11 May 2026 09:51:03 +0000

A note on bias before you read

I'm Abe, founder of OnCrew. We build AI receptionists for service businesses, including plumbers, so I have a commercial reason to write about this topic. I've tried to make this useful even if you never click a link to anything I sell — the call-handling failures described here are independent of who answers your phones.

If you read this and decide your existing answering service or in-house dispatcher is doing fine, great. If you read it and realize your intake is leaking jobs, fix it however you want.

Why plumbing calls are different from "normal" service calls

Most generic answering-service advice treats every inbound call the same: be polite, take a name, take a number, take a message. That's fine for a law firm. It's a slow bleed for a plumbing company.

Plumbing has a few properties that mess with naive intake:

Time-pressure asymmetry. A clogged kitchen drain can wait until tomorrow. A burst supply line can flood a finished basement in twenty minutes. The same caller may not know which of those they have.
Truck economics. Rolling a truck with the wrong tech, wrong parts, or wrong size of equipment is the single most expensive intake mistake. A poorly-captured call can turn a one-trip job into three.
Property-type variance. Residential, commercial, multi-family, and new construction calls require different dispatch behavior. So do owner-occupied vs. landlord-tenant situations, which determine who can authorize work.
Insurance and water-mitigation overlap. Many plumbing emergencies become insurance jobs the moment standing water appears. Capturing this at the front door changes how the job is run.
Licensing and scope. The person taking the call frequently cannot answer technical or legal questions about whether a job is permitted, code-compliant, or covered. Saying the wrong thing here is worse than not answering at all.

A plumbing answering service — human, AI, or hybrid — that doesn't understand these properties will sound competent on the call and still cost you money on the job.

The intake fields that actually matter

The goal of intake is not to "qualify the lead." The goal is to give your dispatcher enough information to make a correct routing decision and your tech enough information to arrive prepared.

Below is the minimum field set I'd want captured on every plumbing call. Anything more is a bonus; anything less is gambling.

Caller and property

Caller name and callback number (always confirm by readback).
Is the caller the property owner, tenant, property manager, or someone else? Who can authorize work and approve payment?
Service address, with unit number for multi-family.
Property type: single-family, condo, apartment, commercial, restaurant, new construction.

The problem

One-sentence description in the caller's own words.
Specific fixture or system: water heater, toilet, kitchen sink, main line, slab leak, sump pump, gas line, sewer ejector, etc.
Visible water? If yes, where and how much? Is it active or stopped?
Has the main shutoff been turned off? Does the caller know where it is?
When did this start? Has it gotten worse? Has anyone worked on it already?

Access and logistics

Are pets, gates, alarm codes, or parking constraints relevant?
Earliest time the caller can be on-site or grant access.
Any access restrictions (HOA hours, commercial business hours, tenant coordination).

Commercial / urgency context

For commercial: are operations affected? Is water shut off to part of the building?
For residential: is the only toilet, shower, or water source in the home affected?
Insurance involved? Has a mitigation company already been called?

Service expectations

What does the caller want: estimate, repair today, repair this week, second opinion, warranty work?
Have they used you before? (Pull the existing record if so.)
How did they hear about you? (Useful for marketing attribution; never required to dispatch.)

If you can get clean answers to those fields on every call, your dispatcher's job becomes routing instead of interrogation. That's the real cost saving.

Emergency vs routine triage

The single most important decision an answering service makes for a plumber is the emergency-or-not call. Get it wrong in one direction and you wake your on-call tech for a slow drip. Get it wrong in the other and you find out at 7 a.m. that a hardwood floor was underwater all night.

A workable triage rubric looks like this:

Treat as emergency / page on-call tech

Active uncontrolled water at the property.
Sewage backing up into the living space.
Suspected gas leak — and the call should immediately include an instruction to leave the property and call the gas utility or 911 first.
No water at all in the residence, especially with vulnerable occupants.
Commercial property where operations are halted and revenue is bleeding.
Frozen-pipe season, exposed pipe with no heat.

Treat as next-business-day

Slow drains, even fully clogged ones, if there is no overflow.
Running toilets, single dripping faucets.
Water heater out, but the household has alternatives or it's not winter and not the only unit.
Diagnostic or estimate requests.
Pre-listing inspections, real-estate-driven work.

Always escalate to a human regardless of bucket

The caller is in distress, elderly, or describes a safety concern.
The caller mentions injury, electrical contact with water, or carbon monoxide.
Suspected gas — already mentioned, repeated for emphasis.
The caller asks to speak to a person.

The "always escalate" list is the one most automation skips. Don't.

After-hours capture: the part most shops underinvest in

Most plumbing companies lose more revenue between 5 p.m. and 8 a.m. than they realize. Not because emergencies happen overnight — they do, but they're a small slice — but because Tuesday-evening homeowners decide at 9 p.m. that they're going to call someone tomorrow. Whoever picks up first the next morning often wins the job.

After-hours capture should do four things, in order:

Answer fast. Not "within three rings" fast — first ring, no IVR maze. Every additional second before a human-feeling voice costs you abandonment.
Triage to true urgency. Use the rubric above. Don't page your on-call tech for a routine call; don't ignore an actual emergency.
Book or hold the slot. If your dispatch system supports it, soft-book the morning slot during the call. If not, capture the preferred window and confirm "first call in the morning."
Send a confirmation immediately. Text the caller a summary: "We have you down for Wednesday 8–10 a.m. We'll text again before the tech is on the way." This single message tends to reduce cancellations.

If your current answering setup does only step one, you're paying for a glorified voicemail.

What an AI receptionist or answering service should not promise

This is the part of the conversation that gets glossed over in marketing copy. Honest scope is part of quality.

An AI or third-party answering service is well-suited to:

Picking up consistently, including overflow and after-hours.
Capturing structured intake.
Applying a triage rubric reliably.
Sending confirmations and reminders.
Pushing data into a CRM or dispatch tool.

It is not well-suited to, and should not promise:

Guaranteed arrival times. Only your dispatcher and the conditions of the day can offer a window, and even then only as a best estimate.
Quoting or binding pricing on complex jobs. Flat-rate book numbers can be shared as ranges; a final price is the tech's call after seeing the job.
Licensed judgment. Whether something is to code, permittable, covered under warranty, or safe to defer is not a receptionist decision.
Replacing emergency services. Anything that smells like gas, electrical-plus-water, or injury goes to 911 or the utility first, your truck second.
Catching 100% of calls perfectly. No system does. Anyone selling you "never miss a call" is selling you a slogan.

If a vendor pitches you on capabilities in that second list, that's a signal about the rest of their judgment.

A scorecard for choosing a plumbing answering service

If you're evaluating options — AI, human, or hybrid — here's a compact checklist you can use on a sales call:

Capability	Question to ask	Why it matters
Industry fluency	"Walk me through how you'd handle a frozen-pipe call in February at 2 a.m."	Generic scripts collapse here.
Intake completeness	"Show me the exact fields captured on a typical call."	If they can't show you, they don't capture them.
Triage rubric	"What gets paged to on-call, and who decides?"	A vague answer means inconsistent nights.
Escalation path	"What happens if a caller is distressed or mentions gas?"	Non-negotiable.
CRM / dispatch integration	"Which dispatch systems do you push to, and how?"	Otherwise your dispatcher re-keys everything.
Confirmations	"Does the caller get a text immediately after the call?"	Reduces no-shows and cancellations.
Reporting	"Can I see every call, recording, and outcome?"	You can't improve what you can't audit.
Failure mode	"What happens when your system is down or unsure?"	An honest answer is a good vendor signal.

If a vendor passes that scorecard, the price difference between options usually matters less than the operational difference.

When OnCrew may fit, and when it won't

To close the loop on the disclosure at the top: I run OnCrew's answering service for plumbers, which is an AI receptionist tuned around the intake and triage logic described above. It fits best for plumbing shops that already have a dispatch process and want consistent, structured intake on every call — especially after hours and during overflow — without paying for a full-time human at 3 a.m.

It is not the right tool if you want a single warm human who knows every regular customer by voice, or if your call volume is low enough that your existing dispatcher already answers everything on the first ring.

Whatever you choose, the test is the same: pull last month's calls, listen to ten of them, and grade them against the intake field list and triage rubric above. The gap between what was captured and what should have been captured is the size of the problem you're solving. The vendor — AI, human, or some mix — is just the instrument.

— Abe

HVAC Answering Service: A Practical Guide for Heating and Cooling Owners

Abe — Mon, 11 May 2026 09:49:11 +0000

Most HVAC owners do not lose jobs because their pricing is wrong. They lose jobs because the phone rang during a heat wave and nobody picked up.

Residential HVAC runs on a strange call pattern. For weeks the phones are quiet. Then a cold snap hits, a furnace fails at 6 a.m., and call volume triples before lunch. Dispatch is on another line. Two homeowners go to voicemail. One calls the next contractor in the search results, and the job is gone before your office knew it existed.

This is the gap an HVAC answering service is supposed to close. This guide is for owners and dispatchers trying to tell the good ones from the bad.

What an HVAC answering service should actually do

Strip away the marketing language and the job is narrow. An HVAC answering service answers the phone when your office is busy, closed, or buried by a peak-weather surge. It captures the right information, tags how urgent the call is, and hands it off to the on-call workflow so your team can decide what to do.

It is not a dispatcher. It is not a technician. It does not promise an ETA. The HVAC company still owns service decisions, safety guidance, and who gets a truck and when.

A good service should consistently do four things:

Answer quickly, including nights, weekends, and storm days
Run a real HVAC intake script, not a generic "name and number" message
Distinguish urgent calls from informational ones
Push the call to your on-call workflow in a form your team can act on

If you can only get two of those four, you have a call center, not an answering service.

A practical HVAC intake checklist

The single biggest difference between a useful message and a useless one is the questions on the script. Generic services ask name, phone, and "reason for calling." That is not enough to triage a no-heat call in January.

A strong HVAC intake captures, at minimum:

Caller name and best callback phone
Full service address
Equipment type if known: furnace, boiler, heat pump, mini-split, central AC, package unit
Current thermostat reading vs setpoint
When the symptoms started
Vulnerable residents in the home (infants, elderly, medically dependent on temperature)
Preferred callback window

From there, the script should branch by symptom.

No heat in winter

Is the thermostat getting power
Any error codes on the unit display
Is the breaker tripped
Last filter change or recent service

No cooling in a heat wave

Is the outdoor unit running
Indoor temperature now and at peak
Any ice visible on the lines
Was there a recent thermostat or wiring change

Gas smell near a furnace or water heater

This is a safety call, not a service call. The script should advise the caller to leave the home and contact the gas utility or 911 per local guidance, then capture details for your on-call team. The answering service is not the appropriate party to assess safety risk.

Water leak or condensate

Active leak or stain only
Where in the home
Is water reaching electrical or finished ceilings
Has the homeowner shut the system off

Tune-up, maintenance, or replacement estimate

System age, brand, and stage if known
Last service date or membership status
Reason for the call: failed, end of life, efficiency, comfort
Timeline: emergency, this month, this season
Two or three callback windows that work

You do not need every field on every call. You need a script disciplined enough to capture the ones that matter for that symptom.

Live, AI, and hybrid models

There are three operating models on the market. Each has honest tradeoffs.

Live human answering services. A trained agent picks up and works the script. Strengths: warmth, judgment on ambiguous calls, comfort with older or distressed callers. Weaknesses: per-minute pricing that can spike in busy weeks, queue times during regional weather events, and variable script adherence across agents.

AI voice answering services. A voice agent answers, runs the script, and posts a structured handoff. Strengths: consistent intake, no queue, predictable cost during surges. Weaknesses: accents and noisy lines can still trip recognition, and a poorly configured agent will sound robotic. The script and the handoff matter more than the brand of the AI.

Hybrid setups. AI answers first and captures the structured intake, then routes to a human for emotionally loaded calls or anything flagged urgent. Strengths: speed plus a safety net. Weaknesses: more moving parts and you need to actually test the handoff path.

There is no universally correct answer. A two-truck shop with a tight on-call rotation may do well with AI plus a clear escalation rule. A larger company with bilingual demand may want live or hybrid coverage. Run the model that matches your callers, not the one that sounds most modern.

Escalation boundaries

This is the part most marketing pages skip. An answering service should not make service decisions on your behalf. It should not promise a tech will be there in an hour. It should not diagnose a furnace over the phone. It should not tell a homeowner with a gas smell to wait.

What it should do is follow the rules you set: tag the call by the urgency criteria you wrote, send the handoff to the on-call number, channel, or CRM you specified, and keep trying until someone on your side acknowledges it. Your dispatcher decides who goes where. Your techs decide what is safe. The service is the front door, not the captain.

Write your escalation rules down before you sign anything. Define what counts as urgent, where urgent calls go, where non-urgent calls go, and what happens if no one acknowledges within X minutes.

An evaluation checklist for HVAC owners

Before you commit, walk through these questions:

Does the script handle the HVAC call types above, or is it a generic template
How are gas-smell calls handled
How are urgent calls routed, and what is the retry path if no one acknowledges
Does it integrate with your field software, or will your team retype every ticket
What does pricing look like during a real surge week, not an average week
Can you listen to or read transcripts of actual calls
Who owns the data and the recordings
How fast can you change the script when your hours, service area, or pricing change

If a provider cannot give you straight answers, keep looking.

Where OnCrew fits

If you want a deeper buyer-side breakdown, including how to write a triage script and what a clean handoff looks like in practice, OnCrew has a guide written specifically for HVAC owners.

https://oncrew.ai/resources/hvac-answering-service

To roughly size what missed calls are costing your shop before you change anything, this calculator is a useful starting point:

https://oncrew.ai/tools/missed-call-calculator

OnCrew offers a 14-day free trial with no charge today and guided setup, but the guide above is worth reading even if you stay with your current provider.

Closing thought

An HVAC answering service is not a magic fix or a replacement for a good dispatcher. It is a disciplined front door for the hours and weeks when your team cannot answer fast enough. Picked carefully, it captures calls you would otherwise lose. Picked carelessly, it is one more vendor charging you to take messages.

Spend an afternoon on the script and the escalation rules. That afternoon will outperform almost any marketing decision you make this season.

Written by Abe.

Building contractor automation without overpromising dispatch: boundaries, observability, and escalation

Abe — Mon, 11 May 2026 08:04:16 +0000

I'm Abe, founder of OnCrew. We build the AI answering service for HVAC, plumbing, electrical, and roofing contractors. This is a follow-up to my earlier post on triage architecture. Here I want to write about something less glamorous but more important: the boundaries you have to design around, the observability you need to know they're holding, and the escalation paths you need so that a misclassified call doesn't turn into a real-world problem.

The shorthand version of this article: it's tempting to build a "full dispatcher" automation. Don't. Build the part that's automatable, leave the part that isn't to humans, and make the seam between them legible.

Why dispatch is not the part to automate

Dispatch — actually slotting a job into a route, promising a customer that a tech will be there at 2:15pm, taking a payment, handling a warranty discussion — has a few properties that make it a bad fit for current-generation automation:

Real-time inventory and constraints. Dispatch depends on where every tech currently is, what jobs they're already committed to, what parts are on the truck, and what skill mix the next job needs. Modeling this in an AI agent is possible but the latency and reliability profile is bad. Get it wrong and you've promised something you can't deliver.

Liability surface. A tech ETA is a soft commitment to a customer. Miss it and they're entitled to be angry. Promise it without authority and the shop is on the hook for the disappointment, not the vendor.

High-empathy edge cases. A frantic customer at 2am whose basement is flooding does not need an AI to read them a service window from a script. They need a person to say "we're getting somebody on the way, here's what to do in the meantime to limit damage." That voice belongs to a human dispatcher.

So our design rule is: the agent does intake, triage, and structured handoff. The human dispatcher does dispatch. The seam between them is where we spend most of our engineering effort.

The boundary layer

The boundary layer is a small piece of code with one job: prevent the agent from saying anything dispatcher-shaped. It runs after the response generator and before the TTS layer.

Filters in the boundary layer:

Promise words. "Guarantee," "definitely," "we will be there," "I'll send," "we'll dispatch." These get rejected or rewritten.
Time-of-arrival statements. Anything matching a pattern like "in X minutes," "around X o'clock," "by X" gets rewritten to "we'll alert the on-call team with your details."
Price statements. "It'll cost $X," "the service fee is $X," any dollar-denominated quote. Rewritten to "the team will be able to give you pricing when they follow up."
Diagnostic statements. "It sounds like your capacitor is failing," "that's probably a clogged drain." Rewritten to "I'll note the symptoms for the team to assess."
Safety-action statements. "You should turn the breaker off," "go ahead and shut the main water valve." Rewritten in most cases to "I'll have the on-call team follow up about that" except for explicit life-safety direction (call 911, leave the building if gas smell), which is allowed.

This boundary layer is the most boring part of the system and the most important. The LLM will, on its own initiative, occasionally say something it shouldn't. The boundary layer catches it. We treat any boundary-layer rewrite as a signal — it tells us where the response generator's prompts need work.

Observability

You cannot maintain these boundaries blind. The minimum observability surface for a phone agent that handles real calls:

Per-call structured summary. Captured fields, classification, action log. Stored as a queryable record, not a free-text blob.

Per-call boundary-layer events. Every rewrite or rejection logged with the candidate response, the rule that triggered, and the final response. This is the dataset you need to improve the prompts. Without it you're guessing.

Per-call ASR confidence histogram. Especially on critical fields (callback number, address). Low-confidence regions get flagged for review.

Per-call disposition. What happened to the captured ticket downstream? Did the dispatcher act on it? Did the call get returned within X hours? Did the customer call back saying the agent got something wrong?

Aggregate dashboards. Classification distributions over time. Boundary-layer event rates. Field-coverage rates per trade. Average call duration. These let you spot drift before the customer does.

Escalation alerts. When a call gets misclassified, or a field that should always be captured wasn't, or a known-bad utterance was generated, an alert fires to a human review queue. We staff this queue. It's the only way to catch regressions in production.

Escalation paths

There are calls the agent shouldn't handle. The design question is what happens when it encounters one.

We have three escalation paths:

1. Live transfer to the on-call human. For calls flagged as urgent and where the shop has a live-answer human on the on-call line. The agent captures intake, then connects. The transfer is a hand-off, not a hot-potato — we pass the captured fields and a one-line summary so the human starts informed.

2. Alert with structured payload. For calls flagged as urgent where there isn't a live-answer line — most shops, most of the time. The agent captures intake, completes the call with the caller, and fires an alert into the shop's configured workflow (text, phone, Slack, webhook into dispatch tool, email). The on-call human sees the structured intake and decides whether to call the customer back themselves.

3. Self-direction to 911 / utility. For life-safety calls — gas smell with respiratory symptoms, smoke, electrocution risk, downed lines. The agent explicitly tells the caller to call 911 and/or the utility's emergency number while also capturing intake for the shop's records. This is not a substitute for emergency services. We don't pretend it is.

The thing to avoid is the fourth path: "agent improvises and tells the caller something it shouldn't." That's what the boundary layer is for. If the agent doesn't know what to do, the right behavior is to capture what it can, complete the call politely, and let the human follow up.

What "automation" actually means in this domain

I want to argue for a definition. "Automating" a piece of contractor operations doesn't mean replacing the human at every step. It means moving the routine, structured, time-of-day-independent work onto a machine, and leaving the judgment-heavy, real-time, relationship-heavy work to the human.

Phone intake is mostly routine and structured. Pattern-matching urgency cues is mostly routine and structured. Producing a clean ticket is mostly routine and structured. These are good candidates.

Dispatch is real-time and judgment-heavy. Payment is judgment-heavy and liability-laden. Warranty discussions are relationship-heavy. These are bad candidates, today.

The framing matters because it changes what you build. If your goal is to replace the dispatcher, you'll build a system that overreaches and disappoints. If your goal is to make the dispatcher's morning easier — clean tickets waiting in priority order, urgent calls already alerted, transcripts available for review — you'll build a system that the dispatcher actually wants.

This is one of those places where the right ambition is the smaller ambition.

Concrete checklist for the design

If you're building something similar, here's what I'd make sure you have before you put it in production:

Hard boundary on promise words and ETA statements, enforced in code.
Per-call boundary-layer event log.
Structured intake schema per trade, with field-coverage instrumentation.
Escalation paths: live transfer, alert with payload, self-direction to emergency services.
Human review queue for flagged calls.
Disposition feedback loop from the dispatcher back into the training data.
Honest marketing copy. If you tell the buyer the agent "dispatches" or "books" calls when it actually intakes and alerts, you've built a credibility debt that you'll pay down for the lifetime of the customer.

The OnCrew side of this is on our contractor answering service page if you want to see the buyer-facing version. There's a demo line at (818) 578-4783 if you want to call it and see how the boundary layer behaves in real time. (Try to get it to promise you an ETA. It won't.)

Closing

The work in this space isn't deciding whether AI can do contractor intake — it clearly can. The work is deciding what AI shouldn't do, building the fences to enforce it, and making the seam to humans clean enough that the whole system actually works. That's the part that takes the time. That's the part that's worth building well.

Designing AI agents for contractor call triage: architecture, prompts, state, and safe handoff

Abe — Mon, 11 May 2026 08:03:57 +0000

I'm Abe, founder of OnCrew, an AI answering service for HVAC, plumbing, electrical, and roofing contractors. This is a technical write-up of how we approach the design of a phone agent that has to do trade-specific intake and triage in real time, without overpromising things that matter (like a tech's arrival time) or under-handling things that matter (like a gas-smell call at 2am).

I'll cover the architecture, the prompt structure, how we manage state across a call, what we hand off, and the boundaries we deliberately don't cross. This is meant for developers building production phone agents in adjacent verticals, not for buyers. If you want the buyer's version of this, the marketing site has it.

The shape of the problem

A residential contractor call has three phases that are easy to confuse:

Detection — what kind of call is this? (Emergency vs routine. New customer vs existing. In-trade vs out-of-trade.)
Intake — collect the fields the dispatcher needs to act on the ticket.
Handoff — decide what happens after the call. Alert the on-call tech? Queue a callback? Direct to 911? Send to the CRM?

Most generic phone agents collapse these phases into a single linear script and that's where they fail. A real call doesn't go in order. The caller will mention an emergency symptom three sentences into a routine appointment request. The agent has to notice and re-classify. A linear script can't.

So the first architectural decision is to treat the call as an event stream and run classification continuously, not just at the start.

Architecture

The high-level pipeline looks like this:

caller speech -> ASR -> turn buffer -> classifier -> intent state ->
  -> intake policy -> response generator -> TTS -> caller
                                |
                                v
                      action queue (alerts, webhooks, summaries)

The pieces that matter:

Turn buffer. Holds the last N utterances and the running intent state. Not just the immediate user turn — context windows of 4-8 turns let the classifier pick up emergency cues that appear mid-conversation.

Classifier. Two-pass. Pass one is a fast model that runs on every turn and outputs a structured classification (intent, trade, urgency, out_of_scope_flags). Pass two is a slower verification model that only fires when the fast model crosses a confidence threshold for an urgent or out-of-scope classification, to avoid false-positive emergencies.

Intent state. A typed object that persists across the call. Fields include trade, service_category, urgency_band, caller_role, address, callback_number, appointment_window, access_notes, flags. The intake policy reads this and decides what to ask next.

Intake policy. A state machine that drives question selection. We deliberately don't let the LLM decide the next question in a free-form way — too easy for it to skip required fields. The policy enforces field coverage based on trade and urgency_band. The LLM only generates the natural-language form of the question.

Response generator. Generates the spoken response in a fixed conversational style. Constraints: doesn't promise ETA, doesn't quote prices, doesn't diagnose, doesn't tell the caller it's safe to do anything physical to their equipment.

Action queue. Decoupled from the call. Webhooks, alerts, CRM writes, recording finalization, and summary generation all run async after the call ends or asynchronously during the call for time-sensitive alerts.

Prompt structure

The single biggest mistake I see in early-stage phone agents is one giant system prompt that tries to be a personality, a knowledge base, and an intake script all at once. We split this into three concerns:

The persona prompt. Short. Stable. Defines tone, pace, and identity ("you're answering for [Company]"). Doesn't include trade knowledge or intake fields. Doesn't change across calls.

The trade pack. Per-trade content: vocabulary, urgency cues, sample fields, sample boundary statements. HVAC, plumbing, electrical, and roofing each have their own pack. The pack is selected at the start of the call based on the caller's first utterance or the configured shop's primary trade.

The intake policy as structured instructions. Not free prose. A list of fields with their preconditions, ask-priorities, and example phrasings. This is the part that's easy to get wrong if you put it in prose, because the model will skip fields it thinks are implicit.

The classifier and the response generator see different subsets of this. The classifier sees the trade pack but not the persona. The response generator sees the persona and the current field-to-ask but not the full intake policy.

Urgency triage, with hard edges

This is the part I want to be careful about, because it's where overpromising can cause harm.

We pattern-match on emergency-shaped language using a layered approach:

Lexical cues. Direct phrases that map to urgency without ambiguity: "gas smell," "sparking," "active leak," "no heat," "burst pipe," "sewage backup," "panel buzzing," "smoke," "exposed wiring," "tarp."
Symptom cues. Combinations that imply urgency without naming it: "water everywhere," "I can hear it dripping inside the wall," "the lights flicker when I plug things in."
Context cues. Time-of-day, weather event, caller stress level (tone, pace, interruptions).
Vulnerability cues. "Elderly mother," "infant," "asthma," "we can't get out of the house."

The classifier outputs an urgency_band (informational / standard / elevated / urgent / life-safety) and a flags array. The action queue uses these to decide:

Informational/standard: queue a callback ticket. No alerts.
Elevated: queue a callback with priority flag. Optionally alert depending on shop configuration.
Urgent: alert into the shop's configured on-call workflow with the captured intake. Tell the caller the on-call team has been alerted with their details and someone will follow up. Do not promise an arrival time.
Life-safety: explicitly direct the caller to call 911 and/or the utility's emergency line, in addition to capturing intake. Do not pretend the answering service replaces those numbers.

The hard rule baked into the response generator: never promise a technician arrival time. Ever. The agent can say "I've alerted the on-call team with your details," not "a tech will be there in 45 minutes." Promising arrival time is something only the dispatcher can do, and only after they've looked at the schedule and the route.

State management gotchas

A few things we learned the painful way:

Don't re-ask captured fields. Sounds obvious. In practice, a free-form LLM will absolutely re-ask the address if the user said it three turns ago, because the model doesn't have a strong incentive to consult prior state. Bake field-already-captured checks into the intake policy, not into the prompt.

Handle correction turns. Callers will correct themselves. "Actually it's 1234, not 1432." If you don't have a correction path, the wrong value persists. We use a correction classifier on every turn that explicitly looks for "actually," "wait," "no I meant," and similar markers, and routes those through a re-capture step.

Don't trust the ASR on critical fields. Phone numbers and addresses are where ASR fails most often. Read back. Always. "Let me read that back — 5 5 5 4 1 2 3, is that right?" Yes, it adds 4 seconds. Yes, it's worth it. The cost of one wrong callback number is much higher than four seconds.

Hangups happen mid-intake. Design the action queue so that whatever fields were captured up to the hangup get written to a partial-ticket. Don't throw away the partial. The dispatcher can still call back.

What the agent never does

Hard boundaries, enforced in the response generator:

Never quotes a price.
Never promises a technician arrival time.
Never tells the caller it's safe to do something physical (flip a breaker back on, turn the gas back on, climb on a roof).
Never diagnoses the underlying problem.
Never says "we guarantee" anything.
Never says "you should call X competitor instead" — if out of trade, says "I'm not able to help with that today" and offers to take a message anyway.

These aren't suggestions. They're filtered at the response generator. Any candidate response containing promise-words ("guarantee," "we will be there," "definitely") gets rewritten or rejected.

Handoff and observability

Every call produces:

Full transcript with speaker turns.
Audio recording (where legal).
Structured summary with the captured intake fields.
Urgency classification and flags.
Action log: which webhooks fired, which alerts went out, what the dispatcher saw.

The shop owner gets a morning digest. The dispatcher gets real-time alerts for urgent calls. The developer-side dashboard shows aggregate classification distributions, ASR confidence, and where the policy had to fall back to clarifying questions. That last metric is the most useful — it tells you where the intake policy has gaps.

If you want to see what this looks like as a finished product, our AI answering service for contractors page walks through the externally visible behavior. The internals are mostly the architecture above with a lot of plumbing.

Closing thoughts

The interesting part of building these agents isn't the LLM. It's the state machine around the LLM. The LLM does language. The state machine does correctness. Get the state machine right and the agent feels intelligent. Get it wrong and the agent feels like a frustrating IVR with extra steps.

Happy to take questions in the comments if you're building something adjacent. The phone-agent space has a lot of bad designs in it right now and the more of us share the boring details of what actually works, the faster the industry stops underserving the buyer.

HVAC Answering Service: AI vs Live Receptionist for After-Hours Calls

Abe — Mon, 11 May 2026 07:43:06 +0000

HVAC answering service

An HVAC answering service should do more than say "someone will call you back." After hours, it should capture whether the caller has no heat, no cooling, water around equipment, strange smells, vulnerable occupants, and a safe callback path. AI and live receptionists can both work, but they solve different operational problems.

Snippet checklist:

After-hours goal: answer fast, collect clear HVAC details, route urgent calls.
AI fit: predictable intake, overflow, nights, weekends, and low-volume call coverage.
Live receptionist fit: nuanced scheduling, membership questions, payment issues, complex exceptions.
Urgency flags: no heat in cold weather, no cooling for vulnerable occupants, burning smell, gas concern, active leak.
Setup requirement: configure your escalation workflow before sending real calls.
Cost lens: compare monthly minimums, included calls, overage, and whether you pay for wrong-number calls.
More context: HVAC answering service and HVAC AI answering service.

HVAC calls have a seasonal rhythm that makes phone coverage hard. In shoulder months, you may have a manageable volume. In a heat wave or freeze, the phone can jump from quiet to overwhelming in a few hours. The owner, dispatcher, and techs may all be working, but customers still expect a response.

The practical choice is not "AI or humans forever." It is deciding which layer should handle which kind of call.

What a good after-hours HVAC call flow asks

A basic no-answer message does not tell you enough. An HVAC answering service should capture the caller's name, phone number, service address, whether the issue is heating or cooling, what symptoms they are seeing, and whether anyone in the home is at higher risk.

For no heat, ask whether the system is completely off, whether the thermostat has power, whether there are unusual smells, and whether the caller is in a home with infants, elderly people, or medical concerns. For no cooling, ask whether the system is blowing warm air, leaking water, tripping breakers, or frozen over.

That intake is not a diagnosis. It is triage. It helps the shop decide whether the call should wake someone up, wait until morning, or be handled as a scheduled follow-up.

Where AI is strong

AI is useful when the conversation can follow a reliable pattern. After-hours HVAC intake is usually pattern-based. The caller has a problem. The service needs to answer, show empathy, ask structured questions, capture details, and notify the right person.

AI can be available 24/7 without asking a tech to answer every ringing phone. It can be consistent with the questions it asks. It can summarize the call so the on-call person sees the key facts quickly. It can also support overflow when your office is already on the phone.

This is where a tool like OnCrew is designed to sit: answer calls, ask trade-specific intake questions, capture caller details, flag urgent calls, alert or route to a configured on-call workflow, and log summaries or transcripts. OnCrew's pricing is also public: Starter is $49/month for 100 included calls, Pro is $149/month for 400 included calls, Multi-Truck is $349/month for 1,000 included calls, and overage is $0.99/call.

Those details matter because "answering service" pricing can look cheap until you compare minimums, minutes, call rounding, and overflow rules.

Where live receptionists are still better

There are calls where a trained human still has the edge. If the caller wants to reschedule an install, debate a maintenance agreement, ask about warranty coverage, negotiate a bill, or coordinate access with a tenant, a live receptionist or in-house dispatcher may handle the nuance better.

A human can also make judgment calls when your schedule is changing in real time. If a tech is running late, a part is delayed, or a crew is being rerouted, the person answering the phone may need access to dispatch context and permission to make decisions.

That is why I would not frame AI as a full dispatcher unless the system is actually integrated into your dispatch operation and your team has defined what it can and cannot promise. For most shops, the better first use is intake and urgent routing.

The mistake to avoid

The biggest mistake is turning on a generic script. HVAC is not generic. "Can I take a message?" is not enough for a freezing house, a water leak around an air handler, or a burning smell near equipment.

Before going live, write the five to ten scenarios you actually care about. No heat. No cooling. Water leak. Burning smell. System will not turn on. Thermostat issue. Maintenance request. Estimate request. Existing customer callback. Wrong trade.

Then test each one. If the service handles them naturally and routes the urgent ones correctly, you are close. If it misses safety details or promises a tech will arrive when your business has not committed to that, fix the flow.

A simple decision framework

Choose AI when your main problem is missed calls, after-hours intake, and structured triage. Choose a live receptionist when your main problem is scheduling complexity, account-specific questions, or high-touch customer service. Use both when your shop has enough volume that the AI can catch overflow while humans handle the complex calls.

The best HVAC phone setup is not the fanciest. It is the one that gives the customer a clear response and gives your team the right information without creating promises you cannot keep.

Disclosure: I am Abe, founder of OnCrew, so read this with that bias in mind. The goal is a useful buying framework, not a claim that one vendor is perfect for every HVAC shop.