We know how to do it. Why do we need to write it down?
Maybe you don’t.
Not every recurring task needs a formal standard operating procedure. Document everything, and you can create a library nobody reads. Document nothing, and eventually you discover that an important business process existed primarily in someone’s head.
The question isn’t whether the process can be documented.
It’s what happens when it isn’t.
If inconsistency creates meaningful cost, customer impact, control problems, regulatory exposure, or operational risk, the process probably deserves more than tribal knowledge.
Start with what happens when the process goes wrong
The importance of an SOP isn’t determined by how often a process occurs.
Start with the consequence of failure.
If someone performs the process differently tomorrow, what happens?
Maybe nothing important. In that case, detailed documentation may be unnecessary.
But if the result can be a financial loss, customer problem, missed deadline, control failure, inaccurate report, compliance issue, or significant amount of rework, consistency matters.
The greater the consequence of getting the process wrong, the stronger the case for defining how it should be done.
If only one person knows how it works, you have a risk
Every organization has someone who knows how everything really works.
That’s useful until that person takes vacation, changes jobs, retires, or simply isn’t available when something breaks.
Ask a basic question:
Could another qualified employee perform this process correctly tomorrow using the information we’ve documented?
If the answer is no, the organization is dependent on a person rather than a process.
That doesn’t mean every piece of an employee’s knowledge belongs in an SOP.
It does mean critical processes should be able to survive the person currently performing them.
Documentation turns individual knowledge into organizational knowledge.
Repeated inconsistency is telling you something
If three people perform the same process three different ways, one of two things is happening.
Either the process allows legitimate judgment, or the expected process isn’t clear.
An SOP shouldn’t eliminate appropriate judgment.
It should define the parts that shouldn’t vary.
- What initiates the process?
- Who owns it?
- What information is required?
- What approvals are necessary?
- What controls have to occur?
- What gets documented?
- When should something be escalated?
If those answers change depending on who is working that day, inconsistency becomes part of the operating model.
That’s usually worth fixing.
Controls belong inside the process
A procedure shouldn’t describe the work and then treat controls as something separate.
If one employee initiates a payment and another must approve it, that belongs in the procedure.
If a reconciliation has to occur before something is considered complete, document it.
If an exception requires approval, define who can approve it.
If evidence has to be retained, say what evidence and where responsibility for retaining it sits.
Controls work best when they are part of the process people actually follow, not a separate document someone retrieves when an auditor asks.
A well-written SOP makes the control part of the work.
A system manual is not an SOP
This distinction matters.
Instructions that say: “Click this menu, select this field, and press Submit” may be useful training material.
They don’t necessarily explain the process.
An SOP should tell the reader what needs to happen, who is responsible, what conditions determine the next step, what approvals or controls apply, and what constitutes completion.
Systems change.
Screens change.
Vendors change.
The underlying business requirement often changes much less frequently.
If the entire procedure becomes obsolete because a button moved, it was probably documenting the software more than the process.
Exceptions are where weak procedures usually break
The easy transaction isn’t what exposes a weak process.
It’s the exception.
- What happens when required information is missing?
- What happens when something doesn’t reconcile?
- What happens when the customer requests something outside the standard process?
- Who can approve an exception?
- When does another department need to become involved?
- When should the employee stop and escalate rather than improvise?
An SOP doesn’t need to anticipate every situation that could ever occur.
But if the same exceptions repeatedly require employees to ask what to do, the procedure probably isn’t finished.
Growth can turn an informal process into an operational problem
A process that works with three employees may fail with thirty.
At a small scale, people can ask each other questions. Experienced employees notice when something looks wrong. Managers can personally review unusual situations.
As volume grows, those informal controls become less reliable.
New employees arrive faster. Work becomes specialized. Handoffs increase. Managers become further removed from individual transactions.
That’s often when organizations discover that the process everyone “knows” isn’t actually the same process across the organization.
Documentation should grow with operational complexity.
Not because larger organizations need more paperwork, but because informal communication stops scaling.
Don't write the SOP until you understand the process
Documenting a bad process makes it a documented bad process.
Before writing, understand what is actually happening.
Talk to the people performing the work.
Follow the handoffs.
Identify where decisions are made.
Look for duplicate work, unnecessary approvals, missing controls, workarounds, and steps that exist because “we’ve always done it that way.”
Then distinguish the current process from the process that should continue.
This is one of the reasons I don’t view SOP development as simply a writing exercise.
The document comes last.
Understanding the operation comes first.
A useful SOP should survive the person who wrote it
The test of an SOP isn’t whether it looks complete in a binder.
It’s whether the next qualified person can use it.
The procedure should clearly establish the purpose, responsibilities, process, decision points, controls, escalation requirements, and evidence that needs to be retained.
It should contain enough detail to create consistency without becoming so cumbersome that employees work around it.
And it should be maintained when the underlying process materially changes.
An SOP Development engagement can help identify the process as it actually operates, resolve gaps and inconsistencies, and turn it into documentation that employees, management, auditors, and successors can use.
The goal isn’t more documentation.
It’s less dependence on memory.