Lesson 84.1 gave you the spine: trigger → inputs → work → review → output → record → improvement. Now comes the discipline that saves more money than any automation platform: look at where jobs actually stall before you buy, build, or automate anything.

Most teams automate the loudest complaint. The loud task is rarely the constraint. This lesson teaches you to find the real one.

The vocabulary of waiting

• A bottleneck (or constraint) is the step whose capacity sets the throughput of the whole operation. Improve anything else and total output barely moves.
• A queue is jobs waiting for a step: drafts awaiting review, inquiries awaiting an expert answer.
• A handoff is work passing between people or systems. Every handoff can drop context, add delay, or add rework.
• Rework is doing a step again because the input was incomplete or the standard was unclear. Rework is a quiet bottleneck: it consumes capacity without appearing on any dashboard.
• Lead time is trigger to delivered output. Cycle time is the active work portion. When lead time is long but cycle time is short, the job spent most of its life waiting — the bottleneck is a queue, not slow work.

Picture a lesson pipeline: research takes two days, drafting three, review waits eleven days for an editor's afternoon. Drafting feels like the hard part, but the constraint is review capacity. Automating drafting would pile more drafts onto an eleven-day queue. Throughput would not move; frustration would.

Trace five jobs

Theory will not find your bottleneck. Evidence will. Pick five recent jobs of the same type — five published posts, five answered inquiries, five delivered orders — and follow each from trigger to output. For each one, record:

• Where did it wait, and for how long?
• What questions came back for missing or unclear inputs?
• What corrections or rework happened, and at which step?
• Which handoff lost information?

A simple table works:

| Job | Longest wait (where, how long) | Questions asked back | Rework | Missing input |

|-----|-------------------------------|----------------------|--------|---------------|

| #1 | … | … | … | … |

Five is a deliberate number: one job is an anecdote, fifty is a research project. Five real traces almost always reveal a pattern — the same approval that waits, the same missing brief field that causes rework, the same handoff where context dies.

A worked miniature: a local service traces five bookings. Intake takes minutes every time. Delivery takes a day. But three of five jobs waited four to six days between "customer said yes" and "work scheduled" — the scheduling handoff, owned by nobody, tracked nowhere. Questions came back twice asking for the address already given in the inquiry. The constraint is not delivery speed; it is the unscheduled, unowned handoff plus intake forms that lose fields. Fixing delivery first would change nothing customers feel.

Why the loudest task is rarely the constraint

The loudest task is the one people complain about: "writing takes forever," "the inbox is overwhelming." Complaints track effort and annoyance, not system capacity. The constraint is often quiet and boring:

• An approval only one person can give.
• Fulfillment or delivery capacity nobody wants to discuss.
• Missing inputs that force every job through two rounds of questions.
• A review step with no scheduled time, so everything queues behind it.

Automating a non-constraint feels productive and changes nothing measurable. Worse, speeding up work before the constraint just builds a bigger queue in front of it — more drafts waiting, more tickets pending — and queues have costs: stale context, expired information, annoyed customers.

The rule, borrowed from the theory of constraints: find the constraint, exploit it (make sure it never waits on trivia), subordinate everything else to it, and only then consider expanding it. Automation is one way to expand it — after you understand it.

Exercise: write your BOTTLENECK-NOTES.md

Create BOTTLENECK-NOTES.md with five observations (one per traced job) and one evidence-based priority:

# BOTTLENECK-NOTES — [operation name]

## Observations (5)
1. Job [id]: waited [where, how long]; questions: […]; rework: […]; missing input: […]
2. …
## Pattern
- The recurring constraint is: […]
- Evidence: [which jobs, which waits]
## One priority
- Improve [this step] by [this change], because [evidence].
- Explicitly NOT doing yet: [loud task], because [why it is not the constraint].

Finish line: one improvement target justified by traces — not a tool-shopping list. "Give the editor two scheduled review blocks per week because three of five jobs waited 8+ days at review" beats "buy an AI writing tool."

Verify: check that your priority names a step on the 84.1 spine and cites at least three of the five traces. If it cites none, it is an opinion, not a finding.

Common failure mode: tracing jobs from memory instead of records. Use timestamps: sent folders, edit histories, ticket logs. Memory edits out the waiting.

Check your understanding

1. Lead time tripled while cycle time stayed flat. What does that tell you? 2. Why does speeding up a non-constraint step fail to raise throughput? 3. What makes rework a bottleneck even when every individual step looks fast?

Next, Lesson 84.3: with the constraint identified, write the automation contract — the implementation-ready specification that says exactly what a workflow may do, what it must log, and what it must never touch.