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. This POC extracts that knowledge automatically and shapes it for the R-Knowledge ingestion pipeline.
What it does
Each call transcript is read once and reduced to atomic claims — single, self-contained statements of fact about a product, policy, procedure, limit or price. Claims that are only about one customer are discarded. The remainder are grouped by subject (the thing they are about) and by kind (the form of knowledge they represent), and each group is written up as one section of a document.
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.
Document shape
Every document follows the same three-level structure, chosen to match how the backend’s structure-aware splitter chunks and embeds content.
# R-Web ← subject
## How to ← kind
### Resetting a forgotten password ← task
1. ...
2. ...The splitter builds a breadcrumb of the full heading path and prepends it to every chunk, so a retrieved passage arrives carrying its product name and task — inside the embedded text, not merely as metadata.
What was measured, not assumed
| Decision | Why |
|---|---|
| Raw transcript, not the call summary | An A/B over 50 matched pairs found the transcript yields materially more usable knowledge, concentrated in long calls and overwhelmingly procedural — the step-by-step material summaries compress away. |
| Product names taken from company records | Every call record lists the products that customer owns. Those products are not
necessarily what the call was about, so the list never decides a document’s subject
— a customer who owns R-Web may be calling about a password reset. Read across all
976 calls, though, it is the company’s own list of product names. Supplying it cut
the number of distinct subject labels from 411 to 229 and produced real names like
R-Web and AdPro in place of invented descriptions. |
| Grouping decided by the facts, not the label | One product arrives under many different labels, which then have to be merged. Judging that from the label alone goes wrong: “Gold Package” reads like a website plan and was filed under the website product, but the facts beneath it were about keyword guarantees and AI search results — an SEO package. Showing two example facts next to each label corrected it, and revealed that three separate products each have a tier called Gold. |
| Classification, not clustering | Similarity clustering chained unrelated facts — at one threshold a single group held 87% of the corpus. The task has a knowable label set, so it is classification. |