Voice agents in the browser and on the phone: validating a pilot

Start with the customer's existing habit

In Tigy AI, the browser lets your team test the agent in the editor; telephony requires provider configuration and number-to-agent assignment. Choose the first validation channel according to intended use. If customers call a number, acceptance must include a call to that number alongside editor tests.

For browsers, consider microphone access, devices and connectivity. For phones, validate the number, routing and configured telephony integration. These are part of service quality even when the agent answers correctly.

Define what the agent knows at the start

The agent should understand its task and how to request necessary information. An incoming phone number does not replace confirmation required by your process.

Test the opening without additional data and with the context your integration actually supplies. Do not rely on information that existed only in a demonstration.

Verify continuity by telephone

Tigy's transfer tool supports telephony calls through supported providers. Browser-editor testing does not verify that transfer: configure the destination and check it through an actual telephone call.

The current phone transfer is blind and does not automatically send conversation context to the receiving person. If the team needs a summary, prepare a separate process and verify what they actually receive.

Compare complete journeys

Assess how easy it is to start, audio quality, task completion and continuation after an exception. Include an interrupted call and a visitor unable to use a microphone.

Choose an initial channel and record what you learn. Expanding to another channel needs new access and operational tests alongside reuse of successful instructions.

Move from editor to number with a short checklist

Verify saved and published configuration, number assignment and pilot origin. Call with known questions, tools and exceptions; inspect audio, transcript and destination effects.

Test transfer through compatible telephony, including destinations, waits and failures. Direct transfer does not automatically provide context; summaries require a separate process.

Record timestamps and references. Missing runs suggest routing investigation; existing runs support audio and behavior investigation.

Choose suitable release evidence

Text does not establish pronunciation; editor voice does not establish number routing; ringing does not establish a tool write. Define the conclusion supported by each evidence type.

Share common scenarios across modalities while adding channel-specific cases. Telephone pilots need unavailable destinations and human operating hours.

After routing or version changes, make a new identifiable call to verify new-conversation behavior.

Choose the channel from the entry context

In Tigy AI, the browser conversation described here is editor testing by your team with workspace access. Use this test to validate the agent and a call to the configured number to validate telephone service.

Editor validation reviews instructions and tools and, in voice mode, recognition, pronunciation and turns. Telephone validation adds number assignment, provider audio and transfer operation. Use the same requests to compare decisions while keeping these criteria separate.

For a telephone pilot, consider real call origins and conditions: noise, connectivity, hours and human destinations. An agent may answer well on a computer yet fail through the configured customer number. Record outcomes across the complete path.

If the business plans another channel in the future, treat it as a requirement to verify, rather than an already available capability. Entry, identification, permissions and continuity will need their own tests when that channel is enabled.

Define identification without trusting channel appearance

An originating number does not establish authorization to retrieve individual information. In editor tests, initial variables represent test context, rather than customer identity verification performed by a website. The integrated system must decide which data the available context authorizes.

Separate general questions from individual lookups. Opening-hours information may need no identification; contract retrieval requires checks defined by the responsible process. Define this distinction by task to avoid excessive collection and unauthorized access.

Test fictional data from different accounts, shared phones and calls of unknown origin. The agent should request only approved information and explain its boundaries. The system holding the data must block lookups without permission, even when someone insists or supplies a seemingly valid record number.

Test entry, failure and exit in each channel

In the editor, check test permission, available usage, saved changes and microphone access. Run a poor-audio case and a text case to separate entry difficulties from agent decisions. Missing permission should not become a negative assessment of a conversation that never started.

For telephony, confirm number, assigned agent and published version through a new call. Include a known lookup, an identifier correction and an exception. Locate the run and verify external operations when tools participate.

Test transfer through compatible telephony, including unstaffed hours and unavailable destinations. Browser testing does not execute this transfer. Summaries for receiving staff require a separate integration and receipt verification.

Compare observations by mode: text investigates logic, editor voice investigates audio and telephone calls investigate channel operation. Do not compare internal-test rates with customer rates as if they described the same population.

Record the hypothesis the pilot will evaluate

Record each stage’s hypothesis. A text test can verify that a corrected code reaches the tool; voice can verify understanding and confirmation; a call to the number can verify routing and continuity. Conclusions should match the stage actually executed.

Keep scenario, configuration, channel, expected result and observed evidence. Mark unexecuted conditions pending. This record helps choose the next test without presenting an internal demonstration as website deployment.