How to write an SOP your team will use, with a free template
A usable SOP has a clear title and ten parts: purpose, scope, owner, trigger, inputs, a step table, exceptions, a definition of done, measures and revision history. The step table says who does each step, in what tool, and how they check it. The full template is below, ready to copy.
Below it: how to write one, and a worked bank reconciliation example. Then when to map the process before you write anything, and when to automate a step instead.
Serkan Honeine, Co-founder, CoSauce
Published · Last updated
The SOP template
Each row is a section of the document. The right-hand column says what to write in it. Keep the whole thing to one or two pages; if it runs longer, the task is probably two tasks.
| Section | What to write |
|---|---|
| Title and ID | A plain name that says what gets done, plus a short ID so people can find it. "Reconcile a client bank account in Xero (FIN-04)". |
| Purpose | Why the task exists, in a sentence or two, and what goes wrong for the business or the client if someone skips it. |
| Scope | What the SOP covers and what it doesn't. Name the clients, accounts, products or teams it applies to. |
| Owner | One named person. They keep the SOP current, and a role title is fine if only one person holds that role. |
| Trigger and timing | What starts the task (a date, a ticket, an email, a form) and how long it should take from trigger to done. |
| Inputs and access | Everything the person needs before step 1: files, logins, permissions, templates, the last period's output. |
| Steps | A numbered table with four columns: who, what, tool, check. One action per row. The step template is below. |
| Exceptions and escalation | The cases that don't fit the steps, what to do with each, who to ask, and how fast they should answer. |
| Definition of done | What the finished output looks like, where it's saved and who you tell when the work is ready. |
| Measures | Two or three numbers that tell you whether the SOP works, such as time per run, rework rate and missed deadlines. |
| Revision history | Version number, date, who changed it and what changed. Put the newest entry at the top so nobody has to scroll. |
The step table
This is the part people use every day, so it gets its own layout. The check column matters most. It tells the person how to know a step is right before they move on, which is where most errors get caught.
| Step | Who | What | Tool | Check |
|---|---|---|---|---|
| 1 | Role or name | One action, starting with a verb | The system, screen or file | How the person knows the step is right before moving on |
| 2 | ||||
| 3 |
Copy the template
Select both tables above, copy them, and paste them into a Google Doc, Word file or Notion page. They keep their rows and columns. Fill in one SOP per task, and keep them all in one shared folder.
How to write an SOP
Most SOPs fail because they're written from memory at a desk, by someone who no longer does the task. Write it from the work instead.
1. Watch the person who does it best
Sit with them, or share a screen, while they do the task for real. Write down every click and judgement call, including the ones they make without thinking. Ask "how did you know to do that?" whenever they pause.
2. Write every step, one action per row
Start each row with a verb. If a row has "and" in it, it's probably two rows. Put the check next to the step, so mistakes are caught where they happen and not at review.
3. Test it on someone new
Give the SOP to someone who has never done the task and say nothing. Every question they ask is a missing step, and every mistake they make is a missing check. Fix it and test again.
4. Version it and give it an owner
Save it in one place, give it a version number, and log each change. When a reviewer makes the same correction twice, the owner adds the missing step. An SOP nobody updates drifts away from the work.
Write for the newest person on the team. Name the screen and the button. "Check the balance" is a wish; "compare the closing balance in Xero with the bank statement" is a step.
A worked example of a bank reconciliation SOP
This is an illustrative example for a bookkeeping team, not a copy of any client's process. Your own coding rules and timings will differ. The SOP is FIN-04, Reconcile a client bank account in Xero.
Example header for FIN-04, version 1.2
| Section | Example |
|---|---|
| Purpose | Keep each client's bank balance in Xero equal to the bank statement, so BAS and management reports start from clean numbers. |
| Scope | Business transaction accounts and credit cards for bookkeeping clients. Excludes trust accounts and loan accounts, which have their own SOPs. |
| Owner | Bookkeeping team lead. |
| Trigger and timing | Every Monday for weekly clients, and by the 5th business day of the month for monthly clients. About 30 minutes per account when bank rules are set up. |
| Inputs and access | Named Xero login with access to the client file, the bank statement or bank portal export for the period, and the client's coding notes. |
Steps
| Step | Who | What | Tool | Check |
|---|---|---|---|---|
| 1 | Bookkeeper | Open the bank account and confirm the feed has imported up to the period end. | Xero, bank account screen | Last imported date is on or after the period end. If not, go to exceptions. |
| 2 | Bookkeeper | Accept matches suggested by bank rules, reading each one before you accept it. | Xero, reconcile tab | Payee and amount make sense for this client. |
| 3 | Bookkeeper | Code the remaining lines using the client's coding notes. | Xero, client coding notes | Every line has an account and the right GST code. |
| 4 | Bookkeeper | Add a bank rule for any payee that has now appeared three times. | Xero, bank rules | Rule tested on the next matching line. |
| 5 | Bookkeeper | Compare the closing balance in Xero with the bank statement. | Xero, bank statement | Balances agree to the cent. |
| 6 | Bookkeeper | Log the account as done and list any open questions. | Practice software job or tracker | Job status updated, questions sent to the reviewer. |
| 7 | Reviewer | Spot-check coded lines and clear the open questions. | Xero, tracker | Corrections noted against the step they belong to. |
Exceptions and escalation
- If the feed has stopped or is missing days, import the statement manually, note it in the tracker, and tell the reviewer the same day.
- If you can't code a line from the notes, leave it unreconciled, add it to the client questions list, and move on.
- If the balances don't agree after all lines are reconciled, stop. Don't force it. Send it to the reviewer with the difference and the date range.
Definition of done: every line for the period is reconciled, the Xero balance agrees with the statement, the job is marked done and open questions are with the reviewer. Measures: minutes per account, lines the reviewer recodes, and accounts finished after the deadline. Revision history: "1.2, added step 4 after the same payee was recoded on three clients."
If you're handing this kind of work to a new or offshore bookkeeper, the Xero onboarding guide covers access and the first four weeks.
When to map the process before you write the SOP
An SOP describes one person's task. Process mapping shows the whole flow: every step, every handoff between people or teams, and every workaround, with the time each one takes. Map first when:
- The work passes through more than one team or person before it's done.
- Two people doing the same task describe it differently.
- Things get stuck or lost at handoffs, and nobody can say where.
- You plan to automate or move the work, and need to know what's worth keeping.
A process map doesn't need special software. Sticky notes on a wall or boxes in a shared doc are enough. Put each step in order, note who does it and how long it takes, and mark each one keep, fix, automate or stop. Then cut the steps nobody needs: duplicate checks, approvals nobody reads, reports nobody opens. Write the SOP for what's left. Writing a careful SOP for a step you're about to delete is wasted effort.
This is how we start every engagement. We map where the time goes and cut the work nobody needs before we touch any technology. The how we work page sets out the order.
When to automate a step instead
Once a step is written down clearly, you can see whether a person needs to do it at all. Automate it when it runs the same way every time and the inputs arrive in a predictable format. The check should also be one you can write as a rule. Copying data between two systems, sending a standard reminder and matching a payment to an invoice are common examples.
Keep people on the steps that need judgement, and on the exceptions. Keep the automated step in the SOP too, with a check row that says who looks at its output and how often. Automating a broken process only makes the mess faster, which is why the map and the SOP come first. If you're weighing outside help for this, read what an AI automation agency does.
Questions
What is the difference between an SOP and a checklist?
A checklist is the list of steps. An SOP adds the context a new person needs around that list. It says why the task exists, who owns it and what starts it, plus what to do when something doesn't fit and what done looks like. Many teams keep the step table as a checklist and link it to the full SOP.
How detailed should an SOP be?
Detailed enough that someone new can do the task without asking anyone. Test it on a new person and you'll find out. If an experienced person finds it slow to read, keep the step table short and move background into the purpose and exceptions sections.
How often should you review an SOP?
Whenever the tool, the client or the rule behind it changes, and whenever a reviewer makes the same correction twice. A short look in a regular team review helps, such as the weekly review we run with offshore teams.
Next step
If you've got work that lives in one person's head, or a process you'd like to map before you hire or automate, book a call with me. Bring the task that takes the most hours. We'll tell you straight what we'd map first, and if we're not the right fit, I'll say so.