Key takeaways
- Give the generator source material, not just a process name: a real run, current policy, field definitions, exceptions and an approved document structure.
- Require the draft to mark unknowns instead of completing them. A blank decision threshold is safer than a plausible invented one.
- Verify claims at instruction level. Every system, role, threshold and expected result needs an owner and a source.
- Have someone other than the drafter perform the SOP from its inputs. Their questions are defects in the document, not training problems to wave away.
Build an evidence pack before writing the prompt
A process name is not evidence. If the input says only “write our customer-refund SOP,” the generator must supply the missing policy from patterns it has seen elsewhere. The prose may be polished and still be wrong for your business.
Use one completed ordinary case and one awkward case. Redact personal data and secrets. Add the current policy, the systems of record, screenshots or field definitions, named roles and the structure your team expects. NIST's AI RMF playbook emphasizes documented context, roles, testing and monitoring; those practices fit this drafting task even when the output is only a document.
| Item | What it contributes | What it must not contain |
|---|---|---|
| Recorded ordinary run | Actual order, tools, inputs and outputs | Unredacted customer or employee data |
| Exception case | A real stop, retry or escalation path | An anecdote presented as the only possible failure |
| Current policy | Thresholds, permissions and prohibitions | Superseded drafts mixed with approved rules |
| Field glossary | Exact meanings and systems of record | Credentials, tokens or unrestricted exports |
| Document contract | Purpose, scope, owner, steps, evidence and revision fields | A template that implies sections irrelevant to the job |
Make the prompt a drafting contract
Draft an SOP only from the attached approved policy, field glossary and two run records. Write for a new operator with access to the named systems.
For each step include entry condition, owner, input, action, expected result, exception and evidence. Preserve exact thresholds and field names. If a fact is absent or sources conflict, insert [OWNER INPUT REQUIRED: question]. Do not infer a system, permission, SLA, threshold or approval.
Finish with a source map that links each instruction to a supplied artifact and a test checklist that another operator can perform. This prompt is an illustrative pattern, not a product test.
Ask for unknowns in a separate list as well as inline. That gives the process owner a work queue. Banning invention in the prompt helps, but it is not a control by itself; the source map and review are the controls.
Review the draft at instruction level
| Draft fragment | Evidence needed | Disposition |
|---|---|---|
| “Open the request in CRM queue A” | Queue name and access shown in current run | Accept if both match |
| “Respond within 24 hours” | Approved service policy | Remove when the source says two business days |
| “Managers approve refunds above 100” | Policy threshold, currency and boundary | Hold until all three are explicit |
| “Notify Finance after approval” | Named recipient and purpose | Rewrite as an owned handoff |
| “Archive the record” | Destination, retention rule and completion proof | Reject vague instruction |
- 01Source checkHuman approvalThe process owner verifies every role, rule, system and expected result against the evidence pack.
- 02WalkthroughHuman approvalThe person who performs the job narrates the draft against a fresh case and marks missing context.
- 03Cold runHuman approvalA competent colleague who did not draft it follows the SOP without coaching. Record every question and detour.
- 04Exception runHuman approvalRepeat with a missing input, duplicate request and rejection. Confirm each has a safe destination.
- 05ApprovalHuman approvalThe named owner resolves all unknowns, approves one version and sets its next review signal.
Choose the input mode that matches the work
| Input mode | Good at | Blind spot |
|---|---|---|
| Screen recording | Clicks, sequence and visible fields | Off-screen policy and judgment |
| Operator interview | Reasons, exceptions and tacit rules | Remembered work may differ from real work |
| Existing documents | Approved wording and structure | Documents may be stale or contradictory |
| Completed-case records | Real inputs, outputs and handoffs | One case does not show the full branch set |
Combine at least two modes. A recording tells you what happened; an approved policy can tell you whether it should have happened. Once the document passes review, use the SOP-to-workflow translation ledger if execution is the next goal.
Limitations and when not to use this
- Do not upload confidential, regulated or personal information until the tool's data handling, retention and access terms have been approved for that material.
- A fluent draft can conceal a false step more effectively than rough notes. Human verification cannot be reduced to proofreading.
- Safety-critical, regulated, financial and employment procedures need the qualified review required by their field; this general drafting protocol is not a substitute.
Sources
- AI Risk Management Framework Playbook — National Institute of Standards and Technology Accessed 31 July 2026
- ISO 9001:2015 — Quality management systems — International Organization for Standardization Accessed 31 July 2026
Use a controlled SOP template
Capture the procedure in an editable format with ownership, exceptions and revision fields already present.
Use a controlled SOP templateUli Prantz
Builds and operates all-agents
Uli Prantz builds all-agents, the process-automation platform this site documents. He writes about the operational side of automating recurring business work: where deterministic code beats model judgment, where it does not, and where a human still has to approve.