AI Voice Agent Pilot: 12 Tests Before Customer Calls

An AI voice agent pilot needs 12 acceptance tests before it handles real customer calls: scope, legal readiness, architecture, audio behaviour, entity capture, grounded answers, tool actions, human transfer, latency, fail-safe controls, evaluation evidence, and operating ownership. A polished demonstration is not go-live evidence. The decision should rest on a signed packet that shows what the agent can do, what makes it stop, and who takes over when it cannot finish safely.

A useful pilot has one call type, one verifiable end state, and one controlled path to a person. For example, an appointment-reminder agent can confirm, reschedule, or transfer. It should not quietly expand into billing disputes, clinical advice, account changes, or general support because those tasks appeared during testing.

The practical result of the 12 tests is a go, limited go, hold, or stop decision. The packet ties every test to evidence, a release blocker, and a named owner. A business owner, operations lead, engineer, and risk or legal contact can inspect the result without relying on a demo script.

The 12-test acceptance packet at a glance

Treat every row as an acceptance condition, not an aspiration. A pass means the evidence exists and matches the exact call route that will receive traffic. A hold means the missing evidence has an owner and a retest date. A stop means the risk cannot be contained inside the proposed pilot.

If you are defining the wider sequence around this packet, the AI agent pilot plan covers the broader path from workflow choice to controlled expansion. The tests here sit at the narrower boundary between an internal pilot and a customer-facing call.

Map your AI voice pilot

Test 1: Lock one call type and one end state

Start with a sentence that a caller, operator, and engineer would interpret the same way. “Confirm or reschedule an existing appointment, then record the result” is testable. “Handle appointment calls” is not, because it hides new bookings, cancellations, refunds, availability disputes, emergencies, identity checks, and unrelated questions.

Write the allowed entry conditions. State whether the agent receives inbound calls, initiates outbound calls, or both. Define the caller records it may access, the facts it may disclose, the fields it may change, and the exact point at which it transfers.

Then define the end states. A call can end as confirmed, rescheduled, transferred, opted out, disconnected, or failed. Every call must land in one state. “Conversation ended” is not a business outcome because it cannot tell the operator whether the task was finished.

Scope exclusions matter as much as the happy path. If the agent hears a billing question during an appointment call, it should acknowledge the boundary and transfer or provide the approved next step. It should not search for a plausible answer outside its assigned workflow.

Test 2: Map purpose, geography, consent, disclosure and recording

Voice automation is not a single legal category. Obligations can change with the call purpose, who initiated it, the geography of each party, the use of an artificial or prerecorded voice, whether the call is recorded, and what data is collected. Put those facts into a call-policy record before any live traffic.

For United States calls, the FCC declaratory ruling on AI-generated voices confirms that the TCPA restrictions on artificial or prerecorded voices encompass current AI technologies that generate human voices. The ruling states that calls using such technology require prior express consent where the restrictions apply.

The FTC Telemarketing Sales Rule guide covers areas such as required disclosures, Do Not Call provisions, calling-time restrictions, automated opt-out mechanisms, caller identification, consent records, and recordkeeping for covered telemarketing activity. These are primary references, not a substitute for advice on a particular campaign.

Have counsel confirm the exact call type, countries and states, purpose, consent basis, disclosure wording, recording notice, opt-out behaviour, suppression-list handling, retention period, and recordkeeping duty. The acceptance packet should hold the approved wording and show that the agent follows it when interrupted, challenged, or asked to stop.

A release is blocked if the implementation team cannot explain why the call is permitted, what the agent must disclose, how a person withdraws consent or opts out, and where that decision is recorded. Do not treat a provider setting as proof that the business process is compliant.

Test 3: Choose the voice architecture that exposes the controls you need

The architecture should follow the call, not the novelty of a model. The OpenAI voice-agent guide describes two main patterns. Speech-to-speech sessions handle live audio directly and support conversational turn-taking, interruptions, tools and handoffs. Chained pipelines separate speech-to-text, the agent workflow, and text-to-speech, which can provide stronger control over intermediate text and approval-heavy steps.

Use speech-to-speech when natural timing and interruption handling are central, and when the workflow can still enforce tool, knowledge, handoff and logging boundaries. Use a chained design when the team needs a visible transcript before an action, deterministic checks between stages, durable text evidence, or replaceable speech components.

Document every dependency between the caller and the business outcome. That includes telephony, streaming transport, speech recognition, model session, retrieval, business tools, text-to-speech, transfer provider, logging, and monitoring. For each dependency, record the timeout, fallback, and caller experience.

The architecture fails acceptance if a high-consequence action can occur inside an opaque conversational step with no inspectable input, rule, tool result, or confirmation. It also fails if the chosen design cannot produce the evidence needed by the remaining tests.

Test 4: Test the audio layer on real phone conditions

Transcript accuracy alone does not prove a usable call. The agent can produce a correct transcript and still talk over the caller, pause at the wrong time, ignore a correction, cut off a name, or leave dead air while a dependency waits.

Build scenarios from the conditions your callers actually bring. Include phone-line compression, weak connections, background conversation, traffic noise, different microphones, code-switching, accents, hesitant speech, long pauses, rapid corrections, and a caller who interrupts before the agent finishes.

Test barge-in at different moments. Interrupt during a disclosure, while the agent reads back a critical value, during a tool call, and immediately after a transfer offer. Decide which speech can be interrupted and which confirmation must restart if it is incomplete.

The Twilio ConversationRelay documentation shows how a telephony layer may handle speech-to-text, text-to-speech, session communication and interruption controls while the application runs the conversational logic. It also makes clear that provider configuration and human responsibility remain part of the implementation. Regardless of provider, test the whole path over real calls rather than validating each component in isolation.

Pass evidence should contain recordings, transcripts, event timing and the expected outcome for each scenario. The business team should hear a sample of passes and failures. Numbers without the audio can hide an experience that callers would reject.

Test 5: Make critical entity capture a read-back contract

Names, dates, addresses, account references, email addresses, order numbers and consent choices are not ordinary words. They are structured values that can change the result of a call. Define which values are critical and require explicit read-back before the agent writes or acts.

Test common ambiguity. “Fifteen” and “fifty” can sound similar. A caller may spell a surname, correct one digit, change a date halfway through a sentence, or say “yes” to an explanation rather than to the confirmation question. The system must bind confirmation to the exact value and action.

Store the heard value, normalized value, confidence or validation result, confirmation wording, caller response, and final written value where the system design supports it. The evidence should show that a partial correction replaces the right field rather than contaminating the entire record.

A critical field fails if the agent can proceed on a weak match, if confirmation is skipped after an interruption, or if the caller cannot hear what will be changed. Use deterministic format and business-rule validation before an action reaches the system of record.

Test 6: Separate grounded answers from polite refusal

Define the sources the agent may use. Customer-specific answers should come from authorized account data. Policy answers should come from approved, versioned business content. The model's general knowledge is not an acceptable source for refund rules, eligibility, delivery commitments, medical guidance, financial decisions, or account status.

Build test cases for missing, conflicting, outdated and inaccessible information. A strong response does not fill the gap with a plausible statement. It says what it cannot verify, offers the approved next step, and transfers when the caller's need exceeds the workflow.

Test prompt injection in spoken form. A caller may ask the agent to ignore its rules, reveal another person's data, invent an exception, or describe hidden instructions. The response should preserve the same data and action boundaries as a typed agent.

The NIST Generative AI Profile organizes risk work through govern, map, measure and manage functions and includes suggested actions for testing, monitoring and incident handling. Use that structure to connect each failure scenario to an owner, measurement and response rather than relying on a one-time model demonstration.

Pass evidence includes the source used for each answer, explicit refusal cases, and the transfer outcome. The test is not whether the agent sounds confident. It is whether confidence tracks available evidence and the agent stops when evidence is missing.

Test 7: Prove tool reads and writes end to end

A voice agent becomes operationally consequential when it touches a CRM, scheduling system, ticketing queue, order platform, payment workflow or identity service. Test each tool as a business transaction, not merely as a successful API response.

For reads, verify identity and authorization before exposing customer data. Check that the returned record belongs to the caller and that the spoken answer uses the current field. Test empty results, multiple matches, stale records, permission failures and timeouts.

For writes, capture the proposed change, confirmation, tool request, tool response, record read-back and caller-facing summary. Run duplicate and retry scenarios. If the network drops after a write but before the acknowledgement, a retry must not create a second appointment, ticket, refund request or follow-up task.

Use the AI agent permissions matrix to define which operations the voice agent may read, prepare, write with approval, or perform inside limits. Voice does not weaken the permission boundary. It raises the need for explicit confirmation because the caller cannot inspect a form before submission.

The release fails if tool success cannot be tied to the final system-of-record state, if a caller can reach another person's data, or if retries create conflicting outcomes.

Test 8: Run a context-preserving human transfer drill

“Transfer available” is not enough. Trigger the transfer from at least four conditions: the caller asks for a person, the agent lacks an answer, a tool fails, and the call reaches an excluded or sensitive intent.

The receiving person should get the caller identity status, detected intent, concise conversation summary, critical entities, actions already attempted, tool results, reason for transfer, and any promised next step. The caller should hear what is happening and should not be told an unsupported wait time.

Test the queue failure too. If no person is available, the workflow needs an approved fallback, such as a callback request or ticket, with accurate expectations. Never trap the caller in a transfer loop.

The existing AI chatbot implementation checklist covers the wider knowledge, CRM and handoff setup for conversational systems. The voice acceptance test adds audio continuity, spoken disclosure, transfer timing and the evidence visible to the receiving call team.

A transfer passes only when the person can continue from the current state and the caller does not have to reconstruct the interaction. Ask the receiving team to reject weak payloads during the pilot. Their feedback is operational evidence, not a cosmetic preference.

Test 9: Measure latency and dependency behaviour against your own baseline

Do not adopt a universal latency promise from a vendor page. Measure the distribution on your own call route, in the geographies you serve, with the tools and knowledge sources the workflow needs.

Record time to first spoken response, turn-end detection, model processing, tool time, speech generation, transfer initiation and the longest turns. Inspect percentiles and outliers, not only an average. A single long silence after the caller shares sensitive information can damage trust even if most turns are fast.

Create dependency failures deliberately. Slow the CRM, return an error from scheduling, interrupt streaming audio, expire a session, and make a knowledge request time out. The agent should acknowledge the problem without guessing, avoid duplicate action, and move to the tested fallback.

Load should resemble the pilot's expected concurrency and burst pattern, but the acceptance threshold must be set from the team's baseline and caller experience. Document the threshold before the run so it is not softened after an attractive demonstration.

Test 10: Exercise the kill switch, rollback and fallback

A kill switch is useful only if the team has activated it in a realistic drill. Define who can pause new calls, what happens to calls already in progress, how traffic returns to the human route, and how the team verifies that automation has actually stopped.

Rollback should cover prompts, tools, knowledge versions, model or speech configuration, and application releases. If a change affects data writes, state whether rollback reverses records, stops future actions, or requires reconciliation. Software rollback does not automatically undo a business transaction.

Keep a caller-safe fallback that does not depend on the failing component. It should state the service limitation plainly, preserve any confirmed information, avoid promises it cannot meet, and route to a person or approved asynchronous path.

The AI incident response runbook covers the broader process for containment, evidence, communication and recovery after a customer-facing AI failure. In this pilot, rehearse the first containment steps before live traffic and attach the drill evidence to the acceptance packet.

A release is blocked when pausing the agent requires an engineer who is not on call, the fallback route has not been tested, or the team cannot identify which calls and records were affected by the faulty version.

Test 11: Bind every change to a replayable evaluation set

Create a versioned set of end-to-end calls that covers the happy path, boundary cases, excluded intents, noisy audio, critical values, tool failures, transfer conditions and adversarial requests. Each scenario needs an expected business outcome, allowed variations, disallowed behaviour and evidence location.

Keep deterministic checks for facts that have one right answer: the chosen account, date, consent state, tool arguments, final record, transfer queue and call end state. Use structured human assessment for tone, clarity and caller effort, with written criteria so judgments remain comparable.

Run the set before a prompt, model, speech, tool, knowledge or routing change reaches pilot traffic. Preserve results by version. When a live call exposes a new failure, remove sensitive data, turn the pattern into a repeatable scenario, and keep it in the set after the defect is fixed.

After launch, the AI workflow monitoring dashboard can connect quality, reliability, cost and business outcomes. The acceptance packet supplies the baseline scenarios and release evidence that make those production signals interpretable.

The test fails if a small configuration change can bypass the evaluation set, if results cannot be compared with the previous version, or if a corrected failure disappears from future regression coverage.

Test 12: Name the operating owner and the expansion rule

The pilot needs one accountable operating owner with authority to pause traffic, assign defects, approve low-risk changes, and call for legal, security or engineering help. Shared responsibility without one decision maker becomes delayed responsibility during a customer incident.

Define the first operating rhythm before launch. Inspect failed calls and transfers daily during the limited release. Reconcile tool actions with system-of-record outcomes. Track why callers opt out or request a person. Review unusual latency and repeat failures by call type. Keep a short decision log for prompt, knowledge, tool and routing changes.

Expansion should be earned by evidence. Do not add a second call type because the first demo looked natural. Require the first scope to hold its acceptance thresholds, demonstrate reliable transfer and fallback, and complete a stable operating period defined by the team. Then build a separate acceptance packet for the next workflow.

KUMO's AI Integration service connects AI to the software a business already runs, including customer-facing portals, retrieval, workflow tools and legacy systems. For a voice pilot, the implementation brief should make the telephony, data, action and operating boundaries explicit before architecture and delivery are scoped.

Go, limited go, hold or stop

Do not average the tests into a score that lets a critical failure disappear. Legal readiness, identity and data access, critical actions, human transfer, and stop controls are release conditions. A strong audio score cannot compensate for a duplicate booking or an untested opt-out path.

The signed decision should identify the exact workflow version, telephony route, knowledge version, connected tools, traffic boundary, acceptance evidence, unresolved limits, operating owner, pause authority, and next decision date.

What to put in the implementation brief

Start with the caller job and end state. Name the inbound or outbound route, caller population, geography, language, excluded intents, disclosure and consent path, data sources, critical entities, tool reads and writes, confirmation rules, human queue, fallback, logs, retention needs, test scenarios, traffic boundary and operating owner.

Attach sample calls, but make them evidence rather than theatre. Include one clean happy path, one noisy interruption, one corrected critical value, one tool failure, one transfer, one opt-out, one out-of-scope request and one kill-switch drill. State the expected record after every scenario.

KUMO's public work on Kaft shows production AI audio and text-to-speech engineering, including deterministic script preparation, provider abstraction, segment-level retries, rollback and serverless delivery. It is relevant proof of AI audio product work, not evidence for any unsupported contact-centre result.

Map your AI voice pilot

Questions buyers ask

What should an AI voice agent pilot handle first?

An AI voice agent pilot should handle one narrow call type with a verifiable end state, such as confirming or rescheduling an existing appointment. The workflow should have clear exclusions, a tested path to a person, and no authority beyond the records and actions required for that call.

How do you test an AI voice agent before live customer calls?

Test the complete phone journey rather than the transcript alone. Cover real audio conditions, critical value confirmation, grounded answers, system reads and writes, retries, human transfer, latency, dependency failure, opt-out, rollback and stop controls. Save the recording, event trace and final business record for each scenario.

Should a voice agent use speech-to-speech or a chained pipeline?

Use speech-to-speech when natural turn-taking and interruption handling are central and the required controls remain enforceable. Use a chained pipeline when the team needs explicit transcripts, checks or approvals between speech recognition, reasoning, tools and speech output. The call's risk and evidence needs should decide the architecture.

When must an AI voice agent transfer to a person?

Transfer when the caller asks for a person, identity cannot be verified, an answer lacks an approved source, a critical tool fails, the intent is excluded or sensitive, or the workflow reaches a defined confidence or safety boundary. The person should receive context, actions attempted and the reason for transfer.

Who should approve an AI voice agent go-live decision?

The accountable business owner should sign the release with the engineering and operations owners, plus legal, privacy, security or risk contacts required by the call type. Approval should reference the exact workflow version, evidence packet, traffic limits, stop authority and unresolved conditions.

A voice pilot is ready when the evidence survives a messy real call, not when the script survives a demo. Keep the first scope narrow, make actions observable, protect the path to a person, and expand only after the operating team can show why the current version deserves more traffic.

Map your AI voice pilot