Conversation Intelligence for Home Services: How to Find Out Why Calls Do Not Book Before You Buy a Platform
Every call that does not turn into a booked job is money your marketing already paid for. If you record your calls, those recordings can tell you exactly where bookings are lost, and AI can now read all of them for under $5 per hundred calls instead of a manager spot-checking a few. This post shows how that works, when to buy software and when to build it, and how to start with no budget at all.
Conversation intelligence is software that records calls, transcribes them, and turns the transcripts into something you can count. The category was built for B2B sales floors (teams selling to other businesses): talk ratios, competitor mentions, deal risk, coaching scorecards for thirty reps.
A home service business has a different call line and a narrower question. Somebody's dryer is broken, they call, and the call either ends with a booked job or it does not. The only question worth paying to answer is: when it did not, why not?
This post is about answering that question from your own recordings, with a pipeline cheap enough to run on every call.
What does conversation intelligence mean for a home service business?
It means three things, in this order:
- Every call becomes text, all of them, rather than a sample or the calls a manager happened to spot-check.
- Every call gets one outcome label from a fixed list. Booked, lost on price, lost with no close attempt, out of service area, not a customer, unclear.
- Every label carries the quote that justifies it. So a manager can check any call in ten seconds without listening to it.
Sentiment curves, talk-to-listen ratios and keyword clouds are not on the list. They are useful on a sales floor with long calls and many reps. On a dispatch line with two or three people answering short calls, they add dashboards without adding decisions. What a small dispatch team needs instead is covered in why I built a field service dispatch board.
Should you buy a platform or build the pipeline?
Buy if your calls already live inside a call-tracking or contact-center product that offers this as an add-on, your outcome categories match the ones it ships with, and nobody on the team will maintain code.
Build if any of these is true:
- Recordings are spread across more than one system, such as an ad platform, a CRM and a phone provider, and no single vendor sees all of them
- Your definition of a lost booking is specific to your trade, your service area or your pricing policy
- You want the transcripts to do a second job, such as disputing invalid paid leads, which a coaching tool will not do for you
The account I built this for met all three. Recordings came from the ad platform and from the CRM, and the second job turned out to be worth more than the first.
How does the pipeline work?
Three steps, each one a small script. In the diagram, an LLM is the AI model that reads each transcript, JSON is a structured data format, and temperature 0 tells the model to give the same answer every time:
recordings/*.mp3
|
v
[1] transcribe Whisper, speech to text
| transcripts/*.txt
v
[2] classify one LLM call per transcript, strict JSON out, temperature 0
| results/*.json
v
[3] report aggregate to CSV, check the distribution, print a summary
| Step | Tool | Cost |
|---|---|---|
| Pull recordings | CRM or ad platform API | Included |
| Transcribe (turn audio into text) | OpenAI Whisper API (about $0.006 per minute), or faster-whisper locally for free | $0 to cents per call |
| Classify | Claude, one call per transcript | About $0.01 to $0.03 per call |
| Report | Python | Free |
Measured cost on the real runs: under $5 per hundred calls. An anonymised version of the pipeline is public as call-audit-demo, MIT licensed, with local transcription and no client data. It runs on the sample transcript without audio or an API key.
What design rules keep the output trustworthy?
These three rules matter more than the model choice.
The model classifies and never supplies a fact. It picks a label from a fixed list and nothing else. Durations come from the file, dates from the filename, counts from the report script. A model asked for a number will produce a plausible one, and a plausible wrong number in a call report is how a team ends up fixing the wrong problem.
Every label carries a verbatim quote. The evidence field is a span copied from the transcript. If the model cannot quote a span that supports the label, the call comes back as unclear instead of as a guess. This is what makes the report something a manager trusts after checking five calls rather than something they ignore.
Check the shape of the output, not just for errors. The report step fails loudly if one label suddenly takes an implausible share, if unclear jumps, or if every confidence score comes back the same. The expensive failure in an LLM pipeline is not a crash; it is valid-looking JSON for every call while the labels have quietly turned into noise. More on that in monitoring LLM outputs.
What did it find on a real call line?
The first run covered 100 calls. Three patterns came up again and again, and none of them appeared in any dashboard, because every one of those calls was logged as completed with a normal duration:
- The passive close. Customer: "Let me call you back." Dispatcher: "Okay, thank you." There was no offer to hold the slot and no follow-up time. The customer did not call back.
- The dropped line nobody returned. One recording was five minutes of "hello? hello?" after the line dropped. Nobody called the number back.
- The refused estimate. A customer asked for a rough price on a belt replacement, the dispatcher said a technician had to see it first, and the call ended thirty seconds in. A range with context would have kept the customer on the phone.
What each pattern costs and how to coach it out is covered in why paid leads do not close, so I will not repeat it here.
The bigger finding came when the pipeline read a full month of recordings. The booking rate on the CRM record was 49%. Matched against the calls, the true rate was 56%, because callbacks made from a second number never attached to the original lead. The team had been treating a seven-point leak that did not exist as a sales problem. The actual problem was attribution, and it changed what the next month of work was spent on. That gap is the subject of the attribution gap piece.
What is the second job the transcripts do?
On Google Local Services Ads you pay per lead, and Google credits back leads that were never real customers: wrong service, outside the area, spam, job seekers. The same transcripts that label lost bookings also label invalid leads, with the quote that proves it. That turns disputing into a filing exercise instead of a listening exercise. How the filing runs category by category is in disputing LSA credits at scale, and the service is Google Local Services Ads lead audits.
How do you start with no budget?
You do not need the pipeline to start. Take the last 20 to 30 recorded calls that did not book, listen to them, and write one line per call: what the customer wanted, and the moment it ended. One or two patterns will cover most of the list. That list is your taxonomy (your own set of reasons a call is lost), and it is the part that takes judgement. The pipeline only makes it run on every call instead of thirty.
What not to do first: buy a platform, accept its default categories, and wait for the dashboard to tell you something. The categories are the work.
What to do with this
Start this week without buying anything: pull 20 to 30 recent calls that did not book, listen, and write one line per call on what the customer wanted and where the call ended. The two or three reasons that keep coming up are what your dispatchers need coaching on, and they are the categories any software should sort calls into later. Before you trust the booking rate in your CRM, check it against the calls themselves, because on one account it read 49% when the real rate was 56%. If you pay for Google Local Services Ads, the same transcripts can support disputes for invalid leads, described on LSA lead recovery.
I build these pipelines for home service operators, from pulling the recordings to a report the dispatch lead actually reads. If your booked jobs are not following your lead volume, send me a line or see AI automation.
Related:
- You Don't Have a Lead Problem. You Have a Conversion Problem You Can't See.
- How to Dispute LSA Credits at Scale: $13,000+ Recovered in One Cycle
- The Website Produced 75 Real Leads Last Month. The CRM Knew Where Three of Them Came From.
- n8n Postgres Disk Full at 3 AM: How an AI Phone Bot Went Down and the Retention Settings That Prevent It