Insights · AI voice
There are four practical routes, they cost wildly different amounts of engineering time, and the one that looks cheapest on a slide is rarely the one you should pick. Here's each approach, what it's genuinely good at, where it stops, and how to choose between them.
Before comparing approaches, settle one question, because it eliminates two of the four options on its own: do you want the AI to route the call, or to finish the job?
Routing is deflection with better manners — work out why the caller is ringing and send them to the right queue with a note. Finishing the job means the AI queries and updates your booking system, your CRM or your core platform mid-conversation, and the caller hangs up with the thing actually done. Those are different products, not different settings, and buyers who don't separate them end up disappointed by whichever one they bought.
The native route. You build a bot in Amazon Lex, define intents and the slots each intent needs, and drop a Get customer input block into your contact flow pointing at it. Amazon Polly does the speaking, Lex does the understanding, and a Lambda fulfilment function does whatever lookup or update the intent requires.
Good at: a bounded set of well-understood tasks. Balance enquiries, order status, appointment reminders, authentication, "which department do you want" done properly. It is fully inside AWS, it inherits your account's IAM and logging, and there is nothing extra to procure.
Where it stops: intent-and-slot design does not degrade gracefully. A caller who describes a problem in a way you didn't anticipate falls through to a fallback intent, and the honest fix is always more intents, more sample utterances, more slot validation. Open-ended conversation, mid-sentence changes of mind and barge-in are structurally hard. And Polly, however good the neural voices are, is reading a script rather than holding a conversation.
Effort: days to a first bot, then continuous. The build is not the cost; the tuning is.
The build-it-yourself route. You keep Connect for telephony, but replace the dialogue brain with a large language model on Amazon Bedrock, orchestrated by Lambda functions you write. Speech-to-text and text-to-speech are wired in as separate services, and you own the glue: prompt design, tool calling, conversation state, guardrails, timeouts, retries and the fallback path when the model returns something unusable.
Good at: total control. If your use case is genuinely unusual, your compliance team wants to see every prompt, or you have a platform team that wants this capability in-house, this is the only approach that gives it to you outright. It also keeps everything in your own AWS account, which is a real advantage for Australian buyers with residency obligations — provided you choose model and speech endpoints in a region you're allowed to use.
Where it stops: the demo is a fortnight and the production system is not. Latency budgeting across three services, barge-in handling, turn-taking that doesn't talk over the caller, and the operational discipline to keep a conversational system stable at 2am are all real engineering, and none of it is differentiating work for a contact centre. Most teams underestimate this by a factor that only becomes visible after the pilot.
Effort: months, plus permanent ownership.
You buy a conversational voice AI from a specialist vendor — the ElevenLabs, PolyAI, Cognigy class of product — and connect it to your contact centre. The vendor's platform holds the conversation; Amazon Connect gets it there and takes it back.
Good at: conversation quality, immediately. These are dedicated products with dedicated research behind them, and the gap between one of them and a home-built prototype is audible in the first ten seconds.
Where it stops: the join. There are two ways to bridge, and they are not equivalent. If the AI answers on its own number on the vendor's platform and dials the caller back into your queue when it needs a human, you have split one customer interaction into two contacts. The routing context is gone, the recording is in two places or one, the reporting double-counts the call and under-counts the resolution, and the human agent starts from zero. If instead the AI is bridged so the call stays a single routed Amazon Connect contact from ring to wrap-up, none of that happens. Ask every vendor which of those two things they do. It is the single most consequential question in the evaluation and it is rarely on the feature matrix.
Effort: weeks, and the integration is where they all go.
Someone else has already done approach 3 properly, packaged it, and listed it where you can buy it against the AWS account you already have. You keep your Connect instance, your numbers and your flows; the AI answers inside them.
Good at: time to first real call, and procurement. AWS Marketplace subscriptions land on your existing AWS bill, and for many organisations eligible Marketplace spend can count toward an existing AWS commitment — worth checking with your account team, because it can turn a vendor-onboarding exercise into a purchase decision. You also inherit somebody else's answers to the hard parts — barge-in, turn-taking, failure handling, and the handoff.
Where it stops: you are adopting a product's opinions. If your requirement genuinely doesn't fit, approach 2 is still waiting.
This is the category ProUCX sells into. Live AI Agent answers on your own Amazon Connect number, holds a full two-way conversation with natural interruption, transcribes every turn live and scores it for sentiment, calls your back-end systems mid-conversation so the process actually completes, and — when a person is the right answer — transfers to a human queue writing the summary, intent and transcript link onto the same Connect contact. Because it operates as an agent inside your instance, call recording, Contact Lens analytics, transfers and Connect reporting all still apply to it.
Two variants exist because buyers split on one axis. If voice quality leads, see the ElevenLabs voice agent in Amazon Connect. If Australian data residency leads, an onshore speech path is the configuration to ask for — the AI voice processing is where residency is won or lost, not the Connect instance, which never leaves your account either way.
All four share the same three variable cost lines and differ only in the fourth. Every AI-handled call consumes Amazon Connect service and telephony minutes at AWS's published rates for your region — an AI call is not a cheaper call, it is a call that doesn't occupy an agent. On top of that sit speech (recognition and synthesis, per minute) and the model (per token, or bundled into the vendor's price). The fourth line is what differs: Lex has its own per-request charge and no licence; a Bedrock build has no licence but carries your engineering cost as a permanent line item; a bought agent carries a licence or subscription.
ProUCX's Live AI Agent is listed on AWS Marketplace in bundles at US$300, US$1,000 and US$3,000 — check the listing for current bundle sizes and terms. We work the whole model through, including where the curve bends, in what an Amazon Connect AI voice agent actually costs.
Insist on hearing it on a real call, on a number you can ring, with a caller who goes off-script. Voice AI demos are curated; the failure modes that matter — a caller interrupting, an accent the model wasn't trained on, a request outside scope — only show up when someone tries to break it. Our demo console at dev.ai.liveucx.com runs a call end to end so you can watch the lifecycle, the live transcript with sentiment, the back-end integrations and the process checklist completing.
And whichever approach you choose, make the exit to a human unconditional. Ask for an agent, stay silent, or hit a limit, and the call should go straight to a person. An AI that can't be escaped generates the complaints that end AI programmes.
Live AI Agent answers on your own Connect number and finishes the job.