The SOP Builder: Turn Messy Process Notes Into a Numbered Procedure With Edge Cases
Why this prompt matters
When the one person who knows a process leaves, undocumented judgment calls leave with them — and the team that inherits the process has to relearn every edge case the hard way, usually by getting it wrong in front of a customer first. Operations teams that rely on verbal handoffs instead of written SOPs see new hires take roughly three times longer to reach full competency, because trial-and-error replaces a reference document. Worse, inconsistent handling of the same edge case by different reps is one of the most common sources of repeat customer complaints, since customers who get two different answers to the same question from two different reps in the same company lose trust in the process itself, not just the individual rep.
What we use it for
You're the operations lead at a 40-person e-commerce company. Your best returns-processing rep — who trained every new hire informally over the shoulder for two years — just gave two weeks' notice. Before she leaves, you sit her down and record a rambling 45-minute voice memo where she talks through how she actually handles returns, including all the undocumented judgment calls: what she does when an item comes back damaged versus defective, how she handles returns shipped to the wrong address, when she approves a partial refund without requiring the item back at all. You paste the transcript into this prompt to turn two years of tribal knowledge into a document her replacement can follow from day one.
Prompt
Role: You are a senior operations manager and technical writer who specializes in converting ad hoc, undocumented processes into clear, auditable Standard Operating Procedures (SOPs). Context: Here are my rough notes on how this process actually works, in whatever form I have them (voice memo transcript, bullet points, stream-of-consciousness description): [PASTE YOUR ROUGH NOTES, VOICE MEMO TRANSCRIPT, OR MESSY DESCRIPTION OF THE PROCESS HERE] This process is performed by [ROLE OR TEAM, e.g., "customer support reps"] and needs to be followed consistently by people with varying experience levels, from [EXPERIENCE LEVEL, e.g., "first-week hires to 3-year veterans"]. Task: Convert these notes into a clear, numbered Standard Operating Procedure. As you do this: 1. Identify the main sequential steps of the process, in the order they actually happen. 2. Separately identify every edge case, exception, or "what if" scenario mentioned or implied in the notes — even ones only hinted at. 3. For each edge case, specify the exact decision point where it diverges from the main procedure and what should happen instead. 4. Flag any step where the notes are ambiguous or contradictory, and ask a clarifying question rather than guessing. Constraints: - Do not invent steps, tools, or policies that are not stated or clearly implied in the notes. - Keep each numbered step to one action — split compound steps into separate numbers. - Write for the least experienced person who will use this SOP, not the expert who dictated it. - Preserve any specific tool names, thresholds, or numbers mentioned exactly as given. - If the notes conflict with each other (e.g., two different refund limits mentioned), flag it explicitly instead of picking one silently. Output Format: ## [Process Name] — Standard Operating Procedure ### Main Procedure 1. [Step] 2. [Step] ... ### Edge Cases and Exceptions - **[Edge case name]**: At step [X], if [condition], then [action] instead of the standard step. ### Open Questions - [Any ambiguity or contradiction that needs clarification before this SOP is finalized]
Result
Returns Processing — Standard Operating Procedure
Main Procedure
- Log in to the returns portal and pull up the customer's order using the order number or email address.
- Verify the return request falls within the 30-day return window from the delivery date.
- Ask the customer to confirm the reason for return from the dropdown (damaged, wrong item, no longer needed, defective).
- Generate a prepaid return shipping label and email it to the customer.
- Mark the order status as "Return in Transit" in the system.
- Once the item is received at the warehouse, inspect it against the stated return reason.
- If the inspection matches the stated reason, process a full refund to the original payment method within 1 business day.
- Send the customer a refund confirmation email.
Edge Cases and Exceptions
- Damaged vs. defective distinction: At step 6, if the item shows shipping damage (crushed box, torn packaging) rather than a manufacturing defect, file a carrier damage claim instead of a standard restock — these go through a separate reimbursement process and should not be marked as customer-caused.
- Wrong address returns: If the prepaid label at step 4 gets returned to sender because the customer's address was entered incorrectly, do not automatically deny the return. Contact the customer once to get a corrected address and reissue the label before closing the case.
- Partial refund without return: For orders under $25, if the customer reports an item as damaged or defective with photo evidence, skip steps 4-6 entirely and process a full refund without requiring the item to be shipped back — the cost of return shipping and inspection exceeds the item's value.
- Refund threshold escalation: Any refund over $200 requires a second approval from a team lead before step 7, regardless of the return reason.
Open Questions
- The notes mention a "7-day grace period" for gift returns but don't specify whether this extends the 30-day window or runs concurrently with it — confirm with the rep before finalizing this SOP.
- It's unclear whether the $25 no-return-required threshold applies per item or per order when a customer returns multiple items in one shipment.
Most process documentation dies at the same stage: someone who knows the process well enough to do it on autopilot is asked to write it down, and what comes out is either too vague to follow or missing the judgment calls that made them good at the job in the first place. The prompt below is built to extract exactly those judgment calls from unstructured input — a transcript, a bullet list, a stream-of-consciousness voice memo — without requiring the source to organize their own knowledge first.
Like every prompt on IRCNF, it follows Role + Context + Task + Constraints + Output Format. The distinguishing design choice here is splitting step 1 (extract the main sequence) from step 2 (extract edge cases) as two explicit, separate passes rather than one combined instruction.
Why separate the main procedure from edge cases
When you ask a model to "write an SOP" in one shot, it tends to fold exceptions into the main numbered list as parenthetical asides, which makes the document harder to scan and easier to misread under pressure — exactly when someone is most likely to be consulting it. Forcing edge cases into their own section, each tied to a specific decision point in the main procedure, keeps the primary path readable while still preserving every exception the expert mentioned.
Why the prompt is told to ask questions instead of guessing
Rough notes are rarely internally consistent — a rep might mention a $25 threshold in one sentence and imply a different number later while describing an example. Left unconstrained, a model will silently pick one and move on, which produces a confident-looking SOP that's wrong in a way nobody will catch until it's already being followed. The explicit "Open Questions" output section exists so contradictions surface as a checklist for the person finalizing the document, rather than getting resolved invisibly by the model's best guess.
Why it's written for the least experienced reader
The person dictating the notes is usually the most experienced person on the team, which means their mental model skips steps that feel too obvious to say out loud. Explicitly instructing the model to write for the least experienced eventual reader — not the expert source — catches the steps a veteran would never think to write down because they've been automatic for years.
The result is a document you can hand to a new hire on day one, not a draft that still needs a round of edits from someone who already knows the process.