Most procedures were written to satisfy an audit, not to be followed. That is why they sit in a folder, and it is also why nothing you install on top of them behaves the way you expected.
Quick answer
A procedure written for a filing cabinet describes what happens. One that can actually be used states who starts it, what goes in, what decides each branch and what finished looks like.
The decisions are the part people leave out, and they are the part that matters most.
Write the one you explain out loud most often. That is where the cost is.
A procedure with no owner and no review date is a snapshot of a business that has since changed.
Ask an established owner whether the business has procedures and the answer is usually a qualified yes. There is a folder. Somebody wrote most of it two years ago. Parts of it are still true.
Then watch what actually happens when a job comes in. Someone checks with the owner. Someone remembers that the written version was replaced by a better way of doing it last spring. Someone does it slightly differently because the customer is a bit awkward and the document never mentioned that case. The procedure exists and the business does not run on it.
That gap is tolerable while everything is done by people who know the business. It stops being tolerable the moment you try to install anything on top of it.
Most Procedures Are Written for the Wrong Reader
Open a typical one and it reads like a description. The team ensures that enquiries are responded to promptly and professionally.
That sentence survives an audit and tells nobody what to do. How promptly. Which enquiries. Responded to by whom, from where, and what happens when the answer is not known. A new starter reading it still needs somebody to sit with them, which means the document saved nothing.
The test is simple and uncomfortable. Hand it to somebody capable who has never done the task, leave the building, and see what they produce. Every question they would have asked you is a gap in the document.
What Changes When a System Reads It
A person fills gaps without noticing. They know the usual customer, they know which rule bends, they know who to ask.
A system has none of that. It does exactly what the words allow, which means every vague instruction turns into either a wrong action or a stop. The point is not that the system is fragile. It is that the document was always incomplete and people were quietly paying the difference.
This is why writing procedures properly pays back twice. The business gets a real training document, and the work you install afterwards has something solid to stand on. One of them is useful on its own. Both together is why it is worth the afternoon.
The Five Things Every Procedure Has to State
Not a format, a checklist. If any of these is missing, the procedure is not finished.
The trigger. What starts this, specifically. An enquiry arriving, a date, a stage changing, somebody asking.
The inputs. What you need in front of you before you begin, and where each one comes from.
The steps. In order, in plain language, short enough that each one is a single action.
The decision rules. What happens when the answer is yes, when it is no and when it is unclear.
What finished looks like. The condition that makes this done, not the last step in the list. Those are different things, and the second one is what people check.
The Decisions Are the Part People Leave Out
Nearly every incomplete procedure is missing the same thing. The steps are there. The branching is not.
A quote goes out. What happens if there is no reply. After how long, how many times, and at what point do you stop. A customer asks for something slightly outside the service. Who can say yes, and up to what value. A job runs over. Who tells the customer, and what are they allowed to offer.
Those rules exist. They live in one or two people's judgement, and they are the real reason the business cannot hand anything over. Writing them down is uncomfortable, because you have to make decisions you have been making case by case, and some of them you will get wrong the first time. Write them anyway and correct them. A written rule that is wrong gets fixed in a minute. An unwritten one gets rediscovered by every new person.
Where This Knowledge Is Supposed to Live
Written procedures on their own still scatter. One in a shared drive, one in somebody's email, two in a folder nobody opens.
What the Business Intelligence Agent from Strategic Marketer holds is that material in one place: brand identity and voice, the products and services actually sold, the customers and the positioning, and a single source of truth for approved facts. Procedures belong beside those, because a procedure that references the wrong price or an offer you retired does damage faster than having none. Once this is in one place, everything installed afterwards reads from the same account of the business instead of from whatever was pasted into it that morning.
If writing it down is the step that keeps getting postponed, that is the conversation worth having first: https://strategicmarketer.com/#contact
None of this is glamorous. It is also the whole difference between a business that can delegate and one where every question returns to the same desk, and it is the groundwork that what has to be true before it works sets out in more detail.
Start With the One You Explain Most Often
Do not start with a project to document everything. That project has been started before in most businesses and finished in none of them.
Start with the procedure you explain out loud most often, because the cost of it being unwritten is already being paid every week. Write it while you are explaining it to somebody for the next time, which is the fastest way to get the real version rather than the tidy one.
Then do the second most common one. Four or five procedures usually cover most of the repeated explaining in a small business, and that is a far better place to stop than a complete manual nobody maintains.
Who Owns It and When It Gets Reviewed
A procedure without a name on it decays quietly, and the first anybody hears about it is when something goes wrong twice.
Give each one an owner, which means the person who changes it when the work changes, not the person who does the task. Give it a date it was last correct. Review anything containing a price, a timescale or a promise to a customer more often than the rest, because those are the ones that cause harm when they go stale.
That is the whole maintenance system. It takes less effort than the version where nobody owns anything and everyone works from memory.
The Gap Is Between Interest and Implementation
Most owners reading this are not unconvinced. They are stuck between knowing the business should be written down and having anything written down, and the blocker is almost never the writing itself.
It is knowing which procedures matter first, what has to be stated in each one, and who holds it afterwards. Those are business questions, and they are answerable in one conversation with somebody who looks at how the work actually runs before recommending anything. Starting from the approach rather than from a template is what makes the difference between a folder and a business that runs on what is in it.
Schedule Your AI Business Assessment →
One conversation. A clear diagnosis of what is holding AI back in the business, the two or three places it would pay for itself first, and a prioritised roadmap you keep either way. No pressure and no obligation, and if it is not a fit, they say so.
Questions Owners Ask About Standard Operating Procedures
How long should one be?
One page for most tasks. If it runs to four, it is probably three procedures that were written as one, and splitting them will make each easier to follow and to maintain.
Does the format matter?
Far less than the five things being present. A document, a checklist or a form all work. What does not work is prose that describes the activity without stating the trigger, the decisions and the finished condition.
Who should write them?
The person who does the task, reviewed by the person who owns the outcome. Procedures written by somebody who has never done the work describe an idealised version that everybody quietly ignores.
What about the exceptions?
Name the common ones and state the rule. For genuinely rare cases, write who decides rather than pretending to cover them. An escalation rule is a legitimate step, and it is far better than silence.
How often do they need reviewing?
Anything with a price, a timescale or a customer promise in it, at least twice a year. The rest when the work changes. The review date matters more than the frequency, because a document with no date carries no warning.
Is this worth doing before buying any software?
Yes, and it reduces what you need to buy. Half the problems people expect software to solve are decisions nobody has made, and software installed on top of an undecided process produces faster confusion rather than less of it.