Start with the problem and the evidence
An AI strategy should not begin with a product demonstration or a list of available features. Start with the customer and business problem, then use current-state evidence to understand its scale, cause and consequence.
Review customer journeys, contact reasons, repeat demand, transfers, failure points, complaints, quality results, handling patterns and colleague feedback. Add the cost, risk and service evidence needed to show why the problem matters. This creates a baseline against which any proposed improvement can be judged.
The strategy then defines the destination and the outcomes the organisation wants to achieve. The change programme closes the gap between the current state and that destination. Technology supports the change after the requirements, operating model and decision criteria are clear.
Choose use cases against real operating problems
The label AI covers capabilities with different data, integration, operating-model and governance requirements. Treat each use case as a separate decision, even when a supplier bundles several capabilities into one platform.
| Use case | Problem it may help address | Evidence and readiness to test |
|---|---|---|
| Agent assistance and knowledge retrieval | Agents spend time finding reliable information or applying complex processes consistently. | Knowledge accuracy, search behaviour, process ownership, desktop integration, agent adoption and a route for correcting unsafe or irrelevant suggestions. |
| Conversational self-service | Routine demand is suitable for automation and customers can complete the journey without avoidable effort. | Contact reasons, journey completion, authentication, integration, exception handling, accessibility, disclosure and effective transfer to a person. |
| Conversation analytics and quality monitoring | Manual sampling gives too little evidence about customer demand, compliance, quality or failure patterns. | Recording coverage, transcription quality, language and accent performance, scoring criteria, reviewer calibration, privacy and a process for acting on findings. |
| Predictive or intelligent routing | Existing routing does not consistently connect customers with the right resource or next action. | Reliable intent and outcome data, routing constraints, skills and capacity, fairness checks, operational ownership and measurable comparison with the current approach. |
| Forecasting and workforce support | Demand, scheduling or intraday decisions are constrained by incomplete or slow analysis. | Historic demand quality, event data, planning rules, human review, seasonal variation and clarity about which decisions remain with operational leaders. |
| Summarisation and administrative automation | After-contact work or record keeping creates delay, inconsistency or unnecessary effort. | Required record quality, CRM integration, validation rules, privacy, exception handling and evidence that time saved is not offset by correction work. |
Run a readiness test before selecting a platform
A promising use case can still be the wrong next step if the operating conditions are not ready. Test readiness across the whole service, not just the technical architecture.
- Data: Is the relevant data available, lawful, representative, accurate enough and accessible at the point of use?
- Process and journey: Is the process stable enough to automate, and are failure paths and exceptions understood?
- Knowledge: Is there an owned source of truth, a review cycle and a way to correct outdated or conflicting content?
- Integration: Can the capability reach the systems and context needed to complete the task safely?
- People and operating model: Who owns the outcome, monitors performance, handles exceptions and improves the service after launch?
- Governance and risk: Are decision rights, privacy, security, transparency, human oversight and escalation requirements clear?
- Commercial readiness: Are implementation effort, usage charges, supplier dependencies, internal resource and exit implications understood?
- Measurement: Is there a reliable baseline and a small set of outcome and guardrail measures that can show whether the change is useful?
Turn the strategy into a controlled roadmap
- Define the decision. State the customer or operational problem, the evidence behind it and the outcome that matters.
- Assess the current state. Identify the data, journey, process, knowledge, integration, people and governance conditions that affect the use case.
- Design the future operation. Define how the service should work, including ownership, human handoff, exceptions, controls and continuous improvement.
- Prove the use case. Test with representative demand and agreed acceptance criteria. Compare the result with the baseline, including failure and correction effort.
- Scale only with evidence. Expand when the outcome, operating controls, support model, cost and residual risks are understood and accepted.
This sequence does not require every organisation to move slowly. It requires each decision to be supported by enough evidence to proceed without transferring avoidable risk into delivery or live service.
What suppliers should be required to prove
Supplier evaluation should test how the proposed capability works in your operating environment. A standard demonstration can show that a feature exists, but it does not prove that it will work with your data, journeys, integrations, controls or service model.
- Ask suppliers to distinguish capability available now from roadmap commitments, preview functions and partner dependencies.
- Use representative customer journeys, data conditions and exceptions in demonstrations and proof activity.
- Require clear answers on data use, model hosting, retention, security, transparency, monitoring and human oversight.
- Identify client-side work across knowledge, integration, process redesign, testing, training, governance and service ownership.
- Test how failures are detected, handed to people, corrected and prevented from recurring.
- Compare the full cost of implementation, consumption, support, change and optimisation, not just the licence line.
- Put acceptance criteria and supplier responsibilities into the commercial and delivery documents rather than relying on presentation statements.
Measure value and protect the customer outcome
A business case should connect each use case to an observed baseline and an intended result. Efficiency may matter, but it should not be measured in isolation from customer effort, resolution, quality, colleague impact, risk and total cost.
Use outcome measures to show whether the original problem improved. Add guardrail measures to identify harm or displacement, such as repeat contact, transfer, abandonment, complaints, corrections, overrides or avoidable escalation. Assign each measure an owner, evidence source and review point.
Pilot results should separate what the technology achieved from changes in demand, staffing, process or measurement. Continue the review after launch because performance, content, customer behaviour and supplier capability can change.
A practical go or no-go check
Before platform selection or approval to scale, the executive sponsor should be able to answer these questions with evidence.
- What customer or business problem are we solving, and what does the current evidence show?
- What outcome will improve, what is the baseline and who owns it?
- Why is AI appropriate compared with process, policy, knowledge or simpler automation changes?
- What data, integration, knowledge and operating-model conditions must be in place?
- How will customers and colleagues know when AI is being used, where required?
- Where does human judgement remain, and how will handoff and exceptions work?
- What could go wrong, how will it be detected and who can stop or change the service?
- What must the supplier prove before contract, pilot acceptance and scale?
- What is the total cost, including internal change, assurance, support and ongoing optimisation?
- Which evidence will allow the governance body to proceed, pause or stop?
The practical test is not whether a platform contains AI. It is whether the organisation can show that a defined use case, in its own operating environment, will improve an agreed outcome with acceptable cost and risk. That is the point at which platform selection becomes a meaningful decision rather than the start of the strategy.