A procedure nobody reads is wasted time. The format that works for a team of three, what belongs in it, and how procedures stay current without a project.
Key takeaways
- A procedure that cannot be read in a minute will not be read at all.
- Write it while performing the task, not afterwards from memory.
- What must be included are the exceptions, not only the happy path.
- Every procedure needs a date and an owner, or nobody knows whether it is current.
A procedure in a small business is not an eight-page document but one page you can open mid-task. The only test that matters: can somebody who has never done the task complete it from what is written, without asking.
The format that works
| Section | What you write | How much |
|---|---|---|
| When to use this | The exact trigger | One line |
| What you need first | Access, files, information | 3-5 lines |
| The steps | One action per line, in the imperative | 5-10 lines |
| What comes out | How you know you are done | One line |
| What to do when something is unusual | The cases that actually happen | 3-5 lines |
| Who to ask | A name | One line |
The fifth row is the difference between a procedure in use and wall decoration. Most of a new employee's time goes precisely on the cases that are not the happy path, and those are exactly what procedures tend to omit.
Writing it without spending a day
Write while performing, not afterwards. Whoever does the task opens a document and records one line per action as they do it. That adds about ten minutes to the task and produces a real procedure, whereas writing from memory two days later produces an abbreviated and slightly wrong version.
A second method that works: record a voice explanation while somebody teaches somebody else, and transcribe it. Both preserve the real order of actions - including the steps "everyone knows" that are exactly what trip up a new employee.
What does not belong
- Explanations of why - one line is enough, not a paragraph.
- History of how it used to be.
- Steps tied to a system that will change in six months, described button by button.
- Policy - what is permitted and forbidden is a different document.
- Many screenshots - they date quickly and make the document heavy.
The last is debatable, so use a simple rule: one screenshot for a screen that is hard to find, not one per click. A procedure with twenty screenshots is out of date six months after it was written, and then nobody trusts it.
Where to keep them
In one place everybody knows, that two or three people can edit. A shared folder is entirely sufficient; what does not work is procedures scattered across emails, files on somebody's computer, and a WhatsApp group.
It is also worth naming each one starting with the action - "how to open a new order" rather than "orders procedure" - because that is how people find it in search. That logic is the same as in an internal knowledge base for a small team, and it is the point where individual procedures become a knowledge base.
How they stay current
The real problem is not writing but maintenance. Three simple mechanisms keep procedures alive:
- A date and an owner at the top - who wrote it and when.
- An update rule - whoever finds the procedure is wrong fixes it there and then rather than reporting it.
- A half-yearly review - go through the list and delete what is no longer relevant.
The second is critical. When updating requires approval, procedures go stale; when anyone can fix a line, they stay close to reality. The risk of somebody making it worse is smaller than the risk of the document becoming irrelevant.
When a procedure is worth writing at all
Not for every task. Three tests: the task recurs at least monthly; more than one person performs it or will; and an error in it costs something - time, money, or a customer. When all three hold, a procedure repays itself quickly.
When only one holds, it is usually better to skip it. A task one person performs annually will be relearned anyway, and writing a procedure for it is work that goes stale before it is used. The prioritisation logic is in how to improve business efficiency.
How to test the procedure
With one check: give it to someone who has never done the task and watch them try - without helping. Every place they stop and ask is a missing line. Five minutes of silent observation is worth more than any proofreading.
What that test reveals almost every time: unwritten assumptions. "Log into the system" assumes permission exists; "send it to the customer" assumes you know which address; "get it approved" assumes it is obvious who approves. Those three assumptions are exactly what makes a procedure useful once they are added.
Where do procedures help most?
In three situations every business has. Onboarding a new employee - there they save the fortnight an experienced person spends not working in order to supervise. Leave or illness - a procedure is the difference between "we'll wait until they're back" and carrying on. And a task performed rarely - year-end closing, a quarterly report, a subscription renewal - where even long-serving staff do not remember.
The third is often the most valuable, because it saves the repeated search. A task performed quarterly is relearned every time, and half an hour of writing the first time saves an hour on every occasion after.
What to do with knowledge held by one person
This is the most dangerous situation in a small business, and it is usually not deliberate: a long-serving person knows how things work and nobody ever asked them to write it down. When they take extended leave or resign, the business discovers all at once how much knowledge existed nowhere.
The practical way to address it is not asking them to write everything - a task nobody ever finishes. Instead, pick three tasks only they perform, and write those with them while they work, across three weeks. That is a sustainable pace, and it covers most of the risk within a month.
Sources
Frequently asked questions
How many procedures does a small business need?
Fewer than expected - usually five to ten covering what recurs: opening an order, handling an enquiry, a return, collections, onboarding an employee. Five that exist and are current beat twenty written once and never opened.
What language should they be in?
The language the team works in, in short imperative sentences. What matters is matching the names used in the system - if the screen is called "Orders", do not write "Sales", because a new employee will look for exactly what is written.
Who should write them?
Whoever performs the task, not a manager. A manager writing a procedure describes the process as they intend it; the performer describes it as it is. If the manager wants to change something, that is a separate decision made after the current state is documented.
What do you do when nobody reads them?
Check three things: whether they are easy to find, whether they are short enough, and whether they are correct. In most cases the problem is one of the first two - a procedure three clicks away, or four pages long, will not be read however good it is.
Keep reading
Related service
MVP Development
Turn an idea into a validated product in weeks, not months.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build and I'll tell you the fastest reliable way to ship it.