Every leadership team we work with arrives with a list. Somewhere between eight and thirty processes that somebody thinks AI could handle. The list is usually right that those processes are painful and usually wrong about which of them to touch first.
The question is not whether a model can perform the task. In 2026 the answer is almost always yes, at some level of quality. The question is whether the economics survive contact with your actual volume, your actual error tolerance, and your actual ability to tell good output from bad. Four tests settle it.
Test one: does it run often enough to matter?
Automation pays back on frequency, not on difficulty. A genuinely hard task that runs twice a month is a bad target, however satisfying it would be to solve. A dull task that runs four hundred times a week is a good one.
The arithmetic is simple enough to do in a meeting. Take the minutes the task consumes, multiply by how often it runs in a year, and convert to a loaded hourly cost. A four-minute task run 600 times a month is 480 hours a year. At a loaded rate of $45 an hour that is roughly $21,600 of annual labour, which will comfortably fund a build in the low tens of thousands and keep paying afterwards. The same task run 20 times a month is 16 hours a year, or about $720. Nothing you build will earn that back.
Do this for every item on the list before you discuss any of them in detail. It usually eliminates half.
Test two: would a plain script do it?
This is the test most often skipped, and skipping it is expensive. A large share of what gets pitched as AI work is deterministic: moving fields between two systems, applying a documented rule, reformatting a file, triggering a notification when a threshold is crossed. Those are integrations and scripts. They are cheaper to build, faster to run, cost nothing per invocation, and fail in predictable ways.
The honest test is whether you could write the rules down. If a competent new hire could follow a one-page instruction sheet and produce the right answer every time, you do not need a language model. You need an engineer and a week.
AI earns its place where the input is unstructured or the rules resist enumeration: reading a supplier email that could be phrased a hundred ways, extracting terms from a contract nobody standardised, classifying a support ticket where the customer describes symptoms rather than causes, drafting a first pass that a person will edit. That is genuine judgment under ambiguity, and it is where the technology is worth its cost and its risk.
Test three: what does a wrong answer cost?
Every automated workflow will be wrong sometimes. The design question is what happens when it is, and that answer, not the model you choose, determines the shape of the system.
| If a wrong output is | Then the system should | Example |
|---|---|---|
| Cheap and reversible | Run autonomously, sampled for quality after the fact | Tagging inbound tickets by topic |
| Visible but recoverable | Run autonomously with confidence thresholds that escalate | Drafting a reply a human sends |
| Expensive or public | Require human approval before the action commits | Issuing a customer refund or a price quote |
| Regulated or safety-bearing | Assist a person rather than act, with a full audit trail | Anything touching clinical, legal, or financial advice |
Teams tend to argue about accuracy percentages in the abstract. That argument goes nowhere. Ask instead what the worst plausible wrong output does to the business, who would notice it, and how long it would take to undo. A workflow where the answer is genuinely alarming is not disqualified, but it belongs in the assist column, where the model saves time without holding the pen.
Test four: can anyone define a correct output?
This is the test that quietly kills more pilots than any other. Before you build, someone has to be able to look at fifty real examples and say, unambiguously, which outputs are acceptable. If your best subject-matter expert cannot do that, or two experts disagree on half of them, you do not yet have a specification. You have a preference.
The practical consequence is that you cannot build an evaluation harness, and without one you have no way to know whether a prompt change, a model upgrade, or a shift in your input data has degraded quality. You will find out from a customer.
Where the definition is genuinely hard, the fix is usually to narrow the scope until it becomes easy. Not "handle supplier correspondence" but "extract delivery date, quantity, and part number from supplier confirmation emails". Narrow problems have checkable answers.
If you cannot write the test, you are not ready to build the system. That is true of software generally and unforgiving of AI specifically.
Running the triage
Put the list on one page with four columns and score each workflow honestly. Volume, in annual hours. Rules-based or judgment. Error cost, on the four-level scale above. Definable output, yes or no.
- Anything failing the volume test comes off the list, unless you can name a specific cycle-time or revenue reason to keep it.
- Anything rules-based moves to a separate list. That list is an integration project and it is probably cheaper and more valuable than the AI one.
- Anything without a definable output goes to a scoping conversation, not a build. Narrow it until it has one.
- What remains gets ranked by annual hours divided by implementation difficulty, and you build the top item. One item.
The instinct at this point is to start three pilots at once because they all look promising. Resist it. Three half-built pilots produce no measured savings and a lot of ambiguity about why. One workflow taken all the way to production, with an evaluation harness and a monitored cost ceiling, teaches your team how to do the next one and gives you a number you can defend.
What good looks like ninety days in
A well-chosen first workflow produces four things by the end of a quarter: a system running against real data, a test set with scored results you can watch over time, a documented cost per run, and at least one person on your team who understands the whole thing well enough to change it.
If you have all four, the second workflow is dramatically cheaper than the first, because the hard parts were never the model. They were the plumbing, the evaluation discipline, and the organisational habit of deciding what correct means before building.
If you have none of them ninety days in, the problem is almost never the technology. Go back to test four.