“Your refund has been processed.”
That sentence is expensive when the payment provider has only accepted the request, not completed it. The customer stops checking their account. Days pass. The refund never arrives. Support gets the call that the voice agent should have prevented.
The rule is simple: an agent may claim work is complete only when the system that does the work can prove it.
Write the rule in the language of the call
Do not settle for “be accurate” in a prompt. Write the exact claim, the proof it requires, and the words to use when proof is missing.
For the refund scenario:
The agent may say a refund is complete only when the payment system returns a completed status and a reference. If the status is pending, failed, or unknown, the agent must say the refund is not confirmed and tell the customer what will happen next.
That rule gives product, operations, and engineering the same boundary. It also prevents the agent from turning an uncertain backend state into a confident customer promise.
Give the agent honest language for uncertainty
An agent does not need to sound evasive when a system is slow. It needs to describe the state accurately.
- “I have submitted the refund request. It is not confirmed yet.”
- “I cannot see a completed refund. I am arranging for our team to check this.”
- “I do not want to promise that until I have the reference number.”
These lines reduce customer effort. The caller knows whether to wait, expect a callback, or ask for help now. They are better than a promise that sends the customer back to the same queue later.
Turn the correction into a release check
After a false confirmation, teams often edit a prompt and move on. That leaves too much to chance. The original call contains a useful test:
- the customer asked for a refund
- the payment provider returned a pending or timed-out state
- the agent said it was complete
- the correct response was to explain the uncertainty and assign follow-up
Preserve that scenario. Test it after the prompt, policy, or tool handling changes. Include nearby states too: completed, pending, malformed, and late success after the caller hangs up.
The point is not to create a large approval process. It is to make sure the same promise cannot return in slightly different words next week.
Put ownership beside the uncertain result
The customer does not care whether the tool state was PENDING or UNKNOWN. They care who will finish the work.
When confirmation is blocked, create the follow-up at the same time. It needs a queue or person, a deadline, and enough context to act. If those fields are missing, the agent has merely moved the problem out of the call.
The management question
What did your agents promise last week that a customer could not verify with a reference number, completed record, or named follow-up?
Review those calls first. They are where repeat contact and complaint risk begin.