Administrative Support
SOP Development for roofing contractors
Two people can follow the same written instructions perfectly and produce two different outcomes. Until that stops, the procedure is not finished.
What a finished procedure looks like
A procedure with one way through it. Every point where the previous version left room has been closed — either by settling the decision and writing the rule, or by naming the person the reader is to stop and ask, which is a legitimate answer and a very different thing from silence.
And the evidence that it works, which is not an opinion about the document. Two people have run it and produced the same thing, and it has been performed once by somebody new while help was still available. Until both of those have happened the procedure is a proposal.
Writing it down is the easy half
Most companies that set out to build procedures produce documents and stop, reasonably enough, because the document looks finished. It reads cleanly, the steps are in order, somebody who knows the work confirms it is accurate. Every visible signal says the job is done.
Two people then follow it, something different comes out of each, and the reason is almost never a step that was missing. It is a step that was present and underdetermined. “Confirm the order with the supplier” — by phone or by email, and does a voicemail count? “Check the measurements” — against what, and how close is close enough? “File the paperwork” — under the job or under the customer, which matters enormously the first time somebody has to find it. Each of those sentences is perfectly clear to a reader who already knows the answer, and each is a fork for a reader who does not.
So the real work is not writing. It is hunting for the forks, and the only reliable way to find them is to let somebody walk into one. That makes the process uncomfortably empirical: you cannot review your way to a procedure that holds, because reviewing is done by people carrying the missing information in their heads. You have to run it, watch the divergence, and close what caused it.
This is also why the finished thing is worth so much more than the document that preceded it. A description transfers understanding to somebody willing to interpret it. A procedure that has had its forks closed transfers the outcome — which is the only version that survives the week the person who wrote it is unreachable.
What makes one hold
Every branch resolves to a rule or to a person. Those are the only two acceptable endings for a decision point, and the second is not a failure — “if the supplier cannot confirm by Thursday, ring the operations lead” is a complete instruction. What is not acceptable is a branch that ends in the reader’s discretion without saying so, because that reads as guidance and behaves as a coin toss.
It has been performed by somebody who did not write it, once, while somebody who did was still available to ask. That single run finds more than any amount of review, and it finds it cheaply, at a moment when the answer is a question away rather than a crisis away.
It states what it does not cover. A procedure claiming to handle every case is either enormous or vague, and it will be vague. Naming the boundary — this covers the ordinary sequence, anything outside it goes to a named person — keeps the document short enough to actually be followed and honest about where its authority stops.
And it can be changed by the people who use it. A procedure that only its author may amend drifts out of date silently, because the people running the work adapt on the ground and stop telling anybody. What you end up with is a document that describes a way of working the company abandoned, and a new person following it faithfully into obsolescence.
The step this one follows
Procedure work is one desk inside Administrative Support, and the limits that govern the whole department are set out there rather than repeated here. Writing down what currently happens is the step before this one and has its own desk. The written programmes a contractor is genuinely required to hold belong to the safety programme, which this brand does not own or author.
What owners ask about making it repeatable
We already wrote our processes down. What is left to do?
Usually the hardest part. A written description tells a reader what normally happens; a procedure has to tell them what to do when it does not, and that means resolving every point where the current answer is somebody using their judgement. Those points are invisible in the text — they read as ordinary sentences — and they are exactly where two people following the same document will diverge.
How do you find the places where it still varies?
By having two people run it and comparing what came out, which sounds laborious and is much faster than analysis. Divergence is easy to observe and nearly impossible to predict; the step everybody expects to be ambiguous is usually fine because it looks ambiguous, and the one that breaks is a sentence nobody looked at twice because it seemed obvious.
Does this mean removing all judgement from the work?
No, and a procedure that tried would be unusable. It means putting judgement where it belongs. Some decisions genuinely require experience, and for those the right instruction is to stop and ask a named person rather than a paragraph pretending to encode expertise. What gets removed is accidental judgement — the places where somebody is deciding not because the decision needs them but because nobody ever settled it.
What happens when the procedure and reality disagree?
Reality wins and the document gets changed, and it matters that this is the stated rule rather than the tolerated exception. A procedure nobody may amend gets quietly abandoned, and the abandonment is invisible — everybody carries on, the document sits there looking authoritative, and a new person follows it into a way of working the company stopped using two years ago.
Which processes are worth this treatment?
The ones that will be performed by more than one person, or by a different person than today. A task the owner will always do personally does not benefit much from invariance; the ones that do are the recurring administrative sequences that quietly depend on one person’s habits — how a job gets from won to scheduled, how a supplier query gets resolved, how a completed job gets closed out and filed.
Can a procedure survive somebody leaving?
That is the test it exists to pass, and it is worth being honest that it passes it imperfectly. What transfers reliably is the sequence, the decisions somebody has already settled, and the named owner for anything unresolved. What does not transfer is accumulated familiarity with particular people and particular jobs. A good procedure makes the loss survivable and shorter rather than making it nil.
No authority sets the form of a procedure
A page here that argued from a published standard would link it. There is no standard governing this, and naming the gap is more honest than filling it with something adjacent. Same position as process-write-ups, one step further on: turning a described process into a repeatable one. No external body sets the form of a contractor's internal procedure.
What it is held to instead: A procedure works when the output does not change with the person performing it.
Where the regulated part of this subject lives: the safety programme, which the brand does not own — see /services/dispatching-operations/.
Have two people run the same procedure today
Compare what each of them produced. Whatever differs is a fork in the document that nobody could see by reading it.