Define the trigger and outcome
Describe what starts the process: an internal request, an incoming document or a recurring date. Then name the expected result. When beginning and end remain unclear, neighbouring tasks accumulate until the description loses its purpose.
State which cases it covers. A normal request process need not also explain every exception. Refer special cases to an appropriate contact or supplementary rule instead of hiding them in tiny text at the edge.
Show the few decisive steps
Write the steps in the order actually required. Each should identify an action and result. “Review” is too general; “check required information and request missing details” explains what happens. Name the role performing the step.
Where a decision changes the route, state its condition explicitly. A complete request may proceed to work while an incomplete one returns for clarification. Avoid unexplained arrows or abbreviations understood only by experienced participants.
Reference supporting tools
The process page need not reproduce forms and templates in full. Link authoritative documents and identify when they are used. Test access with someone from the intended audience. A reference to your private draft is of little help to the team.
Include only contacts needed for questions or exceptions. The description should not require extensive rewriting whenever staffing changes. Role names with a maintained contact reference may be more suitable than many personal names embedded in prose.
Check it against a real case
Ask someone to explain how they would handle a specific case using the page. Notice where extra spoken explanation is required and fill that particular gap. If the page becomes crowded, first consider whether the process was defined too broadly.
Identify who maintains it and show a recognisable version. After changes, old copies should not continue as equally valid instructions. The page helps only when the team knows it describes the current process and knows where to report corrections or a case that the page does not explain adequately.
Walk through a request
Take an internal materials order as an example. Its starting point is not simply “materials missing”, but a request containing the item, quantity and required timing. The next checks establish whether existing stock is sufficient and whether approval is needed. Completion is not merely sending an order; the requester also needs a traceable status.
This example reveals what the page must contain: entry route, minimum information, responsible role, ordering decision and completion marker. A full history of previous suppliers belongs elsewhere unless it changes how the current process is carried out. This keeps the description compact without removing necessary steps.
Make transitions particularly clear. “Pass to purchasing” does not say how or what outcome is expected. “Assign the checked request in the designated area and mark it for approval” describes an observable transition, provided those terms actually match the local workflow. Always use language that colleagues will encounter in their daily work.
Recognize the limits of one page
Complex exceptions do not have to fit in full on the same page. State what triggers a different route and identify the responsible person or supporting explanation. Do not hide an unresolved exception among ordinary steps. If nearly every case becomes an exception, reconsider the process boundary: several distinct workflows may have been combined incorrectly. A useful test is whether someone can recognize an ordinary case and complete it without repeatedly guessing which paragraph applies. When they cannot, changing the scope may help more than reducing the font size or adding another dense block of instructions.
Finally, let someone with little prior knowledge use the description. Observe where they ask a question without immediately supplying a spoken explanation. That point may be missing a definition, prerequisite or identifiable transition. Correct the page there and test the same step again so the improvement remains in the document.
