Process mapping and SOPs

You turn "the way Sam does it" into a map everyone agrees is true and an SOP a new person can follow without asking. The map shows reality, including the workarounds and the exceptions; the SOP is short, imperative and tested. The standard: someone who has never done the task completes it correctly from the SOP alone, and the owner knows who keeps it up to date.

When to use

• "Write down how we do month-end invoicing."
• "Sam is leaving; capture what she does."
• "We keep getting this wrong; we need a standard way."
• "Map our order-to-delivery process."
• "The auditor wants our procedures."

What you need

• The people who do the work, and the person who owns the outcome. Reach them with ask_teammate or brief_team; for a hire with screen access to the systems, observe in your own browser where the owner has signed you in.
• Existing documents, emails, checklists and templates (search_files, the team's shared drive or wiki if connected on the Connections page: Google Drive, Notion, Dropbox, OneDrive, Box).
• System access, or screenshots, for the tools used in each step, so field names and buttons are exact.
• Volumes and timings if available: how many per week, how long each step takes, how often it goes wrong.

Method

1. Set the boundaries with a SIPOC: Suppliers, Inputs, Process (5 to 7 high-level steps), Outputs, Customers. Agree the trigger (what starts it) and the end (what "done" means) with the owner before mapping detail.
2. Map the as-is, not the ideal. Interview the doers one at a time with the questions in references/mapping-and-sop-templates.md. Walk through a real recent case, not a generic one. Ask "what happens when it goes wrong?" for every step.
3. Draw a swimlane map: one lane per role or system; steps as verb plus noun ("Check PO number"); diamonds for decisions with each exit labelled; handoffs where a line crosses lanes; waits shown explicitly. Write it as Mermaid source so it can be rendered and edited (syntax in the reference). Keep the main path to one screen; put exceptions on separate small maps.
4. Measure each step where you can: process time (hands-on work), lead time (from work available to passed on, including waiting), and % complete and accurate (how often the next step can use the output without correcting, adding or clarifying). Roll up: total lead time, total process time, and rolled % complete and accurate (multiply the step percentages). These show where the time and the errors really are.
5. Validate the map with every person who appears in it. Differences between people are findings: either two processes exist or one person has a better way. Note them; resolving them is an improvement decision for the owner.
6. Write the SOP from the agreed map (template in the reference):
   • Purpose, scope, trigger, roles, inputs, tools and access needed.
   • Numbered steps, one action each, imperative, at most about 20 words, with exact field names, buttons and values. Screenshots for tricky screens (browser_vision or ones the owner gives you; redact personal data).
   • Decision points as "If X, go to step N; otherwise continue".
   • Built-in checks ("Confirm the total equals the PO before saving").
   • Exceptions table: situation and what to do.
   • Outputs, where records are kept, related documents, owner, version, review date. Use a checklist format for routine tasks done by experienced staff, and full step-by-step for rare or high-risk tasks.
7. Test it cold. Have someone who has not done the task follow it exactly: a teammate via ask_teammate, or a subagent via delegate_task against a test record. Every question they ask is a gap in the SOP. Fix and retest until they finish without help.
8. Publish and own. Store it where the team works (connected drive or wiki, or the shared folder), name an owner, set a review date (6 or 12 months, or on any system change) with cronjob, and keep a version history. Retire old versions so only one is findable.

Worked example: step table and what it tells you

Step	Role	Process time	Lead time	% complete and accurate
Check order	Sales admin	6 min	4 h	80% (1 in 5 missing a PO number)
Enter order	Sales admin	9 min	2 h	95%
Pick and pack	Warehouse	15 min	20 h	97%
Invoice	Finance	5 min	48 h	90%
Roll-up: 35 minutes of work inside 74 hours of elapsed time; rolled % complete and accurate 0.80 x 0.95 x 0.97 x 0.90 = 66%, so a third of orders get corrected somewhere along the way. The findings note says: the invoice wait and the missing PO are where the time and the errors are; both are improvement candidates (see process-improvement). The mapping itself stays faithful to today.

SOP steps: weak and strong

Weak	Strong
"Process the order."	"In Orders, click New, select the customer in the Customer field, and type the PO number in Reference."
"Check everything is right."	"Confirm the order total equals the PO total. If it does not, go to step 9."
"Send to the warehouse promptly."	"Click Release to warehouse within 2 working hours of entry."
"Deal with any problems."	"If the customer has not given a PO number, email them with template PO-REQ and set the status to Awaiting PO."

Testing it cold

1. Give the SOP and one real but safe test record to someone who has never done the task.
2. The instruction: "follow this exactly and tell me every point where you had to guess or ask".
3. Record each question as a numbered gap. Fix the SOP, not the tester.
4. Repeat until a run finishes with no questions; that is the version you publish.
5. For an agent, delegate_task with the same instruction against a test record works the same way, and the questions it asks are just as telling.

Output

• Process map: Mermaid source and a rendered image if a renderer is available, plus the SIPOC.
• Step table: step, role, system, process time, lead time, % complete and accurate, notes.
• SOP document following the template, with version, owner and review date.
• A short findings note for the owner: variations between people, steps with low % complete and accurate, long waits, and risks (single person dependencies, manual re-keying).

Checks before you finish

• Trigger and end are explicit; every decision has all exits labelled.
• Every step in the SOP is one imperative action with exact names from the system.
• Every exception you heard in interviews is either in the SOP or deliberately excluded with a reason.
• A person new to the task completed it from the SOP without help.
• Owner, version and review date are on the document.
• No passwords, personal data or client secrets appear in the SOP or screenshots.

Pitfalls

• Mapping the official process instead of what people actually do.
• Interviewing the manager only. The doer knows the workarounds.
• Steps that bundle three actions. Split them; errors hide in the bundle.
• Vague verbs ("process the invoice", "handle the request"). Say exactly what to do.
• No exceptions. The exceptions are where errors and delays come from.
• Untested SOPs. If nobody followed it cold, it is a draft.
• Two versions in circulation. Keep one source and retire the rest.

See also

• process-improvement, operations-metrics-dashboard, project-retrospective.