How to Run an AI Voice Agent Proof of Concept: A UK Contact Centre Evaluation Playbook for 2026

Arkadas Kilic 9 min read · 2026-07-27

Most AI voice agent proofs of concept fail before they start. Not because the technology does not work, but because the evaluation is designed to test the wrong things. UK contact centres in financial services, insurance, utilities, and healthcare are under pressure to move fast, but they are also operating in one of the most scrutinised regulatory environments in the world.

This playbook is built from direct experience running AI voice agent deployments in production. It gives you a structured, eight-week path from scoping to a decision-ready PoC, with the specific numbers, compliance checkpoints, and architectural decisions that determine whether your PoC translates into a production system or a slide deck.

Why Most AI Voice Agent PoCs Fail

Before the playbook, understand the failure modes:

• Scope creep from day one. Teams try to automate 40 call types in a PoC. Pick one.
• No baseline data. You cannot measure a 23% containment improvement if you do not know your current containment rate.
• Compliance treated as a phase two problem. FCA Consumer Duty, GDPR, and PCI DSS constraints that are not baked into the PoC architecture will block your production deployment.
• Wrong success metric. Stakeholders evaluate on demo quality rather than production readiness.
• Technology theatre. A PoC running on a vendor sandbox with curated calls tells you nothing about how the system performs on your actual call volume, your actual customers, and your actual edge cases.

Phase 1: Define the PoC Scope (Week 1)

Choose One Call Type, Not Ten

The most successful PoCs we have run are narrow. Pick a single call type that meets all three of these criteria:

1. High volume. Minimum 500 calls per month on this call type. You need statistical significance.

2. Structured intent. The caller is trying to do one specific thing: check a balance, report a meter reading, confirm an appointment, or make a payment.

3. Measurable outcome. You can define done. The call either ends with the task completed autonomously or it transfers to an agent with a reason code.

Avoid choosing your most complex call type because it sounds impressive. Choose the call type where a 60% autonomous containment rate saves you the most money.

Establish Your Baseline Metrics

Before writing a single line of infrastructure code, pull 90 days of data on your chosen call type:

• Average handle time (AHT)
• Current containment rate in your existing IVR
• Transfer rate to live agents
• Average cost per call (fully loaded, including agent time and platform costs)
• CSAT score for this call type
• Peak call volume by hour and day

If you cannot pull these numbers, your PoC evaluation will be subjective. Subjective PoCs do not get budget approved.

Define Your Success Criteria Before You Build

Write down the numbers that constitute a pass. Examples from deployments we have run in production:

• Autonomous containment rate above 55% on the target call type
• Average handling time for contained calls under 90 seconds
• Transfer handoff latency under 3 seconds
• Caller satisfaction score (post-call IVR survey) no more than 0.3 points below live agent score
• Zero PCI DSS violations in call recording and data handling

Get sign-off on these criteria from your operations director, your compliance team, and your technology lead before the PoC begins. This prevents the goalposts moving when results come in.

Phase 2: Architecture Decisions That Determine Production Readiness (Week 2)

Build on Your Production Stack, Not a Sandbox

A PoC built on a vendor demo environment tells you the technology can work. A PoC built on your actual AWS account, connected to your actual telephony, tells you it will work for you.

For UK contact centres, the architecture we build on is Amazon Connect. It is the only cloud contact centre platform with native AWS service integration, which matters when you are connecting to Amazon Lex for speech recognition, Amazon Bedrock for language model inference, AWS Lambda for business logic, and Amazon S3 for call recording with server-side encryption.

The PoC architecture should mirror your target production architecture. That means:

• Your Amazon Connect instance (not a demo instance)
• Real phone numbers routed through your existing carrier or Direct Inward Dialing setup
• Lambda functions that connect to your actual CRM or back-end systems, even if read-only during the PoC
• Call recordings stored in your S3 buckets with your KMS encryption keys
• CloudWatch logging to your existing observability stack

Compliance Architecture Is Not Optional in a PoC

UK-regulated contact centres cannot treat compliance as a retrofit. These are the non-negotiables you build into the PoC from day one:

Phase 3: Build the PoC (Weeks 3 and 4)

The Minimum Viable Voice Agent

For a PoC, you are building three things:

1. The conversation flow. Map the happy path and the three most common failure modes for your chosen call type. The happy path should be completable in under 120 seconds. Failure modes must transfer gracefully.

2. The intent classification layer. This is where most PoCs underinvest. Your voice agent needs to handle callers who do not say what they mean, who change their mind mid-call, or who speak with regional accents. Test your speech recognition on recordings from your actual call centre, not synthetic test cases.

3. The back-end integration. Even in a PoC, connect to your real data. A voice agent that tells a customer their account balance is correct builds more stakeholder confidence than one that returns mock data. Use read-only API access if write access is a governance concern.

Load and Latency Testing

Run your PoC under realistic load. For a UK contact centre, that means simulating your peak hour call volume on the target call type. Acceptable latency thresholds for a production-grade voice agent:

• Speech recognition response: under 800 milliseconds
• Business logic execution (Lambda): under 400 milliseconds
• Total turn-around time from end of caller utterance to start of agent response: under 1.5 seconds

Anything above 1.5 seconds creates perceptible pauses that callers interpret as the system being broken. Test this before you present results to stakeholders.

Phase 4: Live Traffic Testing (Weeks 5 and 6)

Run a Controlled Live Trial

Route 10% to 15% of your target call type to the AI voice agent. Keep 85% to 90% on your existing IVR or agent queue. This is not a full rollout. It is a controlled measurement exercise.

Run the live trial for a minimum of two weeks to capture enough volume for statistical significance. For a call type with 500 monthly calls, two weeks at 15% routing gives you approximately 60 to 75 real calls. That is sufficient for a directional read on containment rate and CSAT.

What to Measure During the Live Trial

Track these metrics daily:

The Compliance Audit

During the live trial, your compliance team should manually review a sample of call recordings. They are checking:

• Consent prompt delivered correctly on every call
• No PCI data in transcripts (if applicable)
• Vulnerable customer transfers executed correctly
• Call recordings stored in the correct AWS region with correct encryption
• Retention policies applied

This audit is what separates a PoC that can go to your risk committee from one that cannot.

Phase 5: Evaluation and the Production Decision (Weeks 7 and 8)

Build the Business Case with Real Numbers

At the end of the live trial, you have real data. Build the business case from it:

• Call type: balance enquiry and recent transaction query
• Monthly volume: 8,400 calls
• Pre-PoC AHT: 4 minutes 20 seconds
• Pre-PoC cost per call: £4.80 (fully loaded)
• PoC containment rate achieved: 61%
• Post-PoC cost per contained call: £0.34 (AWS infrastructure only)
• Monthly saving at 61% containment: approximately £22,000
• Annualised saving: approximately £264,000
• PoC to production timeline: 4 weeks

These are the numbers that get budget approved.

The Production Readiness Checklist

Before you present the PoC results, verify the following:

• [ ] Architecture is identical to target production architecture
• [ ] Compliance controls verified by compliance team
• [ ] Load testing completed at 100% of peak call volume
• [ ] Runbook written for agent escalation scenarios
• [ ] Monitoring and alerting configured in CloudWatch
• [ ] Rollback procedure documented and tested
• [ ] Data retention and deletion procedures documented
• [ ] Security review completed (IAM roles, VPC configuration, encryption at rest and in transit)

If any of these are not complete, you do not have a production-ready PoC. You have a demo.

The Decision Framework

Present stakeholders with three scenarios based on your PoC data:

1. Full production deployment on the PoC call type, targeting 4 to 6 weeks to go live

2. Expanded scope to two or three additional call types, with a 6 to 10 week timeline

3. No-go with documented reasons if the PoC did not meet the pre-agreed success criteria

The no-go option is important. A PoC that produces a clear no-go decision is a success. It saves you from a failed production deployment.

Common Questions from UK Contact Centre Leaders

How long does a PoC take?

Eight weeks if you follow this playbook. The most common reason PoCs run longer is scope creep in weeks one and two. Lock the scope before you build.

What does a PoC cost?

AWS infrastructure costs for a PoC at 15% traffic routing on a 500-call-per-month call type are typically under £500 for the two-week live trial. The majority of PoC cost is engineering time. A well-scoped PoC requires two to three weeks of engineering effort.

Can we run the PoC without connecting to our production systems?

You can, but the results will not be decision-ready. Stakeholders will always ask whether the system works with real data. Connect to read-only endpoints from the start.

What happens after the PoC?

If the PoC meets your pre-agreed success criteria, production deployment takes 4 to 6 weeks. The PoC architecture is the production architecture. There is no rebuild. You are hardening, scaling, and completing the compliance sign-off you started in the PoC.

The Bottom Line

A well-run AI voice agent PoC is not a technology experiment. It is a production deployment running at 15% traffic with a rollback switch. Every architectural decision, every compliance control, and every metric you track during the PoC should be identical to what you will run at 100% in production.

If your PoC is built on a vendor sandbox with demo data and synthetic test calls, you are not evaluating an AI voice agent. You are watching a sales presentation.

We build AI voice agents for UK contact centres in regulated industries. Our PoC process is designed to produce a production-ready system in 4 to 6 weeks, not a slide deck.