Where can voice AI resolve customer needs safely, and when should it transfer to a person?
Voice AI can transcribe a caller, interpret a request and respond with speech. It can support customer service, appointment handling, internal help desks and research operations. Its value depends less on sounding impressive than on understanding the request correctly, completing an allowed task and transferring the conversation when it should.
The best first deployment is a limited service with low consequences and a clear human alternative. Post-call assistance is often an easier starting point than giving an automated voice full control over a live customer interaction.
Recent developments and availability
Google introduced Gemini 3.5 Transcribe on 26 August 2026, describing separate interfaces for live transcription and recorded audio, including speaker attribution and timestamps for recordings. Speech recognition is a component of a voice service, not a complete customer-resolution system. Local accents, names and noise conditions still need testing. Google announcement.
On 2 September 2026, Genesys announced enhancements to its Agentic Virtual Agent. The release states that some capabilities, including the APT-2 model, development tools and Deepgram integration, were available immediately. ElevenLabs integration was expected during August–October 2026, while other voice and interoperability enhancements were expected during November 2026–January 2027. Those planned features should not be described as already generally available. Genesys announcement.
Our assessment is that the market is moving toward more capable voice workflows, but procurement must separate transcription, conversation management, business-system access and escalation. A strong component cannot compensate for a missing handoff process.
How a voice workflow operates
A typical pipeline receives audio, detects when a person is speaking, transcribes the words, interprets the request, retrieves relevant information and generates a spoken response. Some systems combine stages in one model; others use separate speech and language components.
Each design has tradeoffs. A modular pipeline makes individual stages easier to inspect. A more integrated system may reduce delay or improve conversational flow, but the team still needs a record of what was heard, what action was proposed and what actually happened.
Three details matter immediately: interruptions, silence and correction. The system should stop speaking when the caller interrupts, avoid treating a pause as agreement, and handle “Tuesday—sorry, Wednesday” without booking the wrong day.
Practical example: appointment enquiries for a service business
In an illustrative deployment, a voice assistant answers opening-hours questions and prepares appointment requests. It can read an approved calendar of available slots, but a booking is written only after the caller explicitly confirms the date, time and location.
The conversation might be: the caller requests next Wednesday afternoon; the assistant offers two slots; the caller chooses one; the assistant repeats the complete appointment details; the caller confirms. The application then records the booking once and reads back the confirmation.
If the calendar fails, the assistant does not pretend to have booked. It explains that the request is not confirmed and offers a transfer or callback process. If the caller asks for a person, escalation should be direct rather than a repeated attempt to keep them in automation.
For a marketing firm, a safer first pilot is post-call summarization of consented client-discovery calls. The output can identify agreed actions and unanswered questions, while a researcher verifies quotations against timestamps. Both examples are proposed workflows, not claims of measured results.
Implementation sequence
- Choose permitted intents. Start with a small list, such as opening hours, appointment availability and transfer to a person. Write explicit exclusions for disputes, sensitive advice and requests the business cannot automate safely.
- Map the real service process. Identify who receives transfers, what happens outside staffed hours and how failed bookings are recovered. An escalation button is useless without an operational destination.
- Prepare a controlled knowledge source. Maintain current hours, locations, service descriptions and escalation rules. Give each item an owner and update schedule.
- Design confirmation rules. Require explicit confirmation before consequential writes. Re-read dates, amounts and identifiers where errors matter. Silence or an ambiguous “okay” in an unrelated context should not authorize action.
- Integrate through narrow tools. Separate reading availability from creating an appointment. Use a unique request identifier so a retry cannot create a second booking.
- Test audio conditions. Include accents, code-switching, background noise, interruptions, quiet speech and similar-sounding names. Evaluate the actual languages the service will support.
- Pilot with an accessible alternative. Explain that the caller is interacting with an automated assistant. Provide a human or non-voice route and measure whether transfers preserve context.
Review consent, recording and retention requirements for the relevant jurisdictions before collecting real calls. Do not assume one global rule applies everywhere.
A conversation policy template
Handle only the approved service intents. Ask one clear question at a time. Repeat critical details before requesting confirmation. Never claim an action succeeded until the business system confirms it. If the caller asks for a person, or the request is outside scope, transfer with a concise summary. Do not infer identity from voice alone.
The application must enforce these boundaries. The language model should not be the only mechanism preventing unauthorized account access or a duplicate transaction.
Evaluation that reflects the caller's experience
Word error rate measures transcription mistakes, but a low average can conceal a wrong appointment date or account identifier. Measure task outcomes and critical-entity accuracy separately.
| Measure | What to inspect |
|---|---|
| Correct resolution | Was the permitted request actually completed? |
| Critical-entity accuracy | Were names, dates and identifiers captured correctly? |
| Response delay | Time from end of caller speech to a useful response, including slow cases |
| Transfer quality | Did the person receive the transcript or summary and relevant context? |
| Repeat contact | Did the caller need to call again because the first interaction failed? |
Do not optimize solely for containment, the share of calls kept away from staff. A service that traps unhappy callers can score well on containment while worsening customer experience.
Use recorded, consented or synthetic test calls before live use. A proposed pilot might test 20 scenarios with five variations each, then add a small supervised live cohort. That is a starting design, not an assurance that rare failures have been eliminated.
Cost and operating limits
Count telephony, transcription, model usage, speech generation, recording storage and human follow-up. A cost-per-minute comparison may favor short but unresolved calls. Cost per correctly resolved request is more meaningful.
An illustrative service receives 500 eligible calls. If only 350 are correctly resolved without rework, divide the full pilot cost by 350, not 500. Separately account for the 150 exceptions and any repeat contacts. Do not count an abandoned call as success.
Provide an outage mode that gives verified basic information and a reliable alternative. Avoid a fallback that invents answers when a calendar or customer system is unavailable.
Adoption recommendation
Start with post-call assistance if the business lacks a mature service workflow. Move to live information retrieval after testing language coverage and transfer reliability. Add narrowly scoped writes only when confirmation and duplicate-prevention controls are proven.
For agencies, the opportunity includes service design, multilingual testing and conversation-quality review, not just installing a voice model. A trustworthy experience is one that knows when to finish the task and when to bring in a person.
Sources and scope
Evidence cutoff: 10 September 2026. Availability statements reflect the dated announcements, including future rollout windows. Examples, metrics and deployment steps are original recommendations. Recording and privacy requirements require jurisdiction-specific assessment.
- Diego Melendo Casado and Luke Leonhard, Google. “Intelligent transcription with Gemini 3.5 Transcribe.” 26 August 2026. Source.
- Genesys. “Genesys Enhances Agentic Virtual Agent Amid Growing Enterprise Adoption.” 2 September 2026. Source.
- World Wide Web Consortium, Web Accessibility Initiative. “Digital Accessibility User Requirements.” Updated 5 February 2026. Used to frame accessibility needs for natural-language and real-time communication interfaces. Source.
Turn the research into operating value.
Connect the use case, architecture, evidence, controls and operating model around a decision that matters.