SOP to workflow
Write the procedure a new hire could follow before touching a tool, find the decisions a first draft hides, and turn each step into a workflow node.
On this page
An automation can only do what someone has decided. The standard operating procedure, the page a new hire could follow on their first Monday, is where those decisions get made, and it has to exist before anyone opens a tool. A builder working from the name of a task makes every undecided choice in code, where nobody sees it until a client does.
Six parts, in order
An SOP a workflow can be built from has six parts:
- Trigger: what starts a run, an event or a time.
- Inputs: every field the task reads, and the system it lives in.
- Steps: verbs in order, each one something a second person could check was done.
- Decisions, with their rule: every place a person would choose, written as "if this, then that".
- Exceptions: the items no rule covers, and who gets them.
- Done: the state a run ends in, checkable by someone who did not run it. The next lesson is about this line and the one above it.
The test of an SOP is to hand it to someone who has never done the task. Every question they ask is a decision the page is missing. It helps to have mapped the workflow first, with a count on every step, so the SOP describes what people actually do and not what they think they do.
The first draft
The task is the overdue-invoice chase, top of the six in the scoring frame: 35 reminders a week, 4 minutes each, about $303 a month by hand. The operations manager, who has run it for two years, writes it down in ten minutes:
Chase overdue invoices — every Monday
1. Open the receivables report in the accounting system.
2. Email the client about each overdue invoice.
3. Use the polite template the first time and the firm one after that.
4. If they say they have paid, check and update the invoice.
5. Escalate anything difficult to the account manager.
Done: overdue invoices chased.
To the person who wrote it, this is complete. They know which invoices count, who to write to, what "the first time" means and how to check a payment, because they have made those calls a hundred times. None of that knowledge is on the page.
The four decisions it hides
D1: when an invoice is overdue. Step 2 says "each overdue invoice". Built literally, that is every invoice a day past its due date. Clients pay on 30-day terms and most pay within a week of the due date, so the manager has always waited. On a typical Monday about 50 invoices are past due and 35 of them by a week or more. A literal build chases the other 15 too. Assume one in five of those draws a complaint, and each costs the $100 the scoring frame put on a reminder to a client who has paid: 3 a week, $300, about $1,300 a month. One guessed decision costs four times what the whole task costs by hand. The rule: overdue means 7 or more days past the due date.
D2: who receives it. "Email the client" could mean the project contact the agency talks to every day or the billing contact who pays. A reminder to the wrong one is a week's delay at best and an awkward call at worst. The rule: the invoice's billing contact; if blank, the client record's accounts address; if both are blank, an exception.
D3: which template. "Polite the first time, firm after that" needs a memory of what was sent before, and a run that crashes halfway would lose it. A stage computed from days overdue needs no memory, and running it twice sends nothing twice. The rule: 7 to 20 days is stage 1, polite; 21 to 34 is stage 2, firm; 35 or more is stage 3, no email, a call task for the account manager.
D4: what counts as paid. "If they say they have paid, check" names no check. The rule: paid means a payment in the bank feed matched to the invoice number, or to the amount within $1 from the same client. A client who says they have paid, with no matching payment, is held and goes to the exception queue.
Step 5's "anything difficult" is not a decision at all. It is the exception list, unwritten, and the next lesson writes it.
The repaired SOP
Trigger Monday 09:00; the operations manager can also start a run by hand.
Inputs Receivables report: invoice no., client, billing contact, amount, due date.
Bank feed: payments received since the last run.
Client flags: disputed, founder-handled.
Steps 1. Pull open invoices 7+ days past the due date. D1
2. Drop any matched to a payment; log "paid". D4
3. Drop any flagged disputed or founder-handled; log the flag.
4. Set the stage from days overdue. D3
5. Stage 1 or 2: send that stage's template to the recipient, D2
and log the message id on the invoice.
6. Stage 3: create a call task for the account manager, due in 2 working days.
Decisions D1 overdue = 7 or more days past the due date
D2 recipient = billing contact, else the accounts address, else exception
D3 stage = 7-20 days: 1 · 21-34: 2 · 35+: 3, call, no email
D4 paid = payment matched by invoice no., or by amount within $1
from the same client; an unmatched claim is an exception
Exceptions No recipient. A reply claiming payment with no match. A reply disputing
the amount. Accounting system or mail unavailable.
Done By 10:00 Monday, every open invoice 7+ days overdue is in exactly one
end state, recorded on the invoice.
It took the operations manager 90 minutes and two arguments with an account manager about stage 3. That is $45 of staff time against the $1,300 a month that D1 alone was worth.
From the page to the workflow
The repaired SOP translates almost line for line. Each step becomes a node, each decision a branch with its rule written on it, each exception an edge into one queue with an owner.
None of the six steps needs a model. Pulling invoices is a query, matching payments is arithmetic on numbers and amounts, the stage is date arithmetic, sending is a template. The one place the input is free text is the clients' replies: "paid on Friday", "this is the wrong amount", "please use our new address". A model sorts each reply into a paid claim, a dispute or something else, and every label lands in the exception queue for a person. That split, deterministic steps around one bounded model step, is the shape deterministic harnesses describe, and it is why the run costs about $1 a month in model calls.
The SOP is also the test plan. Each decision is a pair of cases on either side of its rule: an invoice 6 days past due is not chased and one 7 days past due is; a payment $0.80 short matches and one $1.20 short does not. A builder handed the repaired page can write those tests before writing the workflow.
In practice
Give the builder, or the vendor, the repaired page and one instruction: "Build exactly this. Any question you have is a decision I missed; send it back to me in writing rather than choosing." Give the operations manager one instruction too: write it so a new hire could run Monday's chase without asking anything. The two instructions produce the same page.
The mistake that costs money: handing a builder the name of a task instead of its SOP. Every hidden decision is then made in code by someone who does not know the clients, and here the first one guessed wrong costs about $1,300 a month.
Check yourself
1. A client pays half an invoice. Where in the SOP does that case go, and what happens the first time it occurs?
The first time, it is an exception: the input is clear but no rule covers it, so it goes to the queue for the account manager. Once they decide, the rule moves into Decisions, for example "a part payment keeps the invoice at its stage, and the next reminder states the balance". An SOP grows from its exceptions; an exception that recurs and stays an exception is a decision nobody has made.
2. The builder offers to skip the SOP and infer the rules from last year's 1,800 sent reminders. Decide whether to accept.
No. Last year's reminders show what was sent, not what was decided: the 15 invoices a week inside the grace period never appear in them, so D1 cannot be inferred from the record and would be guessed, at about $1,300 a month if guessed wrong. The SOP costs 90 minutes, $45. The reminders are useful afterwards, as test cases for rules already written.
3. The builder proposes a model in step 2 to decide whether each invoice is paid. Do you agree?
No. Matching by invoice number, or by amount within $1 from the same client, is exact and free; a model makes the same decision probabilistic, and its mistakes are the $100 reminders to clients who have paid. The model belongs where the input is free text, the replies, and even there its output is one of three labels that a person reads.