Worked example: a summary that converts a request into a promise
A fictional caller, Lee Example, says their technician mentioned a return visit might be free and asks for a callback before lunch. They first give a number ending in 42, then correct it to 24. The receptionist attempts to transfer to the service team, nobody answers, and an internal review task is created. No price exception is approved and no callback time is accepted by staff.
A poor summary reads: Lee needs the free return visit arranged. Transferred to service. Callback promised before lunch. Phone ends 42. It is short and easy to read, but every operationally important statement is wrong or incomplete. The note turns a reported possibility into an approved entitlement, an unanswered transfer into a completed conversation, a preference into a promise and the first phone number into the final contact field.
A useful version says: Lee requested review of a possible free return visit, which they report the technician mentioned. No price exception was confirmed. Transfer to service was attempted but unanswered. Review task created for the service team. Caller requested a callback before lunch; no response time was promised. Use the corrected callback number ending 24. In a real note, include the full approved contact detail and relevant record reference in the appropriate controlled fields.
Reviewers should verify each part with the right source. The call establishes what Lee reported and the correction to the number. The transfer result establishes whether anybody answered. The task destination establishes whether a review item exists and who owns it. A transcript alone cannot prove task creation, and a task alone cannot prove that the caller's words were represented faithfully.
Now test a neighbouring scenario in which an authorised staff member has already approved the free visit and the receptionist can verify that approval through the agreed source. The summary should state the confirmed approval accurately instead of mechanically labelling every fact as unverified. Good caution preserves evidence distinctions; it does not remove useful certainty when a valid source actually supports it.
Ask the service coordinator to act from the corrected note without hearing the call first. They should be able to identify the request, contact the caller using the corrected number and review the reported promise without assuming it is already approved. If the coordinator still needs to replay the entire call to discover the next step, the summary may be accurate but insufficiently actionable.
Use a review worksheet with columns for claim, source evidence, verdict, consequence and correction. For omissions, name the missing fact and why it changes the task. Keep delivery evidence in a separate row. This structure prevents a single overall rating from hiding a consequential error beneath several correct but low-value details.
For ongoing review, keep examples of acceptable uncertainty beside examples of missing information. Appointment time unconfirmed is useful when the caller never settled on a time; omitting an agreed time is a defect. Both can look like an empty field unless the reviewer consults the source. The same distinction applies to authority, price approval and callback timing. A quality rule should preserve uncertainty where it is real and preserve detail where it was actually established. This prevents a cautious revision from making every summary vague enough that staff must repeat the entire intake.