What buyers really ask on sales calls

Some of AHA’s best market research was sitting in sales-call transcripts: what buyers ask before they spend money, and how well the answers land. Reading them by hand doesn’t scale, and they’re a noisy mix of English, Hindi and Hinglish, with broken speaker turns and speech-recognition errors.

Two models, two jobs

I built a two-stage pipeline with Claude Code.

Stage 1: Claude Haiku 4.5, once per call. Each transcript, about 10 KB on average, goes to Haiku with strict rules:

• pull out only the distinct questions the buyer raised, skipping small talk and confirmations;
• rewrite each in clear English, keeping the meaning rather than translating word for word;
• pair it with the rep’s actual answer, or none if they deflected;
• tag it with one of 14 fixed topics, from pricing and installation to internet and offline use;
• mark whether it was handled well: specific, confident and on the question.

The reply is strict JSON. Eight calls run in parallel, and each result is cached on disk.

Stage 2: Claude Sonnet 4.6, once across everything. Sonnet gets every pair in one request and treats near-duplicates as one question. The prompt’s own example: asking whether it works without internet and asking whether it needs wifi count as the same thing. It ranks the questions, picks the single best answer on record for each, and lists coverage gaps. Where no strong answer exists, it says so and asks for one to be scripted rather than inventing it.

Messy output, cheap retries

Haiku sometimes wraps its JSON in code fences or adds a sentence after it, so the parser pulls out the first balanced JSON object instead of trusting the whole reply. On the first full pass, about one call in ten came back unparseable. Because finished calls were cached, the re-run touched only those, and every one went through.

What buyers ask

The average call yields five to six buyer questions. Counting Haiku’s topic tags per call, questions about the demo or a visit come up most, in about 71% of calls, then product features (64%) and pricing (60%). Internet and offline questions come up in about 29%.

Most answers held up: Haiku marked about 87% as handled well. The value was in the rest. Sonnet found 8 questions where the answers on record were vague, missing or contradicted each other, including what a maintenance contract covers after the first year, how a smart lock differs from a digital one, how much automation saves on electricity bills, and what happens to support if a product line is discontinued.

The report is laid out as a video shot-list for the marketing team: each gap is a topic waiting for a script, and each strong answer is a starting draft.

Models cluster, code counts

Sonnet is good at merging near-duplicates and picking the best answer. It isn’t a counter. Stage 2 gets a flat list of questions with no call IDs, so its “asked in about N calls” figures are estimates, and they don’t survive a recount: for most of the eight gaps, the estimate was several times the number of calls whose extracted questions mention the topic. That’s why the shares above come from counting Haiku’s tags, not from the report. Read the report as a list of themes and weak answers, not as statistics.

Where it lives

It runs inside the nightly sync as a non-fatal step. Only new transcripts are extracted, and the clustering is skipped when nothing has changed. The report is stored in the database, so the Questions tab on the Calls page updates without a redeploy. Beside it, a Lead Notes tab shows a short summary that Claude Haiku writes for any lead whose CRM notes changed since the last run.

The top questions had a second life too. With AHA’s name stripped out, they became 21 of the 31 questions in the AI-search tracker, which asks AI assistants what buyers ask and checks whether AHA comes up.

What I’d reuse

1. Cheap model per item, strong model once. Haiku reads every call; Sonnet sees them all together.
2. Fix the categories up front. Fourteen topics can be counted; free text can’t.
3. Cache per item. A failed call should cost one retry, not a full re-run.
4. Extract the answers, not just the questions. The weak answers are where the work is.
5. Let models cluster and judge; count with code. It’s the same reason I don’t let the LLM do the maths.