What a Browser Voice Demo Proves Before Telephone Acceptance

A browser voice demo is an efficient way to hear an assistant and explore its instructions. Telephone acceptance answers a different question: whether a caller using the intended number and carrier can complete the supported interaction. Both are valuable, and the evidence should remain distinct.

The browser path starts with a microphone, browser permissions and an internet connection. The telephone path introduces a number, carrier routing and telephony-specific behaviour. A strong browser conversation is a reason to continue evaluation, not a certificate that every telephone route works.

Use browser testing for what it exposes well

A browser session can reveal confusing instructions, long answers, poor correction handling and missing knowledge. It is convenient for trying a fictional scenario repeatedly without asking someone to dial a business number.

Observe the conversation rather than the animation around it. Can the caller interrupt? Does the assistant admit missing information? Does it preserve a correction? If the demo simulates bookings or messages, keep those outcomes labelled as practice.

Burki's conversational demo checklist can help organise this review. A bounded practice session should be judged against its stated scope, not against features it never claimed to exercise.

Add a telephone-specific acceptance layer

Before a telephone pilot, identify the exact number, carrier connection, assistant mode and permitted workflow. A different number or route may introduce different conditions, so retain this information with the result.

Use a compact matrix:

Only include handoff or other advanced actions when that mode and deployment support them. An unaccepted feature should remain outside the pilot rather than being inferred from a framework's general capabilities.

Follow the evidence across the route

LiveKit's telephony testing guide recommends checking the provider side and the resulting room and participant. For a business reviewer, the important principle is to connect the telephone attempt to the application session and then to what the caller heard.

A hypothetical failure illustrates the need. A test number rings, the carrier marks it answered, and the application creates a session, but the caller hears silence. Those observations show progress through part of the route. They do not establish a successful conversation, and changing the assistant's wording may be irrelevant.

Retain the call identifiers and timestamps so the technical owner can find the same attempt in each system. Avoid combining logs from several nearby calls into one supposed success.

Where several carriers or numbers are planned, keep a route register. One accepted entry should not automatically mark the other entries ready; prioritise the paths that will carry the first real callers.

Test ordinary endings as well as openings

Ask what happens when the caller hangs up during a response, stays quiet or abandons a request. The assistant should not leave an operational record implying an action completed simply because the telephone connection ended normally.

Check the post-call result after the system has had its documented processing time. If a recording or summary is not immediately available, record that as a separate observation rather than deciding the media failed or the business action succeeded.

Keep the conclusion narrow and useful

A good acceptance statement might say that one specified inbound route completed two-way speech and a particular supported task, with the final record checked. It should also name any untested route or action that matters to the planned rollout.

Use Burki's incoming-call testing guide to plan the next layer. Start with the browser for conversational learning, then collect telephone evidence for the actual service you intend callers to use.