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.
A worked example, stage by stage
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.
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.