Voice AI use-case prioritisation: what to automate first

Almost every enterprise now has permission to deploy AI, and almost none of them are capturing the value. McKinsey's State of AI, published in November 2025, found that 88% of enterprises use AI in at least one function, yet only 6% are what it calls AI-mature, with just 14% seeing a measurable impact on earnings. The gap is rarely the model. It is where the model was pointed first.

Voice AI is where this shows up fastest, because a voice programme has to pick a starting call type before it can prove anything. Pick the queue that demos well and you get a launch and no payback. Pick the queue that quietly consumes agent hours and carries a clean success test, and the first phase funds the second. This guide is the prioritisation framework: how to build the shortlist, how to score each candidate call type on value and feasibility, which intents to deliberately leave alone, and how to sequence the survivors into a roadmap.

This guide is shipped by the team behind Dilr Voice, enterprise voice AI built for regulated deployments. Or see DATS, our five-stage AI consulting system.

What is voice AI use-case prioritisation, and why does it set the programme's ROI?

Voice AI use-case prioritisation is the discipline of scoring every candidate call type on value and feasibility before you automate any of them, then sequencing the winners into a phased roadmap. It is the entry decision, made before deployment, not the scaling decision made after your first success. Get it right and early wins fund later phases. Get it wrong and the programme stalls at a launch nobody can defend.

This is a different question from whether to invest at all. The case for the budget belongs in the enterprise voice AI business case, which argues the programme as a whole. Prioritisation comes next: given that you are going ahead, which of your twenty or thirty distinct call types earns the first slot. It also sits upstream of expansion. Once your first use case is live and proven, the voice AI programme expansion playbook governs how you scale the portfolio. Here we are choosing the entry point, and that choice is where most of the eventual return is won or lost, a decision we treat as its own discipline across our strategy playbooks.

Why do most voice AI programmes automate the wrong call type first?

Most programmes automate the call type that is easiest to demonstrate, not the one that moves the most value. The easy queue is usually simple, low-volume, and cheap to handle by a human already, so automating it changes nothing on the balance sheet. Meanwhile the expensive, high-volume queue that would justify the whole programme is left running because it looks harder. The demo wins the meeting and loses the year.

The economics are stark once you look at cost per contact. Gartner's benchmarking puts the median cost of an assisted contact, handled by a live agent over phone, chat or email, at 13.50 US dollars, against 1.84 US dollars for a self-service contact, a difference of roughly seven times. A queue that is both high-volume and expensive to staff is where automated resolution earns its keep. There is also a ceiling worth respecting: Gartner projected that only around 10% of agent interactions would be automated by 2026, up from an estimated 1.6% in 2022. You cannot automate everything, so the discipline is to automate the right thing. The same logic underpins our AI operating model consulting, which places automation where the cost actually sits, and whether those savings actually land is what the benefits realisation discipline measures later.

How do you score a call type on value?

You score value as volume multiplied by cost multiplied by resolvability. Volume is how large a share of daily calls the intent represents. Cost is how long, skilled or agent-scarce each handling is. Resolvability is whether the intent is bounded enough for an AI agent to close it with a clear success test. A queue only scores high on value when all three hold. A rare, cheap, or judgement-heavy call type scores low no matter how visible it is internally.

The point of the third factor, resolvability, is to stop volume from dominating. A billing-status query and a bereavement notification can have identical volumes, and only one belongs anywhere near an automation shortlist. Score each candidate on the three axes below, then multiply, so a weakness on any single axis drags the score down rather than being averaged away.

How do you score a call type on feasibility?

Feasibility asks whether you can actually ship this intent safely, and it has four axes: data availability, integration depth, regulatory exposure, and failure blast radius. A call type can score high on value and still be unbuildable because the answer lives in a person's head, the systems will not expose it, the regulator constrains it, or a wrong answer causes real harm. Feasibility is the veto. It stops a tempting queue from entering the roadmap before the guardrails exist.

Regulatory exposure has become a harder gate this year, and voice sits squarely inside it. The European Union's AI Act now sets an explicit transparency duty on any system that talks to a person:

"Providers shall ensure that AI systems intended to interact directly with natural persons are designed and developed in such a way that the natural persons concerned are informed that they are interacting with an AI system, unless this is obvious from the point of view of a natural person who is reasonably well-informed, observant and circumspect."

That is Article 50(1) of the EU AI Act, in force since 2 August 2026. For a call type, it means the disclosure is not optional, and any intent that also touches regulated advice, safeguarding, or vulnerable customers inherits far more. In the United Kingdom the Financial Conduct Authority Consumer Duty, live since 31 July 2023, holds firms to good outcomes for customers in vulnerable circumstances, and the Information Commissioner's Office expects data minimisation on every call. Integration depth is more prosaic but just as decisive: an intent that resolves against one or two known systems, a CRM such as Salesforce or HubSpot behind a telephony layer like Twilio, is buildable, while one that needs a chain of brittle legacy systems is not, yet. Sequencing that integration work is its own exercise, covered in the voice AI integration roadmap.

Which call types should you never automate?

Some intents should be excluded from the shortlist on principle, not scored and deferred. Bereavement and account-closure-on-death, safeguarding disclosures, crisis and self-harm calls, complaints that signal a vulnerable customer, and anything where a wrong answer causes irreversible financial or physical harm all belong on a permanent exclusion list. The test is failure blast radius crossed with human need. When an error cannot be walked back and the caller is already under strain, the call stays with a trained person.

Excluding these is not a limitation of the technology, it is a design decision that protects the programme. A single mishandled safeguarding call does more reputational and regulatory damage than a year of successful automation earns back, and it is exactly the kind of incident an AI execution office is built to keep off the roadmap. The exclusion list should be written down, signed off by compliance, and revisited only deliberately. It is also what lets you move fast on everything else, because the boundary is explicit rather than argued case by case. A well-run voice AI agent deployment treats the exclusion list as a first-class artefact, not an afterthought.

How do you sequence the shortlist into a phased roadmap?

You sequence by staging early wins to fund later phases, not by starting with the biggest number. The highest-volume queue is often not first, because volume without resolvability or with heavy integration debt is a long build with a distant payback. A better phase one scores well on value, is genuinely buildable now, and produces a clean, attributable result you can take to the board. That result buys the credibility and budget for phase two.

Respect the automation ceiling as you sequence. With only around 10% of interactions realistically automatable at scale in the near term, and Gartner projecting that agentic AI will autonomously resolve 80% of common customer service issues by 2029, the roadmap is a multi-year artefact, not a single launch. Front-load the phases that compound: a contained intent whose data and integrations you reuse later is worth more than an isolated win, and it is what keeps the eventual ROI attribution defensible. This is the same staging logic that turns a pilot into a programme, which the pilot-to-scale design guide sets out in full, and it is where a disciplined DATS five-stage methodology earns its fee. Whatever the sequence, the go or no-go on each phase stays with your operators.

What is the best way to prioritise voice AI use cases in 2026?

The best approach in 2026 depends on how many use cases you are weighing and who owns the governance. For a single, obvious, high-volume queue with strong in-house analysts, a lightweight build on a platform such as Vapi, Retell AI or Bland AI can be right, because you own the scoring and the risk is small. For a portfolio of competing call types across a regulated enterprise, a governed platform such as Dilr Voice or PolyAI wins.

The governed platform earns its place because the value and feasibility scoring, the exclusion list, and the phased roadmap are built into the operating model rather than reinvented by every team. The honest concession is that the DIY route wins when the decision is genuinely simple. If one queue dwarfs every other on value and clears feasibility outright, an elaborate scoring exercise is theatre, and a small team on Vapi or Retell AI will ship faster than any consulting engagement. The governed route earns its cost when the choices are close, the regulatory exposure is real, and the wrong first pick would burn a year. Most enterprise voice programmes sit in the second case, which is why prioritisation is worth doing properly rather than by instinct. If you want a second read on which case you are in, talk to us or read more about Dilr.ai.

Is the highest-volume call queue always the best place to start?

No. Volume is only one of the three value factors, and it is checked by cost per contact and resolvability, then vetoed by feasibility. A very high-volume queue that needs human judgement, or that depends on data your systems will not expose, scores poorly overall. The best phase one is usually a high-value queue that is also cleanly buildable now, which is rarely the single largest one on raw volume alone.

How many use cases should the first phase include?

One, done properly. A first phase with a single well-scoped call type keeps the failure blast radius small, produces a clean and attributable result, and gives you a reusable pattern for data, integration and escalation. Trying to launch three intents at once multiplies the integration surface and blurs the attribution, so the board cannot tell what worked. Prove one, then let its result fund the next.

Who owns the voice AI prioritisation decision?

Prioritisation is a cross-functional decision that no single team should make alone. Customer operations owns volume and resolvability, finance owns cost per contact, data and engineering own feasibility, and compliance owns the exclusion list and regulatory exposure. The framework exists to make those inputs explicit and comparable, but the final sequencing call, and the accountability for it, stays with the programme owner and your executives, not with any vendor.

Ready to run this properly? Try Dilr Voice live, book an AI placement diagnostic, see our DATS methodology, or read about our approach to placing AI where the value is.

Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.