Process Documentation: How to Map a Business Process Before You Write the SOPs
Every company has processes. Very few have processes anyone can see. The order-to-cash chain exists in a ₹40 crore trading company as surely as in a multinational; the difference is that in the multinational it is drawn on a wall, and in the trading company it is distributed across eleven people's habits and the owner's phone.
Process documentation is the practice of recording how work actually flows through a business, from the event that starts it to the outcome that ends it, across every role and hand-off, so that the process can be seen, measured, improved and taught. It sits one level above SOPs: the process map shows the chain; the SOPs describe the individual tasks inside it.
This page covers what to document, the five-step method, the notation that works for a company without a process team, and the mistake that makes most process documentation worthless within a year.
What process documentation is, and what it is not
A documented process has five parts. The trigger, the event that starts it: an enquiry arrives, a PO is received, an employee resigns. The steps, in order, each assigned to a role. The hand-offs, where work passes from one role to another. The decision points, with the rule at each. And the outcome, the state in which the process is complete, stated so it can be checked.
It is not a policy, which states a position. It is not an SOP, which describes one task in step-by-step detail. And it is not an org chart, which shows who reports to whom and says nothing about how work moves. The comparison of the four document types settles which is which.
Why document processes at all
Four reasons, and the reason determines how much detail you need.
To see where work gets stuck. Most delays in an SME happen at hand-offs, not inside tasks. The sales order sits between sales and accounts for two days because nobody owns the hand-off. A process map makes hand-offs visible; nothing else does.
To know which SOPs to write. Writing SOPs without a process map produces procedures that are individually correct and collectively incoherent. The map shows where variation and risk actually sit.
To scale. A second branch, a second shift or a new manager needs to know how the work flows, not just how each task is done.
For an audit or a system implementation. ISO 9001 requires the organisation to determine its processes and their interactions. An ERP or CRM implementation fails when the process it is configured for is not the process the company runs.
The five-step method
1. List the processes, not the departments
Start from outcomes, not org chart boxes. A company of twenty to two hundred people typically has eight to fifteen core processes: lead-to-order, order-to-cash, procure-to-pay, hire-to-retire, produce or deliver, complaint-to-resolution, month-end close, new product or service introduction, and a handful specific to the sector. Name each by its trigger and its outcome.
2. Pick one, and walk it
Choose the process that is currently costing the most: the one with the longest delays, the most rework or the most escalations to the owner. Then walk it physically or on calls. Start at the trigger and follow one real instance, an actual order or an actual complaint, through every person who touches it. Ask each: what arrives, what you do, where it goes next, and what you do when something is wrong.
Do not ask managers how the process works. Ask the people who perform it, and watch. The gap between the two is the finding.
3. Draw it, on one page
Swim lanes, one per role, left to right in time order. Boxes for steps, diamonds for decisions, arrows for hand-offs. If it does not fit on one A3 page, it is two processes, or you are drawing at SOP level and need to come up.
Use whatever draws boxes: a whiteboard photographed, PowerPoint, Google Drawings, draw.io. The notation matters less than the discipline of one page and one role per lane. Formal BPMN is unnecessary in a company without a process team and will not be maintained.
4. Mark the variation and the risk
On the drawn map, mark three things in colour. Where the two instances you walked differed. Where the work waits, and for how long. And where an error would cost money or a customer. Those marks are the list of SOPs to write, in priority order, and the SOP writing method begins where this step ends.
5. Assign an owner and a measure
Every process has one owner, a role, who is accountable for its outcome across all the departments it crosses. Every process has one or two measures: cycle time from trigger to outcome, first-time-right percentage, cost per instance. Without an owner the map is a picture. Without a measure nobody will know whether the process improved.
What to record for each process
A one-page map, plus a one-page summary that lists: process name; trigger and outcome; owner; roles involved; the SOPs inside it by document number; the systems used; the measures and their current values; the known failure points; and the review date. Keep the two pages together in one register, one entry per process. That register is the company's process documentation. It rarely needs to be longer than thirty pages in total.
The mistake that makes process documentation worthless
Documenting the process the company wishes it ran.
The consultant, or the owner, draws the ideal flow: enquiry logged in CRM, quote within a day, order confirmed in the ERP, credit checked automatically. The actual flow is: enquiry on the owner's WhatsApp, quote from memory, order on a phone call, credit checked by the owner's recollection of the customer. The document describes a company that does not exist, and everyone who works there knows it.
Document the process as it is first. Then draw the process as it should be, separately, and label it the target. The gap between the two is the improvement plan, and the SOPs are how you close it one task at a time. Writing the target as if it were the current state produces a document that is politely ignored and quietly discredits the next one.
Process documentation and the owner
In most owner-run companies, the process map, once drawn honestly, has one feature no textbook shows: the owner appears in almost every lane. Approving the quote, releasing the credit, signing the payment, checking the dispatch. The map makes visible what everyone already knew and nobody had drawn, that the process does not flow, it routes.
That is useful information. It tells you which decisions to move first and which thresholds to write into the SOPs. It does not tell you whether the people you are about to move them to can carry them, which is a different question and the one that decides whether the redrawn map holds. The owner dependency guide is the companion to this page for that reason.
Questions people ask about process documentation
What is process documentation with an example?
A recorded description of how work flows from trigger to outcome across roles. Example: order-to-cash in a trading company, drawn as a swim-lane map showing sales, accounts, warehouse and dispatch, with the hand-offs, decision rules and the SOPs at each step.
What is the difference between process documentation and an SOP?
Process documentation shows the whole flow across roles. An SOP is the step-by-step procedure for one task inside that flow. The process map tells you which SOPs to write; the SOPs make each step repeatable.
What software is used for process documentation?
For a company without a process team: a whiteboard, PowerPoint or Google Slides, or draw.io for the map; Word or Google Docs for the summary; a spreadsheet for the register. Specialist BPM software is rarely maintained in companies under two hundred people.
Who should own process documentation?
Each process has one owner, the role accountable for its outcome. The register as a whole is usually owned by operations or quality. The owner of the company should approve, not maintain.
How often should processes be reviewed?
Annually as a minimum, and whenever a system changes, a department restructures or a measure moves the wrong way for two consecutive months.
Where to go deeper
SOP vs Work Instruction vs Policy vs Process — the four levels of documentation.
How to Write an SOP — the next step after the map.
SOP Examples — the tasks that usually sit inside an SME's core processes.
Execution Breaks Down at Scale — what happens when processes live in habits and the company doubles.
What Is an SOP? — the full guide.