Library
The Workflow Audit Framework (The Twelve Questions)
Twelve questions that surface the real inefficiency before anyone picks a tool, a model, or a rewrite. This is the framework we walk in an audit, published in full. If you cannot answer question 11, you are not ready to choose.
Last reviewed
MikeFounder & developer
- Workflow
On this page
Who this is for
- Operators about to buy software, add a model, or commission a build
- Teams who can feel the drag and cannot yet name it
- Readers of When Not to Automate who want the structured pass
Why we publish it
Most failed “transformations” start with a tool. Start with the work instead. These twelve questions are the method we use on a live operation, published so you can run them yourself.
They split into three moments: before anyone visits, while you watch a real case, and before you build. Numbering here is an ordered process: Talk through the work, then Scope the problem, then decide what to Build.
Before the workshop
1. What outcome does this process exist to produce?
Not the department's purpose. The output a real case is supposed to end in: a paid invoice, a resolved complaint, a booked job, a published fact. If two people name two outcomes, you do not have one process.
2. Who waits on whom, and for how long?
Name the people, not the systems. Hours and days, not “it depends”. Waiting is often the inefficiency. It is sometimes the judgement. See Automation vs AI before you collapse a wait that was load-bearing.
3. Where does the same fact get typed more than once?
Re-keying is the cheapest win and the one most automation projects skip. Three systems holding the same company name is not an AI problem.
4. Which step exists only because a previous tool was weak?
Workarounds calcify. A spreadsheet that exists because the last CRM could not export is a candidate for removal, not for a model.
5. What breaks when the usual person is away?
If the answer is “everything”, you are about to automate a single point of failure, or you are about to discover that the process was never written down.
During the walkthrough
6. Watch a real case end-to-end. Skip the happy-path slide.
One live file, start to finish, with the people who do it. Recordings and diagrams lie in the same way: they omit the “we just email it”.
7. Note every hand-off, approval, and “we just email it”.
Each hand-off is a queue, an owner gap, or a control. Label which.
8. Ask what people do when the official path is too slow.
That is where the shadow copilots live. Put them on the inventory.
9. Separate policy constraints from habit.
“We have to keep this step” is sometimes a regulator, a contract, or a safety rule. Sometimes it is 2014. Only the first group is non-negotiable.
10. Capture volumes and error rates in plain numbers, not vibes.
How often, how many, how long, how often it is wrong. Without numbers you will automate a feeling.
Before you build anything
11. Name the core problem in one sentence everyone agrees on.
The people who do the work, not only the sponsor. If you cannot, you are not ready to choose automation, AI, or a custom build.
12. Decide what “done” looks like in the operation, then check it against the live work rather than the software demo.
What will be true in twelve months that is not true today: a wait that shrank, a re-key that died, a named owner, a confirm step that actually happens. If “done” is a licence count, you bought a tool.
If you cannot answer item 11 cleanly, stop. Choosing a vendor from that position is how you spend six months implementing the wrong thing.
After the twelve
Decide what to leave alone. That is a decision. Then choose: a better habit, a smaller automation, a focused build, or nothing. The structured picker is Automation vs AI.
Keep it lasting: fewer moving parts, clear ownership, documentation a new hire can follow without a meeting.
Questions
Is this a secret methodology we should have paid for?
No. Publishing it is the point. The paid work is walking it through your operation, with your files, and staying for the build.
Do we have to run all twelve in order?
The three groups are ordered: you cannot skip the watch and still trust the sentence in 11. Inside a group, use judgement.
Can we send the answers as a brief?
Yes. Paste them into the contact form. Incomplete answers are still a brief.
What changed
- 13 August 2026: Full publication of the twelve questions used in Lathestone audits (the same twelve previously issued as a short checklist). Cadence: stable / evergreen (180–365 days). Next review due 13 May 2027.
When you want this walked through a live operation, see Workflow auditing.
Was this helpful?
Also in the library
- The AI Vendor Risk ChecklistA procurement list you can actually use. Data handling, training-on-your-data, sub-processors, audit rights, and model-change notifications: the clauses that decide whether a vendor is safe to put on a live path.
- Automation vs AI: A Decision FrameworkA rule, a model, and a person are three different tools. Use a rule when the path is stable and the answer is known. Use a model when the input varies and a person will still confirm. Leave it with a person when the volume is low, the judgement is high, or the failure is expensive.
- Building an AI System InventoryStart with a list. Most governance programmes stall because nobody has an honest register of what is already in use, including the vendor copilots people forget to mention. The sheet below is the one we use in an audit. Copy it.