Forem: Abe

Answering Service for Roofers: A Practical Framework for After-Hours and Storm-Season Calls

Abe — Mon, 11 May 2026 21:36:11 +0000

Quick disclosure: I'm Abe, founder of OnCrew. We build phone answering automation for trades businesses, including roofers, so I have a horse in this race. I tried to keep this piece useful even if you never look at our product — if it tilts at any point, push back. The framework below is the same checklist I'd hand a roofer who asked me how to think about this, vendor-agnostic.

Roofing is one of the hardest trades to staff a phone for. The work is loud, often on a ladder, and the busiest days for the crew are usually the busiest days for the phone. A wind event blows through on a Thursday afternoon, and by Friday morning many homeowners with missing shingles, damp ceilings, or a tree branch on a ridge cap are dialing local roofers in order. The shops that pick up — or at least capture a usable callback — often get the job. The rest get a voicemail and a hope.

If you're evaluating an answering service for roofers, this article walks through what a well-designed phone front end does, the script details that matter, how to triage urgent and routine calls, and how to test the setup before forwarding a real customer into it.

Why roofers miss calls in the first place

It's worth being honest about the specific reasons calls slip past, because they shape what the service has to handle.

The owner and lead estimator are on roofs or in attics where they can't pick up.
A homeowner calls during a storm and the office line goes unanswered because the office is closed.
The crew is on a job with no signal, especially in rural or new-construction areas.
Multiple calls hit at once after a weather event, and a single line collapses under the queue.
After-hours calls go straight to voicemail, and many homeowners don't leave one.

Most of these aren't laziness problems; they're capacity problems. The job of an answering service is to absorb that overflow with a script that captures enough for a useful callback, not to replace the human relationship a roofer eventually has with the customer.

What a good roofing answering script should capture

A generic receptionist script gets a name and a number. A roofing-aware script captures enough that whoever calls back can quote a ballpark, schedule the right truck, or send a tarp crew without a second discovery call.

At minimum, the script should pull:

Caller's full name and best callback number.
Property address, including city and zip — needed for routing and service-area confirmation.
Whether the issue is an active leak, visible damage from the ground, an interior stain, or a routine inspection or quote request.
Approximate roof age and material, if the homeowner knows.
Whether water is actively coming into the home right now.
Whether the caller is the property owner, a tenant, or a property manager.
Whether this is storm-related (recent wind, hail, tree fall) or out-of-pocket.
Whether the caller has already placed buckets, moved furniture, or covered anything themselves.
A short summary of the issue in the caller's own words.
Best time window to call back today or tomorrow.

The last item — the issue in the caller's own words — is what most generic scripts skip, and what pays off. A two-sentence verbatim from the homeowner ("the ceiling stain in the upstairs hallway got bigger after Tuesday's rain, and now there's a drip starting") tells the estimator more than a checkbox form ever will.

Urgent vs routine: triage rules you can actually use

Not every roofing call is an emergency, and treating them all the same wastes your crew. A simple rule sorts callers into three buckets:

Active emergency. Water is currently entering the home, the deck or interior is at risk, a tree is on the roof, or the homeowner has a visible structural concern. These should page the on-call person, regardless of hour.
Soon-but-not-now. Visible damage with no active intrusion: missing shingles, lifted ridge cap, gutter damage, hail dimples on metal flashing, post-storm inspection requests. These usually want a same-day or next-day callback but don't need a midnight call to a crew lead.
Routine. Quote requests, scheduled inspections, warranty questions, gutter or skylight add-ons, repaint coordination, financing questions. These land in the normal queue for office hours.

Your answering service — person, AI front end, or hybrid — needs to ask the small set of questions that reliably sort callers into those buckets. "Is water coming into the home right now?" is the single most useful triage question on a roofing line.

Storm, active-leak, and tarp-request workflows

Three scenarios are worth scripting in advance, because they recur and go badly when the front end isn't ready.

Storm-event surge. After a regional wind, hail, or heavy-rain event, call volume can spike for a day or two. The script should confirm whether the damage is consistent with the recent storm, whether the homeowner has already contacted their carrier, and whether they need an inspection for a claim. It should also be honest that lead times may be longer than usual and offer a callback window rather than committing the crew to a same-day visit.

Active leak with water entering the home. The script should establish how fast water is coming in, whether there are electrical concerns (water near fixtures, ceiling fans, light boxes), and whether the homeowner has placed containers or moved valuables. Then it should page the on-call person, not just queue the message.

Emergency tarp request. Tarps are a distinct service from a repair quote, and a homeowner who needs one tonight isn't in the mood to schedule an estimator next Tuesday. The script should confirm the address, approximate roof slope or number of stories, whether anyone is on-site, and that the homeowner understands a tarp is temporary stabilization rather than a repair. Then route to whoever in your shop handles tarps on call.

Live receptionist vs AI vs voicemail vs hybrid

There's no single right answer, and each option has trade-offs. Here's how I'd think about which fits which shop.

Voicemail-only is the cheapest and the worst at capture. Many homeowners hang up; the ones who leave a message often leave incomplete information. Fine as a fallback for a one-truck shop with a tight after-hours rule, but not a primary plan if you do any meaningful after-hours work.
Live receptionist services put a trained human on every call. They're warm, flexible, and good with elderly or upset callers. They cost more per minute, can have hold queues during storm surges, and depend on the receptionist knowing roofing vocabulary. Some are excellent; some sound like a generic operator reading a checklist. Good fit if your call mix is low-volume but high-touch, or if your customer base skews older.
AI phone answering picks up instantly, handles concurrent calls without a queue, and runs the same triage script at 3 a.m. as at 3 p.m. The trade-off: some callers will recognize they're speaking with AI, and edge cases — heavy accents, very emotional callers, complex insurance questions — are often better handled by a human. Good fit if you regularly miss calls during peak hours, get hit by storm surges, or want consistent intake outside business hours.
Hybrid setups use AI to triage and capture, then route true emergencies to a human on-call or transfer the caller live when warranted. This tends to give the best ratio of capture to cost for shops with uneven call volume, which is most roofers.

If you go the AI route, look for one built around roofing intake rather than a generic receptionist bot. A roofing-aware service should already know to ask about water entry, roof age, and tarp need, instead of treating every call as a generic "service request." This is the lane my own product, OnCrew's roofing answering service built around active-leak intake and storm-damage triage, sits in — but whichever vendor you choose, the test is the same: does the script capture the fields above, and does it sort callers into the three triage buckets correctly?

Setup checklist for the first week

Before forwarding a real customer call into a new answering service, walk through this list:

Write the script in plain language, in the order you want questions asked.
Decide who is on-call for active emergencies, and confirm they accept the page method (text, call, or app notification).
Set business hours and after-hours rules separately. Routine calls at 9 p.m. shouldn't page anyone.
Pick a callback SLA you can hit: same-day for emergencies, next business day for routine. Don't promise faster than you can deliver.
Make sure the service captures the caller's own words, not just checkboxes.
Route messages somewhere your team actually watches — a shared inbox, a CRM, or a team chat, not a generic email no one opens.
Decide what happens if the AI or receptionist can't answer a question. A clean "I'll have someone call you back about that" beats a guessed answer.
Set an escalation path: if the on-call person doesn't acknowledge an active-leak page within X minutes, who gets paged next?

How to test before forwarding real calls

Once the script is built, run a testing pass before any homeowner reaches it.

Call it yourself as a routine quote request. Listen for awkward phrasing.
Call it as an active leak at 11 p.m. Confirm the on-call page fires and reaches the right person within your target window.
Call it as a tarp request and confirm the script asks about stories, slope, and on-site presence.
Call it as a tricky case: a property manager calling for a tenant, or an adjuster asking for a report. See whether the script handles it gracefully or falls apart.
Have a friend or family member call it cold and tell you what felt natural and what felt scripted.
Check the message you receive. Does it contain enough to call the homeowner back without a second discovery question?

A few hours of testing catches the script gaps that would otherwise burn real leads.

Quick reference checklist

Print this and tape it inside the office door:

Active leak with water entering home → page on-call now.
Visible damage, no active intrusion → same-day or next-day callback.
Quotes, inspections, routine work → normal queue.
Required intake fields: name, address, callback number, issue in caller's words.
Confirmation questions: property owner or other, storm involvement, best callback window.
Storm surge days → set expectations on lead time honestly.
Tarp requests → distinct workflow, not a quote.
After-hours routine calls → do not page; queue for morning.
Review captured messages weekly and refine the script.

The goal of an answering service for roofers isn't to replace your relationship with the customer. It's to make sure that when a homeowner with a leaking ceiling reaches your number on a Saturday night, the call gets answered, the right information gets captured, and the right person on your crew hears about it in time to help.

— Abe

Best AI Answering Service for Contractors: An Operator's Evaluation Framework

Abe — Mon, 11 May 2026 20:28:53 +0000

Why I'm Writing This (Disclosure First)

I'm Abe. I founded OnCrew, an AI answering service built specifically for trade contractors — HVAC, plumbing, electrical, roofing. So please read this with the obvious bias in mind: I have a horse in this race.

That said, I've spent enough time with contractor phone systems and enough time with AI voice stacks to think most of the published comparisons online are thin. They're either generic AI receptionist roundups dressed up for trades, or ranking-style listicles that never get into the operational details that actually decide whether a system works in the field.

This article is the framework I'd use if I were evaluating an AI answering service for a contractor today, regardless of vendor — what to test, what to instrument, what to negotiate, and where things tend to break in production. It's aimed at builders and operators, not at people looking for a buyer-link to click.

What Makes Contractor Calls Different

Most general-purpose AI receptionist demos are tested on appointment-style scenarios: a clinic, a salon, a coaching practice. Predictable scheduling, predictable urgency, modest call volume. Contractor inbound is none of those.

A typical residential trade phone hour at 8am on a Monday after a heat wave looks more like:

A backed-up sewer line that needs same-day dispatch
A landlord chasing a quote from last week
A new lead asking what you charge for a tune-up
Three callbacks about a tech who didn't show
A robocall about an auto warranty
A property manager with a building-wide HVAC failure

The system has to classify urgency in seconds, resist obvious robocallers without dropping real leads, pull the right context (existing customer? new lead? warranty followup?), capture enough structured data to dispatch from, and know when to escalate to a human on call.

That's the actual workload. Most consumer-facing AI receptionist marketing is not designed around that workload.

Eight Things I Actually Check

Here's what I'd run through when evaluating any AI answering option for a trade. This applies whether you're a contractor buying or a builder evaluating what to build.

1. Trade-shaped call handling, not generic intake. Does the agent know the difference between "no AC and a baby in the house" and "my AC is loud"? Does it ask for service address before name? Does it know that "water coming through my ceiling" should override every other queue?

2. 24/7 with consistent voice and rules. Real coverage means the 11pm call is handled the same way as the 11am call. Watch for systems that quietly fall back to voicemail outside business hours — that's a marketing claim of 24/7, not a real one.

3. Urgency triage with explicit on-call routing. Triage is only useful if it routes. Where does an "active leak" call go at 2am — pager, SMS to the on-call tech's phone, group text to the dispatch lead? You want a clear answer, not "we send an email."

4. Predictable pricing under volume spikes. Contractor call volume is bursty. Storms, heat waves, refrigerant supply issues, holiday weekends. A pricing model that's fine at 80 calls/month can hurt a small shop at 500. More on this below.

5. Transparent transcripts, recordings, and a real dashboard. If you can't see exactly what was said and what was captured per call, you can't trust the system. This is also where you discover that the agent is mishearing addresses or fumbling specific objections.

6. Configurable alerts that match how you actually work. Some shops want a Slack ping for any new lead. Some want SMS for emergencies only. Some want quiet hours after 10pm except for life-safety. The system should bend to that, not the other way around.

7. Safe dispatch boundaries. This is the underrated one. If your agent confidently books a job for the wrong day, or quotes a price you can't honor, or commits a tech to a window you don't have, you have a problem worse than a missed call. More on dispatch boundaries below.

8. Implementation fit with what you already use. ServiceTitan, Housecall Pro, Jobber, ServiceFusion, Workiz — or no FSM at all and a shared Google calendar. The cleanest agent in the world doesn't help if it can't write into the system your dispatcher actually opens.

The Sample Call Test (Run This Before You Sign Anything)

Don't trust a demo on the vendor's preferred script. Run your own. Here's a starting set I'd use for any HVAC/plumbing/electrical/roofing evaluation:

"Hi, my upstairs unit isn't cooling and it's 94 in the house — how soon can someone come out?"
"Yeah, I had Mike out last Tuesday, the part he ordered — did it come in yet?"
"I'm just calling around for prices on a tune-up."
"There's water dripping through my kitchen light fixture."
"Is this the auto warranty department?" (robocall-style)
"I'm a property manager for a 40-unit building, our boiler is banging."
A caller who interrupts mid-sentence.
A caller with a strong accent or heavy background noise.

You're listening for: did it triage correctly, did it get the address right, did it avoid making promises the business can't keep, did it gracefully escalate when it should have, and did it leave you with a transcript a dispatcher could act on without calling back?

If a vendor won't let you run this against their live system, that's useful information by itself.

Dispatch Boundaries: The Conversation Most Vendors Skip

There is a real engineering decision under every AI answering service: how much is the agent allowed to commit to?

A rough spectrum:

Capture only. Take the message, route it. Never quotes, never books.
Soft hold. Capture the request and a preferred window, mark it pending dispatcher confirmation.
Conditional book. Book inside specific rules (after-hours only, certain trades, certain ZIPs) and confirm via callback or SMS.
Full book. Quote pricing, commit to time slots, send confirmations, optionally take deposits.

Most contractors are best served somewhere between 2 and 3. Full-book autonomy looks great in a demo and tends to break in the field, where the dispatcher knows that Tuesday's truck is down and the new tech isn't ready to take a tankless install yet. Capture-only undersells the technology — you can do better than a glorified voicemail.

When you evaluate vendors, ask exactly where on this spectrum they default to, and how hard it is to change.

Data and Transcripts: What You Should Be Able to Export

If you're a builder or an operator who cares about long-term leverage, ask:

Can I export every call transcript as text? In what format?
Can I export structured fields (caller name, address, problem class, urgency level, requested window) as JSON or CSV?
Are call recordings stored, and for how long? Where?
Is there an API or webhook for new captured calls?
Who owns this data if I leave?

This matters more than people think. Six months of structured contractor call data is a real asset — for training, for marketing, for understanding what your callers actually ask for. A system that silos it is a system that has you locked in.

Alerting and the On-Call Workflow

The agent is one piece. The alerting layer is the other. Build the picture for your business before you buy:

Who is on call right now, by trade, by ZIP, by tier?
What's the escalation path if the first responder doesn't acknowledge in N minutes?
What does "acknowledged" mean — a reply text, a click, an inbound call?
What's the quiet-hour policy and what overrides it?
How does the dispatcher pick this up Monday morning — is there a single queue?

If a vendor's answer to most of these is "we email you," that's a 2010 product with an LLM bolted on the front.

The Pricing Stress Test

Pricing models for AI answering services usually fall into a few buckets: per-minute, per-call, per-resolved-call, monthly subscription with included usage, and hybrid live+AI per-conversation pricing.

Per-minute pricing rewards short calls and punishes complex ones — which is exactly backward for trades, where the high-value calls are often the longer ones. Per-resolved-call pricing sounds clean, but the definition of "resolved" is doing a lot of work.

Build a stress test before signing:

80 calls/month at average length (light month)
200 calls/month (normal)
500 calls/month (storm or seasonal spike)
A hypothetical 1,000-call month

For reference, OnCrew's pricing is Starter at $49/month for 100 included calls. Pro is $149/month for 400 included calls. Multi-Truck is $349/month for 1,000 included calls. Overage on each plan is $0.99/call. I'm dropping that here so you can use it as one anchor in your own modeling, not because it's the right plan for every shop. Run the same model against any vendor you're considering and compare apples to apples on a 12-month projection that includes at least one spike month.

A Short Implementation Checklist

If you decide to roll something out, here's the rough order of operations I'd follow:

Write the actual triage logic in plain English first. Urgency tiers, after-hours rules, the categories you'll never quote.
List your service-area boundaries and your hard "we don't do this" categories.
Decide your dispatch boundary on the 1–4 spectrum above.
Wire alerts into the channels your team already lives in (SMS, Slack, your FSM's notifications).
Run the sample call test against the live system, not a sandbox.
Pilot for 2–4 weeks with daily transcript review. Tune as you go.
Track: missed-call rate, after-hours capture rate, lead-to-booked-job rate, dispatcher overrides per week.
Only after the above, expand the agent's autonomy.

If you want a deeper category-by-category breakdown for the buyer side — trade-built AI versus generalist AI receptionists versus AI+human hybrids versus voice-AI builders versus traditional live answering — I wrote a longer guide on choosing the best AI answering service for contractors that complements the operator-focused framing here.

Categories of Solutions, Briefly

Without naming and ranking specific vendors (the rankings rot fast, and the category fit is more useful):

Trade-built AI: Built for HVAC/plumbing/electrical/roofing call patterns. Tighter triage, better defaults, narrower fit.
Generalist AI receptionists: Industry-agnostic. More configurable in theory, more setup in practice.
AI + human hybrid: Live agents fall back when AI confidence is low. Higher per-conversation cost, often better edge-case handling.
Voice-AI builders: You assemble the agent yourself on top of a voice platform. Maximum control, maximum maintenance burden.
Traditional live answering: No AI. Predictable, human, expensive at scale, quality varies.
Voicemail / forward-to-mobile: The baseline you're trying to beat. If your current setup is this, almost any of the above will move the needle.

There is no universally "best" choice across these categories. The best one is the one that maps to your call volume, trade mix, dispatch model, and tolerance for handing autonomy to software.

Closing

If you're a builder thinking about this space: the interesting problems are not the voice quality. Voice is largely solved. The interesting problems are triage, dispatch boundaries, alerting design, and the data layer. Most of the real differentiation over the next two years will live there.

If you're a contractor evaluating: don't outsource the evaluation to a ranking site. Run the sample calls. Stress-test the pricing. Read the transcripts daily for two weeks. The right answer for your shop is sitting inside that data.

I'm biased — I built one of these. The framework above is the one I'd want a friend in the trades to use whether or not they ended up choosing OnCrew.

— Abe

Virtual Receptionist for Contractors: When a Human Still Wins, When AI Is Enough, and How to Design Safe Intake

Abe — Mon, 11 May 2026 19:45:31 +0000

The framing problem

I run an AI answering service for HVAC, plumbing, electrical, and roofing shops, so I field the "human virtual receptionist or custom build" question constantly. Most online answers are sales pitches for one side or the other. Neither will tell you when their product is the wrong choice.

This post is the version I wish existed when I was first talking to contractor shops. It's aimed at the developer or operations lead who has to wire intake, escalation, and on-call into a working phone system - not the buyer who just wants a logo on a slide.

What "virtual receptionist for contractors" actually has to do

Before deciding human vs AI vs hybrid, get specific about the job. A contractor receptionist is not a generic switchboard. On a missed call, the system should:

Pick up before voicemail (many service callers will not leave one).
Identify whether the call is a current customer, new lead, vendor, or spam.
Decide whether the situation is routine, urgent, or potentially life-safety adjacent (gas smell, fire or smoke, electrical hazard, medical concern), versus a property emergency (active flooding, sewage backup, no heat in extreme conditions).
Capture structured intake: address, access, equipment, symptom, timing window, callback number.
Hand off cleanly - to a live person, a queue, or a structured ticket - without making commitments the shop hasn't approved.

The design decisions that follow come back to this list.

The decision framework

Put the question on three axes: call complexity, hours of coverage, and tolerance for variance.

Use a human virtual receptionist when:

Intake genuinely requires unscripted judgment - commercial bid coordination, multi-trade scope clarification, insurance restoration.
Call volume is low enough that per-minute pricing beats per-call, and you want a human relationship with the caller.
You have a regulated context (life-safety adjacent) where you want a credentialed human in the loop.

Use an AI phone agent when:

Intake is largely structured: name, address, problem, urgency, callback.
You want consistent capture on routed calls, including 2 a.m. and during storm spikes when a human queue would be drowning.
You can tolerate the agent saying "I'll take your details and have someone from the shop call you back" instead of trying to be the dispatcher.

Use a hybrid when:

AI carries off-hours and your in-office human handles weekday business.
AI does triage and structured capture, then warm-transfers to a human for anything ambiguous, sensitive, or high-value.

There's no virtue in picking the "modern" option if your call patterns don't reward it. A two-truck shop with a strong office manager often needs better overflow, not full replacement.

For a deeper comparison along these lines, I wrote up AI phone agent vs virtual receptionist for contractors separately - this post focuses on implementation.

The intake checklist (use regardless of human or AI)

Whether you're scripting a human VR or designing prompts for an AI agent, the captured fields should be the same. If they aren't, your dispatcher does double work for some calls and not others, which is how tickets get dropped.

Minimum structured fields per call:

Caller name and best callback number (confirm the number aloud; don't trust caller ID).
Service address, including unit/suite and gate or access notes.
Trade and equipment: "kitchen sink, garbage disposal" beats "plumbing problem."
Symptom in the caller's words, not paraphrased into jargon.
Onset and duration: "started this morning" vs "leaking for two weeks."
Urgency signal, captured without diagnosing: water actively spreading, no heat in extreme conditions, smell of gas, signs of electrical hazard, sewage backup.
Existing customer flag and any account or job number.
Time window the caller can be available.
Source (referral, ad, search, returning customer).
A free-text "anything else we should know" field - real gold usually lives here.

If a human VR can't deliver these consistently, they're providing call screening, not intake. If an AI agent can't, your prompts and tools are wrong - a fixable engineering problem, not a fundamental limit.

Risk boundaries: what intake should never do

This is where I see the most damage from over-eager AI deployments and over-empowered human VRs. Intake is not dispatch. Your intake layer - human or AI - should not:

Promise an arrival time. ETAs depend on truck location, current job status, and parts availability, none of which intake sees.
Assign a specific technician.
Diagnose the problem ("sounds like your capacitor").
Quote prices or commit to warranty coverage.
Make life-safety decisions. For immediate danger - gas smell, fire or smoke, electrical hazard, or any medical or life-safety concern - direct the caller to emergency services or the relevant utility first, then capture details for the shop. For property emergencies like active flooding or sewage backup, capture the situation and escalate to on-call without diagnosing or promising a specific response time.

On the AI side this is a tool-design problem: don't give the model a set_eta or assign_tech tool if you don't want it making those calls. On the human side, it's a training and script problem. Either way, make the boundary explicit, in writing, and audit it.

Implementation: a call flow that doesn't pretend

Here's the skeleton I recommend for contractor intake, regardless of which provider sits behind it.

inbound_call
  -> greet (shop name, identify as answering service if applicable)
  -> classify (existing | new | vendor | spam
              | life_safety_signal | property_emergency)
  -> if life_safety_signal (gas smell, fire/smoke,
                            electrical hazard, medical):
        direct caller to emergency services / utility first
        capture minimum fields
        page on-call via configured channel
        close without diagnosing or quoting timing
  -> else if property_emergency (active flooding, sewage backup,
                                 no heat in extreme weather):
        capture minimum fields without diagnosing
        page on-call via configured channel
        close with "someone from the shop will follow up; if the
                    situation becomes a safety issue, please contact
                    emergency services or your utility"
  -> else:
        run intake checklist
        confirm callback number by repeating digits
        set expectation: "someone from the office will follow up
                          by [window]"
        close
  -> on each branch: write structured ticket to CRM/queue + audio
                     + transcript
  -> on each branch: emit observability event (latency, classification,
                                               escalation taken)

Two things to notice. First, the closing line should not commit the shop to an action it can't keep. "Someone will follow up by [window]" is honest; "we'll have a tech out within the hour" is not. Second, there's no branch where the call ends without writing a structured record. A virtual receptionist that doesn't leave a queryable trail is a black hole.

The pragmatic hybrid

For many shops between two and twenty trucks, the model that holds up best is:

AI handles first-touch on routed calls, 24/7. It captures structured intake, classifies urgency, and writes the ticket.
A live human (in-office, or contracted for specific hours) gets warm-transferred for: explicit "I want to talk to a person," ambiguous classification, repeat callers on the same issue, and any call the AI flags as outside its competence.
The on-call rotation gets paged on emergencies, with structured intake already attached so they're not re-interviewing from scratch.
Office staff sees the same ticket queue regardless of who took the call, with provenance ("captured by agent" / "captured by [name]") preserved.

This split keeps human judgment where it pays off without paying a per-minute rate for "what's your address" hundreds of times a month.

Pricing reality check

If you're evaluating providers, do the math on your actual call mix, not the marketing comparison. Human VR services typically bill per minute plus a monthly base, with rates that vary widely. AI providers generally bill per call or per minute at lower rates. For reference, OnCrew's plans are Starter at $49/mo for 100 calls, Pro at $149/mo for 400 calls, and Multi-Truck at $349/mo for 1,000 calls, with $0.99/call overage. A long human call is typically more expensive than a short structured intake with AI, and either is usually cheaper than a missed call on a real job.

What to build, what to buy

If you're a developer at a contractor shop, the buy/build question comes down to whether your differentiator is in the call layer. For many shops, it isn't - the differentiator is the trade work and the dispatch quality. Buying intake (AI, human, or hybrid) and integrating it into your CRM is usually the right call. Building from scratch is justified mainly if you have unusual integration needs or you're a multi-state operator with a real software team.

What you should own, even when buying: the structured ticket schema, the escalation tree, and the observability around classification accuracy. Those are the parts that determine whether the system is serving the shop or just transcribing voicemail in a nicer voice.

Founder disclosure

I'm Abe, and I run OnCrew, an AI answering service built for HVAC, plumbing, electrical, roofing, and other contractor shops. OnCrew does intake, triage, summaries, and configurable alerting - it does not dispatch, does not promise ETAs, and does not pretend to be the human in the chair. I tried to write this post the way I'd want one written if I were the operations lead on the other side of the table. If you disagree with any of the framing above, I'd genuinely like to hear it in the comments.

Answering service for electricians: what the intake has to capture before the callback

Abe — Mon, 11 May 2026 19:44:53 +0000

Hey, I'm Abe, founder of OnCrew. We build AI phone intake for HVAC, plumbing, electrical, and roofing shops. This post is about a corner of that work I think generalizes if you are designing any contractor-facing telephony layer: what an answering service for electricians actually has to capture before a callback can be useful, and where naive intake breaks down. I'll keep it technical and skip the marketing.

Most generic "phone agent" demos online are built for small business reception. Name, callback, message, done. For electrical work, that intake is both unsafe and lossy. The reason: electrical service spans a wider risk band than almost any other trade, from "ceiling fan install next Tuesday" to "panel buzzing and faint smell of burning." The intake has to know enough to tell those apart, and the post-call handoff has to route them differently.

Let me walk through how we model this in practice, and what I'd want anyone building in this space to think about before they ship.

Why trade-specific intake is its own design problem

If you have ever built a chat or voice agent over an LLM, you know the temptation is to write one big system prompt and hope the model handles every case. That works in low-stakes domains. It does not work for electrical, for two reasons.

Electrical-emergency language is unusual and partial. Callers often do not know the right term. They say "the wall outlet got hot" or "there's a clicking sound from the basement box" or "the lights went brown for a second." A general agent will reply politely and book a callback. A trade-tuned intake recognizes those as panel, arc, and brownout signals, and follows up specifically.
Life-safety branches must be deterministic, not improvised. If a caller says "I smell something burning," the system has to do a small number of specific things in a specific order. Reaching that branch by free-form LLM reasoning is not acceptable. We treat it as a hard rule above the model.

So in practice, the intake is a hybrid. An LLM-driven dialogue grounded by a structured slot-filling schema, with a small set of deterministic escalation rules that take priority over the model's natural conversational flow.

The minimum intake schema

Roughly what we try to capture on every call. I'll write it as a typed sketch so it is easy to translate into whatever your stack is.

type Intake = {
  caller: {
    name: string
    callback_number: string
    relationship: "owner" | "tenant" | "property_manager" | "other"
  }
  location: {
    address_line1: string
    unit_or_suite?: string
    city: string
    access_notes?: string  // gate codes, dogs, parking
  }
  issue: {
    description_verbatim: string  // caller's own words, not normalized
    category?:
      | "panel"
      | "outlet_or_switch"
      | "lighting"
      | "ev_charger"
      | "generator"
      | "new_construction"
      | "unknown"
    power_state: "on" | "partial" | "off" | "unknown"
    visible_damage: boolean | "unknown"
    smell_or_smoke: boolean | "unknown"
    sound: "buzzing" | "clicking" | "popping" | "none" | "other" | "unknown"
    injuries_reported: boolean
    occupants_present: boolean | "unknown"
  }
  scheduling: {
    preferred_window?: string
    flexibility: "asap" | "today" | "this_week" | "flexible"
  }
  urgency_flag:
    | "life_safety"
    | "same_day"
    | "next_business_day"
    | "routine"
  raw_transcript_url: string
  recording_url?: string
}

A few choices worth flagging:

description_verbatim is preserved before any normalization. If you reduce the caller's words to a dropdown, you lose the signal the dispatcher uses to confirm urgency in the morning.
urgency_flag is derived, not asked. The caller does not pick it. The intake derives it from the issue slots and a small set of trigger phrases.
"unknown" is a first-class value everywhere. Forcing booleans into yes/no when the caller does not know produces false signal and bad routing.

The triage state machine

The reason intake fails for electricians is almost always at the triage step, not the capture step. So this is the part I'd encourage anyone building in the contractor space to take seriously.

We model triage as a small state machine that runs in parallel with slot-filling. Roughly:

                          (any trigger phrase: smoke, burning,
                           sparking, shock, downed line,
                           panel buzzing, exposed wire, fire)
                                        |
                                        v
   [initial] --> [gathering] ------> [life_safety_branch]
                     |
                     | (no triggers, but panel,
                     |  partial power, outlet hot,
                     |  EV charger smoking)
                     v
                  [same_day_branch]
                     |
                     | (work request, no urgency signals)
                     v
                  [routine_branch]

Each branch has its own continuation prompt, its own required slots, and its own handoff behavior. The life-safety branch in particular does three things the others do not:

It tells the caller, in plain language, that for active fire, smoke, or shock, they should call 911 immediately, and for a downed power line they should call the utility's outage number. We do not replace those numbers. We do not claim to.
It still finishes intake in parallel, because the dispatcher will need the address and details regardless.
It triggers a higher-priority handoff to the on-call workflow (page, SMS, ring group, whatever the shop has configured) with the urgency flag visible.

I want to be specific about something. The intake is not a diagnostic tool. It does not tell the caller whether it is safe to flip a breaker back on. It does not tell them whether the outlet is okay. It captures details and flags urgency. The shop's licensed electricians decide the rest. Any system that pretends to do more than that with a homeowner on the line is taking on liability it cannot back up.

Handoff design

The handoff is where most AI phone systems quietly fall apart. The call ends, the recording lands somewhere, and nothing happens until a human opens a dashboard. For after-hours electrical, that is the same as voicemail.

Three patterns we have found useful:

Per-shop routing config. Every shop sets, in plain config, what happens at each urgency level. Routine calls go to email or the CRM only. Same-day calls fan out to a dispatch SMS group during business hours and to the on-call phone after hours. Life-safety calls alert the on-call electrician immediately, regardless of clock. Hardcoding any of this is a mistake. Different shops want different thresholds.
Idempotent webhook fan-out. When the intake completes, we POST a structured payload to every configured destination, with a stable call id so retries are safe. CRMs, FSM tools, dispatch boards, and a Slack or Teams channel all sit on the same webhook contract. Retries are exponential. Failures alert.
Transcript before summary. The shop owner gets the structured summary first, but the raw transcript and recording are always one click away. When an ambiguity comes up the next morning, the summary is not the source of truth. The recording is. A surprising number of disputes resolve by listening to thirty seconds of audio.

Failure modes worth designing around

A non-exhaustive list of cases that break naive implementations:

Repeat callers during storm spikes. During a wind event, call volume can jump several times normal in under an hour. Your intake has to be stateless enough to handle bursts, and your handoff has to dedupe by address so the dispatcher does not see the same outage twice.
Wrong-number and prank calls. If you do not filter these at the intake layer, every one becomes a "lead" in the CRM and the value of the CRM data collapses. We classify and drop, but keep the recording for audit.
Callers in another language. Detect early and switch the intake. Do not force a Spanish-speaking caller through an English script. You lose the job and produce a bad experience.
Carrier handoffs and ringback. If the shop's existing number is forwarded conditionally, you need to handle "the line was already ringing" gracefully. Otherwise you queue duplicate intakes on the same call.
PII in transcripts. Recordings and transcripts contain addresses, names, and sometimes credit card spelling. Treat them like the sensitive data they are. Encrypt at rest, scope access, and keep a retention policy you can defend.

What this means if you are evaluating one

If you are building or comparing an answering service for electricians, here are the questions I would ask, regardless of vendor:

What is the schema you capture, and is urgency_flag derived or asked?
Are life-safety branches deterministic, or are you trusting the LLM to improvise around fire and shock?
Where is the handoff contract documented, and is it idempotent?
Can the shop owner configure routing per urgency level without filing a support ticket?
Do you preserve verbatim language and raw recordings, or only summaries?

Generic voice agents will not get those right by accident, because they were not designed for this trade. The reason we built OnCrew the way we did is that picking up the phone is the easy part. Capturing the right details, classifying urgency without overclaiming, and routing the result through a workflow the shop actually trusts is where this work lives.

For context on the OnCrew side: trial is 14 days, no charge today, cancel anytime. Pricing is included-call tiers with $0.99 per call on overage. The product page linked above covers the trade-specific details.

If you are building something adjacent in contractor telephony or field-service automation and want to compare schemas or triage logic, I am happy to talk shop in the comments.

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.