Customer-support calls contain more than questions and answers. Important facts, diagnostic checks, assumptions and exceptions may be spread across many turns, interrupted by repetition or unrelated conversation. A transcript or whole-call summary does not preserve these relationships in a reusable form.
We implemented a staged process: transcribing calls → connecting evidence across the conversation → organizing reusable guidance → linking related cases → maintaining knowledge. The central problem is to reconstruct operational meaning without mistaking conversational noise or an unverified hypothesis for an established procedure.
Reconstructing Operational Meaning from Conversations
- Speech is fragmented and noisy
Overlapping turns, acknowledgments, repeated statements and digressions complicate the separation of useful business evidence from conversational filler. - Facts and decisions appear across multiple turns
Symptoms, usage conditions, attempted checks, possible causes and outcomes are rarely described in a single uninterrupted passage. - Different words can express the same operational state
Customer phrasing varies even when the underlying fault, prerequisite or resolution is similar. Extracted information must be normalized without losing distinctions. - A call is not automatically a verified procedure
Individual interactions may contain exceptions, failed attempts and tentative diagnoses. Reuse requires distinguishing observed facts from candidate explanations and actions.
From Call Transcripts to Connected Knowledge Objects
- Preserve speakers, timing and utterance boundaries
We organized the transcript so reviewers can follow who said what, the sequence of checks and the context of each decision. - Identify substantive segments and digressions
We separated repetitions, brief acknowledgments and unrelated turns while retaining information needed to understand changes in the customer’s goal or situation. - Extract evidence across the conversation
We collected the issue, symptoms, environment, checks, candidate causes, actions, outcomes and exception conditions even when they occur in different parts of the call. - Build KCS-style knowledge objects
We organized problems, conditions, checks, possible causes and resolutions into guidance that teams can assess and reuse. - Connect items through an ontology or knowledge graph
We represented relationships among symptoms, equipment conditions, diagnostic steps and solutions to support retrieval beyond surface-level text similarity. - Integrate new knowledge cautiously
We checked new candidates against existing knowledge for duplication and relationships before incorporating them into an evolving operational knowledge base.
Key Engineering Decisions
- Preserve evidence, not just summaries
Retain the context needed to understand why an extracted action or conclusion is associated with a particular problem. - Model exceptions separately from normal procedures
A digression, failed check or unusual resolution should not silently become a standard SOP step. - Make updates relationship-aware
As the knowledge base grows, duplicate concepts and contradictory cases must be handled rather than simply appending more call summaries.
Engineering Reusable Knowledge from Unstructured Calls
We implemented the extraction of problems, conditions, decisions and outcomes as connected knowledge units. Preserving their relationships and distinguishing tentative explanations from observed facts created guidance that support teams could assess and reuse.