Each of those is a decision made before the first sentence is written. Length is set by how much detail the reader needs at the moment they are reading. Accuracy is set by whether anybody mapped the process first. Usefulness is set by knowing who the reader is and what they already know. Improving the prose addresses none of the three, which is why rewriting a poor procedure usually produces a better-written document that is still ignored.
Do not start with the SOP
The single biggest determinant of whether a procedure gets used is what happened before it was written. An SOP written from a manager’s account of the work describes an intention. The people doing the job read it, notice it does not match their day, and carry on as before - and because the document now exists, the organization believes the problem is solved.
So the order is: map the current state from the people who perform it, identify the gaps, establish what each role must be able to do, and only then write. Documentation is the fourth stage of five, and the sequence matters more than anything in this article.
Write to a defined need, not to be complete
Without an established need, the writer decides the scope, and writers include everything they know because leaving something out feels risky. That is how you end up with a procedure covering the whole system when the role touches four screens.
Before writing, split the content three ways. What must the person know from memory. What must they be able to find in under a minute. What do they never need to see. The third category is usually the largest and it is the one that makes procedures unusable when it is not removed.
The shape of a usable procedure
Purpose, in one sentence
What this procedure lets you accomplish. If it takes a paragraph, the scope is wrong.
When it applies, and when it does not
The second half is the one people skip and the one that prevents misuse.
Who owns it
A role. An unowned procedure goes stale immediately and nobody notices.
Inputs
What you need in hand before you start, including access and approvals.
The steps
Numbered, one action each, in the imperative. “Check the credit limit in Business Central.” Not “the credit limit should be verified.”
What good looks like
How the person knows they did it correctly, stated concretely.
What to do when it goes wrong
The escalation path, named. Most procedures assume everything works, which is why people abandon them at the first exception.
How long is too long
Short enough that somebody under time pressure will open it. For most tasks that means the answer is findable in under a page.
We have inherited procedures running to eighteen pages that were technically complete and practically useless, because nobody stops to read eighteen pages to settle one question. Length is not thoroughness. A procedure nobody opens documents nothing.
If a task genuinely needs more, split it: a short procedure for the common path and separate reference material for the exceptions. The common path is what people use daily.
Write in their vocabulary
Use the words your people already use, including the informal names for things. If everyone calls it “the Tuesday file”, the procedure says the Tuesday file, with the formal name in brackets once. Translating the work into consulting language guarantees that the document reads as something imposed from outside, which is most of the way to being ignored.
Consistency across documents beats polish within one
Same structure, same section order, same voice in every procedure you produce. The payoff is that familiarity with one transfers to all of them - someone who has used two of your SOPs knows where to look in the thirtieth. That is worth more than any individual document being beautifully written.
Decide the convention once, write it down, and apply it mechanically.
Plan for the second version before you write the first
Every procedure describes something that will change. Before you publish, settle four things: who owns updates, what triggers a review, how a version is identified, and where the current one lives. Without that, the second revision quietly contradicts the first and the whole set becomes untrustworthy within a year.
And keep it where people work. A procedure in a folder nobody opens is a procedure that does not exist.
The test
Not whether the document is complete. Whether a new hire in week two can find the answer to a real question without asking a colleague, and whether the answer they find is correct.
That standard is unforgiving in a useful way. It cannot be met by a procedure written from an assumption, or one so long that nobody opens it, or one describing a process that changed eighteen months ago.
Do your procedures pass the week-two test?
If a new hire still has to ask a colleague, the documentation is not the problem the way most people think it is.