AI Workflow Automation

AI Workflow Automation Examples, Specified Step by Step

For the operator who has read enough lists of use cases: three ordinary processes taken down to the level of individual steps, showing which parts become code, which need judgment, and which keep a person.

Uli PrantzBuilds and operates all-agents
Published
Key takeaways

Key takeaways

  • An example is only useful once every step is assigned to fixed code, model judgment or a person. A list of process names tells you nothing about what you would actually be buying.
  • Most steps in a real process are dull lookups and writes. The model earns its place in one or two steps, and paying for judgment on the rest is the most common way these projects get expensive.
  • Each example carries an exception that will break it, and each one is knowable in advance. Design for the exception you can already name, because it is the one that arrives first.
  • The share of steps that keep a human approval is a property of the work, not of the software's maturity. A process that ends in a commitment to a customer keeps its gate permanently.
  • Volume decides whether any of this is worth doing. Two of these three examples only repay the effort because they grow as the business does.
Most published examples of AI workflow automation are process names with a sentence attached, which tells you nothing you can act on. A useful example goes down to individual steps and marks each one as fixed code, model judgment or a human approval, because that split decides what the process costs to run, how much it varies, and how much of your week you actually get back. Three ordinary processes are worked out that way below — routing inbound leads, producing a recurring client report, and reviewing a supplier renewal — each with the exception that will break it.

What a useful example has to specify

The parent guide catalogues six process shapes that recur across small operating teams. This page takes three of them and builds them out, because the shape is the easy part. Everything expensive lives in the steps.

Each step below carries one of three labels. Fixed code means a rule somebody wrote once: a lookup, a calculation, a write to a system. It costs almost nothing per run and behaves identically every time. Model judgment means the step genuinely cannot be enumerated in advance, so a model reads the input and decides. It costs money and varies on every run, forever. A human approval means somebody has to be answerable for what happens next, and no amount of accumulated confidence changes that.

All three examples pass the test Google's engineers use for which work deserves automating. They call it toil: manual, repetitive, automatable work that produces no enduring value and grows at least as fast as its source. Two of the three grow directly with sales. The third does not, and it is included precisely because that makes it the marginal case.

Example one: routing an inbound lead

A form submission arrives and somebody has to work out whether it is worth a salesperson's time and whose it is. Left manual it is the sort of job that gets done in batches on Friday, which is also why the good leads go cold.

  1. 01A form is submitted, or a record appears in the CRMTrigger
    Two sources, one process. The second one matters: leads entered by hand at a conference should not take a different path just because they arrived differently.
  2. 02Look up the company and fill in the firmographicsCode
    Domain to company record, headcount, country, existing customer or not. Entirely mechanical, and the largest single block of manual minutes in the process.
  3. 03Decide whether this record is the same company as one you already haveAI judgment
    “Acme GmbH”, “ACME Holdings” and a personal email address from a contractor working for them. No rule settles this reliably, which is what makes it a genuine judgment step.
  4. 04Map a free-text job title to a segmentAI judgment
    “Head of Ops”, “Operations Lead”, “COO” and “I do a bit of everything” all need to land somewhere. The last one is the interesting case, and the reason a lookup table stops working.
  5. 05Apply the routing rules and assign an ownerCode
    Territory, segment, round-robin within a team. Once the two judgment steps above have produced clean values, this is arithmetic.
  6. 06Write the record and notify the ownerCode
    No approval here, and that is the point: this process commits the company to nothing. Nobody outside is told anything, and a wrong assignment is fixed by dragging a record.

The exception that breaks it. A large customer submits the form again through a different subsidiary, and the deduplication step confidently merges it into the existing account, hiding a new opportunity inside a closed one. It will happen, it is knowable now, and the fix is a rule that any merge touching an account above a certain value stops and asks. That rule costs nothing to add on day one and is painful to retrofit after somebody has lost a deal to it.

Example two: the recurring client report

Every Monday, figures from three systems become a document that goes to a client. The work is dull, the deadline is immovable, and the person who does it is usually senior enough that it is an expensive way to spend a morning.

  1. 01Nine o'clock on MondayTrigger
    A schedule, which is the simplest trigger there is — and the one most likely to fire on a bank holiday when the source data has not landed yet.
  2. 02Pull the figures from each systemCode
    Fixed queries against fixed sources. If this step is hard, the problem is your reporting stack, and no automation layer will disguise it.
  3. 03Reconcile the numbers against each otherCode
    Totals from two systems should agree within a known tolerance. A mismatch is a rule, not a judgment: if the gap exceeds the tolerance, the run stops rather than reporting a number somebody will later have to retract.
  4. 04Write the commentary on what moved and whyAI judgment
    The only genuinely open-ended step in the process. Which movements are worth explaining, which are seasonal noise, and how to say so without overclaiming a cause the data does not support.
  5. 05A person reads the commentary and releases itHuman approval
    Permanent, because the document goes to a client with the company's name on it. Approving an assembled report takes two minutes; producing one took a morning. That asymmetry is the entire return on this process.

The exception that breaks it. A source system is late, so the reconciliation passes on partial data and the commentary explains a decline that never happened. The approver, reading a fluent and internally consistent document, agrees with it. This is the failure mode the EU AI Act names in its human oversight requirements, which expect an overseer to stay aware of the tendency to over-rely on a system's output. The practical defence is to make the gate show its working: the approver needs the freshness of each source in front of them, not just the finished prose.

Example three: the supplier renewal review

A contract comes up for renewal and somebody should check whether it still makes sense before it rolls over silently. This is the marginal example of the three, because it happens perhaps forty times a year and does not grow much with the business.

  1. 01Ninety days before a renewal dateTrigger
    Calculated from the contract record. If your contract records do not carry reliable renewal dates, that is the actual project, and it is a data problem rather than an automation one.
  2. 02Assemble the current positionCode
    What is being paid, against what was budgeted, alongside whatever usage figures exist. Mechanical, and tedious enough that it is often skipped entirely when done by hand.
  3. 03Read the terms and summarise what changed since last timeAI judgment
    Contracts have no fixed layout, which is exactly the condition that makes a model worth paying for. The output is a summary with the clauses quoted, not a verdict.
  4. 04Renew, renegotiate or cancelHuman approval
    Permanent, and not a close call. The decision commits money and is awkward to reverse, so it stays with a person who is answerable for it — regardless of how good the summary in front of them has become.

The exception that breaks it. Auto-renewal notice periods are quietly different per contract, so a ninety-day trigger is too late for the one supplier that wanted one hundred and twenty. The process runs perfectly and the decision arrives after the window closed. Notice periods belong in the trigger calculation, and finding that out from the contracts rather than from a missed deadline is the whole value of writing the process down first.

What the three have in common

Laid side by side, the pattern is more useful than any individual example.

Step counts from the three examples above. The middle column is the one that costs money on every run.
ProcessFixed codeModel judgmentHuman approvalWhat that mix means
Routing an inbound lead4 steps2 stepsNoneNothing leaves the company, so it can run unattended. A good first process for exactly that reason.
The recurring client report3 steps1 step1, permanentAlmost all the effort is assembly, and the approval takes minutes. The best return of the three.
The supplier renewal review2 steps1 step1, permanentLow volume. Worth doing because the cost of missing a renewal is high, not because it saves hours.

Two things stand out. The model does one or two jobs in each process, and everything around it is ordinary lookups and writes — which is why a system that calls a model for every step is charging you judgment prices for arithmetic. And the human approvals are not there because the software is immature. They are there because those two steps commit money or reach a client, and that property does not change however many clean runs accumulate behind it.

Each example also needs an owner: one person who would notice next March that the commentary has quietly stopped being right. NIST puts govern at the centre of its four AI risk functions, ahead of measuring and managing, and a process with no named owner has skipped the step that makes the rest meaningful.

Limitations and when not to use this

  • All three examples are composites built to show the shape of the work. The step counts are real properties of the processes as described here, not measurements from any organisation, and your version of each will have steps these do not.
  • Step counts are a poor proxy for effort. One fixed-code step that reconciles three systems can be more work to build than four straightforward ones, and the table above deliberately does not pretend otherwise.
  • Nothing here describes what any particular product does. The split between code, judgment and approval is a property of the process; whether a given tool can express that split is the subject of the tools guide.
  • Nothing here is legal, financial or procurement advice. The renewal example in particular touches contract terms, where the details are specific to your agreements and jurisdiction.

Sources

  1. Eliminating ToilGoogle, The Site Reliability Workbook Accessed 27 July 2026
  2. Article 14: Human oversightEU Artificial Intelligence Act Accessed 27 July 2026
  3. AI Risk Management FrameworkNIST Accessed 27 July 2026

Specify your own process to this level

The examples here are only useful as a target. Take your own process and write it out step by step, marking each step as code, judgment or approval, using an editable template.

Specify your own process to this level
About the author

Uli Prantz

Builds and operates all-agents

Uli Prantz builds all-agents, the process-automation platform this site documents. He writes about the operational side of automating recurring business work: where deterministic code beats model judgment, where it does not, and where a human still has to approve.

Bring one process. We will scope it in 30 minutes.

You leave the call knowing whether it is a fit, what can become code and what still needs a person.

Book a discovery call