Which AI Use Case Should You Start With?

Not the most advanced capability. The one with high volume, a knowable right answer, content that already exists, an owner with a number, and a route into the workflow people already use. Where each department usually starts, and the five-point test to apply before committing budget.

The question is not which AI capability is most advanced. It is which part of your organisation has a repetitive, high-volume task with a clear right answer, an owner who wants it fixed, and content good enough to answer from. That combination exists in most companies in two or three places, and almost never in the place the AI conversation started.

Why where should we start is the right question

Two ways to open the conversation

• We need an AI strategy. Produces a document. Nothing in it says which team is losing hours, who owns the outcome, or how you would prove any of it.
• Which team is losing the most hours to work a machine could do, and can we prove it in a month. Produces a result. Someone will defend it at budget time, and the framing survives contact with the organisation.

Every AI programme that stalls stalls for one of four reasons: no owner, no measure, no content, no adoption. Choosing the starting point well removes three of them.

Source: Thinklytics AI strategy practice, 2026.

We need an AI strategy produces a document. Which team is losing the most hours to work a machine could do, and can we prove it in a month, produces a result someone will defend at budget time.

The second framing also survives contact with the organisation. Every AI programme that stalls stalls for one of four reasons, and choosing the starting point well removes three of them:

• No owner. Nobody is accountable for the outcome, so nothing changes when it ships.
• No measure. Nobody wrote down what success was, so nobody can tell whether it arrived.
• No content. The answers the system needs to give do not exist anywhere in a form it can read.
• No adoption. It works, and people carry on doing it the old way, because the old way is in their workflow and this is in a separate tool.

Where each function usually starts

This is the pattern across the work we see. It is not a ranking of sophistication, it is a ranking of what tends to land.

| Function | Where it usually starts | What to measure | | --- | --- | --- | | Finance and back office | Document processing, invoice matching, anomaly detection | Cycle time per document, exception rate, cost per invoice | | Customer support | Support copilot, knowledge assistant, case summarisation | First response time, deflection on the repetitive tail, answer consistency | | Sales | CRM copilot, lead scoring, call summaries | CRM completeness, time from enquiry to first contact, selling hours recovered | | Analytics and BI | Certified metrics first, then dashboard copilot and automated commentary | Analyst hours on ad hoc requests, reporting turnaround | | HR and internal operations | Policy assistant, onboarding assistant | Repeat questions to the HR inbox, time to productive for a new starter | | Legal and procurement | Contract extraction, clause review, renewal tracking | Hours per document reviewed, renewals missed | | Operations and supply chain | Demand forecasting, predictive maintenance, scheduling | Forecast error, unplanned downtime, stockouts |

Three observations about that table.

Three observations about that table

Not a ranking of sophistication. A ranking of what tends to land.

Source: Thinklytics AI strategy practice, 2026.

Finance and support are the usual first movers, because the work is high volume, the right answer is knowable, and the baseline is already measured. You know what an invoice costs to process today, and that makes the pilot honest.

Legal and procurement are underrated. Contract extraction is one of the few places where the technology is strong, the documents already sit in one place, and the people doing the work are expensive. It rarely comes up in the AI conversation because it is nobody's transformation programme.

Analytics is the one people start with and should usually not. A dashboard copilot on top of metrics that three teams define differently will answer the same question three ways, at speed, with confidence. It automates a disagreement instead of settling it.

The test to apply before you commit

The five-point test before you commit budget

Score the candidate against each one without flattering it.

• Volume. Does it happen at least hundreds of times a month? Below that the saving will not clear the running cost.
• A knowable right answer. Could a competent person, given the same inputs, say definitively whether an output was correct? If not, you cannot evaluate the system, and if you cannot evaluate it you cannot deploy it.
• Content that exists. The policies, the SOPs, the contracts, the historical labelled examples, actually there, current, and identifiable as current. This is the step most programmes skip and the step most of them die at.
• An owner with a number. One named person whose existing measure improves if this works.
• A route into the existing workflow. It has to appear inside the CRM, the service desk, the ERP, or Teams, wherever the work already happens.
• A steering committee as the owner. Not an owner. Nobody is accountable for the outcome, so nothing changes when it ships.
• A separate portal. A slow way of discovering that nobody will open it.

Anything below four out of five is a pilot, not a programme.

Source: Thinklytics AI strategy practice, 2026.

Score the candidate against five things, without flattering it. Anything below four out of five is a pilot, not a programme.

1. Volume. Does it happen at least hundreds of times a month? Below that the saving will not clear the running cost. 2. A knowable right answer. Could a competent person, given the same inputs, say definitively whether an output was correct? If not, you cannot evaluate the system, and if you cannot evaluate it you cannot deploy it. 3. Content that exists. Are the policies, the SOPs, the contracts, the historical labelled examples actually there, current, and identifiable as current? This is the step most programmes skip and the step most of them die at. 4. An owner with a number. One named person whose existing measure improves if this works. Not a steering committee. 5. A route into the existing workflow. It has to appear inside the CRM, the service desk, the ERP, or Teams, wherever the work already happens. A separate portal is a slow way of discovering that nobody will open it.

What the first engagement should produce

Not a platform. Four things, in two to four weeks:

• A baseline measured before anything is built, because after the fact it is a negotiation.
• A go or no-go on real data: your documents, your exceptions, your edge cases, not a demo set.
• A written statement of what the system will refuse to do and where it escalates to a person.
• The running cost in year two, including the person who keeps the content current.

If that produces a no-go, it was the cheapest no-go available. Most organisations discover the same thing six months and a considerable sum later.

The uncomfortable part

In a meaningful share of these assessments the answer is that the problem is not an AI problem. The invoices arrive in nineteen formats because nobody has ever asked the suppliers to change. The support queue is repetitive because the product documentation is wrong. The forecast is poor because two systems disagree about what a unit is.

Automating any of those makes the underlying fault permanent and harder to see. The finding is unwelcome and it is worth considerably more than the pilot would have been.

Frequently asked questions

Which AI use case should we start with?

The one with high volume, a knowable right answer, content that already exists in a current and identifiable form, an owner whose existing measure improves if it works, and a route into the workflow people already use. That combination exists in most companies in two or three places, and rarely in the department that raised the AI conversation.

Which department usually gets the first win?

Finance and customer support, because the work is high volume, the right answer is knowable, and the baseline is already measured. You know what an invoice costs to process today, which makes the pilot honest. Legal and procurement are underrated for the same reasons and come up less often.

Why is analytics a bad place to start with AI?

A dashboard copilot on top of metrics that three teams define differently will answer the same question three ways, at speed, with confidence. It automates a disagreement instead of settling it. Fix the definitions first, then put the assistant on certified metrics.

What is the five-point test for an AI use case?

Volume of at least hundreds of occurrences a month. A knowable right answer a competent person could verify. Content that exists, is current, and is identifiable as current. One named owner with a number that improves. A route into the existing workflow rather than a separate portal. Below four out of five, treat it as a pilot rather than a programme.

What should the first AI engagement produce?

Not a platform. A baseline measured before anything is built, a go or no-go on real data including your exceptions and edge cases, a written statement of what the system will refuse to do and where it escalates, and the year-two running cost including the person who keeps the content current.

Why do AI programmes stall?

Four reasons. No owner accountable for the outcome. No measure written down, so nobody can tell whether success arrived. No content, because the answers the system needs do not exist in a form it can read. No adoption, because it shipped in a separate tool and the work happens somewhere else. Choosing the starting point well removes three of them.

What if the assessment says AI is not the answer?

That happens in a meaningful share of cases and it is worth more than the pilot would have been. Invoices arrive in nineteen formats because nobody asked the suppliers to change. The support queue is repetitive because the product documentation is wrong. Automating either makes the fault permanent and harder to see.