Check callback details before ending a call

The decision this workflow supports

A request can be complete except for one incorrect digit in the callback number. Caller ID may also differ from the number the person wants staff to use. Make the preferred contact an explicit part of the readback.

Put the review process in place

Ask which contact route the caller wants to use and read it back in manageable groups. Permit corrections without restarting the whole request. Record an inability to confirm the contact rather than silently treating an unclear number as verified.

Worked example for your team

In a fictional intake, the caller asks staff to use a business number rather than the number displayed on the incoming call. During readback, they correct the last two digits. The final note should contain only the corrected preferred contact, with any uncertainty flagged. Ask the reviewer to explain which number they would use and why. Then try an interrupted readback where the caller never confirms the digits. The workflow should retain an unconfirmed-contact status instead of treating the absence of a correction as positive verification.

Sample wording to approve

“What is the best contact for this request? I will read it back so you can correct anything. Please use a business contact where appropriate; no payment information is needed.” This wording is a draft for the restaurant owner to approve before use.

Fields for the staff handoff

Staff need preferred contact route, caller-provided number or email, correction made, request reference, and confirmation status. Mark uncertain details explicitly and keep the requested action separate from anything restaurant staff have already confirmed.

Acceptance tests before use

A corrected digit replaces the old version. Caller ID is not substituted without asking. An unconfirmed contact is clearly flagged for the reviewing staff member. Record the observed result, assign any mismatch, and repeat the affected scenario after correction.

Related guides