Handling a changed request
How to handle callers who change their request mid-call
By ByTomorrow · Published
A caller starts by asking for an estimate, then says the real reason is to change an appointment. The agent can keep pursuing the original task even after the customer has moved on.
The difficult case is an action already started. The proposed trace below separates the current request from completed, pending and unsent actions. It is a design pattern to implement and test, not an existing vendor guarantee.
Where mistakes enter
Check these failure points
The first label becomes permanent
A request category is provisional until the conversation settles. It should not force the caller through irrelevant questions after a clear correction.
Changing the request is mistaken for undoing work
A new instruction cannot erase a booking already created or a message already sent. Inspect the earlier action before describing its state.
Practical working sheet
Use this procedure with your own records
Keep a request trace
Record current request; replaced request; action already submitted; action result; details still relevant; details requiring confirmation. Preserve previous actions in the trace while marking only the current request active.
Fictional conversation before any action
Caller: “I need an estimate. Actually, I already have an appointment and need to change it.” Suggested reply: “You want to change an existing appointment. I have not booked anything new. Which appointment do you mean?” Retain a confirmed name and callback route; stop the new-estimate intake.
If the earlier action is still pending
Tell the caller you need to check its result. Do not issue a conflicting action merely because the request changed. If the system cannot resolve the pending state, create an owned review with both requests and the original action reference.
If the earlier action completed
State what actually happened, then confirm the newly requested change. Use the normal permission and verification process for any reversal. “I changed my mind” is a new request; it is not evidence that a prior booking disappeared.
Decide what to retain
Keep confirmed identity/contact details unless corrected. Reconfirm action-specific details such as the intended appointment and time. Never transfer a requested date from one task into another without checking its meaning.
Apply and verify
Test the complete behavior
Identify transition cases
Write examples of new inquiry to existing service, booking to information-only and changed appointment time.
Add an action-status check
Before continuing, determine whether the previous task was unsent, pending, successful or failed.
Check the current confirmation
Have the agent restate the latest request in plain language.
Test with a delayed action
Use a controlled test environment to expose pending work. Confirm the trace survives the change.
Review the final record
It should show the current request and any earlier completed action without contradictory success claims.
Questions
Straight answers.
Post-call extraction runs after the call. Retell documents a separate tool for values needed during a conversation. Use the appropriate mechanism and test its timing.
No cancellation should be assumed. Confirm the action state and execute any authorized reversal through its own checked process.
Usually the design can retain relevant confirmed details. Reconfirm the information whose meaning changed instead of repeating every question.
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 .
- Retell post-call extraction
Retell documents structured analysis after a call and absent custom fields when no conversation occurred.
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