Key takeaways
- The best first SOP has a crisp trigger, authoritative inputs, frequent repetition and exceptions that already have named destinations.
- Linear checklists, threshold branches, judgment queues, approval gates and timed escalations produce different workflow shapes even when their documents look alike.
- Automate the stable middle before the ambiguous edge. A useful first version may still send several cases to a person.
- A workflow is complete only when it records an outcome or a named exception state; sending a notification is not a finish condition.
Five SOP shapes produce five different automations
| Example | Shape | Control point | Finish state |
|---|---|---|---|
| Daily data-quality check | Linear checklist | Every required check returns a result | Report stored or exception assigned |
| Request priority routing | Threshold branch | Exact priority rules and tie handling | Queue and owner assigned |
| Support evidence triage | Bounded judgment | Uncertainty and unsupported claims | Draft packet or human queue |
| Customer credit adjustment | Approval gate | Proposed amount and authority | Posted, rejected or expired |
| Contract-renewal reminder | Timed escalation | Deadline, response and escalation clock | Renewed, declined or owner escalation |
Google's SRE workbook describes toil as work with manual, repetitive and automatable qualities, among others. Those qualities help find candidates. The examples below add the missing selection test: can the process owner state what happens at the point where the path changes?
Examples 1 to 3: sequence, rules and bounded judgment
Trigger: 06:00 after the source export closes. Code: verify file date, schema, row-count range and required-field completeness. Exception: a failed check creates an owned ticket and blocks publication.
Evidence: input checksum, result per check, output location and ticket ID. The workflow finishes as published or blocked-owned, never “email sent.”
Trigger: a valid request enters the queue. Code: route P1 for a named service outage or safety condition; route P2 for a blocked user; otherwise P3. Equality and multiple matches resolve to the higher priority.
Human: cases with contradictory fields enter triage rather than letting the system guess. Evidence: evaluated facts, matched rule, resulting queue and assignee.
Trigger: an operator requests a draft case summary. AI: extracts claimed events from the ticket and links each statement to a message. Code: rejects statements with no source reference and checks required fields.
Human: reviews contradictions and customer-facing conclusions. Finish: a sourced draft packet or insufficient-evidence; the automation does not send a reply.
Examples 4 and 5: approval and time
Trigger: an approved service case requests a credit. Code: retrieves account, currency, prior credits and policy limit. Proposal: exact amount, reason and ledger destination.
Human gate: an authorized role approves that immutable proposal. An edit creates a new proposal. Effect: post once, reconcile the resulting transaction ID and close as posted, rejected or expired.
Trigger: 90 days before the stored renewal date. Code: validates owner, notice period and contract status, then creates an owner task. Reminders occur at approved intervals.
Exception: no owner routes to the operations queue; conflicting dates route to legal operations; no response by the internal deadline escalates to the department lead. The workflow never assumes renewal from silence.
All figures, policies and cases on this page are simulated. They show specification structure, not recommended thresholds or proof that all-agents currently connects to the systems implied by each job.
Choose the first SOP with a control-point scorecard
| Dimension | 0 | 1 | 2 |
|---|---|---|---|
| Trigger | Informal | Observable but noisy | One explicit event |
| Inputs | Scattered or disputed | Mostly named | Authoritative and accessible |
| Path | Changes by operator | Stable middle | Stable with named branches |
| Exceptions | Handled from memory | Known but unowned | Named destination and owner |
| Effect | Hard to reverse | Review can contain it | Reversible or draft-only |
| Evidence | No completion record | Partial record | Outcome and reason retrievable |
A total near 12 is a strong design candidate, not permission to deploy. A low effect score may be rescued with a human gate; missing inputs and unnamed exceptions usually require process work first.
Once you choose the shape, use the translation ledger to convert the actual procedure. Do not copy an example's thresholds, roles or timing into a different business.
Limitations and when not to use this
- These are simulated process designs, not customer case studies, benchmarks, legal advice or verified descriptions of all-agents integrations.
- A high score reflects specification readiness. It does not measure expected savings, safety, employee impact or regulatory suitability.
- Processes involving money, employment, health, safety, legal rights or sensitive access require qualified review and stronger evidence than this general guide supplies.
Sources
- ISO 9001:2015 — Quality management systems — International Organization for Standardization Accessed 31 July 2026
- Operational Efficiency: Eliminating Toil — Google SRE Accessed 31 July 2026
- Business Process Model and Notation (BPMN), Version 2.0.2 — Object Management Group Accessed 31 July 2026
Translate one SOP
Turn the chosen procedure into owned nodes, branches, exceptions and acceptance tests.
Translate one SOPUli 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.