Confirming spoken details
How to confirm names and phone numbers during a call
By ByTomorrow · Published
An agent can repeat a name or number confidently while still holding the wrong value. A caller may correct one part, but the saved record may retain the original or combine both versions.
Use a field-level confirmation protocol. The suggested scripts and states below are editorial examples that need testing against your speech and recording system.
Where mistakes enter
Check these failure points
Recognition is treated as confirmation
Capturing spoken text establishes what the system heard. It does not establish that the caller agreed the stored detail was correct.
A correction updates only the conversation
The spoken response may acknowledge a correction while the next tool still receives the older value. The final action needs to use the confirmed version.
Practical working sheet
Use this procedure with your own records
Assign a state to each detail
For each action-critical field record value, source, captured/awaiting confirmation/confirmed/unresolved state and last correction. These are proposed business fields, not required Retell field names.
Confirm one detail at a time
Suggested prompt: “What name should I put on the request?” If uncertain, ask for the spelling or the unclear part. For a callback number, read the digits in clear groups and allow the caller to correct them. Do not require a particular name format.
Process the correction as a replacement
Fictional example: caller says “Maren, with an e.” Mark the old candidate superseded, update the name, then ask “Maren. Have I got that right?” Preserve any unresolved surname separately instead of guessing it.
Reconfirm the whole corrected number
If the caller changes a digit, repeat the complete updated callback number for confirmation before using it. Repeating only the changed digit can conceal a second recognition error.
Check the value at the action boundary
Immediately before creating a callback task, compare the supplied destination with the confirmed field. If it is unresolved, follow the approved manual-review path rather than using a convenient old value.
Prepare an uncertainty ending
Suggested wording: “I have not been able to confirm that number accurately. I can pass the request to our team through the available review route.” Only offer a route your business actually provides; do not claim a callback can happen without a usable destination.
Apply and verify
Test the complete behavior
Choose critical fields
Apply this process where an error changes the next action. Avoid needless confirmation of every conversational detail.
Test different corrections
Include a full replacement, a changed digit, spelling clarification and a caller declining to provide a detail.
Inspect the outgoing record
Check the actual task or test tool input, not merely the transcript.
Check repeated uncertainty
Ensure the process ends through its agreed fallback instead of asking the same question indefinitely.
Questions
Straight answers.
This procedure checks the caller's stated destination. It is not an identity-verification system or proof of ownership of that destination.
Its documentation describes dynamic-variable extraction. It also notes that prompt-agent extraction timing is not fixed, so confirm that required checks occur before the action that uses a value.
No. Confirming a callback field for this request and changing a permanent customer record are separate decisions. Follow the authorized update rules for the latter.
Sources and further reading
- Retell extraction during a call
Retell documents extraction during a call; prompt-agent extraction timing is not guaranteed to occur at a fixed step.
Checked .
Choose one behavior to verify
Bring the relevant route, script or worksheet to a scoping conversation. Agree on the expected result and the evidence before changing the working system.
Discuss your workflow