# How to document a team process on one page

https://techy.eus/en/resources/document-a-team-process
Updated: 2026-09-20

Documentation earns its place when a person can complete a task without waiting for someone to answer a chat message. For many processes, one clear page beats a large handbook.

Techy · Editable offline copy. Examples are illustrative, not customer results. Review the guide's limitations before applying it.

## Choose work that repeats

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.

## Use actions and observable results

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.

## Test it with a new reader

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.

## Worked example: deliver an approved file

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.

## Design a safe restart after an interrupted task

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.

Worked example · fictional inputs

| Checkpoint | Evidence | Restart rule |
| --- | --- | --- |
| Draft ready | Versioned draft link | Continue with review |
| Approved | Approver and matching version | Check delivery record |
| Sent | Message reference and timestamp | Do not send again |
| Delivery uncertain | Missing or inconclusive status | Verify before retrying |

## Test the result and handle the exception

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.

## Your working sheet — fill in locally

Situation and date: ____________________

Inputs and where they came from: ____________________

Decision / calculation: ____________________

Expected result: ____________________

Actual check and evidence reference: ____________________

Exception and next action: ____________________

Owner and review date: ____________________

Do not put passwords, patient details or other sensitive data in a shared worksheet. Downloading or checking a box does not verify real-world compliance.