“Why is everything slow?” is the wrong question. It leads to vague “we need more focus” answers and another all-hands. The useful version decomposes cycle time stage by stage, splits work from wait, and surfaces the one stage where most of the elapsed time is queue, not action.
That split matters because the queue is almost always the problem. Across knowledge-work teams that don’t actively manage flow, flow efficiency (active work time ÷ total elapsed time) typically lands at 15-25% — meaning 75-85% of the time between starting and finishing a task, nobody is touching it (per Lean Kanban University, as cited June 2026). Optimize the work and you shave the small 15%; cut the wait and you reclaim the other 85%.
The prompts below force that decomposition, name the stage with the worst wait-to-work ratio, and propose a ranked fix plan instead of scapegoating one team. Paste them into ChatGPT (GPT-5.5), Claude (Opus 4.7 / Sonnet 4.6), or Gemini 3.1 Pro — any of the three reasons well over a stage table. Once you have a named bottleneck, pair these with process improvement prompts to design the actual change.
TL;DR
- Measure wait, not work. Most teams are at 15-25% flow efficiency; the bottleneck is the longest queue, not the slowest worker.
- Decompose first (prompt 1), split wait vs work (prompt 2), then fix only the top stage (prompt 3). Optimizing a non-bottleneck adds zero throughput.
- Little’s Law (
cycle time = WIP ÷ throughput, prompt 7) tells you the WIP cap that actually shortens cycle time. - Get a baseline before you touch anything — otherwise you can’t tell whether the fix worked.
Best for
- Engineering velocity audits (DORA lead time, review wait, CI duration)
- Support ticket-time analysis
- Sales cycle audits and pipeline leakage
- Hiring pipeline audits and time-to-hire
- Approval-chain and handoff reviews
- Cross-tool workflow consolidation
Which prompt to use
| Goal | Use prompt | Output |
|---|---|---|
| See where time goes | 1. Cycle-time decomposition | Stage table, top suspect |
| Prove it’s queue, not work | 2. Wait vs work | Top 2 wait-heavy stages |
| Decide the fix | 3. Remediation options | 4 options ranked impact × effort |
| Stop bounce-backs | 4. Rework rate | Root causes + controls |
| Trim approvals | 5. Approval-chain audit | Removable / stuck approvals |
| Cut tool-hopping | 6. Tool-switching cost | Consolidation list |
| Set a WIP cap | 7. WIP via Little’s Law | Per-stage WIP limit |
| Ship the plan | 12. Bottleneck-to-roadmap | 90-day plan with owners |
1. Cycle-time decomposition
Workflow: [workflow]. Stages: [stages]. For each stage, estimate (a) median
time, (b) variance, (c) primary cause of waiting (handoff / approval / tool
switch / rework). Output a stage-by-stage table with the top suspect
highlighted and the % of total cycle time each stage consumes.2. Wait vs work time
For each stage in [workflow], split total elapsed time into WORK time (active)
vs WAIT time (queued / approval / handoff). Report flow efficiency = total work
time / total elapsed time. Any stage where wait > 50% of its own time is a
bottleneck candidate. Identify the top 2 and explain what kind of wait
dominates each.3. Bottleneck remediation options
For the top bottleneck stage, propose 4 remediation options: (a) Eliminate the
stage, (b) Parallelize with other work, (c) Automate, (d) Pre-stage prep. For
each: estimated cycle-time reduction, effort to implement, risk introduced.
Rank by impact / effort.4. Rework rate audit
Identify stages with high rework rate (work bounces back upstream). Diagnose
root causes: (1) Unclear input from prior stage, (2) Missing handoff doc,
(3) Late discovery of a constraint, (4) Skipped acceptance check. For each:
one preventive control + who owns it.5. Approval-chain audit
This workflow has approval steps. Audit: (1) Approvals that pass >= 95% of the
time (candidates for removal or opt-out), (2) Specific approvers who are
bottlenecks (out-of-office, SLA breaches), (3) Approvals that exist for legacy
reasons no one remembers. Recommend trims and the risk of removing each.6. Tool-switching cost
How many tools does an item cross in this workflow? List them. For each tool
boundary: time lost to context switch, copy-paste, missed notification, manual
status sync. Recommend consolidations, with the single most impactful change
first.7. WIP limit recommendation
The team has too much work-in-progress. Using Little's Law
(cycle time = WIP / throughput), recommend a WIP cap per stage given our
current throughput of [items per week]. Explain the math so the team agrees
with the cap instead of resenting it. Don't over-engineer it.8. Engineering velocity audit
Eng workflow: open -> in-progress -> code review -> merged -> deployed.
Identify which stage drags. Likely culprits: code-review wait, CI duration,
deploy gates, environment availability. Output stages ranked by median wait
time + the single highest-leverage fix. Map each stage to the DORA metric it
affects (lead time for changes, deployment frequency).9. Support ticket-time analysis
Tickets take an average of [avg] to close. Decompose: triage -> first-response
-> investigation -> fix -> verification -> close. Find the stage with highest
wait. Suggest one intervention (macro/template, automation, escalation rule)
with the expected reduction in time-to-close.10. Sales cycle audit
Sales workflow: lead -> qualified -> demo -> proposal -> close. Audit:
(a) stage-to-stage conversion rate, (b) average time per stage, (c) where
opportunities die quietly vs explicitly. Identify the leakiest stage and the
single sales-motion change that could fix it.11. Hiring pipeline audit
Hiring pipeline: sourced -> phone screen -> onsite -> offer -> accepted. Audit:
(a) median time per stage, (b) drop rate per stage, (c) most common reason
candidates drop at each stage. Output 3 targeted fixes ranked by impact on
time-to-hire.12. Bottleneck-to-roadmap
I identified bottlenecks A, B, C (pasted below). Prioritize by impact / effort.
Output a 90-day plan: month 1 = quick wins (no new tooling), month 2 = process
change (requires team alignment), month 3 = automation or tool consolidation.
For each month: owner and one success metric.
[paste bottleneck list]Common mistakes
- Asking “why is everything slow?” instead of decomposing cycle time stage by stage.
- Optimizing a non-bottleneck stage. It doesn’t reduce total cycle time; it only adds slack ahead of the real bottleneck (Theory of Constraints 101).
- Scapegoating one team. Bottlenecks are systemic; the team is downstream of the design.
- Ignoring wait time. Work time is usually the smaller slice but gets all the attention.
- No baseline before the fix. Without a starting flow-efficiency number you can’t prove the change worked.
- Adding approval steps “for visibility.” Every approval is a wait queue in disguise.
FAQ
What’s a realistic flow-efficiency target? Most knowledge-work teams sit at 15-25% (the rest is wait). A well-managed process reaches ~40%, and world-class Lean operations push past 50%. Don’t chase 100% — some buffering is healthy. Doubling from 15% to 30% usually halves cycle time on its own.
Why does optimizing a non-bottleneck stage do nothing? Total throughput is capped by the slowest stage. Speeding up any other stage just makes work pile up sooner at the bottleneck. This is the core idea of Goldratt’s Theory of Constraints: improve the constraint, or you’ve improved nothing the customer feels.
How do I get the time data if we don’t track it? You don’t need a tool first. Have the AI estimate from your description, then sanity-check two or three stages against real timestamps (PR opened vs merged, ticket created vs first reply, lead created vs demo booked). Rough numbers expose the bottleneck just fine; precision can come later.
Which AI model should I run these in? Any current frontier model handles a stage table well as of June 2026. ChatGPT Plus ($20/mo, GPT-5.5), Claude Pro ($20/mo, Sonnet 4.6 / Opus 4.7), and Google AI Pro ($19.99/mo, Gemini 3.1 Pro) all work. For multi-stage reasoning with lots of pasted context, use a “thinking” mode (GPT-5.5 Thinking, Claude Opus 4.7) and feed it real timestamps.
What is Little’s Law in one line?
Cycle time = WIP ÷ throughput. If 30 items are in progress and you finish 6 a week, average cycle time is 5 weeks. Cutting WIP to 18 (same throughput) drops it to 3 weeks. That’s why a WIP cap shortens delivery at no extra cost.
Related
- Process improvement prompts
- Project planning prompts
- Weekly report prompts
- SOP drafting prompts
- Project risk analysis prompts
- Productivity & Office Prompts hub
Tags: #Prompt #Productivity #Bottleneck