How to document a business process before you automate it
Most process documentation describes the shape of the work and then cannot answer the only question you asked it: is this worth automating? That takes six fields, measured rather than estimated — and one field almost everybody leaves out.
A flowchart is not documentation
Most process documentation is a diagram. Boxes, arrows, a swimlane if someone was feeling thorough. It describes the shape of the work perfectly well, and then fails at the only question you actually asked it: is this worth automating?
You cannot answer that from a flowchart, because a flowchart carries no quantities. It tells you the invoice goes to the manager for approval. It does not tell you that it happens 40 times a week, that the manager spends four minutes on each one, or that the manager costs £60 an hour. Without those, you are choosing what to automate on instinct — and instinct systematically picks the process that is most annoying rather than the one that is most expensive.
| What most process docs capture | What the decision actually needs |
|---|---|
| The sequence of steps | The sequence of steps |
| Who does what | Who does what, and what each of them costs per hour |
| Systems touched | How many times this runs per week or month |
| A diagram | Minutes spent per run, per person |
| Occasionally, a pain point | What would still be done by hand afterwards |
The right-hand column is not a bigger document. It is usually a smaller one — a single row per process, with numbers in it.
The six fields that turn a description into a decision
A process record that can produce a number needs six things. Anything beyond these is nice to have; anything missing from them makes the record undecidable.
| Field | What it means | Where people go wrong |
|---|---|---|
| Unit | The thing the process happens to — one invoice, one new starter, one job sheet. | Choosing a unit nobody counts. If the business does not already track it, pick something it does. |
| Cadence | Weekly or monthly. Pick one and stay in it. | Mixing cadences across processes, so totals cannot be added up. |
| Volume | How many units per that period. | Using a peak week. Use a normal one, or average four. |
| Roles and minutes | Every person who touches it, and the minutes each spends per unit. | Recording one total time for the whole process. This hides who is doing the work. |
| Current steps | The actual sequence, including the bits that are not in the official procedure. | Documenting the policy instead of the practice. |
| Pain points | Where it fails, not just where it is slow. | Only recording slowness. A step that is fast but wrong twice a month may cost more than one that is merely tedious. |
Note what is doing the work here: roles and minutes, separately. A process where a £35-an-hour administrator spends 20 minutes is a different proposition from one where a £60-an-hour manager spends 20 minutes, even though a single blended average would price them identically. Blending the rate is how expensive people doing cheap work stays invisible.
Measure the minutes, do not estimate them
Self-reported times are the weakest number in the whole exercise, and they are wrong in a predictable direction: people overestimate tasks they find irritating and underestimate tasks that have become habitual. Since the irritating ones are exactly the ones that get volunteered for automation, estimating quietly biases the entire roadmap.
How to get a defensible minutes-per-unit figure
- Time it for two weeks, not one — one week is always atypical for someone
- Count the interruption, not just the task: opening the system and finding the record is part of the minutes
- Record it per unit, not per day, so it stays comparable across processes with different volumes
- Have the person who does the job record it, not the person who manages the job
- Where timing is impractical, ask for a range and use the lower bound — an understated case that still stacks up is one nobody can argue with
If you take one thing from this article, take this: a business case built on measured minutes tends to hold up under scrutiny from a finance director. One built on estimates often does not, and the question usually gets asked.
The field everyone leaves out
Here is the omission that makes most automation business cases wrong. People record what a process costs today, assume automation takes it to zero, and present the whole figure as the saving. It rarely goes to zero.
Automated invoice chasing still needs someone to read the replies. An automated onboarding flow still needs someone to check the new starter's details are right. The number you need alongside the current effort is the residual effort — what is still done by hand afterwards. The saving is the difference, not the original.
Illustrative example — why the residual figure changes the answer
| Invoices chased per week | 40 |
| Current minutes per invoice (admin, £35/hr) | 9 |
| Residual minutes per invoice after automation | 2 |
| Minutes actually saved per invoice | 7 |
| Hours saved per year (40 × 7 ÷ 60 × 46 weeks) | ≈ 215 |
| Annual saving, honestly stated | ≈ £7,520 |
Illustrative figures, not a client result. Stated without the residual field the same process would have claimed roughly £9,660 — about a 28% overstatement. Substitute your own measured inputs.
Recording the residual also forces a more useful conversation during discovery. Asking "what would still need a human after this runs itself?" surfaces the verification steps, the exceptions and the judgement calls — which are usually the parts that determine whether the automation is feasible at all.
Score it for feasibility, not just for size
A record with volumes and minutes in it will rank your processes by cost. That ranking is not the same as the order you should build them in, because the most expensive process is frequently the hardest one. Add three judgements to each record:
| Judgement | Scale | What a good answer looks like |
|---|---|---|
| Feasibility | High / Medium / Low | High means the data is already structured and the rules are clear. |
| Complexity | High / Medium / Low | Low means it touches one or two systems, not five. |
| Quick win | Yes / No | Yes means it can be built and proven inside a few weeks, visibly. |
Sort by cost, then filter by feasibility. The first thing you build should be a high-feasibility, low-complexity quick win — even if it is third or fourth on the money list. The most expensive process is the one you want to have already proved yourself on before you touch it.
What a finished record looks like
Pulled together, one process fits on a single screen. This is a real shape, not a simplified one — it is the structure our own discovery work is captured in before any figure is calculated:
One process, fully documented
- Name: Chasing overdue sales invoices
- Unit: one overdue invoice | Cadence: weekly | Volume: 40
- Roles: Finance Administrator — 9 mins/unit (£35/hr) · Finance Manager — 2 mins/unit on escalations only (£60/hr)
- Current steps: run the aged debtors report → cross-check against the bank → draft an email per client → log that it was sent in a spreadsheet → flag anything over 30 days to the manager
- Pain points: the spreadsheet log is not always updated, so some clients get chased twice and some not at all; nobody can say what is outstanding without rebuilding the report
- Residual after automation: 2 mins/unit — reading replies and handling genuine disputes
- Feasibility: High | Complexity: Low | Quick win: Yes
Notice that the pain points are doing real work here. "Some clients get chased twice and some not at all" is not a time cost — it is a relationship cost and a cash-flow cost, and it will not appear anywhere in the minutes. Record it anyway. Some of the strongest cases for automating something have very little to do with the hours.
Turning the record into a decision
Once three or four processes are documented this way, the decision mostly makes itself. Annual cost is volume × minutes × rate, per role, across the working year. Rank them, apply the feasibility filter, and the first build is obvious.
Before you commit to building anything, check
- Every minutes figure was measured, not estimated
- Each role is costed at its own loaded rate, not a single blended average
- Every process has a residual-effort figure, so no saving claims to be total
- The pain points include failures, not only delays
- The first process chosen is a quick win, even if it is not the biggest number
- Someone who does the job has read the record and agrees it describes reality
That last one catches more errors than the rest combined. A process record that the person doing the work does not recognise is a description of the official procedure, and automating the official procedure rather than the real one is how automation projects quietly fail six weeks after launch.
Frequently asked questions
How long does documenting a process take?
The writing is usually under an hour per process. The measurement takes longer — timing minutes-per-unit over about two weeks tends to give a more defensible figure than estimating, because a single week is often atypical. Several processes can be measured in parallel.
Is process mapping software needed?
Generally not. A table with six columns — unit, cadence, volume, roles and minutes, current steps, pain points — can carry everything the decision needs. Mapping tools produce better diagrams, but a diagram on its own carries no quantities, and quantities are what answer the question.
What is the most common omission?
Residual effort — what is still done by hand after automation. Treating a process as going to zero can overstate a saving substantially; in the illustrative example on this page it would overstate it by roughly 28%. The saving is current effort minus remaining effort, and the remaining effort is rarely nil.
Should one average hourly rate be used for everyone?
Usually not. A single blended rate prices a manager's twenty minutes the same as an administrator's, which can hide a useful finding: expensive people doing routine work. Costing each role separately tends to make the ranking more informative, though it does require knowing your loaded rates.
Which process should be documented first?
Often the one people complain about most, simply to get the method working — then three or four others before deciding anything. One documented process gives a number with nothing to compare it against; several give a ranking, which is what the decision actually needs.
Want this applied to your business?
A free 30-minute automation review turns any of these ideas into a costed plan for your own processes.