A finished SOP, section by section

The interview hands you eleven fields per process, in the operator's own words, with the exceptions still attached. That's raw material, not a document. What it has to become is something a new hire could run in their second week and a controller could put a number against.

Most process documentation doesn't fail on effort. It fails on being the wrong document — a tidy account of how the work is supposed to go, written by someone who doesn't do it, filed where nobody looks.

Current state, not the state you wish you had

One rule decides whether the document is worth anything: it describes what happens now, including the parts you'd rather it didn't.

The temptation runs hard the other way. Once the process is laid out in front of you the inefficiencies are obvious, and writing down the version with the workaround still in it feels like documenting a mistake. So people document the improved process instead — and produce a document that is wrong on its first day. Nobody follows it, because it doesn't match what they do. Nobody can cost it, because the timings belong to a process nobody runs. And when the improvement doesn't fully land, there's no record of what you started from.

Improvements belong in a different document. The SOP says what is; the roadmap says what to change and what that's worth, against tests. Mix them and you get a document that is simultaneously not true and not actionable.

The eight sections

Purpose. One or two sentences: what this process produces, and for whom. Its job is to let a reader decide in five seconds whether this is the document they need. Skip it and every SOP in the folder looks identical from the outside.

Scope. Where the process starts and stops, and what it explicitly doesn't cover. This is where the exceptions you dug for land — standard certificate requests are in scope; anything requiring a policy endorsement isn't, and goes to the account manager. Unscoped SOPs get argued about instead of followed.

Systems Used. Every system touched, named the way staff name them. Including the spreadsheet. Especially the spreadsheet — a shadow tool that isn't listed here is a dependency nobody knows they have.

Roles Involved. Who performs it, who approves, and who covers when the first person is out. "Coverage: none — requests queue until she's back" is a legitimate entry and one of the more valuable lines in the document.

Procedure. Numbered steps, each naming four things: who acts, what they do, which system, and how long it takes where you know. The difference this makes:

3. Process the request.

versus

3. CSR opens the request in Outlook, confirms the client's active policies in the AMS, and drafts the certificate in the carrier portal. ≈12 min.

The first is a heading pretending to be an instruction. The second can be followed by someone who has never done it, and the minutes attached to it are what make the process costable later.

Volumes & Frequency. How often, captured while the person was in front of you, with a range if a range is what you got. Ranges are fine. Invented precision is not.

Known Pain Points. What the people doing the work said is hard, in their words, stated neutrally. Not your diagnosis. Their sentence is evidence; your paraphrase is opinion — and it's their sentence that survives being read back to them in a room full of colleagues.

Observations. Facts worth flagging that don't fit elsewhere: two people described the same step differently, one instance took three times as long as another, a step exists only because of a system limitation that was lifted last year. Still no recommendations. Observations are the seeds of a roadmap; they are not the roadmap.

Mark the gaps, don't fill them

Where the notes don't cover something, write [To be confirmed] and move on.

That's harder than it sounds, because at drafting time you can usually guess, and the guess is usually close. But a plausible guess and a captured fact are indistinguishable on the page a month later, and the guess is the one that quietly gets built on. The marked gap has a second property the filled one doesn't: it's assignable. Someone can be asked to close it. A gap you papered over is invisible, and nobody can be assigned to a problem no one can see.

We hold our own drafting tool to the same rule. It's forbidden to invent a step, a system, a role, or a number, and where the capture is thin it's required to say so rather than write around it.

Where the interview fields land

Captured in the interview	Lands in
Trigger	Procedure, step 1
Inputs	Procedure — the gathering steps
Systems touched	Systems Used
Steps	Procedure
Exceptions	Scope, and Observations
Handoff	Procedure's last step, and Roles Involved
Failure mode	Known Pain Points
Volume, duration	Volumes & Frequency, and per-step timings
Owner, coverage	Roles Involved

Nothing captured is thrown away, and nothing appears in the SOP that wasn't captured. An empty section is a finding about the interview — not permission to write something plausible.

A sample, from the modeled agency

The figures below come from the 24-person agency used as a running example across these articles. It's a modeled fixture, not a client. Certificate requests, abbreviated to fit:

Certificate of insurance requests

Purpose. Issue a certificate of insurance to a client or their counterparty on request.

Scope. Standard certificates drawn from active policies. Requests requiring an endorsement are out of scope and route to the account manager.

Systems Used. Outlook (shared inbox) · agency management system · two carrier portals · a shared tracking spreadsheet.

Roles Involved. CSR performs; account manager approves non-standard wording; coverage when the CSR is out — [To be confirmed].

Procedure. Seven steps, ≈20 minutes door to door. Step 1: CSR sees the request in the shared inbox, checked roughly four times a day. Step 4: CSR re-keys the holder's details into the carrier portal, ≈4 min. Step 7: CSR emails the certificate and logs the request in the tracking spreadsheet, ≈3 min.

Volumes & Frequency. ≈15 per week, year-round, with a spike around January renewals.

Known Pain Points. "About half of them don't say who the holder is, so it's two emails before I can even start."

Observations. Two CSRs described step 4 differently — one re-keys from the AMS, one from the original email. The tracking spreadsheet is not part of any system and has no owner.

With the volumes and the timings both in place, the process is costable without another conversation: 15/week × 52 weeks × 20 minutes ÷ 60 × $35 blended = $9,100 a year. That's what the current state costs. It is not what anyone would save by changing it — savings are a separate number, smaller, and argued much more carefully.

Three tests before you call it done

1. The new-hire test. Could someone competent but new run this without asking a question? Wherever a step assumes knowledge they don't have, it's a heading, not an instruction.
2. The costing test. Do the volumes and durations support the arithmetic above? An SOP with no numbers in it is a training document — useful, but it can't be ranked against the other thirty-nine.
3. The diff test. A year from now, when the process has changed, will you be able to see what changed? That requires a fixed shape: same sections, same order, every time.

None of this needs a consultant. It needs discipline about the boring parts — the same eight sections in the same order, gaps marked instead of guessed, minutes written down while the person is still in the room. Doing that once is easy. Doing it forty times in two weeks, across departments, and then costing the result honestly is most of what the assessment is.