Write operating procedures people can use

Choose a narrow process and a clear result

Use a task such as approving a supplier invoice, onboarding a customer, or completing the monthly close. Name the starting trigger, inputs, responsible role, and expected output. Define what finished means. A procedure titled administration is too broad to test. A procedure titled approve an invoice before payment can specify the documents, authorization, and evidence required at the end.

Capture the normal path and the exceptions

Write steps in the order the work occurs. Add decision points, required approvals, and links to the actual templates or systems. Explain when to stop and escalate, such as when banking details change or a purchase lacks approval. Avoid embedding passwords or unnecessary customer data. Use screenshots only where they clarify a step and assign someone to update them when the interface changes.

Test with the next person doing the work

Ask someone unfamiliar with the process to follow the draft using a realistic example. Note where they hesitate, improvise, or need missing information. Revise the procedure, then publish a dated version with an owner and review date. Measure errors or rework after adoption. A process that no one uses should be simplified or redesigned rather than expanded into a longer document.

• State the trigger, owner, inputs, and expected result.
• Include approvals and the conditions that require escalation.
• Test the instructions on an actual or safely simulated task.
• Retire outdated copies so people use one current version.