The prompt
Score 10 of 10, Excellent
Use it when You need the bottlenecks, handoffs and rework in a process and practical fixes.
- {{audience}}
- {{process_name}}
- {{output_and_customer}}
- {{volume}}
- {{process_steps}}
- {{pain_points}}
- {{constraints}}
Full prompt and why it works
Prompt
Review the process below and find where time, effort and quality are lost, for {{audience}}, who want practical fixes they can start on soon. Process: {{process_name}} What it produces, and for whom: {{output_and_customer}} How often it runs: {{volume}} How it works today, step by step, with who does what and any times you know: """ {{process_steps}} """ Known problems and complaints: {{pain_points}} What cannot change (systems, budget, rules, required approvals): {{constraints}} Produce: 1. Current process: a table with the columns Step, Who, Work time, Wait time, Handoff to, Notes. Use the times given and write "not measured" where there is none. 2. Where time and effort are lost: for each problem, the step, the kind of loss (waiting, handoffs, rework, duplicate data entry, approvals that add little, batching, searching for information, unclear ownership) and the evidence from the notes. 3. The bottleneck: the one step that limits how much the process can handle, and why, if the notes show it. If they do not, say what to measure to find it. 4. Fixes: up to 8, in a table with the columns Fix, Steps affected, Expected effect, Effort (low, medium, high), First move. Put quick, low-effort fixes first. 5. How to tell it worked: 2 or 3 measures to track before and after, such as time from request to completion. Keep it under 900 words. Each fix should be specific enough to act on, for example "Let team leads approve orders under the limit in our policy instead of sending every order to the director", not "streamline approvals". Some steps that look like waste are controls, such as a second check on payments or a sign-off a policy requires. Do not recommend removing a control; label it as a control and suggest ways to make it faster instead. Respect what cannot change, and do not recommend new software unless the constraints leave no other option, in which case say so. Do not invent times, volumes or costs. If a step is unclear, or the notes disagree about how it works, list it under "Questions for the people who do the work" rather than guessing.
Variables
- {{audience}}
- Who will act on the review, for example "the finance operations team and its manager".
- {{process_name}}
- The process's name, for example "supplier invoice approval".
- {{output_and_customer}}
- What the process delivers and who receives it.
- {{volume}}
- How often it runs or how many items go through, for example "about 400 invoices a month".
- {{process_steps}}
- Each step as it really happens today, with who does it and any times you know: notes, a transcript or a list.
- {{pain_points}}
- What people complain about: delays, errors, chasing, duplicate work.
- {{constraints}}
- What cannot change, such as a system you must keep or an approval a policy requires.
Why it works
- Background facts. A step table that separates work time from wait time shows where a process actually loses time, which is usually in the waiting.
- What to avoid. Controls such as a second check on payments are labeled and kept, so a fix never removes a safeguard that only looks like waste.
- What good looks like. Fixes must be concrete enough to act on, and each comes with a first move and a measure that shows whether it worked.