Every use case on this page documents the same six things: the workflow, what data must exist before it runs, its automation posture, the stage of transformation it belongs to, the metric to measure, and the trap that catches most teams. That's enough to decide whether it's worth doing — before you spend anything on it.
The first reply is where the queue backs up. Drafted from your knowledge base, reviewed by an agent before it sends.
The two highest-volume, lowest-stakes inquiry types get answered end to end, with exceptions escalated to an agent.
Three-way match runs automatically; only true exceptions reach an AP clerk, with a suggested resolution and reason.
The workflow that resolves exceptions now proposes and executes its own fixes — inside an eval ceiling and a spend threshold.
Not a faster close memo — a continuous narrative that ties each variance to its driver, cited. A new Finance role runs it.
Answers to routine policy questions include the actual policy paragraph — so employees verify the answer instead of filing a ticket.
Recorded sales calls become structured CRM field updates — with consent, field mapping, and rep review.
Before each call, an agent stitches together the last 90 days of interactions, open items, and the account plan into a one-page brief.
Every incoming ticket gets a category, a priority, and a suggested runbook — so agents start at the solution, not the description.
Incident timelines, chat logs, and traces become a drafted postmortem and an updated runbook — reviewed by the on-call engineer.
One approved master brief generates per-market variants — with brand voice preset, legal-required substitutions, and a review gate per market.
Inbound contracts get flagged against a clause playbook before a lawyer opens them — hidden risk surfaces in minutes, not days.
A continuous risk agent reads news, filings, and shipping data, flags supplier exposure, and proposes reroutes — a new Ops function runs it.
Support tickets, sales calls, reviews, and surveys continuously synthesize into ranked, cited themes — a new Research-Intelligence role curates them.
Try removing a filter, or search the hub directly.
Every use case here documents the same six things. If a use case you find elsewhere is missing two or more of them, be careful — it's probably a pitch, not a plan.
The actual steps, start to finish — including where the human sits. If a use case can't describe where the human decides, it hasn't been designed yet.
What must exist at the start and mid-way through the workflow. Not "clean data" — current and accessible data, with the source and permissions named. This is the field most pilots skip, and the field that kills most pilots.
Assist, automate, agentic, or co-designed. Posture is a decision about the shape of the build — not a statement about the technology. Two use cases with the same title can be entirely different projects depending on their posture.
Which of the five stages — pilot, expand, executize, transform, autonomate — this use case typically first appears in. Stage isn't a difficulty rating; it's a function of what substrate the workflow requires.
What to measure, and what baseline to set first. A metric without a baseline isn't a metric — it's an opinion with a number attached.
The failure mode most teams hit — in one sentence. If a use case page can't name its trap, it hasn't been written by someone who has run it.
Same use cases, filtered by where in the five-stage model they typically first appear.
Where in the org the workflow sits — not a claim that the workflow only belongs there.
Start with a workflow where work is repetitive, information-heavy, and slow — and where you can see the metric you'd change. Skip anything you can't baseline in under a week. Most teams start with customer service, finance, or IT operations because the inputs are already digital and the before-and-after is measurable.
The five most common across this index are: drafting first replies to routine tickets (customer service), matching invoices and flagging exceptions (finance), answering policy questions with cited sources (HR), meeting notes to CRM updates (sales), and first-pass service-desk triage (IT). They are common because the workflow is already instrumented, the input is already digital, and the metric is already tracked — which is exactly what makes a pilot provable.
Every use case here lists it under Data in. In general, three things: the source data the workflow already consumes, access controls for who can read that data, and a feedback loop so you can measure whether the output was correct. "Clean data" is not the bar — "current and accessible" is.
Not meaningfully. A use case labeled Autonomate still passed through Pilot — the workflow was mapped, a baseline was set, an automation posture was chosen. What differs is how far you have pushed the same underlying workflow. The five-stage model is cumulative, not a checklist of things to do once.
Three that recur: automating without mapping the data, so nothing is provable; choosing a use case you cannot baseline, so nobody believes the improvement; and treating human-in-the-loop as a permanent state rather than an interim posture, so the intervention rate never falls and neither does the cost.
In Pilot, one to three. In Expand, ten to twenty across functions. Beyond that, the pattern library and the operating model should carry the load — the central team's job shifts from building workflows to teaching the pattern. If every new use case still needs the central team to build it, you haven't expanded; you've just queued.