Most contact-centre AI projects begin too late in the decision process.
The first serious conversation is often about products, models or vendors. By then, somebody has usually decided that AI is the answer. The remaining work is treated as selection and implementation.
After more than 20 years working with contact-centre operations and technology, I would start somewhere else. Before choosing a tool, establish whether the operation is ready to use one responsibly and whether the proposed use case is worth solving.
Readiness does not mean having perfect data or a modern platform. Few operations do. It means understanding the current workflow, knowing where the risks and exceptions sit, and having enough operational control to introduce AI without losing sight of the customer outcome.
I assess that readiness across seven connected areas.
First, decide what kind of help you need
AI assistance, automation and autonomy solve different problems.
Assistance gives a person better information or reduces manual effort. It can retrieve relevant knowledge, summarise a conversation, suggest a response or draft after-call notes. The adviser remains responsible for the decision and the action.
Automation follows a defined process. It might classify an email, populate fields or route an interaction according to known rules. AI can improve parts of the process without deciding the overall objective.
Autonomy gives the system authority to choose and execute actions within a boundary. It can decide what to do next, use connected tools and change a customer or business record without approval on every step.
These are not stages of maturity where every use case should end in autonomy. In my experience, assistance is often the strongest starting point in a contact centre. It can remove friction around the human conversation while keeping judgement with the person who understands its context.
A useful readiness assessment therefore starts with one question: what authority does this use case actually require?
1. Is the workflow understood well enough to change?
Choose one workflow, not a broad ambition such as “improve customer service with AI”.
Map how the work happens today:
- what starts the interaction
- what information the adviser needs
- which decisions follow fixed policy
- where judgement is required
- which exceptions occur regularly
- what gets recorded, approved or escalated
- who owns the outcome
This usually exposes a more precise opportunity. The problem may be time spent searching several knowledge sources, inconsistent case summaries, avoidable transfers or a queue that mixes routine and specialist work.
AI does not repair an unclear process. It can make the unclear process faster and harder to inspect.
Ready looks like: the team can describe the current workflow, its exceptions, its owner and the specific point where AI would reduce effort or improve a decision.
2. Can the system reach reliable data and knowledge?
Contact-centre AI depends on operational context. That may include customer history, product records, policy documents, interaction transcripts, case status and channel-specific metadata.
The important test is not whether data exists. It is whether the right information can be found, trusted and used for the stated purpose.
Check:
- whether policy and knowledge content has a named owner
- how conflicting or expired information is identified
- whether important customer context is split across systems
- which personal data the use case genuinely needs
- how access will follow existing permissions
- what information may be retained in prompts, logs or evaluation records
The Information Commissioner’s Office guidance on AI and data protection is a useful reference here. Data protection responsibility does not disappear because a model or service is supplied by somebody else.
Ready looks like: the team knows which sources are authoritative, who maintains them, what access is permitted and how poor information will be detected rather than presented confidently.
3. Are the integrations designed for failure as well as success?
A demonstration can use a clean transcript and a working API. A live contact centre has delayed records, partial outages, duplicate events, channel transfers and customers whose circumstances do not match the expected path.
List every dependency between the AI capability and the current platform. For each one, ask what happens when it is slow, unavailable or returns incomplete data.
A summary feature should not block an adviser from completing an interaction. A recommendation should show when required context is missing. An action should be idempotent where possible, so retrying it does not create a duplicate refund, message or case.
The fallback matters as much as the primary path. Advisers need to know whether they can continue safely, whether work will be queued, and whether the customer must be transferred.
This is where contact-centre AI and customer-experience technology becomes a platform question rather than a model question. The value is created inside the workflow, which means routing, identity, customer data and back-office systems all matter.
Ready looks like: dependencies, timeouts, retries, fallback behaviour and recovery ownership are part of the design before a pilot reaches customers.
4. Is authority matched to consequence?
Every use case needs an explicit boundary.
Retrieving a policy is not the same as recommending an adjustment. Drafting an adjustment for approval is not the same as applying it. The further a system moves from observation to action, the more evidence and control it needs.
For each proposed action, consider:
- the financial, regulatory and customer consequence of an error
- whether the action can be reversed
- which customers or situations need different treatment
- when human approval is mandatory
- what evidence must be recorded
- who can stop the capability
The NIST AI Risk Management Framework groups practical risk work around governing, mapping, measuring and managing AI. That is a better model than treating governance as a final approval meeting.
The same principle runs through my earlier article on why autonomy has to be earned and maintained. A system should receive only the authority its evidence and operating environment justify.
Ready looks like: the business owner, technology owner and risk owner agree what the system may observe, recommend and do, including the cases where it must stop or hand over.
5. Have agents and supervisors helped shape the change?
Agent adoption is not a communications task at the end of implementation.
Advisers understand where knowledge is unreliable, which systems add delay and which apparently simple interactions regularly become difficult. Supervisors know how queue pressure, coaching needs and unusual customer situations change through the day.
Involve both groups while choosing and designing the use case. Let them test realistic examples, including poor transcripts, ambiguous requests and policy exceptions. Ask whether the output helps them act, not merely whether it looks impressive.
The interface should also make the AI’s role clear. Advisers need to know what information was used, what remains uncertain and what they are expected to verify. If rejecting or correcting a suggestion takes more effort than accepting it, the design creates pressure towards uncritical use.
Ready looks like: advisers and supervisors can explain how the capability changes their work, where they remain accountable and how they report a poor output or unsafe pattern.
6. Can you measure an operational outcome?
Define the baseline before the pilot.
The metric should follow the problem. If advisers lose time searching for policy, measure search effort and whether the retrieved answer is correct. If after-call work is the target, measure completion time and the quality of the record. If routing is the problem, measure transfer patterns and successful resolution, not just classification accuracy.
Contact-centre measures interact. Reducing handling time can be meaningless if repeat contact rises or records become less useful. Higher containment can be harmful if customers struggle longer before reaching a person.
Use several forms of evidence:
- a direct operational measure
- quality review against agreed criteria
- adviser and supervisor feedback
- customer impact
- failures, overrides and escalations
- cost per successful outcome
Agree in advance what would justify expansion, revision or stopping. A pilot without a decision rule can continue because it is interesting rather than because it works.
Ready looks like: the team has a baseline, a narrow set of balanced measures, an evaluation method and a named decision date.
7. Can the organisation operate it after launch?
Production AI is a service to be operated, not a feature to be handed over.
Someone needs to own model and prompt changes, knowledge updates, access, evaluation, incidents, supplier changes and cost. Monitoring should show operational outcomes as well as technical availability.
Plan for:
- sampled quality review and automated evaluation where appropriate
- changes in customer language, products and policy
- model or supplier updates
- unusual cost, latency or error patterns
- security events and inappropriate access
- rollback, suspension and manual operation
- a clear retirement process
The National Cyber Security Centre’s guidance for secure AI system development treats secure operation and maintenance as part of the AI lifecycle. Its emphasis on logging, monitoring, update management and incident processes reflects what production systems actually require.
This also connects to a broader engineering principle: security is cheapest when it is a default decision, not a control added after customers and operations depend on the system.
Ready looks like: ownership, monitoring, change control, incident response and a safe way to disable the capability are funded parts of the operating model.
Use red, amber and green to make the decision
Score each of the seven areas:
- Green: understood, owned and tested well enough for the proposed scope
- Amber: a known gap with an owner and a realistic plan
- Red: an unresolved dependency or risk that makes the proposed pilot unsafe or impossible to evaluate
Do not average the scores. One red area can invalidate the whole use case. Strong agent interest does not compensate for inaccessible data. Good integration does not compensate for unclear authority. A polished demonstration does not compensate for having no production owner.
An amber score is not necessarily a reason to stop. It may tell you how to narrow the first deployment. Use one knowledge source instead of five. Start with drafting rather than sending. Limit the pilot to one queue, one interaction type or one group of trained advisers.
That is sensible scope control, not lack of ambition.
The output should be a decision, not another workshop
A useful contact-centre AI readiness assessment should produce five things:
- a defined operational problem and baseline
- the required level of assistance, automation or autonomy
- a map of workflow, data, integration and risk dependencies
- a bounded pilot with measures and stopping rules
- a production operating model with named owners
The result may be “not yet”. That is still valuable if it identifies a broken workflow, an unowned knowledge base or an integration that would undermine any vendor choice.
When the answer is “yes”, the organisation can approach technology selection with a clearer brief. It knows what the system must do, what it must never do and what evidence will determine whether it should go further.
The best first contact-centre AI project is not the one with the most advanced model. It is the one attached to a real operational problem, given proportionate authority and designed to keep working when the demonstration conditions disappear.
If you are assessing a live use case, share the workflow, current platform and outcome you need. The useful first step is to identify what must be true before choosing a model or supplier.
The AI and contact-centre technology reading path brings this assessment together with the related work on trusted autonomy, security and production ownership.
For help applying the assessment, see the contact-centre AI and CX capability and the implementation and delivery approach. Discovery, requirements assessment, proof of value and implementation can be scoped around the workflow and operational responsibilities, rather than assuming that every team needs the same solution.