Key takeaways
- A procedure a colleague can follow is not a procedure a machine can run. Add the six things people supply from memory: the trigger, the exact inputs and their system of record, the thresholds, every exception path, the finish condition, and who approves what.
- Test each step by asking what should happen when the input is missing, ambiguous, or rejected downstream. If your procedure has no answer, that step is not specified yet, and no tool will specify it for you.
- Sort every step into fixed rule, genuine judgment, or human approval before you automate anything. How much of the procedure lands in the first bucket is what makes the result cheap and repeatable.
- Automate the procedure you already run weekly and can describe when it fails. A procedure whose rules changed twice this quarter should stay a written checklist until it settles.
- Keep the written procedure as the source of truth after the automation takes over. It is what you check a suspicious run against, what you hand to a new colleague, and what you edit when the rule changes.
Why a procedure written for people breaks when software runs it
Every working procedure is written for someone who already knows a lot. It says “check the invoice against the purchase order” because the reader knows which system holds purchase orders, what counts as a match, and what to do when the totals differ by two cents. The reader fills that gap silently and never mentions it. The document stays short and useful precisely because so much of the real procedure lives in the reader.
Software has none of that. Where a step is under-specified, an automation does not quietly apply house style; it either does something arbitrary or it stops. Both get blamed on the tool when the cause is the sentence. SOP automation is a writing problem first and an engineering problem second.
The formal quality-management world worked out half of this long ago. ISO 9001 is built on documented information that is maintained and reviewed rather than written once and filed, because a procedure nobody keeps current cannot be audited, improved or handed over. Automation adds a second demand: the document has to be complete enough to execute, not just complete enough to explain.
A cheap way to find the gaps first is to read your procedure as a competent new starter with no context would. Every question that person would have to ask a neighbour is a gap, and the machine hits the same ones without the option of asking. In practice they cluster into five kinds.
- Location. Which system holds the record, and which wins when two disagree.
- Tolerance. What counts as close enough: rounding, date range, acceptable variance.
- Escalation instinct. Who gets asked when something looks odd, and what “odd” means here.
- Stopping. When the work is finished, and how an outsider could tell.
- Restraint. The cases where an experienced person would simply not proceed, and would never call that a rule.
The six things a machine-ready procedure must state
Almost every procedure that fails to automate is missing one of six statements. Treat the table as a checklist for the document you already have: read your procedure once per row and mark where it goes quiet.
| Element | The question it answers | Where it goes missing |
|---|---|---|
| Trigger | What starts a run, and how does the system learn about it? | Procedures say “when an invoice arrives”, but rarely arrives where, or what happens to the second copy of the same invoice. |
| Inputs and their source | What does the run need, and which system is authoritative for each field? | The document is named but the system of record is not, so two sources disagree and nobody has said which wins. |
| Decision criteria with thresholds | What is the exact rule, including which side of the boundary the boundary itself falls on? | “Large orders need approval”, with no number. Ask three colleagues for the number and you will often get three answers. |
| Exception paths | For each step, what happens when it cannot be completed as written? | The happy path is documented; the four things that actually happen most weeks live in one person's head. |
| Finish condition | What is true when the run is done, and where is that recorded? | Procedures end with the last action rather than with the state that proves the action worked. |
| Approvals | Which steps need a person to sign off, and which person? | Approval is described as a habit — “I go through them on Friday” — rather than a required gate with a named role and a consequence for “no”. |
Exception paths do most of the work here, and they are hardest to write because nobody experiences them as exceptions. Run the procedure for a week with a notebook open and record every deviation. That list, not the document, is your real procedure.
Then ask three questions of each step: what happens when the input is missing, when it is ambiguous, and when the downstream system refuses it. A step with three answers is specified. A step with none is a guess waiting to be made on your behalf.
Rewriting one step so software can execute it
The difference between the two columns below is not length or formality. It is that the right-hand version leaves no place where a reader has to supply something from experience.
| Written for a colleague | Written to be executed | What the rewrite pinned down |
|---|---|---|
| Check the invoice matches the PO. | Match the invoice to the open purchase order with the same PO number in the finance system. Compare supplier, currency, line count and total. Treat a total within 0.5% or 2 units of currency, whichever is smaller, as matched. Anything else is a variance. | Where the purchase order lives, which fields constitute a match, and the tolerance everybody applied but nobody had written down. |
| Get approval if it is a big one. | If the total is at or above 2,500 EUR net, or the supplier is not on the approved list, request approval from the cost-centre owner named on the matched PO before payment is scheduled. The run waits for a reply; it does not time out into approval. | The threshold, the behaviour exactly at it, the named approver rather than “finance”, and what happens during the wait. |
| Chase anything unusual. | If no matching PO exists, the PO has no cost-centre owner, or the invoice currency differs from the PO currency: stop the run, leave the invoice unpaid, and raise an exception to the payables queue naming which condition fired. | Three distinct exceptions compressed into one word, and the fact that stopping is a legitimate outcome rather than a failure. |
| File it. | The run is complete when the invoice is recorded as approved-for-payment with the PO reference, the approver identity and a timestamp. No message goes to the supplier here. | A finish condition expressed as a verifiable state, plus an explicit statement of what the step must not do. |
Two small phrases carry more weight than they look. “At or above 2,500” settles what happens to an invoice for exactly 2,500, the kind of boundary that produces one wrong payment a quarter. “It does not time out into approval” states the default for the waiting case, which is where an automation otherwise invents policy on your behalf.
Step 4 — approval routing. An illustrative specification. The figures are invented for this page and are not results from any customer.
Enter this step when: the invoice matched a purchase order and any variance is within tolerance.
Rule: total at or above 2,500.00 EUR net → approval required. Below 2,500.00 EUR net → skip to step 5. A supplier absent from the approved list requires approval at any amount.
Approver: the cost-centre owner recorded on the matched PO. If that field is empty, raise exception no-approver and stop.
Exceptions: no reply within 3 working days → escalate to the finance lead, and record the escalation. Rejected → raise exception approval-rejected, leave the invoice unpaid, record the stated reason.
Done when: an approval or a rejection is recorded against the invoice, carrying the approver identity and the time it was given.
You do not have to invent that structure. The procedure templates are free, editable and already carry these headings, so the job becomes filling in the blanks rather than remembering which blanks exist.
A category map: which steps become code, which need judgment, which keep a person
Once the procedure is precise, go through it again and put every step in one of five categories. This decides what the automation costs to run and how repeatable it is, and it is far easier to make on paper than after something has been built.
| Step category | What it looks like in the document | Where it should end up | What the procedure must state |
|---|---|---|---|
| Lookup and transform | Fetch the record, read a field, reformat a date, write it back, copy a value between two systems. | Deterministic code. | The system of record for each field, and what to do when the record is not there. |
| Rule with a threshold | Any sentence containing over, under, within, older than, more than, at least. | Deterministic code. | The number, the unit, and which side of the boundary the boundary belongs to. |
| Classification of messy input | Deciding which of five categories a free-text message belongs to; reading an attachment that is a clean PDF one week and a phone photo the next. | Model judgment, scoped to that one decision. | The closed list of allowed answers, and what the step does when none of them fit. |
| Drafting and summarising | Writing the reply, summarising a case for whoever reviews it. | Model judgment, usually behind a human check. | What must appear, what must never appear, and who reads it before it leaves the building. |
| Irreversible or accountable action | Paying, sending to a customer, closing an account, acting on a decision about an individual. | A permanent human approval gate, however well the rest of the procedure runs. | Who approves, on what evidence, and what happens when they say no. |
You want as much of the procedure as possible in the first two rows. Steps that land there behave identically on every run, cost almost nothing, and can be tested. Every step left in rows three and four is a place the procedure could not be pinned down — sometimes genuinely, often because the rule exists and nobody has written it yet. Treat those as a cost to keep small, not a feature.
The fifth row is different in kind. It exists not because the software might be wrong, but because somebody has to be answerable. Internal-control guidance has held for decades that key duties should sit with different people: authorising a transaction, processing and recording it, reviewing it. An automation that both raises a payment and approves it collapses that separation, however good it is. Naming the approver inside the procedure is what keeps the separation in place once the manual steps disappear.
The human-in-the-loop guide sorts those gates by how much damage a step can do.
Deciding whether this procedure is ready to automate
Writing a procedure to this standard takes real effort, so it is worth knowing in advance whether the effort will be repaid. Google's site reliability engineers use a useful test for which work deserves automating. They call it toil: work that is manual, repetitive, automatable, produces no enduring value, and scales linearly as the service grows. That last property is the one that decides it for business procedures. Work that grows in proportion to how well you are doing never improves on its own.
| If this describes your procedure | It is | Do this next |
|---|---|---|
| It runs weekly or more often, the steps have been stable for a quarter, and you can say what happens on each exception. | Ready | Write the six elements, then run it with a person supervising before it runs alone. |
| It runs often and is stable, but the exceptions live in one person's head rather than the document. | Nearly ready | Log every deviation for a fortnight, add them as explicit exception paths, then automate. |
| It runs often, but the rules changed twice in the last three months. | Not yet | Settle the rules as a written procedure first. Automating a moving target gives you a second thing to keep up to date. |
| It is frequent and painful, but every case is genuinely different. | Partly | Automate the assembly — gathering inputs, checking them, recording the outcome — and keep the judgment with a person or a narrowly scoped model step. |
| It runs a handful of times a year. | No | A checklist is cheaper and will be more accurate than an automation nobody has exercised since March. |
| One mistake is expensive, legally significant or hard to reverse. | Only with permanent gates | Automate everything up to the irreversible action and keep that action behind a named approver, permanently. |
Frequency is what pays for precision. To put numbers on that trade for your own process, the automation ROI calculator works from your time per run and run count, not from a vendor's assumptions.
How a written procedure becomes a running one: learn, codify, run
No document written at a desk is complete on the first pass. The model below is how all-agents works, and the shape is worth knowing even if you build it another way: the procedure is learned by running it, hardened deliberately with a person in the room, and only then allowed to run on its own.
- 01Run the procedure with the system, not for itAI judgmentThe first runs execute with a model's flexibility while you watch. Before anything irreversible — an email, a payment, a write to an external system — it stops and asks you. That is what makes it safe to start before the document is perfect.
- 02Keep every accepted run as a concrete exampleAI judgmentEach accepted run records the real inputs, the path taken, the decisions made and your corrections. Different runs exercise different branches: the invoice in a foreign currency, the request with no approver. The written procedure is refined after each one, so it sharpens while the work is being done rather than in a documentation sprint afterwards.
- 03Decide it is ready — you, not a counterHuman approvalThere is no magic number of runs. What matters is whether the branches you care about have been seen and whether the procedure reads as complete. The system surfaces that; the person who owns the process makes the call.
- 04Walk the whole procedure through, step by stepHuman approvalThis is the part that changes the outcome. Walking a real run with real data jogs the knowledge nobody thinks to write down (“oh — for that customer we always copy legal in”). Where the examples were ambiguous, the system asks rather than guesses: every example was under 10,000, so what happens above it? You can pin a step to stay judgment-based, and pin gates that always need a person. Everything surfaced here is written back into the procedure, not only into the code.
- 05Run it as code, with the gates you pinnedCodeA trigger arrives and the procedure runs the same way every time: deterministic wherever the step allows it, model judgment only where you kept it, a human approval wherever you pinned one. Runs are recorded and can be replayed, so “what did it do on the 14th” is a question with an answer.
- 06When reality changes, the human comes backHuman approvalA supplier changes a form, a new kind of input appears, an assumption breaks. A failed run goes back in front of a person rather than being silently patched: either a targeted fix you confirm, or a return to supervised runs until the procedure is pinned down again.
Note the direction of authority. The written procedure is the source of truth and the code is its implementation, not the other way round. That is what keeps the automation reviewable by the person who owns the process rather than only by whoever built it.
Keeping the written procedure true after the automation takes over
The failure mode of a successful automation is quiet drift. The process runs, nobody reads the document, and a year later the document describes a procedure that stopped existing. Then a rule changes and nobody can tell which parts of the automation it affects. Continual improvement in the ISO 9001 sense is a maintenance habit, not a launch activity, and it applies more once a machine is doing the work, not less.
- Give the procedure one owner. Someone has to say what correct looks like and notice when it stops being correct. An unowned document is an unowned automation.
- Edit the procedure first, then the automation. When the threshold moves from 2,500 to 5,000, the change belongs in the document and the automation follows from it. The other way round is how the two stop matching.
- Watch the exception rate, not just the failures. A rising share of runs taking an exception path means reality has moved. That signal arrives well before anything breaks.
- Check whether your gates are real. An approval granted every time without inspection is theatre. Either remove it or give the approver the evidence they would need to say no.
- Re-read it at handover. When the owner changes, the remaining tacit knowledge is briefly visible, and that is the cheapest moment to capture it.
None of this requires the automation to exist yet. A procedure written to the standard on this page makes handover possible and the process auditable, and it is the document you would have to write before any tool could help. Starting there loses you nothing if you decide not to automate at all.
Limitations and when not to use this
- This page assumes a procedure stable enough to write down. If yours is being invented as you go — a new function, a process that changes shape with every customer — specifying it to this precision produces a document that is wrong within a month. Write the rough version, run it, come back.
- Nothing here is legal, financial or compliance advice. Where your industry or jurisdiction prescribes how procedures must be documented, retained, approved or segregated, those rules govern. We cite primary sources where we can, but your obligations depend on your circumstances.
- Do not automate a procedure whose exception path is the common case. If most runs need a human decision the document cannot describe, you are not automating a procedure, you are building case management, and a person with a good checklist will be faster for now.
- Precision has a running cost. Fifty specified branches take real time to write and real time to keep current. Specify to the depth the frequency justifies, and leave a rare step as a plain instruction to a person inside an otherwise automated run.
Sources
- ISO 9001:2015 — Quality management systems, requirements — International Organization for Standardization Accessed 24 July 2026
- ISO 9001 explained — International Organization for Standardization Accessed 24 July 2026
- Eliminating Toil — Google, The Site Reliability Workbook Accessed 24 July 2026
- Standards for Internal Control in the Federal Government (Green Book) — U.S. Government Accountability Office Accessed 24 July 2026
Start from a procedure template
Free, editable templates with the trigger, inputs, thresholds, exceptions, finish condition and approvals already laid out as headings. No account needed.
Start from a procedure templateUli 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.