How to document a team process on one page

Start with tasks that happen several times a month or generate repeated questions: onboarding a teammate, publishing an update, preparing a delivery, or routing a request.

Do not document every rare exception first. Capture the normal flow, then add an exception only when it becomes frequent enough to matter.

Each step should begin with an action and end with something a reader can check. ‘Prepare the handoff’ is vague; ‘confirm the link opens and notify the client’ is testable.

Include examples, links or screenshots only when they remove a real uncertainty.

• When to use the process.
• What is needed before starting.
• Steps in order.
• What to do when something fails.
• Who keeps it current.

Ask someone who did not write the page to follow it. Every question reveals an implicit step. Update the document until the work can be completed without a separate call.

For a fictional client delivery, the trigger is approval of a particular version. Inputs are that file, a verified recipient and permission to share. Open the file, confirm the version, create the restricted link, test access as an appropriate recipient, then send it and record the version and date. Opening it as the owner does not prove the client can access it.

The exception path matters: if access fails, stop delivery and review permissions rather than making the file public. If the client requests another format, return to approval before replacing the deliverable. Ask a colleague to follow the instructions with a dummy file. Every question identifies a missing input or decision. A maintenance date should reflect a checked procedure, not an automatic timestamp added whenever the website is rebuilt.

Fictional agency workflow: a coordinator prepares, approves and sends a weekly client report. Their browser closes after they press Send. A procedure that only says ‘send the report’ leaves the next coordinator guessing whether to repeat an external action.

Record progress at the boundary between preparing work and taking an external action. The next operator should inspect the delivery system, not infer success from a completed checkbox. Keep evidence references in the record rather than copying private client contents into the process manual. Test the restart using a dummy report and a test recipient.

Scroll the table to see every column.

An unavailable delivery system is a reason to pause and investigate, not to mark the process complete. For actions that cannot be undone, make the stop condition especially visible before the action.

• The procedure says where to find the delivery reference.
• A changed report version requires its own review.
• The operator can escalate uncertainty to a named owner without broadening access.