Standard Operating Procedure Template: Write SOPs People Use

What an SOP is for

A standard operating procedure, or SOP, is a short written description of how one recurring job is done, so that anyone trained can do it the same way, and a standard operating procedure template keeps every SOP in the same shape.

SOPs earn their keep in three moments. When someone new joins and needs to learn the job. When the usual person is away and someone else has to cover. And when something goes wrong and the team needs to see which step was missed. In each case, a page that says exactly what happens beats a colleague trying to remember.

Most SOPs fail for the same reasons. They are written once from memory, they describe the ideal case instead of the real one, and they are too long to follow with the work open on the other screen. A good template fixes the first two by forcing the right questions and the third by keeping each procedure to one job.

SOPs are one part of process documentation, the wider habit of writing down how a business works. Business process mapping draws the big picture: which jobs exist, who hands what to whom. An SOP zooms into one box on that map and says how the job inside it is actually done.

The five-part template

Every SOP needs five parts: purpose, start, steps, checks and filing; anything more is optional.

The template below works for almost any office job, from entering supplier bills to sending a monthly statement. Keep each part short. If a part grows longer than the rest of the page, the job is probably two jobs and deserves two SOPs.

Using the same standard operating procedure template for every job has a benefit beyond tidiness. A reader who has learned one SOP knows where to look in all the others: the start is always second, the approvals always fourth. Over time, the set of procedures reads like one manual instead of a pile of notes written by different people in different moods.

Add a header line above the five parts with the procedure's name, its owner and the date it was last checked. That last date matters more than people expect; it tells a reader whether to trust the page.

Writing steps people follow

Steps people follow are numbered, start with a verb, name who does each one and fit on one screen.

Write each step as an instruction, not a description. Say: open the bill and check the supplier name against the supplier list. Do not say: the supplier is usually verified. The first can be done; the second can be argued about.

Name the person or role on any step that changes hands. Most errors in a process happen at handovers, when one person assumes the other has done something. If a step says who, nobody has to assume.

Here is a short example, written the way an SOP should read, for a small team handling incoming supplier bills.

Notice what the example leaves out. It does not explain how to use the accounting system or why bills matter; that belongs in training, not in the procedure. Each step is one action a person can tick off, and the last step hands the work to someone who signs.

1. Accounts assistant: open each new bill in the accounts mailbox at the start of the morning.
2. Accounts assistant: check the supplier is on the supplier list; if not, pass the bill to the finance lead and stop.
3. Accounts assistant: check the invoice number has not been entered before for that supplier.
4. Accounts assistant: enter the bill as a draft in the accounting system and attach the PDF.
5. Accounts assistant: save the PDF in the supplier's folder, named by date and invoice number.
6. Finance lead: review the drafts and approve the ones that are correct.

Adding checks and approvals

Put checks where mistakes are expensive and approvals where something leaves the company or money moves.

Not every step needs a check. Too many and people tick boxes without looking. Pick the points where an error costs real money or real trust: a payment, a new supplier record, an email to a customer, a figure that goes into a tax return. Those deserve a named check and, where it matters, a named person who approves.

Write the check as something a person can verify in seconds. Totals add up. The bank details match the supplier file. The customer's name is spelled as on the contract. A check that needs a judgement call is fine, but say whose judgement it is.

It also helps to write down what the procedure does not cover. A short list of exclusions stops people stretching an SOP to cases it was never written for.

• What happens when the case does not fit the steps, and who decides.
• Which documents must never be entered without a second person's look, such as refunds.
• Which changes need the owner's approval, such as a new supplier or new bank details.
• Where to record that the check was done.

Writing SOPs from real emails and files

The most accurate SOPs are written from the evidence of the work, the emails, attachments and folders, rather than from someone's account of it.

Ask anyone to describe their job and they will give you the version they think they do. The mailbox tells you the version they actually do: which suppliers write in, which customers chase, which reports go out at month end, which colleague is copied on what. The folders show where things really get filed, not where they were meant to be.

This matters most when someone is leaving. An employee handover document written in a rush, in the last week, tends to list the obvious tasks and miss the quarterly one, the yearly renewal and the favor done for a particular client. Those gaps only surface after the person has gone.

This is where an AI employee can help, and it is one we run today. When a key person is leaving, our handover robot reads their mailbox history and attachments read-only and writes what the role actually did, what is still open, the deadlines and a handover plan, before the last day. It changes nothing in the mailbox and sends nothing.

That write-up is not an SOP on its own. It is the raw material: a factual list of the jobs the role carried out, with examples. A person then picks the recurring jobs and writes each one into the five-part template, checking the steps with whoever will take them over.

Keeping SOPs current

An SOP stays useful only if someone owns it, checks it on a fixed rhythm and changes it whenever the job changes.

Procedures go stale quietly. A supplier moves to a portal, a new approval is added, a folder is renamed, and the SOP still describes last year's job. The fix is simple and dull: one owner per procedure, a review date on the header, and a habit of updating the page the same day the process changes.

A practical rhythm is to review each procedure after any change to the job and, at the latest, once a year. When you review, do not just reread the page. Watch someone do the job with the SOP open, or compare it with the last few real cases in the mailbox, and fix every step that no longer matches. If you update the standard operating procedure template itself, roll the change through all your procedures at the next review rather than all at once.

Keep all SOPs in one place your team already uses, such as a shared folder, with the same naming pattern for each. A procedure nobody can find is the same as no procedure.

Finally, know the limits of the document. An SOP describes how the job is done; it does not do the job. If a procedure is followed the same way, many times a month, and ends in a document or an entry, it may also be a good candidate for an AI employee that drafts the work for a person to check. The SOP then becomes its job description.

Questions