SOP writing prompt builder
A Standard Operating Procedure is only useful if anyone can follow it and get the same result. That means numbered steps, clear ownership, the materials needed, the decision points where the process branches, and checkpoints that confirm each stage was done right. This builder converts your process description and responsibility list into an LLM prompt that produces a consistent, audit-ready SOP — not a wall of prose. You bring the prompt to your own model and review the draft.
How it works
You describe the process from trigger to completion, list the responsible roles, set how often it runs, choose a detail level, and pick an output format. The tool assembles a prompt that gives the model a clear SOP structure: purpose and scope, roles, materials, sequential numbered steps, explicit decision points (“if X, then…”), and quality checkpoints. It also instructs the model to flag any missing information rather than invent steps. Everything runs locally until you paste the prompt into your LLM.
What a well-formed SOP step looks like
The difference between an SOP that gets followed and one that gets ignored is usually step granularity. Compare these two steps for the same action:
Too vague: “Process the return.”
Well-formed: “Log into the returns portal. Open the customer order using the order number on the return label. Click ‘Accept Return’. Select the return reason from the dropdown. Click ‘Issue Refund’ only if condition is ‘Acceptable’; if condition is ‘Damaged’, escalate to Shift Lead before proceeding.”
The second version is executable by someone who has never done the task. It names every system, names the decision point, and names who handles the exception. The builder generates prompts that ask the model to write at this level of specificity.
Decision points and why they must be explicit
Every real process has branches — what happens when the normal case does not apply. Common examples:
- What if the item arrives without a receipt?
- What if the system is down during the approval step?
- What if the customer escalates during the resolution step?
Generic SOPs ignore these. An SOP that hits an undocumented decision point leaves the operator to improvise — which is exactly what SOPs are supposed to prevent. When you describe your process, name the conditions where the path forks. The generated prompt will turn each one into an explicit “If X, then Y; if not X, then Z” step.
Quality checkpoints: how to verify each stage was done right
Quality checkpoints are verification steps embedded within the procedure, not just at the end. For each critical step, a checkpoint answers: “How do I know this step was done correctly before moving on?” Examples:
- After data entry: “Verify order status shows ‘Confirmed’ before proceeding.”
- After a system action: “Screenshot saved to case file.”
- At a handoff point: “Receiving team member signs off on the transfer form.”
The generated prompt asks the model to add a checkpoint after each critical step, not just at the end of the SOP, which is where auditors look and where human error most often hides.
Tips and notes
- Describe the trigger and the done state. “Starts when a return arrives; ends when the refund is confirmed” bounds the procedure cleanly.
- Name roles, not names. “Shift lead” survives staff turnover; “Maria” does not.
- Call out the branches. If the process forks (damaged vs. undamaged item), say so — the prompt will turn each fork into a decision point.
- Match detail to the reader. New-hire SOPs need explicit, self-contained steps; expert SOPs can be terse. Set the level accordingly.
- Have the responsible role review the draft. The model structures the procedure; the person who does the job verifies that the steps are correct.