SOP Template: Write Procedures People and AI Assistants Can Follow

A usable SOP template has six parts: the purpose of the procedure, its scope (when it applies and when it does not), the roles involved, numbered steps written as commands, the checks that prove it was done right, and the records it leaves behind. Put an owner, a version and a review date at the top, keep it to one or two pages, and store it where the work happens. The template and a filled example are below. The last section shows how the same procedure splits into a rule and a skill, so an AI assistant follows it exactly as a new hire would.

What an SOP is, and when you need one

The EPA’s Guidance for Preparing Standard Operating Procedures↗ (opens in a new tab) defines an SOP as “a set of written instructions that document a routine or repetitive activity followed by an organization.” The key words are routine and repetitive. A one-off project needs a plan; a job that happens every week, done by whoever is on shift, needs an SOP.

Write one when any of these is true: the job is done by more than one person, a mistake in it costs money or trust, someone new will have to learn it, or you keep explaining it in chat. That last test now applies to AI assistants too. If you paste the same instructions into Claude or ChatGPT every Monday, you already have an unwritten SOP.

Regulated industries have no choice about this. The FDA’s rule for drug manufacturers, 21 CFR 211.100↗ (opens in a new tab), requires written procedures for production and process control, requires that they be followed and documented at the time of performance, and says any deviation “shall be recorded and justified.” A small team is not under that rule, but the habit it describes is the one worth copying: write it down, follow it, and note when you did not.

The six sections of a good SOP

1. Purpose: one or two sentences on what the procedure achieves and why it exists. If you cannot write this, you do not yet agree on what the job is.
2. Scope: when the procedure applies, and just as important, when it does not. The exclusions stop people from forcing an unusual case through the standard steps.
3. Roles: who does each part, named by role rather than by person, plus who approves and who to ask when something does not fit. Include what a person needs to know before starting.
4. Steps: numbered, in order, one action per step, written as commands. Put warnings on the step they apply to, not in a paragraph at the top.
5. Checks: how the person doing the work, or the next person, knows it was done right. A checklist, a number that must match, a second pair of eyes at a named step.
6. Records: what the procedure leaves behind, where it is kept and for how long. A record is how anyone can tell later that the procedure was actually followed.

Above those six sections goes a header block: title, owner, version, the date it was approved and the date it will next be reviewed. The EPA guidance lists much the same elements for administrative SOPs, including purpose, scope, responsibilities, the procedure itself, criteria and checklists, and records management, so this is not a house invention.

How to write an SOP in five steps

1. Watch it being done. Ask the person who does the job best to do it once while you write down every action, including the ones they do without thinking.
2. Draft the steps as commands. “Check the order total against the payment,” not “the order total should be checked.” Use active voice and present tense, one action per line.
3. Cut. Anything that is background, history or opinion goes into a short note at the end, or out. An SOP is read while working, often in a hurry.
4. Test it on someone else. Give the draft to a person who has not done the job, and watch them follow it without help. Every question they ask marks a missing step.
5. Approve it and publish it where the work happens. An SOP in a folder nobody opens is not an SOP.

For wording, the federal government’s plain language guidance on digital.gov↗ (opens in a new tab) is a good standard: write for the specific reader, then test whether that reader actually understands it. For an SOP, the reader is the least experienced person who will ever follow it.

An SOP template you can copy

# SOP: [Name of the procedure]

Owner: [role]          Version: [1.0]
Approved: [Month day, year] by [name]
Next review: [Month day, year]

## 1. Purpose
[What this procedure achieves, and why it exists. One or two sentences.]

## 2. Scope
Applies to: [the cases this covers]
Does not apply to: [the cases it does not, and where they go instead]

## 3. Roles
- [Role]: [what they do in this procedure]
- [Role]: approves [what], when [condition]
- Ask [role] when a case does not fit these steps.
Before you start: [training, access or knowledge needed]

## 4. Steps
1. [Command. One action.]
2. [Command. One action.]
   Warning: [what goes wrong here, and what to do instead]
3. [Command. One action.]

## 5. Checks
- [ ] [What must be true before the work counts as done]
- [ ] [Who checks, at which step]

## 6. Records
- [What is recorded, where, and for how long]
- If you did not follow a step, record which step and why.

## Change history
- [version] [Month day, year] [what changed, who approved it]

A filled example: handling a refund request

An invented small online store, so the example can show each section doing its job.

# SOP: Handling a refund request

Owner: Support lead     Version: 1.2
Approved: September 8, 2026 by the store owner
Next review: March 8, 2027

## 1. Purpose
Refund customers who are owed one within two business days, the same way
every time, without refunding anyone twice.

## 2. Scope
Applies to: refund requests by email or the contact form for orders
placed in the last 60 days.
Does not apply to: chargebacks from the card issuer (see the Chargeback
SOP) or orders older than 60 days (send to the store owner).

## 3. Roles
- Support person: checks the request and prepares the refund.
- Store owner: approves any refund above the approval limit.
Before you start: access to the order system and the payment dashboard.

## 4. Steps
1. Find the order by the customer's email address.
2. Check the order has not already been refunded.
   Warning: a partial refund still counts. Read the payment history.
3. Confirm the reason is one the refund policy covers.
4. If the amount is under the approval limit, issue the refund.
5. If it is over the limit, send it to the store owner and stop.
6. Reply to the customer with the amount and when to expect it.

## 5. Checks
- [ ] The refund amount matches the order line, not the order total,
      when only part of the order is refunded.
- [ ] The customer reply names the amount.

## 6. Records
- Note the refund and the reason on the order. Kept for seven years.
- If a step was skipped, say which and why in the same note.

Keeping an SOP current

An SOP goes stale the moment the process changes and nobody edits the document. The EPA guidance says SOPs should be updated and re-approved whenever procedures change, and reviewed on a periodic basis, for example every one to two years, and withdrawn when the process they describe is no longer followed. For a small team, three habits cover it:

• Every SOP has one owner and a next-review date in its header. When the date passes, reviewing it is a task like any other, with the owner’s name on it.
• Every deviation is a signal. If people keep skipping step 4, either the step is wrong or the training is. Fix one of them rather than living with the gap.
• The change history is kept, not overwritten. When a customer asks why they were treated differently in March, the version in force in March is the answer.

The same procedure, written for an AI assistant

An AI assistant can follow an SOP, but a single long document is the wrong shape for it. Split the procedure into three kinds of text, because an assistant treats each kind differently:

• The lines that must always or never happen become rules. “Never issue a refund; prepare it for a person to approve” is a rule, not a step. Rules are short, absolute and read before any work starts.
• The numbered steps become a skill: a folder with a SKILL.md file that the assistant loads when the job comes up. Anthropic’s Claude Code skills documentation↗ (opens in a new tab) says to create a skill when you keep pasting the same instructions, checklist or multi-step procedure into chat, which is an SOP by another name. The folder layout and frontmatter are covered in how to create a Claude skill.
• The facts the procedure depends on, such as where the approval limit is written or which system holds order history, become context: notes the assistant reads, kept apart from the steps so they can change without a new version of the procedure.

Keep the human checks as explicit stop points in the skill: “If the amount is over the limit, prepare the refund, tell the person, and stop.” An assistant will not infer where your approvals are. The Roles section of your SOP already names them, so copy those lines across word for word.

Where fenbs fits

fenbs does not store documents, so the SOP itself lives in your docs or your repository. What fenbs holds is the part an AI assistant must never miss. On the Decisions and rules page, a rule is a decision that holds from now on, the person who made it is recorded as the decider, and every connected AI assistant reads the rules first, in full, before its AI context notes. Changing a rule means recording a new decision that supersedes it, so the old wording is kept, much like an SOP’s change history.

The upkeep is ordinary work on the board: “Review the refund SOP” is a task with a note saying what prompted it, a plan saying what will change, and a test status once someone has walked through the new version. Every change to the task is recorded with who made it.