The Operations Bottleneck Audit

I want you to help me diagnose an operational bottleneck in one process in my business: [name it here with its start and end, for example "Lead → signed customer", from first contact to a signed agreement]

The decision this needs to inform: not decided yet — ask me before continuing.

Your job is not to give generic business advice or recommend an AI solution. Your first job is to understand how the work happens.

I will give you evidence from: whatever records that process already leaves behind, which may include a CRM, accounting, email, calendar, task or project software, support tickets, HR records, written procedures, or a spreadsheet I fill in by hand. Work from whatever subset of this the business actually has, and say plainly where there isn't enough evidence to know something.

Work through these stages, in order, as your working:

1. INVENTORY THE EVIDENCE
Read back the process and the decision this is for; if I haven't
given you the decision, ask. Then list what I gave you: each
file or note, what it covers, its date range, and what the
stages below need that isn't there. Do not proceed as though a
missing record means nothing happened.

2. RECONSTRUCT THE PROCESS
Describe what happens, start to finish, based only on the
evidence. The major steps, who and what systems are involved,
where a step depends on another person or system, and where work
waits, gets handed off, gets repeated, or gets escalated. Give
touch time and elapsed time as separate totals where the
timestamps allow it. Separate facts from assumptions.

3. IDENTIFY FRICTION
Where work waits, gets stuck, gets repeated, gets handed off,
requires escalation, or depends on one person. For each, the
rows or messages it rests on. Don't assume every inefficiency is
important.

4. IDENTIFY CANDIDATE BOTTLENECKS
For each significant issue, say whether it looks like a symptom,
a local inefficiency, or a real bottleneck on the larger
business, and its likely effect on throughput, revenue,
capacity, cash flow, and management attention.

5. CHALLENGE THE DIAGNOSIS
Don't simply agree with my assumptions. For each candidate: what
evidence supports it, what contradicts it, what else could
explain it, what's missing, and what we'd expect to see if it
really were the bottleneck.

6. FIND THE UNDERLYING CAUSE
Ask "why" repeatedly to move from the visible problem to its
cause. Don't call something a root cause unless the evidence
supports it. Keep observed facts, likely causes, hypotheses, and
unknowns separate.

7. NAME THE BOTTLENECK AND SIZE IT
Identify the issue most likely limiting the larger system, and
explain the reasoning. Put a number on it from the evidence: how
much work, time, or money it holds up per week or month, and the
rows that number rests on. If the evidence can't support a
number, say what would. Do not recommend a solution yet.

8. GENERATE INTERVENTION OPTIONS
Only now: eliminating the work, simplifying it, changing
ownership, changing the decision rule, improving the information
available, and technology or AI, cheapest and easiest to undo
first. Don't assume AI is the answer.

9. DESIGN A TEST
The smallest practical change that would test whether the
intervention affects the bottleneck: what we'd change, what we
expect to happen, what to measure, its baseline today, how long
to test it, and what result would tell us the diagnosis was
wrong.

HOW TO REPLY
Do the stages above as your working. Do not show me the working.
If a stage needs an answer from me, ask that one question and
stop. Otherwise reply with the headline and the brief alone, in
the shape below, and lead with the headline every time, even
when the news is that nothing needs to change.

Keep the writing under 900 words and the whole reply, table
included, under 1,200, and count both before you send it.

THREE THINGS ARE OUTSIDE THAT BUDGET AND CANNOT BE SHORTENED,
MERGED AWAY, OR DROPPED TO MAKE ROOM: the headline's four lines,
the required lines in section 1, and the rows of the table.
Write those first, then spend what is left of the budget on the
prose. If you are over, tighten sentences and cut adjectives
everywhere; if that is not enough, shorten sections 3, 6, 8 and
9, in that order. Never buy words by dropping a finding, a row,
a number, or a required line.

Inside the table, every cell is a phrase rather than a sentence,
about a dozen words at most; anything that needs a sentence to
be fair belongs in "What to change" or "Still to confirm".

BEFORE YOU SEND IT, CHECK ALL FIVE:
- the headline is four labelled lines, under 120 words, and
  names the specific thing rather than a category;
- section 1 carries every required line, with "none" written in
  where one does not apply;
- every finding you named has a size, or a stated reason it
  cannot be sized;
- every row you merged says that it is merged;
- both word counts are inside their limits.
If any of these fails, fix it and take the words from the prose.

If I say "show your working", show the ledger and every rule you
applied.

THE HEADLINE
Open with this. Four labelled lines, under 120 words in total,
before any scope, method, or description of what I sent you.
Someone who reads only these four lines has the answer.

- The finding. One or two sentences naming the specific thing
  that is holding the business back, or where the money is
  going. Name the thing, never the category: not "a process
  issue" but the step, the channel, the queue, the person's
  calendar. Where the records disagree with what I believed,
  that contrast belongs here and nowhere else.
- What it costs. The single number that sizes the finding, with
  its period and unit, and the one line of arithmetic behind it.
  If the evidence cannot put money on it, size it in the unit it
  can - hours, days waiting, deals, seats - and say plainly that
  money isn't available and why.
- Do this first. The cheapest fix, what it costs, and who does
  it. Then, if I asked you to decide something, the answer in
  one line, labelled a judgment where it is one.
- How sure. "High confidence: from your own records", "Medium:
  your records plus what you told me", or "Low: mostly what you
  told me" - then the single thing that would most change the
  answer if it turned out otherwise.

THE BRIEF
Everything below supports the headline for a reader who wants
more. Expand it; do not restate it in the same words.
1. What this ran on. Labelled lines, not prose. These are
outside the word limit and none of them may be dropped; write
"none" where one does not apply.
- Scope and period.
- The decision this is for.
- Scored: what you included, and how many.
- Excluded: how many, why, and what they were worth.
- Evidence pulled: the date the records were pulled.
- Computed with: the tool you used and the rule you applied, or
  that you had no tool and worked from summary figures.
2. What the evidence covered. Three to five bullets: what I gave
you, the period it covers, and what was missing that would have
changed the answer.
3. What we found. One paragraph, under 150 words, in plain
words: how the work actually runs and what the evidence shows,
in enough detail to make the headline's finding stand up.
4. The numbers. What the bottleneck holds up per week or month
(work, time, or money), the cost of the test, and the one number
that would show the test worked. For each: how it was computed
and which rows it rests on.
5. The ledger. One table, one row per candidate bottleneck: the
symptom, the evidence for and against, whether it is a symptom,
a local inefficiency, or the bottleneck, and its verdict.
A finding too small or too uncertain to act on still gets its own
row, marked as such. Where the table is long, you may merge rows
only when they are the same kind, and the merged row has to say
so. Never drop one.
6. What to change. Every fix, cheapest first, the headline's
included, with one line each on why the more expensive ones
aren't needed yet.
7. How you'd know it worked. For each fix, in this order and
always these four: the measure, named the same way you would
name it again next time; its baseline today, with the date the
evidence was pulled; the target; and the result that would mean
the diagnosis was wrong. Write them so someone re-running this
in a month can line their numbers up against yours without
having to interpret anything.
8. Still to confirm. Up to four things the evidence couldn't
settle, each with exactly what would settle it.
9. Not claiming. Up to five claims you are refusing to make, one
line each.

RULES THROUGHOUT
- If you have a code or data-analysis tool, use it for every
  count, median, and total, and state the rule you applied. If you
  don't, say so and ask me for summary tables instead of raw
  exports.
- Never invent a number that is not in my evidence. Where a
  value is blank, say so and leave it out of the totals rather
  than estimating it.
- Numbers I gave you in the walkthrough count as evidence: use
  them where the records have nothing, and label each one as my
  estimate.
- Never quote an industry benchmark, average, or percentage from
  outside my data, even if I mention one. If I ask how I compare
  to one, tell me plainly that you are not going to and why,
  rather than leaving the question unanswered.
- My exports often cut the same figures more than one way.
  Before adding two numbers together, check they come from the
  same cut; if they do not, report them side by side and say which
  values may be counted in both rather than summing them.
- Where I have told you something happens off-system or goes
  unlogged, silence in the records there is not evidence of
  anything. Say what would need to be logged.
- Where you nest one finding under another as its cause, the
  parent carries the rolled-up total of everything beneath it,
  labelled as a roll-up so no figure is counted twice. Every item
  you size belongs to exactly one total, and no finding you name
  is left without a size unless you say what is missing to size
  it.
- Keep observed facts, inferences, and unknowns separate. It is
  fine, and often correct, to conclude the evidence cannot settle
  something.
- If I push you for a verdict on the decision afterwards, give
  your best read, label it a judgment rather than a finding, and
  say what would change it.
- Don't confuse activity with results, or an annoying problem
  with a business bottleneck.
- Don't recommend technology just because it's available.
- Your goal is to find what's holding the business back, not to
  make it sound more sophisticated than it is.