An AI calling demo can sound convincing without completing the caller’s task. Our view: evaluate the call from the first request to the confirmed outcome, including failed lookups, interrupted speech, uncertain system responses and human handoffs. A smooth conversation is one part of that test.
What evidence proves the caller’s request was completed?
01 / Look up the right record before acting.
A caller asks to change an appointment. The agent needs the relevant booking, the requested change and permission to make it. A matching name or phone number may be useful context, but it should not silently become sufficient authorization for every action.
Define the verification required for each operation. Pass the minimum necessary customer information to the conversation, decide which records can be changed, and provide a route when verification fails. Test ambiguous matches and unavailable customer systems, not just the account prepared for the demonstration.
02 / Test when the caller changes direction.
Try an interruption halfway through an answer. Correct a date after it has been repeated. Switch from booking an appointment to asking about an existing one. The agent should stop the outdated response and preserve the relevant context without treating every fragment as a new instruction.
Use realistic calls across the devices, audio conditions and languages in scope. Record where the delay occurs: speech recognition, reasoning, a tool response or speech playback. A single total latency figure can conceal which part needs attention. A fast answer that acts on an incomplete request is still a failure.
03 / A spoken confirmation needs a system result.
If a booking system times out after receiving a request, the result is uncertain. Repeating the write can create a duplicate. Assign an operation reference, check the existing result where the system supports it, and keep uncertainty explicit until the record can be confirmed.
Separate a proposed action, a submitted request and a confirmed change. Evaluate the resulting record as well as the transcript. For failed actions, define whether the agent retries, collects a callback request or transfers the conversation. Do not let an optimistic script announce a completed task.
04 / Test the receiving side of a transfer.
A transfer instruction is not proof that someone answered. Check the real telephone route, busy and unanswered destinations, and what context reaches the receiving person. The caller should know whether they are being connected, waiting, or leaving a request for later.
For example, ElevenLabs documents different transfer options and restrictions across its telephony integrations. That is why a successful browser demonstration does not establish the behavior of a deployed telephone route. Our acceptance brief would include an answered transfer, an unanswered transfer and a failed connection, with an expected outcome for each.
ElevenLabs: telephone transfer options and limitations (opens in a new tab)Test an appointment change from call to record
- Request
- Move an existing appointment to another day.
- Identity and context
- Find the correct appointment and apply the verification required for a change.
- Interruption
- The caller corrects the day; the agent uses the corrected request before taking action.
- Uncertain write
- The scheduling system times out. Check the operation result before retrying; do not announce a confirmed change.
- Transfer
- If unresolved, connect to the receiving person with context, or clearly collect a callback request when no one answers.