Complete systemBuilt to be run. Everything below is yours to use, with or without us. The last section is a prompt you paste into any AI assistant along with your own log.

The Waste Diagnostic

Find the work in one process that exists to serve the process rather than the customer, put a number on it, and decide what happens to each piece. This is the complete system in one place: the checklist, the worksheets, the pattern lists, the finding format, and the exact prompts, so you can run it on a real process over the next two weeks. One example runs through the whole page, a supplier-invoice process at a firm of about thirty people, so every blank has a filled-in version next to it.

You need one process, two weeks of honest observation, and the willingness to describe what happens rather than what is supposed to happen. Nobody has to be told they are the problem, and nobody is.

What you are looking for

Every step in the process is for somebody. There are three possible answers and the answer decides what you are allowed to do about it.

The customer. Work the person you named came for, which correctly moves their case toward it, performed right the first time. Protect it and aim at more of it.

A named requirement. Work a law, regulator, contract, insurer, or documented risk obliges you to do. Keep the purpose and challenge the execution.

The process itself. Work that exists because of how the work is arranged. Aim at it stopping, and say out loud when you settle for less.

The output is a short list of findings, each carrying the pattern that names it, the number that sizes it, and the decision that follows. It is not a percentage of wasted time, and a business case resting on somebody else’s published percentage is the easiest thing in the room to argue with.

Name the decision before you start, because it changes what counts as a finding. Working out whether you can take on more work without hiring is a different exercise from working out why this process embarrasses you in front of customers, which is different again from working out what a new system would have to do. An audit with no decision attached is an inspection, and inspections get filed.

Pick one process

One process, one customer, one clear start and finish. Everything below runs on that and nothing else.

Choose something that runs often enough to observe several times in two weeks and that somebody in the room owns. Define it as a span rather than a department: from the request arriving to the thing being finished, whatever crossings it makes on the way.

Example

The process: from a supplier’s invoice arriving to the payment leaving the bank

The customer and what they came for: the supplier, who has already delivered and wants paying accurately and on time

The decision this is for: whether the firm can take on a third more work next year without adding anyone in finance

Write these three lines before anything else

The process: from ______ to ______

The customer and what they came for: ______

The decision this is for: ______

The second line settles most of the arguments that come later. When two people disagree about whether a step is waste, they are usually picking different customers without having noticed. The third line is what keeps the exercise from being filed.

Evidence checklist

Gather it before you interpret any of it. Reading as you collect is how the first irritating example becomes the conclusion.

From the systems

Every case that ran through the process in the period, with the timestamp at each stage it touched
Queue age: how long items sat before somebody picked them up, especially at approvals and decisions
Work in progress: how many cases were open at once, and how old the oldest was
Rework signals: reopened items, corrections, credit notes, amended documents, resent messages
Duplicate records, and what created them
The reports and dashboards this process produces, with who opens them
The recurring meetings attached to it, with attendees, duration, and what each one decides

From the people doing it

A walkthrough in their words, describing what happens rather than the documented procedure
Where they go looking for information, and roughly how long it takes to find
What they re-key from one place into another
What they chase, and who they chase
The questions they have to ask before they can start, and who they ask
The exceptions: how often the normal path fails and what they do instead
What they would change first if it were entirely up to them

If nothing useful is logged

Run the smallest tally that can answer the question, for two weeks, one row per event. A shared sheet is enough and one person has to own the definitions.

Columns: date · a reference of your own for the job or case · what happened · who did it · minutes spent · how long it had been waiting · a note. Leave a pattern column empty while you log; you sort them afterwards, all at once.

Three rows from the invoice log, so you can see the grain:

Date	Ref	What happened	Who	Min	Waited	Note
Sep 3	INV-2291	Re-typed header fields into accounting	AP clerk	6	0	Scanner had already read them
Sep 9	INV-2291	Emailed owner to chase approval	AP clerk	2	—	Second chase
Sep 12	INV-2291	Approved	Owner	3	9 days	—

Scroll sideways for the rest of each row.

Two weeks of real rows beats a year of recollection. Start it on Monday and the exercise has evidence by the end of the month.

How to tell the people who do the work

A log that arrives unexplained reads as a stopwatch study, and people respond to stopwatch studies by working differently for two weeks. Say this, or something like it, before the first row is written:

Say: “For the next two weeks I want to write down what happens to a supplier invoice between arriving and being paid: each step, how long it takes, and how long it sat before anyone could get to it. I’m not measuring how fast anyone works. I’m measuring how the work is arranged, and most of what I expect to find is time nobody is spending, where an invoice sits in a queue. You keep the log yourselves. Nobody’s name goes in the write-up, and the first thing I want from you is your own list of what you’d change.”

Then do these three things: let them keep the log, rather than logging them; put “what would you change first” on the walkthrough agenda and mean it; and show them the ledger before anyone senior sees it, so the first correction comes from the people who know.

The findings are about queues, re-entry, and unowned decisions. If one turns out to be about a person, it is a management conversation and it does not go in the brief.

Know what the evidence will not show you

Elapsed time: systems record when somebody acted, rarely how long the work sat before they did. The wait is usually the largest number in the process and the one nobody owns.

Interruption: nothing logs the four times a person was pulled off this to do something else. It shows up as work taking longer than it should for no recorded reason.

Work done off-system: the spreadsheet, the side chat, the personal checklist somebody built because the real system does not fit. This is where the most interesting findings live and only the walkthrough surfaces it.

Ambiguity: leaves no trace at all. You infer it from clusters of clarification, rework, and meetings that keep re-deciding the same thing.

These gaps are not obstacles to the exercise. They are the reason the walkthrough exists, and the reason a finding sourced only from a system export is worth less than one somebody confirmed out loud.

Getting your evidence into an assistant

The step nobody writes down, and the one that stops most people before they start.

Getting the files out

Nearly every business system has an Export or Download button that produces a CSV or Excel file. Your project tool, ticket queue, accounting system, or shared drive will have one.
For email, you don’t need to export a mailbox. Open the thread that matters and copy the text, or forward it to yourself and copy it from there.
If something won’t export, photograph the screen. These assistants read screenshots, and a legible screenshot of a report beats a description of it.
If nothing exports at all, you can still run this by writing down what happened — as long as you stick to what you could check later. Dates, counts, amounts, who did what. Not your impression of how it went.

Which assistant, and how many chats

ChatGPT, Claude, Gemini, and Copilot all work. You want one that accepts file uploads; the free tiers of ChatGPT and Claude do, with a daily cap on how much you can send.
Keep the whole thing in one conversation. Upload your evidence at the start and send the prompts in order, so what you uploaded is still in front of it when you reach the later ones.
Start a fresh chat when you move to a different process, month, or account. Mixing two sets of evidence in one conversation is the most common way these go wrong.
If a long upload fails or the replies start drifting, send less at a time: one campaign, one month, one stage of the process.

Before any of it leaves your building

Check first: customer and client material can be covered by your engagement terms, your professional obligations, or privacy law. Whether you may send it to a third-party assistant is a question for you and, if you have one, your lawyer. It is not a question we can answer for you, and no page on this site assumes you have.

You probably don’t need the names: a diagnosis runs on dates, counts, amounts, timestamps, and who did what. Names almost never change the answer. Replace them with Client A, Client B, Supplier C before you upload, and the exercise works exactly as well.

Check the setting once: consumer tiers of some assistants may use what you send to improve their models. Business and team tiers generally do not, and the control sits in the account’s privacy settings. Worth two minutes before you start rather than after.

None of this is a reason to skip the exercise. It is the reason to spend ten minutes on the first upload deciding what actually needs to be in it.

Write out what happens, step by step

Write the process out as individual actions. This is where the exercise is usually lost, because it is tempting to work at the level of names people already use.

“Onboarding,” “approval,” and “intake” are containers. Asked who they are for, the answer is always some version of “required,” the container gets an exemption, and you finish having found nothing. Break each into actions with one actor, one input, and one output, and give every wait a row of its own.

One row per action

Action: ______ (one actor, one output)

Who it’s for: the customer / a named requirement / the process

If a requirement: ______ (which one, and who requires it)

Touch time: ______

Wait before it: ______

Where the pile is arguable, write both candidates and what would settle it. Those rows are the ones worth taking back to the people who do the work.

Example — four of the eleven rows in the invoice process

#	Action	Who it’s for	If a requirement	Touch	Wait before
3	AP clerk re-types the header fields the scanner already read	The process	—	6 min	0
4	AP clerk matches the invoice to the purchase order and the delivery note	A named requirement	Firm’s payment control: nothing is paid that was not ordered and received. Owner: the managing partner	8 min	2 hrs
5	AP clerk emails the owner to chase the approval (twice, on average)	The process	—	2 min	—
6	Owner reads and approves the invoice	Arguable: the approval is required, the wait for it is not	Same control as row 4. Nothing says every invoice needs the owner	3 min	9 days
	All eleven rows			41 min	14 days

Scroll sideways for the rest of each row.

Row 6 is the one that gets argued about, so both candidates are written down. The argument is settled by splitting it: the approval stays in the required pile, the nine days go in the third.

Keep two clocks on every row. Touch time is the minutes somebody spent working on it; elapsed time is how long the case sat between one action and the next, inbox time included. When the rows are done, total them separately and put the two side by side. For the invoice: 41 minutes of touch time inside 14 days of elapsed time, which is what “invoice approval takes a couple of days” turned out to mean. In most office processes the second is many times the first. That ratio is the single most persuasive number this exercise produces, and it belongs at the top of the brief.

Work out who each step is for

Now answer the question for every row. Full method in System 01.

It is customer work only if all three pass

Customer test. Would the person you named recognize this as part of what they came for?
Transformation test. Does it correctly move their case toward that outcome?
Right-first-time test. Is this the first correct performance, rather than a correction of an earlier one?

It is required work only if this has an answer

“What exact requirement or risk would we violate, and who requires it?”
Answers that hold: a statute or regulator rule, a signed contract clause, a licensing or insurance condition, a documented safety or control requirement, a quantified exposure, a technical constraint that cannot be removed yet.
Answers that do not: we have always done it, Finance likes it, somebody might ask later, that is how I was trained, the old system needed it.

Where the requirement is real, split the row in two. The objective belongs in the required pile. The specific execution is a design decision somebody made once, and any excess in it belongs in the third pile even when everyone involved would describe the whole thing as mandatory.

Internal effort alone is not value. Seniority, duration, difficulty, and attendance have no bearing on which pile a row lands in.

Name the patterns, in this order

Take the third pile and name each row. Full lists in System 02. Run the passes in this order, because each one makes the next easier.

Waits and queues. Start here. It is the biggest number, the easiest to evidence from timestamps, and the one nobody currently owns, so naming it creates no conflict.

Duplication and re-entry. The same information supplied, typed, or answered more than once. Visible in the walkthrough and uncontroversial once written down.

Rework, defects, and chasing. Corrections, reopened cases, and the pursuit of missing information. For each, find where the defect originated rather than where it was noticed.

Output nobody uses. Reports, updates, and meetings. Check who opens each report and what each meeting decides. Then check the cadence against the decision it feeds.

Searching and over-processing. Time spent finding the current version or the right person, and work done in more detail, more often, or by more approvers than the next step requires.

Load, interruption, and sequence. Where one person is the required path, where the day is fragmented, and where work is ordered by who asked loudest.

Trace back to ambiguity. Last pass, and the most valuable. For each finding so far, ask what somebody would have had to know, decide, or own for it never to have happened. Where the same answer keeps returning, that answer is the finding and the rest are its consequences.

Measurement gets its own look while you are here. If any of these patterns is being produced on purpose by a number somebody is judged on, no redesign of the process will survive, and the finding is the measure rather than the step.

How to write up a finding

Anything that cannot be sized stays a question. Questions go on a separate list with the evidence that would settle them.

The shape of a finding

Pattern: which one, and whether you spotted it from the customer’s side or from inside the work

Where it shows: the step, the queue, the report, the system

How often: per day, per week, per case

Cost per instance: time, and whose

Reaches the customer: yes / no, and how they’d describe it

Upstream of it: the ambiguity or decision this traces back to, if any

A finding without a frequency is a story. A finding without an owner’s name on the time is a number nobody will defend in the room where it gets discussed.

Example — the largest finding in the invoice process

Pattern: waits and queues, seen from inside. From the supplier’s side it is “waiting on you.”

Where it shows: the owner’s inbox, between the invoice being matched (row 4) and being approved (row 6)

How often: every invoice. 38 invoices in the two weeks logged.

Cost per instance: 9 days elapsed (median; the range was 2 to 16). Touch time is 3 minutes of the owner’s. The two chasing emails per invoice, 2 minutes each of the clerk’s, are a consequence and sit underneath this finding rather than beside it.

Reaches the customer: yes. Four suppliers called in the two weeks to ask when they would be paid.

Upstream of it: nobody has ever decided which invoices need the owner. The working rule is “all of them,” and it was never written down by anyone.

Add it up

One line per finding, sorted by cost within each pile. This is the document people argue with, so its arithmetic has to be unembarrassing.

Three rules that keep the total honest

One event, one row. An hour spent chasing a missing approval is waiting, or interference, or the consequence of an ambiguity. Pick one. Totals built by adding overlapping categories are why these exercises get dismissed.

Consequences nest under their cause. Where the trace-back pass found a shared origin, the consequences are listed beneath it and counted once, in the parent.

Annualizing is a separate claim. Report the two weeks you measured. Multiplying it up is a second statement, made deliberately, with the assumption that the two weeks were typical written next to it.

Your ledger — one line per finding

Id · pattern · pile · where · count in the two weeks · touch minutes each · whose time · wait each · customer-facing · parent finding

Keep this in a spreadsheet. Underneath it, two totals that are never added together: touch time recovered, which is the payroll number, and elapsed time recovered, which is how much faster the customer gets an answer. They answer different questions.

Example — the invoice ledger, process pile only

Id	Pattern	Where	Count	Each	Whose	Notes
W1	Waits and queues	Owner’s inbox, before approval	38	9 days wait	—	Supplier feels it
W2	Chasing	Clerk emails owner	76	2 min	AP clerk	Consequence of W1
W3	Duplication and re-entry	Re-typing scanned fields	38	6 min	AP clerk	Internal only
W4	Over-processing	Filing the record in two extra places	38	4 min	AP clerk	Internal only
W5	Defects	Duplicate payment, two spellings of one supplier	1	45 min	Bookkeeper	Supplier feels it

Scroll sideways for the rest of each row.

Touch time recovered: about 9½ hours in the two weeks (W2 152 min, W3 228, W4 152, W5 45), nearly all of it the clerk’s.

Elapsed time recovered: about 9 of the 14 days each invoice currently takes, all of it W1.

W2 is counted in the ledger and reported under W1, because the chasing stops the day the queue does. Annualized, the touch time is roughly 250 hours a year, on the assumption that these two weeks were typical, which is a separate line in the brief and says so.

Decide what happens to each finding

Each finding gets the highest rung it can survive. Full method in System 03.

Eliminate. Stop doing it. The only option that returns the whole cost and leaves no residual.

Reduce or combine. Less often, for fewer cases, or inside something already happening.

Simplify and standardize. Fewer fields, fewer approvers, one written way, done where the information already is.

Automate. Only for work that survived the three rungs above. An automated step stops being questioned and quietly becomes permanent.

Accept and monitor. Leave it, write down that you chose to, and date the review.

For anything in the required pile, the objective is fixed and the execution is open. Five levers change the execution without touching the requirement: put a threshold on it, move it earlier, collapse the approvals, take the evidence from the work itself, or change who holds the authority. Whoever carries the risk signs off the new design in writing before it runs.

The shape of a decision

Finding: the pattern, where it shows, what it costs

Pile: customer / required / process

Decision: eliminate, reduce, simplify, automate, or accept

Change: what is different on Monday, and whose name is on it

Expected: what you should see, measured how, by when

Reversal: what result would make you put it back

Measure the whole flow from request to finished rather than the step you changed. Cutting a step releases the demand it was absorbing, and that demand goes into the next queue along.

Example — the decision on W1

Finding: W1, the nine-day queue in the owner’s inbox. 38 invoices in two weeks, suppliers calling to ask.

Pile: process. The approval itself is required; the queue in front of it is not.

Decision: eliminate the queue, by putting a threshold on the approval.

Change: from Monday, invoices under $2,500 that match a purchase order and a delivery note are approved by the bookkeeper; the owner approves everything above that and anything unmatched. The owner signs the delegated limit before it starts. In the last two weeks this would have sent 31 of 38 invoices down the new path.

Expected: median time from invoice arriving to payment leaving falls from 14 days to under 5 within a month, measured on the whole flow from the accounting system’s timestamps. Chasing emails stop. Suppliers stop calling.

Reversal: any payment in the first quarter that the owner says they would have refused, or the whole-flow time failing to move even though the queue is gone, which would mean the wait has moved to the next step and the diagnosis was incomplete.

What the finished brief contains

If it is missing any of these, it is not finished.

In it

The process, the customer, and the decision this was run to inform
Touch time against elapsed time, at the top
The findings, sorted by cost within each pile, each with its frequency and whose time it takes
Consequences nested under the cause they trace back to
A decision line and a reversal line for every finding
The first change, chosen because it is reversible and owned by people in the room
The questions you could not settle, with the evidence each one needs

Not in it

A percentage of time wasted, borrowed from a published survey
Totals made by adding overlapping categories together
An annualized figure presented as an observation
Any finding whose evidence is that somebody remembers it being bad
A recommendation to buy something, arrived at before the three rungs above it were tried
Names. The findings are about how the work is arranged

Example — the invoice brief, on one page

Process, customer, decision: supplier invoice arriving to payment leaving; the supplier, paid accurately and on time; whether finance can absorb a third more volume without a hire.

Touch against elapsed: 41 minutes of work inside 14 days, per invoice. 38 invoices in the two weeks logged (Sep 1–12).

Findings, process pile, by cost: W1 nine-day approval queue (with W2 chasing nested under it) · W3 re-typing scanned fields, 228 min · W4 filing in two extra places, 152 min · W5 one duplicate payment, 45 min plus a supplier refund.

Required pile: R1 the three-way match, kept, with its threshold design going to the managing partner for sign-off.

Decisions: W1 eliminate by threshold (reversal: a payment the owner would have refused) · W3 stop re-typing once a hundred-invoice sample shows the scanner’s accuracy (reversal: accuracy under 98%) · W4 eliminate, one named system of record (reversal: an auditor asking for a copy that is not there) · W5 merge the two supplier records, fix at source.

First change: W4, the extra filing. Process pile, owned by the clerk who found it, reversible in a day, and the clerk notices the difference on Monday.

Open questions: whether the 2 to 16 day spread in W1 tracks invoice size or the owner’s travel (needs three months of timestamps to show); and whether the two suppliers who called have gone quiet since, which the phone log would show.

One page, no percentage, no software. The answer to the decision the brief was run for is yes, on the evidence of the two weeks: the clerk gets roughly a third of the time back that the process took, and the volume increase fits inside it.

The master prompt

Paste this into any AI assistant along with your walkthrough and your log. It runs the whole method in order and will not hand you a percentage.

Run the full diagnostic

I want you to help me find the unnecessary work in one of my
business processes. Your job is not to redesign it or recommend
tools. Your job is to work out which steps exist to serve the
process rather than the customer, put a number on them, and be
exact about how confident we can be for each one.

I will give you a walkthrough of how the process really runs,
and whatever log or system data I have for the same period.

Work through these stages, in order, and do not skip ahead:

1. SET THE FRAME
Read back to me, in one sentence each: the process from start to
finish, the customer it serves, what they came for, and the
decision I said I am trying to make. If I have not told you one
of these, ask before continuing.

2. BREAK IT DOWN
Turn the walkthrough into individual actions: one actor, one
input, one output each. Put every wait between actions on its own
row. Do not use container names like "onboarding" or "approval"
as steps. Give me touch time and elapsed time as separate totals.

3. CLASSIFY EVERY ROW
For each row, say who the step is for:
  THE CUSTOMER - passes all three tests: they would recognize it
  as what they came for, it correctly moves their case toward it,
  and it is the first correct performance rather than a correction.
  A NAMED REQUIREMENT - name the requirement and who imposes it.
  If I have not told you one exists, say you do not know and ask
  me. Never assume a requirement into existence.
  THE PROCESS ITSELF - everything else.
Where a requirement is real, split the row: the objective is
required, and any excess in how it is executed is not.

4. NAME THE PATTERNS
Take everything in the third pile and name each one, in this
order: waits and queues; duplication and re-entry; rework,
defects and chasing; output nobody uses; searching and
over-processing; load, interruption and sequence. Where an event
fits two patterns, name both and say whether each is visible to
the customer or only from inside, then pick one for counting.

5. TRACE BACK
For each finding, ask what somebody would have had to know,
decide, or own for it never to have happened. Where the same
answer keeps returning, make that the parent finding and nest the
others beneath it as consequences.

6. SIZE IT
For each finding: frequency, minutes per instance, whose time,
total for the period, and whether the customer feels it. Use only
what is in the evidence I gave you. Where the evidence does not
support a number, say so and move that item to a separate list of
questions rather than estimating. Never quote an industry
percentage at me. One event, one row: do not build totals by
adding overlapping categories together.

7. DECIDE
Give each finding the highest rung it can survive: eliminate,
reduce or combine, simplify and standardize, automate, accept and
monitor. Justify anything you put on automate by saying why the
three rungs above it fail. For required work, say which of these
would preserve the objective while changing the execution: a
threshold, moving it earlier, collapsing approvals, taking the
evidence from the work itself, or changing who holds the
authority.

8. ARGUE THE OTHER SIDE
For each elimination, make the strongest case that the step exists
for a reason I have not found, and tell me who I should ask. For
each decision, write the reversal line: the specific result that
should make me undo it.

9. WRITE THE BRIEF
Touch time against elapsed time. The findings sorted by cost
within each pile, consequences nested under their cause. A
decision and a reversal for each. The one change to make first,
chosen because it is reversible and owned by people who were in
the room. The questions you could not settle and the evidence each
one needs. And the claims you are refusing to make.

The refusals matter as much as the findings. An assistant asked to audit a process will happily produce a confident list, because that is what the request sounds like it wants. The stages above spend most of their instructions making it say which parts it cannot support, which is the part you would otherwise have to catch yourself.

Run it on one process and you will have a ledger, a first change, and a short list of things you could not settle. Run it on the second process and you will notice the same few causes turning up again, which is the point at which this stops being an exercise and starts being how the business gets looked after.