Der SOP Builder: Aus unordentlichen Prozessnotizen eine nummerierte Prozedur mit Randfällen erstellen
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.
Die meisten Prozessdokumentationen scheitern an derselben Stelle: Jemand, der den Prozess gut genug kennt, um ihn im Autopilot-Modus durchzuführen, wird gebeten, ihn niederzuschreiben. Was dabei herauskommt, ist entweder zu vage, um ihm zu folgen, oder lässt die Entscheidungsspielräume außer Acht, die ihn zuvor so gut in seinem Job gemacht haben. Der folgende Prompt ist darauf ausgelegt, genau diese Entscheidungsspielräume aus unstrukturierten Eingaben zu extrahieren – einem Transkript, einer Aufzählung, einer assoziativen Sprachnotiz –, ohne dass die Quelle ihr eigenes Wissen vorher ordnen muss.
Wie jeder Prompt auf IRCNF folgt er dem Schema Rolle + Kontext + Aufgabe + Einschränkungen + Ausgabeformat. Die entscheidende Designentscheidung hier ist, Schritt 1 (Hauptablauf extrahieren) und Schritt 2 (Randfälle extrahieren) als zwei getrennte und explizite Durchläufe zu behandeln, anstatt sie in einer einzigen Anweisung zu kombinieren.
Warum Hauptablauf und Randfälle trennen
Wenn man ein Modell bittet, in einem Rutsch „ein SOP zu schreiben", neigt es dazu, Ausnahmen als eingeklammerte Anmerkungen in die nummerierte Hauptliste einzufügen. Das macht das Dokument schwerer überblickbar und unter Druck leichter falsch lesbar – genau dann, wenn jemand es am wahrscheinlichsten zur Hand nimmt. Indem man Randfälle in einen eigenen Abschnitt zwingt, jeweils verknüpft mit einem bestimmten Entscheidungspunkt im Hauptablauf, bleibt der Hauptpfad lesbar, während dennoch jede vom Experten erwähnte Ausnahme erhalten bleibt.
Warum der Prompt angewiesen wird, Fragen zu stellen, statt zu raten
Rohe Notizen sind selten in sich konsistent – ein Mitarbeiter könnte in einem Satz eine Schwelle von 25 $ erwähnen und später bei der Beschreibung eines Beispiels eine andere Zahl andeuten. Ohne Einschränkung wählt das Modell stillschweigend eine aus und macht weiter. Das ergibt ein selbstbewusst wirkendes SOP, das auf eine Weise falsch ist, die niemand bemerkt, bis es bereits befolgt wird. Der explizite Ausgabeabschnitt „Offene Fragen" existiert, damit Widersprüche als Checkliste für die Person, die das Dokument finalisiert, auftauchen, anstatt unsichtbar durch die beste Schätzung des Modells aufgelöst zu werden.
Warum es für den am wenigsten erfahrenen Leser geschrieben ist
Die Person, die die Notizen diktiert, ist normalerweise die erfahrenste im Team, was bedeutet, dass ihr mentales Modell Schritte überspringt, die zu offensichtlich erscheinen, um sie laut zu sagen. Indem man das Modell explizit anweist, für den am wenigsten erfahrenen Leser zu schreiben – nicht für die Expertenquelle – werden die Schritte erfasst, die ein Veteran nie niederschreiben würde, weil sie seit Jahren automatisch ablaufen.
Das Ergebnis ist ein Dokument, das man einem Neueinsteiger am ersten Tag in die Hand geben kann, kein erster Entwurf, der noch eine Runde Überarbeitung durch jemanden benötigt, der den Prozess bereits kennt.