We have call transcripts. What should we do with them?

In this guide

• Start with the decision the analysis should support
• Follow one call from words to questions
• Keep the customer's question distinct from your interpretation
• Turn the finding into an action someone can own
• Look across calls before calling something a pattern
• Judge an analysis tool by the questions you can use

THE SHORT ANSWER

Use the transcript as evidence: extract the questions the customer needs answered, keep the supporting wording, and record what was answered or left open. Review similar questions across calls to decide whether to improve information, a process or staff training. A transcript makes a conversation readable; the analysis helps you decide what to do about it.

You have a folder of call transcripts. They are searchable, and perhaps each one has a neat summary. But when someone asks what customers are struggling with or what the team should improve, you still have to read them all.

The next useful step is to extract the customer's questions. Preserve enough evidence to check each one, distinguish an answer from an unresolved request, and use those findings to make a decision. This article follows one fictional call through that process; the examples are illustrations, not results from a customer deployment.

Start with the decision the analysis should support

Choose a practical question before processing the folder:

• Which customer questions need clearer answers on our website?
• Which promises need follow-up in our existing work queue?
• What should we practise with a new teammate?
• Which recurring problem needs an operational change?

Those tasks need different outputs. A callback requires a verified next action and owner. A reusable help page needs a general question and a correct answer. A pattern report needs comparable records across calls.

For a single case, reading the transcript may already be enough. More analysis is useful when it removes repeated reading or reveals something you need to act on. Avoid collecting fields that nobody will use.

Follow one call from words to questions

Here is the fictional source excerpt. The timestamps are illustrative.

00:18 — Customer: I paid for delivery tomorrow. Does that include carrying it upstairs? There's no lift.

00:26 — Staff: Standard delivery is to the building entrance. I'll ask dispatch whether an upstairs service is available and call you by three.

00:39 — Customer: If that costs extra, can I collect it instead?

00:44 — Staff: I need to check whether the warehouse has released it. I can't confirm collection yet.

A summary might say: “Customer discussed delivery arrangements; staff will check options.” That is readable, but it loses the specific questions a help-page editor or operations lead needs.

The following extraction keeps those questions separate.

On a phone, scroll the table sideways to see every column.

Extracted customer question	Supporting evidence	What the call establishes
Does delivery include carrying the item upstairs?	Customer at 00:18; staff at 00:26	Staff says standard delivery ends at the entrance; upstairs availability remains to be checked
Can I collect the item instead if upstairs delivery costs extra?	Customer at 00:39; staff at 00:44	Collection is not confirmed; warehouse release needs checking

The question wording is a paraphrase. The references let a reviewer check it against the source. The staff member's description is evidence of what they said, not independent proof of the current delivery policy.

Notice what the extraction does not establish: a confirmed surcharge, collection eligibility or a successful callback. It also does not tell us whether delivery happened on the requested day. Those facts require other evidence.

Keep the customer's question distinct from your interpretation

“Delivery” is a topic. “Does delivery include carrying it upstairs?” is the question. “Our delivery description may be unclear” is a hypothesis to investigate.

Keeping these separate prevents a broad label from hiding a useful detail, or a plausible interpretation from becoming a claimed fact. Intercom's conversation-topics documentation describes categorising conversations and exploring them by topic. A question-level record can help you examine exactly what customers needed within a category; this is a suggested workflow, not a claim that another product implements the same extraction.

Customers do not always speak in question marks. “I still haven't received the refund” may express a need to know its status. You can record an inferred question such as “What is happening with my refund?” if the surrounding conversation supports it, but label that wording as inferred. Do not invent a request for compensation or a reason for the delay.

If the transcript is unclear, leave the finding uncertain. A sentence with a missing “not,” an incorrect date or the wrong speaker can reverse the meaning. For mixed-language calls, check capture, transcription and meaning separately before trusting the extracted questions.

Turn the finding into an action someone can own

The fictional call suggests several possible next steps. They belong in different places:

For this customer: Confirm that the promised dispatch check has an owner in the actual follow-up system. Check the current case status before creating duplicate work. The transcript records a promise; it does not show that the promise was fulfilled.

For customer information: Compare the current delivery description with the actual service rules. If the description omits the entrance-only boundary, propose clearer wording where people choose delivery. Have the policy owner confirm it before publication.

For staff training: Practise distinguishing an available service from an option that still needs checking. Use an adapted example and the verified policy, as in the customer-call training guide.

For operations: Investigate whether staff have a dependable way to check upstairs-service availability and warehouse release. If the information is inaccessible, rewriting a script will not fix that access problem.

The GOV.UK Service Manual recommends using support feedback to improve the service and involving the people who handle enquiries. The practical application here is to bring the source-backed question to the person who can change the answer or process.

Choose one improvement to investigate, give it an owner and decide what you will review afterwards. You do not need to turn every question into a new project.

Look across calls before calling something a pattern

One conversation can reveal a real issue worth fixing. It cannot establish how common that issue is.

For a fictional batch of ten reviewed calls, suppose three ask whether delivery includes stairs. Report “3 of 10 reviewed calls,” with the scope and coverage, rather than “30% of customers are confused.” The reviewed calls might not represent all callers, and callers do not represent everyone who buys.

Group questions that need the same answer and count distinct calls. Keep “Can you carry it upstairs?” separate from “Can I choose a delivery slot?” even though both concern delivery. For the full ledger and counting method, use the recurring customer questions guide.

Then check several examples behind the group. Perhaps the information is missing, perhaps customers cannot find it, or perhaps a service exception needs individual help. Choose the response that fits: improve an FAQ, investigate a process or bring evidence to a weekly management brief.

After a change, compare similar periods and check customer outcomes as well as question counts. Fewer calls alone cannot tell you whether the answer improved.

Judge an analysis tool by the questions you can use

When trying a tool, use material your organisation has approved for that workflow. Start with a small set you can review yourself, including clear questions, several questions in one call and an ambiguous example.

Check whether the output:

• Preserves each distinct customer question rather than flattening the call into a broad topic.
• Lets you verify the finding against the source wording.
• Distinguishes confirmed answers, promises and unresolved requests.
• Leaves unsupported details unknown.
• Produces a finding useful enough to guide a real next step.

Call Nerd's emphasis is extracting and analysing customer questions from usable handled-call recordings, with recurring questions and management briefs. Transcription provides the source material for that work. The value to assess is whether the reviewed findings help your team understand what customers need and choose a useful improvement.

The deployment uses approved Android phones, with capture and language fit checked on real samples. It does not automatically fix a delivery process, publish your FAQ or complete the follow-up work. Keep the source, the finding and the decision connected so a neat report can lead to something your team actually does.