SOP format
There is no official SOP format, but there is a functional one: a reader has to know when the procedure applies, who does what, in what order, and what to do at each point where the path forks. Here are the ten parts that produce that, in a builder that writes them the way Sendabrief itself does, and gives you the result as a PDF or Word document.
Build your SOP
The same fields, step types, and layout Sendabrief itself uses, so what you build here is what a finished SOP looks like. Fill the left side, watch it take shape on the right, take it away as PDF or Word.
- Title
- Description
- Trigger
- Roles
- Numbered steps
- Step timing
- Decision branches
- Step detail
- Definitions
- Review date and owner
Specific, and naming the department where it helps. “Finance procedures” is a folder, not a title.
One sentence: what this process is and who it is for. Exceptions and thresholds belong on the step they affect, not here.
The specific event and actor that start this. Format: “When [actor] [action] [object]”.
Comma separated. Job functions, not people's names, so the document survives someone changing team. Steps start with one of these, and they are bolded wherever they appear in step detail.
Answers. Every answer names where it leads, including back to an earlier step for a rework loop.
Answers. Every answer names where it leads, including back to an earlier step for a rework loop.
The same review cadences the app schedules against. An SOP that is quietly wrong is worse than none, because people follow it.
Preview
Supplier Invoice Approval, Finance
How Accounts Payable checks a supplier invoice and gets it approved before payment.
Trigger
When a supplier invoice arrives in the accounts payable inbox.
Steps (5)
Accounts Payable records the invoice in the finance system with supplier, date, amount, and invoice number Same business day
Log it before assessing it. An unlogged invoice under review can be paid twice or not at all.Do the invoice, the purchase order, and the goods receipt match?
They matchThere is a discrepancyBudget Owner reviews and approves the invoice in the finance system Within 2 business days
Approval is recorded in the system, not given verbally or in a chat message.Has the supplier corrected the invoice?
Never pay from bank details supplied in an email. Verify any change to a PO or to payment details by phoning a number you already hold.Yes, a corrected invoice arrivedNo, the invoice was withdrawnEnds procedureInvoice approved and scheduled for payment · End
Roles
Definitions
- PO
- Purchase Order
Owner and review
Owned by the Financial Controller, reviewed quarterly.
The ten parts the builder writes, and what each is for
Title
What the procedure is, specific enough to distinguish it from adjacent ones, and naming the department where that helps.
People find procedures by scanning titles. A vague title means the document is not found, or the wrong one is opened.
ExampleSupplier Invoice Approval, Finance
Common mistakeNaming a department instead of a process. "Finance procedures" is not a title, it is a folder.
Description
One sentence saying what the process is and who it is for.
It is the only whole-process summary in the document. Someone deciding whether to read on gets their answer here rather than by skimming twenty steps.
ExampleHow Accounts Payable checks a supplier invoice and gets it approved before payment.
Common mistakeTurning it into a paragraph of exceptions and thresholds. Those belong on the step they affect, where they are visible at the moment they matter.
Trigger
The specific event that starts the procedure, and the actor who notices it.
A reader needs to know whether this document applies to the situation in front of them right now. A title alone rarely tells them.
ExampleWhen a supplier invoice arrives in the accounts payable inbox.
Common mistakeStating a topic rather than an event. "Invoice processing" does not tell anyone when to start.
Roles
The job functions involved, named as functions rather than as people.
Names go stale the moment someone changes team. Functions survive reorganisations, and they are what each step is addressed to.
ExampleAccounts Payable, Budget Owner, Financial Controller
Common mistakeUsing individuals' names, or omitting roles entirely so every step is addressed to an implied "you".
Numbered steps
One action per step, in order, each starting with the role that performs it. Three kinds: an ordinary step, a decision where the path forks, and an ending that states the outcome.
Numbering lets someone say "I am stuck on step 4", which is far more useful than "somewhere in the middle". Subject-first removes the ambiguity about whose job it is, and an explicit ending tells a reader they are finished rather than leaving them wondering what comes next.
Example4. Accounts Payable checks the invoice against the purchase order and the goods receipt.
Common mistakeCompound steps. "Create the folder and share it with the team" is two steps, and it will get half done. A close second is a procedure that simply stops, with no step saying it is over.
Step timing
The deadline or window that applies to one specific step, where the process has one.
A timing expectation is only enforceable if it sits on the step it governs. "Turn invoices around in five days" written at the top tells nobody which step is running late.
ExampleWithin 2 business days
Common mistakeInventing a deadline that nobody agreed to. If no timing was ever stated for a step, leave it blank rather than making one up that people will be judged against.
Decision branches
At each point where the answer changes the path, the question, each answer, and the step that answer leads to. An answer may end the procedure, or point back at an earlier step for a rework loop.
This is the part almost every template omits, and the part that decides whether the document survives real use. A linear list that assumes the happy path stops being followable exactly where the reader needed help.
ExampleDo the invoice, the purchase order, and the goods receipt match? They match, go to step 3. There is a discrepancy, go to step 4.
Common mistakeDescribing the check but not the consequence, so the reader knows to look but not what to do with either answer. The other half of the mistake is inventing a fake ending for a rejection, when the answer should point back at the step being redone.
Step detail
Exceptions, thresholds, and known failure modes, attached to the step they affect.
Nobody reads a general notes section at the bottom while executing step 3.
ExampleNever pay from bank details supplied in an email. Verify any change by phoning a number you already hold.
Common mistakeCollecting every caveat in a notes block at the end, where it is invisible at the moment it matters.
Definitions
The acronyms used in the document, expanded. Nothing else.
The person most likely to be following this is the person who has not done it before, and they are the one who does not know what PO stands for.
ExamplePO: Purchase Order
Common mistakeWriting explanations instead of expansions. "PO: the document purchasing raises to commit spend" is a paragraph about procurement, not a definition of two letters.
Review date and owner
When this gets re-checked, and who is accountable for it.
Every procedure has a shelf life. An SOP that is quietly wrong is worse than none, because people follow it.
ExampleOwned by the Financial Controller, reviewed quarterly.
Common mistakeLeaving it blank, which turns going stale from a visible event into a discovery made by someone doing the wrong thing confidently.
Questions about SOP format
Is there an official SOP format?
No. There is no single standard that dictates SOP layout, and anyone claiming an official format is describing a convention. What is genuinely required is functional: a reader has to know when the procedure applies, who does what, in what order, and what to do at each point where the path forks. ISO 9001 requires documented information to be controlled, identifiable, and approved, but it does not prescribe a layout.
What format should an SOP be written in, Word or Excel?
Word or an equivalent document format suits procedures, because steps have detail and branches that a spreadsheet cell handles badly. Excel suits checklists where the point is ticking off repeated instances. If you find yourself needing merged cells to fit the text, you wanted a document.
How long should an SOP be?
As long as the process, and no longer. If it runs past roughly 15 steps, check whether it is actually two procedures joined at a handoff, which is usually the case. Splitting them and linking is better than one document nobody finishes.
Do I need every one of the ten parts?
The title, trigger, roles, and numbered steps are not optional; without any one of them the document is not followable, and the steps need an explicit ending so a reader knows they are done. Step timing, decision branches, step detail, and definitions apply where the process has them, and most real processes have all four. The description is one sentence of orientation, and the owner and review date are what stop the whole thing silently going stale.
Should an SOP include screenshots?
For anything performed on a screen, yes, and they are the difference between a procedure people follow and one they skim. The cost is maintenance: screenshots go stale when interfaces change, so they are worth it for stable tools and a liability for ones that change monthly.
Faster than filling in a form
This builder is manual entry, which is the right tool when you already know what the procedure says. If you do not, it is quicker to click through the process once in your browser, or describe it out loud for two minutes, and have the steps written for you. That works with no account either.