Process documentation template: how to document a process so it gets followed (2026)

Process documentation is the written description of how a piece of work flows through your organization from the event that starts it to the result that ends it: the stages in order, the role that owns each one, what passes from one role to the next, what each stage leaves behind, and what happens when the normal path is blocked. A process documentation template is the fixed skeleton those words go into, so that the tenth process reads like the first and a person who has read one can find their way in all of them.

Most processes are already documented somewhere — in a diagram from a workshop two years ago, in a wiki page nobody opens, in the head of the one person who has done it since the beginning. The problem is rarely that the document doesn't exist. It is that it isn't followed, and the three reasons for that are the same in every organization. This guide is the craft first — what a process document is and isn't, the standard format, a template you can copy, a worked example — then the three reasons and what fixes each, where the document and its walkthrough live in the tools your team already uses, and what the colleague who reads it in another language gets. Because a process document is judged on the morning a new account manager, a new nurse or a new distributor's clerk has to hand something to the next person, and doesn't know who that is.

What a process document is — and what it isn't

Three documents describe how work gets done at the level of a process, and they are often confused with each other and with the procedures underneath them:

The map is the picture; the process document is the text that makes the picture usable; the SOPs are the detail underneath each box. The distinction decides the length: a process document that explains how each step is clicked is a manual nobody reads, and a process map without the text is a picture everyone interprets differently. The SOP, its template and its review cycle are in SOP template and how to write an SOP; this guide is about the level above them — the one that says where the SOPs are needed and who hands what to whom.

A process document is also not a description of how the work is usually done. It is the agreed way, with an owner, a version and a review date — which is why a stage nobody follows is a stage to change or a conversation to have, not a sentence to leave in.

What to include: the standard format

A usable process document carries a header and eight sections. Most templates online carry the purpose, the steps and a diagram, and stop — which is why most process documents are read once and not again:

The header — the identity of the document, five fields on one line: an ID people can cite ("PR-HR-02"), a version ("v1.3"), the owner — one named person who is accountable for the whole process, not a department — the effective date and the next review date. A process without a review date is reviewed when something goes wrong.

1. Purpose and outcome. One or two sentences: what this process delivers, to whom, and what good looks like — with a number if you have one. "A new hire has accounts, equipment, a plan and a named buddy on day one, and a 30-day review by day 30."
2. Trigger and end state. The event that starts the process and the result that ends it. "Starts when the signed contract lands in the HR folder; ends when the 30-day review is recorded." Everything between those two sentences is the process; everything outside them is another document. If the process has no clear end, it is two processes.
3. Scope. When this process applies and when it does not, naming the neighbouring processes by ID. "Employees on a contract with us, in any country. Not: contractors (PR-HR-04); not: internal transfers (PR-HR-06)."
4. Roles. Each role that appears in the stages, with what it owns — roles, not names, so the document survives a hire. One of them is the process owner, accountable for the whole flow, including the hand-offs nobody owns by default.
5. Stages and hand-offs. The heart of the document: the stages in order, each with the role that does it, what arrives (the input), what leaves and where it is recorded (the output), who it goes to, and the time limit. The hand-off is written explicitly — "to: IT, by day −5" — because the hand-off is where processes fail: both sides think the other has it.
6. Exceptions and escalation. The branches off the happy path: what happens when the permit is late, the credit check fails, the owner is away. Each exception names a role or a person who decides, never "ask someone". The last line covers what you missed: "Anything not covered here: the process owner decides, and the case is raised at the next review."
7. Measures. Two or three numbers the owner watches — cycle time from trigger to end state, cases per month, the share that hit an exception. Not a dashboard; the numbers that tell the owner the process is drifting before a person complains.
8. Related documents and revision history. The SOPs under each stage, the policy the process implements, the link to the map; then one line per version — date, what changed, who approved it. The history is what stops the same mistake being reintroduced under a new version number.

What stays out: the justification for each rule (the policy's job), the click-by-click detail of a stage (the SOP's job), and anything a person could not act on. "We value a smooth onboarding" is a sentiment, not a stage.

How to document a process so it gets followed

Three reasons explain almost every process document that is not followed, and each has a fix that belongs to the writing, not to some later enforcement.

Reason one: it describes the process as designed, not as run. The document was written in a workshop by the people who manage the work, and the people who do it have a different version — with the spreadsheet on the side and the colleague who gets called at stage 3. The fix is to map it from evidence before you write. Follow three real cases from trigger to end state and write down what actually happened: the emails, the messages, the forms, the waits. If the process lives in a group chat — orders from distributors arriving on WhatsApp, shift swaps agreed in a Telegram group — the chat is the evidence, and the walkthrough starts with its history: what Export chat gives you and where it stops is in how to export a WhatsApp chat. Where the three cases differ is the reason the document exists; decide for each difference whether it is a stage to fix in the text or a conversation to have with the team.

Reason two: nobody can find the current version. The document is in a folder with forty others, a copy is on someone's desktop, a third version is in the wiki, and the person who needs it on a Tuesday morning asks a colleague instead. The fix is to publish where the team already reads, with the header visible. One place, the current version first, the owner's name and the review date at the top — so "is this still right?" is answered by the header, not by asking around. And the stages are written as hand-offs between roles, so each person finds their own stage and the two stages next to it in under a minute.

Reason three: it changed and the people whose stage changed were never told. A review moved the credit check before the pick, or added a step for hires who relocate, and the document was updated — but the warehouse and the hiring managers kept doing what they did before. The fix is to walk the process through with the people who run it, and announce every change with the lines that changed. The walkthrough is a meeting: the owner and one person per role, the current version on everyone's screen, each stage read aloud by the person who does it, each hand-off confirmed by both sides. What the walkthrough changes becomes a new version with one line in the history, and the three lines that changed go to the people whose stages they touch, in the place they already read, the same day. A decision that changes a rule rather than a stage goes into the decision log as well, with the process ID in the entry.

The sequence, then: pick one process with a clear start and end; follow three real cases; draft the stages first, in the template, with the hand-offs explicit; fill in the exceptions from what the cases showed; walk it through with one person per role; publish where the team reads, with the owner and the review date in the header; put the review date in the calendar. The document that comes out of this is followed because it is true, findable and announced — the three properties the template alone cannot give it.

A process documentation template

[Process ID] — [Process name]
Version: [n.n] · Owner: [name, role] · Effective: [date] · Next review: [date]

1. Purpose and outcome
[One or two sentences — what this process delivers, to whom, and what good looks like, with a number if you have one.]

2. Trigger and end state
Starts when: [the event] · Ends when: [the result that now exists]

3. Scope
Covers: [cases, sites, customers, countries] · Does not cover: [what another process handles, with its ID]

4. Roles
Process owner: [the one person accountable for the whole flow]
[Role] — [what it owns in this process]
[Role] — [what it owns in this process]

5. Stages and hand-offs
5.1 [Stage] — [role] — in: [what arrives] — out: [what leaves, where it is recorded] — to: [next role] — by: [time limit]
5.2 [Stage] — [role] — in: … — out: … — to: … — by: …
5.3 [Stage] — [role] — in: … — out: … — to: … — by: …

6. Exceptions and escalation
If [condition]: [what happens, who decides]
If [condition]: [what happens, who decides]
Anything not covered here: [role] decides; the case is raised at the next review.

7. Measures
[Two or three numbers the owner watches — cycle time, cases per month, share that hit an exception — and where they are read.]

8. Related documents and revision history
SOPs: [IDs, one per stage where needed] · Implements: [policy] · Map: [link to the diagram]
v[n.n] — [date] — [what changed] — approved by [name]
v[n.n] — [date] — [what changed] — approved by [name]

The template is plain text with bold labels, so it pastes into a Word file, a Google Doc, a wiki page, a Slack canvas or a chat note without reformatting. The two sections most often left blank are the hand-offs — "to whom, by when" — and the review date; they are the two that decide whether the process is still run the way the document says in a year.

A worked example: onboarding a new hire, from signed contract to day 30

A company of sixty people with hires in three countries; the process crosses four roles and ends when the 30-day review is recorded.

PR-HR-02 — Onboarding a new hire
Version: 1.3 · Owner: Head of operations, Inés M. · Effective: 1 Oct 2026 · Next review: 1 Apr 2027

1. Purpose and outcome — A new hire has working accounts, equipment, a first-month plan and a named buddy on day one, and a recorded 30-day review by day 30, whichever country they start in.
2. Trigger and end state — Starts when: the signed contract lands in the HR folder. Ends when: the 30-day review is recorded in the hire's file.
3. Scope — Employees on a contract with us, in any country, office or remote. Not: contractors (PR-HR-04); internal transfers (PR-HR-06).
4. Roles — Process owner: head of operations. HR: the file, documents, payroll, the welcome pack. IT: accounts, equipment, access. Hiring manager: the plan, the buddy, the check-ins. Finance: payroll setup.

5. Stages and hand-offs
5.1 Open the file — HR — in: the signed contract — out: the onboarding record with start date, country, manager, language; the welcome pack sent in the hire's language — to: IT and the hiring manager — by: two working days after signature
5.2 Accounts and equipment — IT — in: the record — out: accounts created, laptop shipped to the hire's address, access per the role profile; confirmation in the record — to: HR — by: five working days before the start date
5.3 Documents and payroll — HR, then finance — in: the record, the hire's documents (permit or registration where the country requires it) — out: the hire in payroll, documents in the file — to: the hiring manager — by: the start date
5.4 The first month, planned — hiring manager — in: the record — out: a 30-day plan in the file, a named buddy, the first week in the hire's calendar, the welcome call booked with the team — to: the hire, on day one — by: the day before the start
5.5 Day one — hiring manager and buddy — in: the plan — out: the welcome call held, the plan walked through, the hire's open questions logged in the team's channel — to: the hire — by: end of day one
5.6 Check-ins — hiring manager — in: the plan, the logged questions — out: a day-7 and a day-30 check-in, the 30-day review recorded in the file — to: HR, to close the record — by: day 30

6. Exceptions — Permit or registration not through by the start date: the hire starts on the tasks the manager marks as allowed without it; HR owns the follow-up and the date goes in the record. Laptop not delivered by day −2: IT ships a loaner from the office stock; the head of operations is told the same day. Hire in a country we have not hired in before: stage 5.3 pauses; the head of operations decides the employer-of-record route within three working days (PR-HR-05).
7. Measures — Working days from signature to accounts ready (target ≤ 7); share of hires with a recorded 30-day review by day 30 (target 100 %); questions logged in week one, read at the quarterly review to see which stage keeps producing them.
8. Related — SOP-IT-03 "New accounts and access"; SOP-HR-08 "Payroll setup by country"; Onboarding policy §2; map: the swimlane diagram in the HR folder.
v1.3 — 1 Oct 2026 — welcome pack now sent in the hire's language; day-7 check-in added — approved by Inés M.
v1.2 — 3 Jun 2026 — laptop shipping moved to five days before start after two late deliveries — approved by Inés M.

Notice what the example does. Every stage names the role, what arrives, what leaves and where it is recorded, who gets it next and by when — so a hand-off that didn't happen is visible as a blank in the record, not as a surprise on day one. Each exception names who decides. The measures are three numbers, not a dashboard. And the history explains why the stages are the way they are: stage 5.2 has its date because two laptops were late, and the day-7 check-in exists because the day-30 review kept finding questions that should have been answered in the first week.

A shorter second example, the shape of a sales process for an exporter with distributors:

PR-SA-01 — Order to delivery · Owner: Export manager · Starts when: a distributor's order arrives · Ends when: delivery is confirmed and the invoice is sent
1. Order check — account owner — in: the order — out: order confirmed in the system, or a query back to the distributor — to: finance — by: one working day
2. Credit check — finance — in: the confirmed order — out: released, or held with a reason — to: warehouse — by: one working day
3. Pick and pack — warehouse — in: the released order — out: packed, with the packing list — to: logistics — by: three working days
4. Documents and shipping — logistics — in: the packed order — out: the shipment booked, the destination's documents attached, tracking in the system — to: finance and the account owner — by: one working day
5. Invoice and confirmation — finance, then the account owner — in: the shipment — out: invoice sent; delivery confirmed with the distributor and recorded — If credit is held: the account owner calls the distributor within one working day; the export manager decides release or prepayment.

Twelve lines, and a new clerk at the distributor and a new person in the warehouse both know who they are waiting on.

Where the process document and its walkthrough live in the tools you already use

The document itself lives wherever the team's documents live — a Word file in a shared library, a Google Doc, a page in a wiki, a canvas in a channel. The walkthrough is a meeting, and each platform has a place for what the walkthrough leaves behind; each stops at a different point. Documented behaviour only, from the vendors' own pages, with the month each page was checked:

Two things are the same everywhere. The process document is a file in the one language it was written in, and the colleague who reads another language reads that one or a copy someone made; and what the walkthrough changed reaches the document only when a person types it in afterwards, in that same language. The translation these suites document belongs to the call, not to the document: Microsoft documents live translated captions in Teams meetings when the organizer holds a Teams Premium or Microsoft 365 Copilot license, and Google documents translated captions in Meet on eligible Workspace plans (both checked August 2026) — what each covers and where each stops is in Microsoft Teams live translation and Google Meet live translation. The process the new clerk opens on Tuesday, and the walkthrough that changed it, are separate objects from those captions, and they are read in the language they were typed in.

How the process, its walkthrough and its history stay readable for every member

InterMIND is a communication space where a team's work lives in a channel, so the finished process document has an obvious home: the channel of the team that runs the process — one channel for the people across HR, IT, finance and the hiring managers who each own a stage. Posted as a note — a rich-text message with headings and numbered lists, edited later from its own menu — it is read by each member in their own language with the original a toggle away, and pinned so the current version is the first thing a new colleague finds; with edit history switched on, the earlier wording of a changed stage appears above the current text as a word-level diff with its timestamp. Uploaded as a file — a PDF or a Word document — it carries, on every plan, an AI summary in the reader's language with each point linked to the paragraph it came from, so the one-page read exists before anyone has written it; on paid plans the file itself opens translated into the reader's language (30 languages for documents). If the master copy stays in a document tool, its updates land in the channel by email: the channel's host gives it an address of its own, and a message sent there appears as a regular message with the sender named and attachments kept.

The walkthrough starts from that channel. During the call, the current version goes on everyone's screen next to the video tiles with Share to conference — a note, or a Google Docs or OneDrive document linked in the chat — and each participant scrolls it independently and reads it in their own language; a shared note is edited live by the sharer while the room watches the changed hand-off take shape. When the call ends, the recap is written from the meeting itself — a summary, the points marked agreed, open or disputed, the action items with owners, each line keeping its timestamp — and the documents shared during the session contribute their summaries alongside what was said. It arrives by email, as a message in the channel and as a link in the calendar event, and every signed-in member reads it in their own language: the record is translated per reader, not written once in the language the room happened to use. Any member can edit it, every edit keeps author and revision history, and the channel keeps the recap of every past session — so the walkthrough that produced v1.3 is one click from the note that is v1.3. A member's own assistant — Claude, ChatGPT, Copilot or Gemini, connected through the MCP connector — searches recaps, transcripts, chats and the text of shared files in one question, "why does the laptop ship five days before the start date?", and reads the document itself; this runs for organizations with AI features on. Set next to the table above, the difference is a plain statement of fact: the captions those suites document translate the call while it runs; here the process, its walkthrough and its history are one record, read by each member in their own language.

The people who take part in a process are not always employees. A distributor's order clerk, a payroll provider in another country, a contractor who owns one stage: an external member of the channel joins by email onto a free account and reads the process and its history like everyone else; a person without an account is a guest of one meeting — they join the walkthrough by link, from a phone, at no cost, hear it live in their own language, and get no record afterwards. The host provides the space and, on a paid plan, pays only for the members active in the previous 28 days — joined a meeting, wrote in a chat or asked the assistant; members who go quiet keep their access at no cost.

• Open a complete recap — a real record rendered by the same code that writes yours.
• Try the live demo — no signup; speak, and hear the room translated per listener.

Process documentation as a craft survives every tool: somebody still has to follow three real cases, write the stages as hand-offs a second person can check, and walk the whole thing through with one person per role. What doesn't have to survive is the second job — keeping a translated copy of every version by hand, and retyping what the walkthrough changed, in one language, for people who read others.

FAQ

What is process documentation?

Process documentation is the written description of how a piece of work flows through an organization from the event that starts it to the result that ends it: the stages in order, the role that owns each, what passes from one role to the next, what each stage leaves behind, the exceptions off the normal path and who decides them, and the few numbers the owner watches. It sits between the process map — the diagram — and the SOPs that describe how each stage is done step by step.

What should be included in process documentation?

A header with the ID, version, owner, effective date and next review date; the purpose and outcome; the trigger and the end state; the scope, including what the process does not cover; the roles, with one named process owner; the stages in order, each with the role, the input, the output and where it is recorded, the next role and the time limit; exceptions and escalation with a decider for each; two or three measures; and the related SOPs, the policy it implements and a revision history.

How do you document a process step by step?

Pick one process with a clear trigger and end state. Follow three real cases from start to finish and write down what actually happened, including the branches. Draft the stages first, in the template, each as a hand-off — role, input, output, next role, time limit. Add the exceptions the cases revealed, with who decides each. Fill in the purpose, scope, roles and header. Walk the document through with one person per role, each reading their own stage aloud and confirming the hand-offs. Publish it where the team already reads, with the owner and the review date visible, and put the review date in the calendar.

What is the difference between process documentation and an SOP?

Process documentation describes how work flows across roles and teams — stages, hand-offs, what each stage leaves behind — at the level of one page per process. An SOP describes how one of those stages is done by one role, step by step, down to the result each step produces. The process document tells you where the SOPs are needed and who hands what to whom; one SOP tells one person what to do on Tuesday morning. Writing an SOP for a whole cross-team process produces a manual nobody opens; writing a process document at SOP detail produces the same thing.

What are examples of process documentation?

Any recurring flow that crosses roles with a clear start and end: onboarding a new hire from signed contract to day 30; an order from a distributor to a confirmed delivery and an invoice; a customer complaint from intake to closure; a patient from referral to first appointment; a new product from approved brief to listed in the catalogue; month-end close from timesheets to sent invoices. The worked example in this guide is hire onboarding — six stages across four roles, three exceptions, a history of three versions — with a shorter order-to-delivery example after it.

Is there a process documentation template in Word or Google Docs?

The template in this guide is plain text with bold labels, so it pastes into a Word document, a Google Doc, a wiki page, a Slack canvas or a chat note without reformatting. The format matters more than the file: whatever holds the document needs the header with the owner and the review date, the trigger and the end state, stages written as hand-offs between roles with a time limit, a named decider for each exception, and a revision history — and it needs to live where the people who run the process already read.

Who should write process documentation?

The process owner — one named person accountable for the whole flow, usually the manager of the area the process mostly runs through — with one person from each role that takes a stage. The owner holds the pen and the review date; the people who do the stages are co-authors, because a document written about them instead of with them describes the process as designed while the real one lives in their heads. A newcomer is the tester: if they can find their stage and the two next to it in under a minute, the document works.

How often should process documentation be updated?

On the review date in its header — every six or twelve months is usual, shorter where the process is regulated — and earlier when one of four things happens: a hand-off failed and nobody owned it, a tool or form a stage depends on changed, the rule the process implements changed, or the measures moved. Each update is a new version with one line in the history saying what changed and who approved it; the old version is kept, and the people whose stages changed are told, with the lines that changed, the same day.

Sources: Microsoft — Take meeting notes in Microsoft Teams; Microsoft — Use live captions in Microsoft Teams meetings; Zoom — Using Meeting Summary with AI Companion; Google — Calendar & Meet settings for "Take notes for me"; Google Meet — "Take notes for me" in Google Meet; Google Meet — Use translated captions; Slack — Meeting agenda template (canvas). Microsoft, Google and Slack meeting-notes and template pages checked October 2026; the Zoom meeting-summary page and the Teams and Meet captions pages checked August 2026. Vendors change plans, features and language lists over time; check their pages for the current state.