Key takeaways
- A workflow has five nameable parts: a trigger, inputs, ordered steps, decision points and a finish condition. If you cannot say what a correct finished run looks like, you have a habit rather than a workflow.
- Automating is a range, not a purchase. Writing the procedure down is the second rung, and it delivers the consistency that teams usually expect to buy at the fourth.
- Running unattended is not the target. Most business processes should stop at the rung where software does the assembly and a person approves whatever commits the company.
- Judge a candidate by whether the work grows as the business does. Repetitive work that stays flat is usually cheaper to leave written down than to automate.
- The parts of your process you cannot describe are the parts that stay manual after you buy something, because software cannot carry out a decision nobody has made.
The five parts of a workflow
Most teams have more workflows than they think, because the word sounds more formal than the thing. If the same sequence happens every Tuesday and one person carries it in their head, that is a workflow with no document. The test is not whether it has a name, an owner or a diagram. Every workflow has the same five parts, and the quickest way to see them is in three jobs that have nothing else in common.
| Part | Chasing an unpaid invoice | Answering a support email | The Monday numbers |
|---|---|---|---|
| Trigger | Fourteen days past the due date. | A message lands in the shared inbox. | Nine o'clock every Monday. |
| Inputs | The invoice, the payment record, a contact who pays. | The message, and the customer's account and history. | Last week's figures, from three systems. |
| Steps | Confirm it is genuinely unpaid, find the right contact, send the reminder, log that it went. | Read it, work out what it is, look up the account, reply, record the outcome. | Pull the figures, reconcile them against each other, chart them, write the commentary. |
| Decisions | A polite reminder, or an escalation to someone senior? | Is this a bug, a question, or a complaint? | Which movements are worth explaining, and which are noise? |
| Finish condition | The reminder is sent and logged, or the invoice turns out to be paid. | The customer has an answer and the ticket is closed under a category. | The report is posted and its totals agree with the source systems. |
Those three jobs share nothing but the shape. The shape is what the word workflow refers to, and it is the reason one piece of software can carry processes that look nothing alike.
Now fill in the same five rows for your own process. The row you cannot fill in is the interesting one, because it is the part that will still be manual after you buy something: software cannot carry out a decision nobody has made. It is also why the second rung below repays more than teams expect.
What workflow automation replaces, one rung at a time
Google's engineers describe automation as a progression rather than a state, running from no automation at all through to systems that no longer need any, and they are explicit that the gains are consistency and a platform to build on, not merely hours saved. Their subject is infrastructure rather than operations, but the shape carries over. Each rung buys a different thing, and the price changes at each one.
| Rung | Who does the work | What you gain | What it costs |
|---|---|---|---|
| 1. It lives in someone's head | One person, from memory | Speed, for as long as that person is there. | The process is unavailable when they are, and it leaves the company when they do. |
| 2. It is written down | A person, following a document | Consistency. Two people now produce the same result. | An afternoon, plus the discipline to update the document when the process changes. |
| 3. Individual steps are tooled | A person, driving tools that do the fiddly parts | Fewer transcription errors, and some time back. | Nothing structural, which is the catch: a person is still what holds the sequence together. |
| 4. Software runs it, a person approves | Software end to end, stopping where the work commits you | Most of the time back, with accountability intact at the points that matter. | Setup, and somebody who actually reads an approval before signing it. |
| 5. It runs unattended | Software, with a person told when it fails | Nobody thinks about it until it breaks. | Building the detection that tells you it broke, which is often more work than the automation. |
Rung two is the one teams skip, because writing a procedure down feels like preparation rather than progress. It is the rung that delivers consistency, which is the benefit people usually expect to buy at rung four. It is also the cheapest place to discover that two colleagues disagree about the correct sequence: that costs an afternoon at rung two and a rebuild at rung four.
Rung five is not the goal, and treating it as one is how teams end up with a process that has been quietly wrong since March. A process worth automating is usually a process that can go wrong in ways worth noticing, so unattended operation is only honest once somebody will actually hear about the failure — a named person, not a distribution list. NIST puts govern at the centre of its four AI risk functions rather than alongside them, on the reasoning that responsibility has to be settled before anything can usefully be mapped, measured or managed. That ordering holds just as well for a process with no model in it anywhere.
Not every repetitive job earns a place on the ladder at all. Google's site reliability engineers use the term toil for work that is manual, repetitive, automatable, produces no enduring value, and grows at least as fast as its source. That last property is the one that decides it. Work that grows with your success will keep taking more of your week, so it is worth spending on. Work that stays flat as the business doubles is usually cheaper to leave at rung two.
Five questions that tell you whether you have a workflow
One question per part. Run them against the process you have in mind, and answer out loud. In your head you will give yourself credit for the ones you nearly know.
- Can you name what starts it, without using the phrase when needed?
- Can you list what has to be in front of you before you begin?
- Could you write the steps in order on one side of paper?
- Can you name every point where the path forks, and what decides each one?
- Can you describe a correct finished run in a way somebody else could check?
Five yeses and you have a workflow, and one of the rungs above has your name on it. Fewer than five and what you have is closer to a habit. That is not an insult, and a good deal of valuable work is exactly that, but it cannot be handed to software while it stays that way.
Two questions sit just outside this one. The toil test above is a quick filter for whether a workflow is worth automating; the four questions on the tools page put blast radius and ownership beside frequency and settle it properly, faster than any product demo. Whether your written procedure is precise enough for software to follow is a harder problem again, and the subject of the SOP automation guide: a document that works perfectly for a colleague usually omits everything a machine would need, because the colleague already knows the job.
One shared inbox, walked up the rungs
Definitions are easy to nod along to, so here is an ordinary process moving up four rungs. The figures are illustrative and chosen to show the shape of the change rather than to report anyone's result.
Rung one. Internal requests and a few supplier queries land in a shared inbox. The operations lead reads each one, decides whose it is, copies the details into a tracker and replies to acknowledge it. Around thirty a week, four minutes each. Two rules exist only in their head: anything mentioning payment terms goes to finance regardless of who sent it, and the two largest suppliers get an acknowledgement the same day.
Rung two, one afternoon. Writing the procedure down surfaces something nobody had noticed: a colleague covering holidays had been routing the payment-terms cases to operations for about a year. Both routes eventually reached the right person, so nothing ever broke loudly enough to investigate. It was simply slower, and only visible once the correct sequence was on paper.
Rung three. A request form captures the fields the tracker needs, and saved replies handle the acknowledgement wording. Handling time falls from four minutes to roughly two and a half. Nothing structural has changed: the sequence still lives with a person, and it still stops when that person is on leave.
Rung four. Software now reads each request, works out which of six categories it belongs to, writes the tracker row and drafts the acknowledgement. Classification is the one step that needs judgment, because requests are written by people in a hurry. Any reply containing a date commitment stops for a person, permanently, since that is the point at which the company promises something. Attention per request drops to about thirty seconds, and it goes on approvals instead of copying.
What made it possible. The classifier got the payment-terms rule wrong until it was written down, which is rung two's document doing a second job it was never intended for. The process did not become automatable when the software arrived. It became automatable the afternoon two invisible rules were made explicit, and the software was what the team did with that afterwards.
Where the judgment steps come in
Everything above works with no model involved anywhere. Rules, forms and scripts have automated workflows for decades, and for a process whose branches are all knowable in advance they remain the cheapest and most predictable answer.
The limit arrives when a step needs reading a document with no fixed layout, or sorting free-text requests into categories, or drafting something that fits this case rather than the average one. Enumerating every variation stops being possible, and that is the point at which the classification step in the example above stops being a rule and becomes a judgment. What that changes about cost, variance and the approvals you keep is the subject of the AI workflow automation guide. The five parts and the five rungs stay exactly as they are.
Limitations and when not to use this
- This page defines the category and helps you place your own process on the ladder. It does not compare products, and being on rung four is not an argument for any particular way of getting there.
- Workflow here means recurring business operations: the procedural work a small team does across everyday tools. The word carries different and older meanings in manufacturing, clinical care and software delivery, where the constraints and the economics are not the ones described here.
- The rungs describe what teams tend to find, not a maturity model to be climbed for its own sake. Plenty of processes are correctly parked at rung two forever, and a process that runs six times a year almost certainly should be.
- Nothing here is legal, financial or employment advice. A process that decides something significant about an individual carries obligations that depend on your jurisdiction and your industry, and this page does not enumerate them.
Sources
- Automation: The Evolution of Automation at Google — Google, Site Reliability Engineering Accessed 27 July 2026
- Eliminating Toil — Google, The Site Reliability Workbook Accessed 27 July 2026
- AI Risk Management Framework — NIST Accessed 27 July 2026
Write the procedure down first
Take the process you had in mind while reading and get it to the first rung this week. The templates are editable and need no signup, and the exercise itself tells you whether you have a workflow or a habit.
Write the procedure down firstUli 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.