Turning recorded calls into knowledge-base documents
Customer-service calls carry a large amount of durable product knowledge — how to reset a password, what a package includes, which limits apply — that exists nowhere else in writing. New staff learn it by asking colleagues; customers cannot find it at all. This system reads the recordings and writes the documents.
What it does
Each recording is read once and broken into single, self-contained facts — one statement about a product, a rule, a step, a price. Anything that is only true for one particular customer is thrown away, which is also why almost no personal detail survives: personal details are, by their nature, specific to one case.
Every fact that remains is then labelled twice: what it is about, which decides the document it lands in, and what kind of statement it is, which decides the section. Those two labels place a fact exactly, and the documents assemble themselves.
Each document draws on many calls at once. No single call contains a complete procedure — an agent walks one customer through the first few steps and another customer through a later problem. The pipeline collects those fragments and rebuilds the whole sequence. The password-reset instructions in Account Access were assembled from 59 separate conversations.
How a page is laid out
Every document has the same three levels — the thing, the kind of information, and the specific task a reader is looking for.
# R-Web ← what it is about
## How To ← kind of information
### Resetting a forgotten password ← the task a reader looks for
1. ...
2. ...The structure is not decoration. When someone later searches the knowledge base, each passage carries its full heading path with it, so a retrieved answer arrives already saying which product and which task it belongs to.
What was tested, not assumed
| Decision | Why |
|---|---|
| Read the whole recording, not the call summary | Every call already had a short written summary attached. Testing both on 50 matched calls, the full recording produced far more usable knowledge — and almost all of the difference was step-by-step instructions, which a summary compresses into a single sentence. |
| Knowing the product names matters, a lot | Told what the company sells, the system uses the real brand names. Not told, it invents descriptions like “Advertising Services” and the same product ends up split across several pages. Supplying the list halved the number of duplicate topics. A business with no such list can have one worked out from a sample of its own calls. |
| Group by the facts, never by the label | The same product arrives under a dozen different names that have to be merged. Judging that by the name alone goes wrong: “Gold Package” reads like a website plan and was filed under the website product — but the facts underneath were about keyword guarantees and AI search results, an SEO package entirely. Showing the facts alongside each name fixed it, and revealed that three separate products each have a tier called Gold. |
| Decide the sections from the calls, not in advance | The original version had a fixed list of seven section types. It described a software company, and it was wrong even for one: 43% of the sections it produced held a single item, because a slot existed rather than because there was anything to put in it. See below. |
Why it works for any business
Nothing here is written for a software company. The system does not have a fixed set of section types — it invents a label for every fact it reads (175 different ones here), then groups those into the 5 sections these documents actually use. A section survives only if enough facts support it.
Run unchanged over a small English bakery’s calls — with no customer IDs, no product list, and no settings beyond its name and language — it produced a different structure, including an Opening Hours section that could not have existed under a fixed list, and dropped a section that survived here.
What you should not yet trust
Nothing checks these documents against the recordings. A wrong sentence looks exactly like a right one. Review them before treating them as authoritative.
These are things agents said, not approved company policy. Where agents contradicted each other the text says so rather than picking a winner — that is a flag for a person, not a resolution.
Prices and dates carry no expiry. Everything is recorded as stated at the time of the call.
Small topics are not yet carried forward. 24 topics had too few facts for a page. Some never will; others are thin only because this is one month of calls. For a monthly run those must be kept and promoted once they grow — discarded, they can never reach the threshold.