A process map is ready to become an SOP only when every activity has an owner, input, method, acceptance criterion, exception path, output, and retained record. Approval of the arrows confirms the agreed flow; it does not automatically supply those operational details.
The map-to-SOP handoff is therefore an expansion, not a transcription. A weak handoff turns each box into a numbered sentence. A strong one asks what a trained person would still need in order to perform, verify, and prove the work.
First freeze what the map actually establishes
Before drafting prose, record the approved map’s:
- purpose and boundary;
- start trigger and required input;
- end state and downstream owner;
- roles or systems represented by lanes;
- activity sequence;
- decision tests and branches;
- named records or approvals;
- map owner, approver, version, and approval date.
ISO’s public process-approach guidance identifies inputs, outputs, sequence, interaction, controls, responsibilities, risks, and measurement as core process questions. It also notes that process descriptions can use flowcharts, instructions, checklists, visuals, or electronic methods—the format is a means, not the goal.
That distinction prevents two opposite mistakes: treating the map as the entire procedure, or discarding it once prose begins.
Expand every activity with the 4A test
For each task box, capture four things:
- Actor: Who performs it, and what authority or competency is required?
- Action: What observable action occurs, using which tool or system?
- Acceptance: What condition proves the step is complete or correct?
- Artifact: What record, file, transaction, or physical mark remains?
“Review request” fails all four. A usable expansion might be:
The shift supervisor compares the submitted request with the approved order in the operations portal. Confirm customer ID, quantity, delivery window, and authorization status. If all four match, mark the request “verified” and retain the review log under the order number.
The map can keep the concise box. The SOP carries the operational burden.
Convert each decision into a test
A diamond labeled “Approved?” is not yet a decision rule. The handoff must name:
- evidence examined;
- threshold or criterion;
- person or system authorized to decide;
- outcome when evidence is missing or contradictory;
- escalation owner and response time;
- record of the decision.
Write the rule in if / then / otherwise form before turning it into prose. If the team cannot agree on the condition, the workflow was not truly approved; only its drawing was.
Build an exception inventory
Happy-path maps often omit the work that consumes the most judgment. Run a workshop with three prompts:
- What arrives incomplete, late, damaged, duplicated, or out of sequence?
- Which tool, person, or external dependency can be unavailable?
- When must the operator stop instead of improvising?
Classify each exception as recover, escalate, reject, or hold. Give every class an owner and an evidence requirement. Do not hide “use judgment” inside a note unless the role, allowed discretion, and review mechanism are explicit.
Map records separately from instructions
ISO’s documented-information guidance distinguishes information maintained to operate processes from information retained as evidence of results. In plain language: the SOP tells people what to do; the completed checklist, log, approval, or transaction proves what happened.
Create a record register:
| Record | Created at | Owner | Minimum fields | Retention / destination |
|---|---|---|---|---|
| Intake log | Trigger | Coordinator | source, time, request ID | operations system |
| Verification result | Review | Supervisor | criteria, outcome, reviewer | order record |
| Exception note | Branch | Assigned owner | condition, action, escalation | case folder |
| Completion notice | Handoff | Operator | output ID, recipient, time | notification log |
The register catches “phantom evidence”—an SOP that requires a review but never defines where the review is recorded.
Use a worked handoff: customer refund
Suppose the approved map is:
request received → verify purchase → eligible? → issue refund / explain denial → close case
The SOP still needs at least:
- accepted request channels and required fields;
- the system of record for purchase verification;
- eligibility source and effective version;
- who can approve exceptions and up to what amount;
- duplicate-refund check;
- payment method and expected processing boundary;
- required customer message;
- case-close criteria and retained evidence;
- outage procedure when the payment system is unavailable.
Once the crosswalk is complete and the wording is approved, SOPMaker fits the next job: turning those structured process facts into a controlled SOP draft that a team can review, localize, and maintain. The tool should receive the approved facts; it should not be asked to invent policy, thresholds, or regulatory requirements.
Approval is three different approvals
Do not use one signature to mean everything. Record:
- Process approval: the sequence, roles, and decisions reflect intended operations.
- Content approval: instructions, controls, and records are correct and sufficient.
- Release approval: the version is authorized for use, distributed, and effective on a stated date.
The same person may hold more than one role, but the claims remain distinct.
Run a tabletop test before release
Give the draft to a qualified person who did not write it. Provide one normal case and two exceptions. Observe without coaching.
Record:
- where they ask for missing information;
- where two interpretations are possible;
- which system names or field labels are outdated;
- whether acceptance criteria can be observed;
- whether required records can actually be created;
- where they improvise.
Update both SOP and map when the test changes process logic. Update only the SOP when the flow is right but execution detail was missing.
The release checklist
- Every box passes Actor, Action, Acceptance, Artifact.
- Every diamond has a test, evidence source, and exception owner.
- Tools, forms, systems, and source policies are named and current.
- Stop conditions and escalation paths are explicit.
- Required records have destinations and owners.
- Process, content, and release approvals are distinguishable.
- A cold reader completed normal and exception cases.
- Map and SOP share version references and review dates.
The map remains the fastest way to see the system. The SOP becomes the controlled instruction for operating inside it. A good handoff preserves both artifacts and makes their different claims explicit.