Every company has processes that live in one person's head. Refunds work because Maria in support knows which ones need her manager. Onboarding works because the office manager remembers to order the laptop two weeks ahead. Then Maria goes on vacation, and nobody knows whether a $600 refund needs approval.
Documenting a process is not about producing a binder nobody reads. It is about writing down enough that someone else could run it correctly next week, and seeing where it breaks.
Key takeaways
- Document one process at a time, starting with one that repeats often and goes wrong when a single person is out.
- Define the trigger, the start and the end before writing any steps.
- Write each step as a verb with one owner, its input, its output and its deadline, and put the decision rules next to the step they affect.
- A process document needs an owner and a version number, or it will be out of date within a quarter.
This guide shows how to document a process in eight steps, with a template you can copy and a worked example for a customer refund.
What process documentation is (and is not)
A process document describes how a recurring piece of work gets done: what starts it, the steps, who does each one, what information goes in and comes out, the rules for decisions, and what "done" means.
It is not a policy (a policy says what is allowed, the process says how it happens), a job description or a software manual. For the bigger picture of how documented processes fit into running a company, see what is process management.
How to document a process in 8 steps
1. Pick the process
Do not start with "all our processes". Pick one that:
- Repeats often, weekly or more
- Involves more than one person or team
- Causes complaints, errors or rework
- Depends on one person who knows how it works
- Involves money, customers or compliance
Good first candidates are purchase requests, expense reimbursement, customer refunds, employee onboarding and system access requests. Give it a plain name, like "Customer refund", not "Refunds and related stuff".
2. Define the trigger, the start and the end
Before writing a single step, write four lines:
- Trigger: the event that starts the process. A customer asks for a refund.
- Start: the first action someone takes. Support logs the refund request.
- End: what "done" looks like, including the unhappy endings. Refund issued and customer notified, or request declined with a reason.
- Out of scope: what this process does not cover. Card chargebacks, which finance handles separately.
This prevents a document that slowly grows to cover everything and helps with nothing.
3. Interview the people who do it
Talk to the people who do the work, not only their manager. Ask them to walk you through the last real case, then the last one that went wrong.
Questions that work:
- What did you receive, and from whom?
- What did you do first? And then?
- How did you decide whether to approve, reject or escalate?
- Who do you wait for, and for how long?
- What goes wrong most often?
Write down what actually happens, not what should happen. You will improve it later, but first you need an honest picture.
4. Write each step as a verb with an owner, input and output
Each step should start with a verb and have exactly one owner:
- Verb: "Check eligibility", "Approve refund", "Issue refund". Not "Eligibility" or "Finance stuff".
- Owner: a role, not a name. "Support lead", not "Maria". People change jobs; roles stay.
- Input: what the owner needs to do the step.
- Output: what the step produces and hands to the next one.
Two rules of thumb. If a step has two owners, it is two steps. If a step has no output, ask whether it is really a step.
5. Note decision rules and exceptions
Rules are where most of the knowledge hides. "Refunds over $500 need the finance manager" belongs next to the step it affects, not in a paragraph at the end. If approvals depend on amounts, write them as tiers, the way an approval matrix does.
For exceptions, list the three or four that happen regularly and what to do in each. For everything rarer, write one line: "anything else, escalate to the process owner". Do not try to design a branch for every case you can imagine.
6. Add timing and deadlines
For every step, write how long it should take: "1 business day", "same day". Then add a target for the whole process and what happens when a step is late: who gets reminded, and who it escalates to. Without this, the document describes the order of the work but not its speed, and most complaints are about speed.
7. Review it with the team
Walk through the draft with the people who do the work, using a recent real case. Then hand it to someone who has never done the process and ask them to follow it. Every question they ask is a gap in the document.
8. Version it and name an owner
Put a version number, a date and a one-line change note at the top. Name a process owner, usually the manager of the team that does most of the steps, responsible for keeping it current when the policy, the tools or the people change. Set a review date, at least once a year, and keep the document where people actually work, not in a folder nobody opens.
Process documentation template
Copy the header and the step table below into a doc or spreadsheet. The example is a customer refund; the amounts, windows and roles are only illustrations, so replace them with your own policy.
Header
| Field | Example |
|---|---|
| Process | Customer refund |
| Process owner | Customer support lead |
| Version | 1.2, reviewed March 2026 |
| Trigger | A customer asks for a refund by email, chat or ticket |
| Starts | Support logs the refund request |
| Ends | Refund issued and customer notified, or request declined with a reason |
| Out of scope | Card chargebacks and disputes (handled by finance) |
| Target time | 5 business days from request to refund |
| Related policy | Return and refund policy |
Steps
| Step | Owner | Input | Action | Output | Deadline | Rule |
|---|---|---|---|---|---|---|
| 1. Log the request | Support agent | Customer message, order number | Record order, amount, reason and payment method | Refund request | Same business day | No order number, no request: ask the customer |
| 2. Check eligibility | Support agent | Refund request, order history, refund policy | Confirm the order is within the refund window and the item came back or the service was not delivered | Eligibility note | 1 business day | Example: within 30 days of delivery; outside it, escalate to the support lead |
| 3. Approve the refund | Support lead up to $500, finance manager above | Request with eligibility note | Approve, reject with a reason, or send back for missing information | Decision | 1 business day | Nobody approves a refund they logged |
| 4. Issue the refund | Billing specialist | Approved request | Refund to the original payment method and record the transaction ID | Transaction ID | 2 business days | Any other payment method needs the finance manager |
| 5. Notify the customer | Support agent | Transaction ID | Email the customer with the amount and expected timing | Request closed | Same day as the refund | Use the standard refund email |
Exceptions
- Partial refund (one item of an order): same steps, amount is the partial value.
- Store credit instead of refund: support agent can issue directly up to the same limit, no finance step.
- Third refund request from the same customer in 90 days: always goes to the support lead, whatever the amount.
- Anything else: escalate to the process owner.
Fill all seven columns: the empty cells are exactly where the process breaks in practice.
SOP vs process document vs checklist
People use these terms loosely, and they are not the same thing. Each answers a different question, and most processes need more than one.
| Process document | SOP | Checklist | |
|---|---|---|---|
| Answers | Who does what, in what order? | Exactly how is this task done? | Did we do everything? |
| Scope | End to end, across roles | One task, one role | One task or event |
| Detail | Medium: steps, owners, rules | High: screens, fields, exact wording | Low: items to tick |
| Main reader | Everyone involved, managers, auditors | The person doing the task | The person doing it, in the moment |
| Refund example | The customer refund process above | How to issue a refund in the billing system | Refund issued, transaction ID logged, email sent |
A good setup is one process document per process, with SOPs linked from the steps that need them, and checklists where people need a quick check in the moment. Our employee onboarding checklist is an example of the checklist format. In regulated industries, "SOP" often means a formally controlled document with its own approval and training records, so check what your auditors expect before renaming anything.
Common mistakes
- Documenting the ideal instead of reality. People keep doing it their way and ignore the document.
- Too much detail. Clicks and screenshots belong in an SOP, linked from the step. The process document should fit on one or two pages.
- Names instead of roles. "Send to Maria" breaks the day Maria leaves.
- Rules hidden in prose. If the $500 limit is in paragraph six, nobody finds it. Put rules in the step table.
- Writing it alone. A process documented without the people who do it is a guess.
- No owner, no version. Six months later nobody knows whether the document is current.
- A flowchart with forty boxes. Many business processes are a straight line with a few rules. A numbered table is easier to read and much easier to keep up to date than a complex diagram.
Frequently asked questions
What should a process document include?
At minimum: the process name and owner, the trigger, where it starts and ends, the steps with an owner for each, the inputs and outputs, decision rules, deadlines and a version with a date. Exceptions and links to related policies or SOPs are the next most useful additions.
What is the best format to document a process?
For most business processes, a short header plus a step table like the template above. Flowcharts help when a process has real branches that run in parallel, but most routine processes are linear with a few rules, and a table captures owners, deadlines and rules better than boxes and arrows.
How often should you update process documentation?
Whenever the policy, the tools or the roles change, plus a scheduled review at least once a year. Putting the review date in the header makes it much more likely to happen.
Running it in Easyflow
The template above maps almost one to one onto an Easyflow process. Each row becomes a step with an owner and a deadline; the inputs become fields on the first form, filled by whoever starts the request; the rules become conditions that skip a step or hide a field, or approval limits that pick the approvers by amount. Late steps get reminders and escalate to the people you name, and processes stay linear on purpose, just like a good process document.
The gallery has Customer refund, Customer complaint, Employee onboarding and Access request ready to adapt. Every request keeps a full timeline, and Insights shows lead times and late steps per process, so you can see which deadlines in your document are unrealistic.
If your team is deciding whether this kind of work belongs on a board or in a workflow, read Kanban boards vs workflows.