Document a Process at the Right Level of Detail

Why this matters

The two ways to ruin a written process are equal and opposite: too vague to follow, or so detailed nobody reads it. "Be professional on site" tells a new tech nothing. A forty-step novel for changing a filter insults an experienced one and gets ignored. The right level of detail depends on who is reading it and how often they will do it. Get this right and your documents actually get used instead of gathering dust.

The core principle: write for the least-experienced person who will follow it unsupervised

This is the rule that settles most arguments. Picture the greenest person who will do this task without you standing there. Write so that person can succeed. If only senior techs ever touch it, you can skip basics. If a first-week hire will do it alone, spell out what a veteran assumes.

When the audience is mixed, write the steps for the beginner and let the veteran skim. Skimming a clear document costs nothing. Guessing at a vague one costs a callback.

Match detail to frequency and stakes

The biggest mistake is forcing judgment work into a step list. Some tasks cannot be reduced to steps. Those need teaching, not an SOP (see the standard-vs-judgment article).

Test for "too vague"

A step is too vague if two reasonable people would do it differently. "Confirm the appointment" is vague: confirm how, when, saying what? "Call the customer the evening before, confirm the date and four-hour window, and ask if anything changed at the property" is followable. If a step contains a soft verb like handle, manage, deal with, or make sure, it usually needs to be made concrete.

Test for "too detailed"

A document is too detailed when it explains things the reader already knows, or breaks one obvious action into five micro-steps. "Pick up the phone. Press the green button. Hold it to your ear." is noise. If your reader would roll their eyes, cut it. Detail should land on the parts that go wrong, not the parts everyone gets right.

Use the right structure for the content

• Sequence matters and order is fixed: numbered steps.
• Items must all be checked but order is loose: a checklist with boxes.
• There is branching (if this, then that): a short decision tree or an if/then table.
• It is a standard to meet, not a sequence: a list of criteria ("a clean job looks like...").

Forcing a decision-heavy task into flat numbered steps is a common failure. If the work branches, show the branches.

Put the warnings where the danger is

Do not bury the one step that causes injury or expensive damage in the middle of a paragraph. Call it out:

• STOP before the irreversible step ("verify the circuit is dead before touching the conductor").
• WATCH OUT for the common mistake ("the two valves look identical; the cold side is on the right").
• VERIFY the result before moving on ("confirm no leak under pressure before closing the wall").

These three flags carry most of the real value in a high-stakes document.

Keep it maintainable

Detail you cannot maintain is worse than none, because it goes stale and people stop trusting the document. Two habits keep it alive:

• One owner per document. Someone is responsible for it being correct.
• A last-updated date on every file. Stale dates are a signal to recheck.

When the process changes, update the document the same day. A document that lies once loses the team's trust for good.

What to do this week

Take one process you have already written. Find the vaguest step and make it concrete enough that two people would do it the same way. Find the most over-detailed step and cut it. That single editing pass is what separates a document people follow from one they ignore.

References

• See related: Your First Operations Manual: What to Document First
• See related: Standard vs Judgment Call: When to Write a Rule
• See related: Checklist vs SOP vs Training: A Decision Matrix
• Trade-standard practice for technical work instructions and SOPs