Key takeaways
- Translate the SOP one sentence at a time. Each sentence needs an entry condition, owner, input, action, output, exception and evidence record before it can become a workflow step.
- Draw branches from explicit decisions, not from vague words such as normally, appropriate or unusual. Those words mark policy work that the process owner must finish.
- Keep a traceability link from every workflow node back to the exact SOP version and clause that authorized it.
- Test the workflow with missing, duplicated, late and contradictory inputs. A happy-path demonstration proves very little.
Start with a translation ledger, not a diagram
A flowchart drawn directly from prose usually preserves the prose's gaps. “Check the request and route it appropriately” becomes a box with the same words inside it. It looks like engineering, but nobody has defined check, appropriately or the possible destinations.
Make one ledger row for each instruction first. ISO 9001 treats documented information, controlled operations and performance evaluation as connected parts of a quality system. The practical implication is simple: the workflow must preserve the approved rule, execute it and leave enough evidence to evaluate the result.
| Field | Question | Reject the row when |
|---|---|---|
| Entry | What exact state makes this step eligible? | It depends on “when ready” or another unobservable condition. |
| Owner | Is this code, model judgment or a named human role? | The owner is a team inbox with no assignment rule. |
| Input | Which record and version does the step read? | Two sources may disagree and no authority is named. |
| Action | What operation occurs, with which boundary rules? | The verb is check, handle or review without criteria. |
| Output | What new state or artifact must exist? | Success is described as “done” rather than observable state. |
| Exception | Where does each expected failure go? | Failure only sends a message and leaves ownership unresolved. |
| Evidence | What record proves the action and decision? | The record cannot name the rule, actor or before-and-after values. |
Connect rows only after every branch has a destination
- 01Mark the trigger and finish statesTriggerA trigger creates one run identifier. Write success, rejected, cancelled and exception as separate terminal states so “stopped” is not confused with “failed.”
- 02Classify each actionCodeFixed transformations and exact thresholds belong in code. Evidence interpretation may use model judgment. Consequential effects wait for the human role named in the SOP.
- 03Turn decisions into branchesCodeWrite mutually exclusive conditions and say where equality lands. Add an otherwise branch. A decision with no otherwise path hides an exception.
- 04Add waits, retries and duplicate handlingCodeState deadlines, retryable errors, retry limits and the idempotency key. A repeated trigger must not create a second external effect.
- 05Attach evidence and acceptance testsHuman approvalFor every node, name the event it emits and one test that must pass. The process owner approves the translation, not just the drawing.
BPMN provides a standard vocabulary for events, activities, gateways and flows. You do not need full BPMN to get value from its discipline. The useful habit is to distinguish something that happened, work that must occur and a decision that changes the path.
Worked example: a supplier-address change
SOP clause: “Verify supplier address changes and update the record.”
Entry: a change request with supplier ID, proposed address and requester identity receives run ID SC-2048. Input: current supplier record plus the original request. Rule: compare normalized address fields. An identical address closes as no change. A difference proceeds to review.
Human gate: the vendor-data owner sees the before-and-after diff, requester, supporting document and duplicate warning. Approve writes the exact proposed fields once. Reject leaves the record unchanged. Missing evidence moves the run to needs-evidence.
Done: one of unchanged, updated, rejected or needs-evidence is recorded with SOP version, actor and timestamp. All values here are illustrative.
The original sentence hid four policies: what verification means, who may approve, whether no change is success and what happens when evidence is absent. The ledger forced those questions before the workflow could act.
Test the translation against cases people usually skip
| Case | Expected state | Defect it catches |
|---|---|---|
| Same address with different capitalization | unchanged | Missing normalization rule |
| Request has no supporting document | needs-evidence | Invented or silent verification |
| Approver edits the proposal | New version, new decision | Approval bound to the wrong payload |
| Trigger delivered twice | One run and at most one write | Missing idempotency |
| Write succeeds but confirmation times out | Reconcile before retry | Duplicate external effect |
Google's SRE workbook defines toil partly by its manual, repetitive and automatable character. That makes toil a useful discovery signal, but not an authorization signal. Repetition tells you where to inspect; the SOP and its owners tell you what the workflow may do.
When the ledger still contains unanswered policy questions, return to the SOP automation pillar. Do not ask the workflow builder to settle them.
Limitations and when not to use this
- This method does not prove that the underlying SOP is lawful, safe or commercially sensible. The process owner and relevant subject specialist remain accountable for the rule.
- A diagram is not executable merely because every box has a label. Connectors, permissions, transactions, observability and recovery still require implementation and testing.
- High-risk procedures may require formal validation, segregation of duties, retention controls or qualified review beyond this general method.
Sources
- ISO 9001:2015 — Quality management systems — International Organization for Standardization Accessed 31 July 2026
- Business Process Model and Notation (BPMN), Version 2.0.2 — Object Management Group Accessed 31 July 2026
- Operational Efficiency: Eliminating Toil — Google SRE Accessed 31 July 2026
See five translated examples
Compare five SOP shapes and the control point that determines how each should run.
See five translated examplesUli 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.