How to document a business process
How to document a process so it stays true: name an owner per step, record the decision rules, put the document under version control and approval, and set a review date. With a live example.
Documenting a process means capturing what happens, who is accountable for each step and what the decision rules are, in a form that has one current version, a named owner and a review date.
The short version
- One current version, identifiable as current. Everything else is a copy.
- Every step names an accountable role; every decision states its rule and threshold.
- Say where the evidence lands: which system, which register, which record.
- Approval with a signature and a date is what turns a document into a controlled one.
- Set a review date, and review after anything goes wrong.
Choosing documentation tools
Why process documentation stops being trusted
Almost every organisation has process documentation. Very little of it is trusted, and the reason is rarely the writing. It is that nobody can tell which copy is current. A procedure lives as a Word file in a shared drive, a diagram in someone's slide deck, and a wiki page updated eighteen months ago, and each of the three is right about something different. The work of documenting a process is only half about writing it down; the other half is making one version identifiable as the agreed one.
The content test is simple: could someone who has never done this job execute it, and could an outsider tell whether it was followed? That means every step names an owner, every decision states its rule and its threshold rather than saying "if appropriate", and every step that produces a record says where the record goes. "Verify the bank details" is a sentiment. "Call the vendor on the number from the signed contract, never the number on the invoice, and record who verified it and when" is a control.
The example below is a vendor onboarding process. Read the procedure text under the canvas alongside the diagram: they are generated from the same rows, which is the point. When the diagram and the written procedure are two documents, they diverge, and the divergence is invisible until an auditor lays them side by side.
A documented process, diagram and text
Vendor onboarding across five lanes. The procedure text beneath the canvas is generated from the same rows: two views, one source.
Record the trigger and the intake
A request form and a documented check for whether an existing vendor already covers the need. Documenting the intake is what stops the process being entered halfway through, which is how unapproved suppliers get onto the ledger.
Name the checks, and who runs them
Contract terms with Legal, credit with Finance, data protection with Security. Four reviews, four owners, one lane each: a procedure that says "due diligence is performed" without naming who performs which part is not documentation, it is a heading.
Write the decision rule down
The risk tier drives the depth of review, and the due-diligence gate has an explicit rejection route. When the rule and its threshold are written on the step, the decision is repeatable by whoever is on duty rather than dependent on who is asked.
Document the control, including the loop
Bank details are verified by callback, and unverified details route back to be verified again; payment setup does not proceed on an unverified account. Controls that only exist as a sentence in a policy get skipped; controls drawn as a gate with a loop are visibly non-optional.
How it works
Decide what the document is for
Training a newcomer, satisfying an auditor, and settling arguments between teams need different levels of detail. Write down which one you are doing, because it determines how much goes in. Trying to serve all three at once produces a document too long to train from and too vague to audit against.
Capture the flow before the prose
Build the process as a chart first: steps as rows, connections by row number, an owner lane per step. The diagram forces the gaps into the open: an unowned step, an unlabelled branch and a missing exception are all visible in a chart and easy to hide in a paragraph.
Give every step an owner and every decision a rule
Put the accountable role in the step's lane and the decision rule in its comment: the threshold, the criteria, who may grant an exception. Replace "as appropriate" and "in a timely manner" with numbers wherever you can, and where you genuinely cannot, name who decides.
Say where the evidence lands
For each step that produces a record (an approval, a signed contract, a register entry), write down which system holds it and under what name. This is the difference between documentation that survives an audit walkthrough and documentation that generates a follow-up request.
Get it approved, not just published
Route the finished chart through QueryChart's approval workflow so the current version carries a reviewer, a signature and a date. That is what makes it a controlled document rather than a file: an approved version, an immutable change history, and no ambiguity about which copy people should be reading.
Set a review date and a trigger
Pick a cadence (annual is common, six-monthly for anything that changes often) and add a rule that the process is reviewed after any incident, audit finding or system change that touches it. Documentation decays silently, and a date on the page is the cheapest defence against it.
Mistakes to avoid
Two documents, one process
A diagram in one file and a written procedure in another will diverge, and nobody will notice until they are compared under pressure. Keep one source, and generate the views from it.
"As appropriate"
Vague qualifiers move the decision from the document to whoever happens to be on duty. That is the opposite of documenting a process. Write the threshold, or write who decides.
No named owner
A document everyone can edit and nobody owns is a document nobody updates. One name, on the page.
Version by filename
process_v3_FINAL_updated2.docx is not version control; it is an archaeology exercise. Use a system that can tell you which version is approved and what changed between revisions.
Document your own process
Open the vendor onboarding example as your own chart, or start blank and build the flow from your rows.
Related guides
Frequently asked questions
What is the difference between a process document and an SOP?
A process document describes how work flows, usually across several roles: sequence, decisions, handoffs. An SOP is an instruction for performing one job, written for the person doing it, and often includes detail a process map would not carry: screenshots, exact field values, safety notes. In practice they pair up: the process map shows how the SOPs connect, and each SOP expands one step of it.
How detailed does process documentation need to be for an audit?
Detailed enough that an auditor can pick a real case, follow your document, and find the evidence where the document says it will be. That means named owners, stated decision criteria, and a location for each record. What auditors chase is not length but consistency: a documented process, evidence that it was followed, and an approval record showing the documented version is the current one.
Who should write the process documentation?
Someone who does not do the job, working from interviews with the people who do. Practitioners skip the steps that have become automatic to them, which are exactly the steps a newcomer needs. Draft it as an outsider, then have the practitioners correct it: the corrections are quick, and what they add is the tacit knowledge that never makes it into a first draft.
How often should process documentation be reviewed?
On a fixed cadence and on specific triggers. Annually is the common baseline, six-monthly for high-change processes. The triggers matter more: review after an incident, an audit finding, a system migration, or a reorganisation that moves a lane owner. Most decay happens through unreviewed change, not through the passage of time.