Define the summary audience
Specify whether the output is a brief customer issue, an agent handoff, a structured action list, or a retrospective interaction summary. Each format needs different detail. Give examples showing the desired level of specificity and which personal or account details should be excluded from the output.
Separate requests from outcomes
A customer’s wish, an agent’s proposal, and a completed action are different claims. Require reviewers to preserve that distinction. When a call ends before resolution, the reference should state the known boundary rather than invent an outcome based on common workflow patterns or a later unprovided system record.
Attach evidence and uncertainty
Link important summary claims to turns or time intervals. Mark unclear product names, dates, or commitments instead of resolving them through guesswork. Decide whether a summary may use a transcript alone or must be checked against audio, particularly when transcription mistakes could change amounts, negation, or promised actions.
Review task fit in a pilot
Compare references across long calls, transfers, repeated explanations, and no-resolution cases. Check whether reviewers agree on what deserves inclusion. Send Fiund the output schema, evidence policy, call types, and source-review requirements so a potential dataset can be assessed for summarization rather than assumed useful because transcripts exist. Use a call where the agent promises to investigate but does not confirm a final resolution. A sound reference distinguishes the promise from completed work and records any stated next step. This helps reveal whether summary reviewers are relying on a plausible business narrative instead of limiting claims to the evidence in the supplied conversation.
Review checklist
- Choose audience and output format
- Distinguish requested and completed actions
- Require evidence for consequential claims
- Include unresolved and transferred calls