Which AI use case should you fund first?

Most leadership teams finish an AI workshop with a list of twenty or thirty ideas and budget for one. The list is usually ranked by ambition, or by whoever argued for their idea most convincingly. Both orders lead to the same place: a pilot that impresses in a demo, needs more data than anyone can get, and stalls before it reaches the people who would use it.

A better order comes from four questions you can ask about any process. They take an afternoon to apply to the whole list, and the use case that comes out on top is rarely the one people expected.

Four questions decide it

How often does it happen?

Count how many times the work is done in a normal week, and by how many people. Work that happens a few times a quarter won't give you enough examples to test against, and the time it saves is small. Work that happens hundreds of times a week gives you a test set from your own history and a saving you can see within a month.

Small tasks add up faster than they look. Take a hypothetical ten-minute check that one analyst does every working day. Over a quarter that's around sixty-five checks. Across a team of forty, it's thousands of checks and hundreds of hours, and nobody lists it as a problem because each instance feels trivial.

How much judgment does it need?

Walk through the steps and mark the ones that need someone who knows the customer, the contract or the history. Reading a document, matching it to a record and routing it are steps anyone trained could do. Deciding whether to accept a late delivery from a key supplier is a judgment. Most processes are mostly the first kind with one or two of the second, and that mix is what you want.

Where do the inputs come from?

A process that starts from a form, a structured email or a record in a system you own is ready. A process that starts from a phone call nobody writes down, or a spreadsheet on one person's laptop, needs that input fixed first. Fixing it is often cheap, but it comes before the AI work, so count it in the plan.

How would you know it worked?

Name the number that should move: hours spent per week, time from receipt to decision, the share of cases resolved without a second touch. If you can't name it, you can't tell whether the project paid for itself, and the second project will be harder to fund.

Put the list on two axes

Frequency and judgment do most of the sorting. Plot each candidate by how often it happens and how much judgment it needs, and four groups appear.

• Frequent, little judgment: fund these first. Invoice matching, document intake, ticket triage and data entry between systems usually sit here.
• Frequent, needs judgment: automate the routine steps and keep a person at the decision. Claims, credit reviews and exception handling sit here.
• Rare, needs judgment: leave these with people. Strategy, negotiations and one-off investigations don't repeat enough to learn from.
• Rare, little judgment: leave these alone for now. The saving is too small to justify the work.

The other two questions then act as filters. A candidate in the first group whose inputs live in someone's inbox moves down the list until the inputs are fixed. A candidate with no measure moves down until someone owns one.

Keep a person at the exception

Projects that go wrong are often the ones that tried to remove every human step. The ones that last keep the decision where it was and remove the work around it.

Take supplier invoices. Each one is read, matched to its purchase order and queued for approval. When the amount doesn't match, the invoice goes to someone in finance with the order, the invoice and the difference side by side, and they approve or reject it in a minute instead of hunting for the paperwork. Designing that exception path well is most of the work, and it is where the trust comes from.

Ask of every candidate: where does a person need to decide, and what would they need in front of them to decide quickly? If you can answer that, the rest of the process is a candidate.

Where first use cases usually come from

The same handful of processes tend to pass all four questions, because they are frequent, mostly routine and already run through systems.

• Finance and operations: matching invoices to orders, reconciling accounts at month end, and reading orders that arrive as email attachments.
• Customer service: sorting incoming requests, pulling the account and order history into the ticket, and drafting replies from approved answers for an agent to check.
• Sales operations: keeping the CRM accurate from email and calendar activity, and making sure every open quote gets a follow-up.
• Risk and compliance: checking documents against a fixed list of requirements and sending the gaps to a reviewer.

What to leave for later

• Anything that happens a few times a year. You won't have enough examples to test against.
• Anything where the inputs are a mess. Fix the form or the inbox first.
• Anything customer-facing where you can't yet say how a mistake would be caught. Start with the internal step before it.
• Anything that depends on a system with no way to connect to it. Check before you commit, not after.

None of these are never. They become second or third projects once the first one is running and your team knows what good looks like.

Decide the measure before you build

Whichever use case you pick, write down three things before any work starts: the number that should move, its value today, and who will read it after launch. The value today is the step teams most often skip, and without it you'll be arguing about whether anything changed. Take it from your ticketing system, your ERP or a week of timesheets. A rough reading taken before the change is worth more than a precise one taken after.

This is also how you'll know whether the work earned its cost. A system that removed hours of re-keying each week has a number next to it, and that number is what funds the next project.

What to do this week

1. List the ten processes that take the most time across finance, operations, service and sales.
2. Score each on the four questions: frequency, judgment, inputs and measure.
3. Pick the one that is frequent, low on judgment, starts from a system you own and has a measure you can take today.
4. Write down where a person decides in that process and what they'd need in front of them.
5. Take the measure's reading now, before anything changes.

If you'd like a second opinion on the list, that's what a strategy engagement is for. We score the candidates with you, check the data and controls each one depends on, and tell you which one we'd fund first and why.

Get the next article when it's published.