Most AI use case lists are organized by industry, which is close to useless. Two companies in the same industry will have completely different results from the same idea, because what determines success is not the domain but the shape of the task. A task with messy inputs, a narrow output, and a person already checking the work is a good candidate almost anywhere. A task requiring an exact number, with no reviewer downstream, is a bad candidate everywhere. This guide is organized by shape.
What makes a task a good candidate
Before the patterns, the screen. Across engagements, the use cases that survive contact with production share the same handful of properties. The ones that fail usually fail on the last two, and they fail late, after a demo has already convinced someone.
- The input is unstructured or inconsistent (text, documents, email, notes) and a person currently reads it.
- The output is narrow: a set of fields, a category, a short summary, a ranked list of candidates.
- There is a defined correct answer, at least well enough that two experienced staff would agree on it.
- You can assemble 100 to 300 real historical examples with known answers to test against.
- A wrong answer is visible to someone before it causes harm.
- A wrong answer is cheap to correct once it is spotted.
The seven patterns that carry the value
Extraction from unstructured documents
Pulling structured fields out of invoices, purchase orders, certificates, statements of work, inspection reports, or inbound email. This is the most consistently profitable pattern in operations because the current cost is obvious (someone is typing) and the output is checkable field by field. Expect 90–97% field-level accuracy on documents with recurring structure, lower on handwriting and photographed pages. Measure it as minutes per document and correction rate per field, and confidence-score the fields so low-confidence ones route to a person rather than the whole document. It is not worth doing if you receive fewer than a few hundred documents a month, or if the sender could simply be given a form.
Classification and routing
Deciding what an inbound item is and where it should go: which queue, which team, which priority. Good candidate when the category list is stable, under roughly twenty options, and the current routing decision takes a person under a minute but happens thousands of times. Expect 85–95% accuracy, and understand that the residual errors concentrate in the categories your own staff disagree about. Measure time-to-first-touch and misroute rate, not raw accuracy. Skip it if the categories are ambiguous enough that your own team's historical labels are inconsistent. You will be encoding the inconsistency.
Summarization for handoff between people
Condensing a long case history, ticket thread, or account record so the next person picking it up does not read forty messages. The value here is real but harder to see, because the time saved is distributed across many people in small pieces. It works because the reader is an expert who will notice if the summary is wrong, and because the source material stays one click away. Measure ramp time on handoff and the rate at which readers open the full thread anyway. Do not use it where the summary becomes the record of decision. Summaries omit, and omissions become invisible.
Drafting a first version a human edits
Response drafts, scopes of work, job descriptions, incident write-ups, customer communications. The economics depend entirely on edit distance. If the draft is usually 80% right, this is one of the highest-return patterns available. If it is 50% right, editing costs more than writing and adoption collapses within a month, quietly, without anyone reporting it. Measure accepted-with-minor-edits rate and time to send. The failure mode to watch is not bad drafts. It is good-enough drafts that flatten a distinctive voice or slowly normalize sloppy detail.
Search and retrieval over internal knowledge
Answering questions from policies, manuals, contracts, and past tickets. Attractive on paper and frequently disappointing in practice, because retrieval quality depends on the state of your documentation, not the model. If your knowledge base contains three contradictory versions of the same policy, this pattern will confidently surface all three. It works when answers must cite their source document so a person can verify in one click. Measure deflected questions and click-through-to-source, and treat a low citation rate as a documentation problem rather than a tuning problem.
Anomaly and exception surfacing
Flagging the transactions, orders, or records that look unlike the others so a person looks at them first. This pattern is safer than most because it changes the order of human attention rather than replacing a decision. Nothing is auto-approved; something is merely moved to the top of a queue. Set the threshold to over-flag early and tighten it with feedback. Measure exceptions caught before they reached a customer, and precision at the top of the queue. It is not worth doing where the exception rule is already known and expressible in SQL.
Matching and reconciliation
Linking records that refer to the same real-world thing across systems that never agreed on identifiers: vendor names, part descriptions, customer entities, remittances against invoices. Fuzzy matching is a long-standing problem and modern models are genuinely better at the ambiguous residue that rules leave behind. The correct design is a rules layer for the exact and near-exact matches, with the model handling only the remainder and proposing matches for confirmation. Measure the auto-match rate and, more importantly, the false-match rate, because a wrong reconciliation is far more expensive than an unmatched record.
Scoring the patterns
| Pattern | Build effort | Payoff | Risk | Realistic accuracy |
|---|---|---|---|---|
| Extraction | Medium | High | Low | 90–97% per field |
| Classification and routing | Low | Medium | Low | 85–95% |
| Summarization for handoff | Low | Medium | Medium | Judged, not scored |
| First-draft generation | Low | High | Medium | Measured by edit distance |
| Retrieval over knowledge | High | Medium | High | Depends on documentation |
| Exception surfacing | Medium | High | Low | Tuned by threshold |
| Matching and reconciliation | High | High | Medium | 70–90% auto-match |
The pattern most organizations should start with is extraction or exception surfacing: bounded, measurable, and low risk. The one most start with instead is retrieval, because it demos well to a leadership audience and because it feels like it should be easy. It is the hardest column in the table.
Where AI is currently the wrong tool
Three categories of work should be ruled out before you spend a day on them. Ruling them out early is worth more than any use case you add.
Anything requiring exact arithmetic
Pricing, tax, commission, payroll, inventory positions, financial totals. A language model produces plausible numbers, and plausible is the worst possible failure mode for arithmetic because it passes a glance. The correct architecture is to have the model extract or identify the inputs and a deterministic function do the math. If a design has a model computing a figure that ends up on an invoice, that design is wrong regardless of how well it tests.
Decisions that are unrecoverable and unreviewable
Sending an external communication, issuing a credit, terminating an account, dispatching a crew, filing a regulatory submission. The problem is the combination: unrecoverable alone is manageable if someone approves first, and unreviewable alone is manageable if you can undo it. Together they mean the first serious error is also the last thing anyone learns before the damage is done. Either insert an approval step or leave the decision alone.
Anything a deterministic rule already handles
If routing is genuinely by customer tier, or the exception is genuinely orders over a threshold, write the rule. A rule is cheaper, faster, free to run, auditable, and correct every time. Introducing a model where a rule works trades certainty for probability and gains nothing. The honest sequence is rules first, model for the residue, and a measurement of how large that residue actually is before anyone builds.
Choosing the first one
- 1
Inventory the tasks where staff read something and re-key it. That list is where the value concentrates.
- 2
Assign each one a shape from the seven patterns. A task that does not fit a shape is usually several tasks in a trench coat.
- 3
Estimate current cost honestly: volume per month, minutes per item, and the cost of the errors already happening.
- 4
Pull 100 to 300 historical examples with known-correct answers before writing any code. If you cannot assemble them, you cannot evaluate, and you should stop here.
- 5
Define the accuracy threshold at which a person would actually adopt it, and the review step that catches everything below it.
- 6
Build the narrowest version, run it alongside the existing process, and compare against the human baseline rather than against perfection.
The organizations that get value from AI in operations are rarely the ones with the most ambitious use case. They are the ones that picked a task with a clear shape, measured the before state, and put the capability inside the system where the work already happens instead of beside it.
Common questions
- What is the best first AI use case in an operations team?
- Usually document extraction or exception surfacing. Both have measurable current costs, a narrow output that is easy to check, and a natural review step, which means a wrong answer is caught cheaply. They also produce a labeled dataset as a by-product, which makes the second use case easier to evaluate than the first.
- How accurate does an AI workflow need to be before it is worth deploying?
- The threshold is set by the cost of an error, not by a universal number. For routing, 90% is often fine because a misroute costs a few minutes. For anything touching money or a customer commitment, the workflow needs a review step regardless of accuracy. Compare against your current human error rate rather than against perfection. That baseline is frequently worse than people assume.
- How do we measure whether an AI use case is paying off?
- Measure the operational metric that would have moved anyway: handling time per item, queue depth, time to first touch, rework rate, or exceptions caught before reaching a customer. Capture the baseline before you build. Model-level metrics and usage counts describe activity, not value, and they will not survive a budget conversation.
- Why do AI pilots work in a demo and fail in production?
- Demos use clean inputs, a friendly path, and no downstream consequence. Production adds the malformed documents, the ambiguous edge cases your own staff disagree about, and the reality that someone has to act on the output. The gap is usually closed by evaluation against representative failure cases, confidence thresholds, and a defined human review step rather than by a different model.
- Should we use AI for calculations and reporting?
- Not for the calculation itself. Have a model identify or extract the inputs and a deterministic function compute the result, so the arithmetic is verifiable and repeatable. Models are useful in reporting for narrating what a figure means, but the figure should come from a query, not from generation.
- What if a deterministic rule could do most of the job?
- Then write the rule and apply the model only to what the rule cannot handle. Rules are cheaper, auditable, and correct every time, and quantifying the residue first tells you whether the remaining volume justifies any build at all. In matching and routing work, the rules layer routinely covers the majority of cases.