The question I hear in every first conversation: "Where should we use AI?" It usually arrives with a list attached — twenty ideas collected in a workshop, ranked by enthusiasm, with the CEO's favorite at the top and a pilot already half-approved.
That selection method fails for a specific reason: enthusiasm tracks novelty, not value. The use cases that demo well — an agent that drafts board decks, a chatbot that answers anything — tend to be low-volume, high-judgment work. The use cases that pay — invoice matching, ticket triage, report assembly — are boring, so they never make it onto the workshop wall.
I score candidate processes against four tests before recommending AI for any of them. The tests come from manufacturing, where automation decisions have been made and paid for since before AI had a marketing budget. On the shop floor at Vedanta, nobody automated a production station because it seemed exciting. They automated it because the numbers cleared a bar.
Test 1: Volume
How often does the work happen, and how long does each instance take? Multiply the two. A 20-minute task performed 30 times a week consumes 10 hours weekly — roughly 500 hours a year. That is a real target. A 3-hour task that happens once a quarter is 12 hours a year, and no automation of it will ever repay its own setup cost.
This test kills the majority of workshop favorites. Painful-but-rare loses to boring-but-frequent, and it isn't close.
Floor to clear: 5+ hours per week of repeated work.
Test 2: Repeatability
Do the steps stay the same from one instance to the next? There is a fast way to find out: ask the person who does the work to walk you through the last five instances. If the inputs, steps, and decision points match across all five, the process is repeatable. If the answer to half your questions is "it depends," you are looking at judgment work — AI can assist the person doing it, but it cannot own the process.
On a production floor, you map a station before you automate it: inputs, outputs, handoffs, exceptions. Skip the mapping and the automated station produces defects at machine speed. The office version of this rule is identical, and skipping it has the identical result.
Test 3: Data
Where do the inputs live? If they sit in one system, digitally, and everyone trusts the numbers, the process passes. If they are scattered across email threads, three spreadsheets, and one veteran employee's memory, the process fails — for now.
A failed data test does not mean AI is off the table. It means the project you are about to fund is a data consolidation project wearing an AI badge, and it should be planned and priced as one. The expensive failures happen when this goes unnoticed: the AI project starts, the team discovers mid-build that the inputs disagree, and a data cleanup effort begins inside a project that budgeted zero hours for it. I wrote about the mechanics of this in Why 95% of AI Projects Fail to Generate ROI — data disagreement is failure cause number one across every major study this year.
Test 4: Cost of error
AI systems produce wrong outputs at some rate. The design question is what a wrong output costs and who catches it before it lands.
Drafting a support reply that an agent reviews before sending: an error costs one minute of the agent's attention. Sending quotes to customers with no review step: an error costs a customer. Same technology, same accuracy rate, completely different risk. A process with human review built in can absorb a 5% error rate and still save hundreds of hours. A process with zero error tolerance and no review capacity is a bad candidate no matter how well it scores on the first three tests.
Score by the minimum, not the average
Rate each candidate process 1 to 5 on each test. Then take the lowest score — not the average. Averages hide fatal flaws. A process that scores 5-5-5-1 averages 4, which looks healthy, but that single 1 means the project fails in production.
Two examples from the kinds of engagements I run:
Support ticket triage. Volume: 5 — forty tickets a day. Repeatability: 4 — categories and routing rules are stable. Data: 4 — everything lives in the helpdesk system. Cost of error: 4 — an agent reviews before anything reaches a customer. Minimum score: 4. Strong candidate, and the case-study results match: response times from 8 hours down to 12 minutes.
Board deck drafting. Volume: 1 — monthly. Repeatability: 2 — every deck is different. Data: 2 — inputs come from six places. Cost of error: 2 — errors reach the board. Minimum score: 1. This is the use case that wins the workshop vote.
Where AI adds complexity instead of value
The inverse profile is worth naming explicitly. Be suspicious of automating: processes that run rarely, processes where every instance needs judgment, processes whose data is disputed, and processes where an error is expensive and nothing catches it.
Two more traps that the tests alone won't catch. A process that is about to change — a reorg, a new system, a pending acquisition — should not be automated until it settles, because you will pay for the automation twice. And a process that exists as a workaround for a deeper problem should not be automated at all: automating a manual reconciliation between two systems that should talk to each other directly just preserves the broken plumbing, permanently, at a monthly license fee.
What to do this week
List ten processes your team runs. Score each one against the four tests, 1 to 5. Take the minimum score for each. The top two or three are your candidates — and in my experience they will not be the ones anyone nominated in the workshop.
I built a free tool that runs this analysis against your specific business:
- AI Opportunity Finder — describe your operations, get your processes scored and ranked
- Implementation Complexity Score — for the candidates that pass, how hard will each one be?