Process improvement asked as “how can we be more efficient” gives you platitudes. Good prompts force specificity: where exactly does work wait, who hands off to whom, what got escalated last week, what should never have been a meeting. These 15 templates get past the platitudes: value-stream maps, friction inventories, retro deep-dives, automation candidates, and the awkward “is this role even still needed” prompt.
Who this is for
Ops leads, eng managers, chiefs of staff, founders past 10 people, team leads inheriting a stalled team, anyone running a retro that needs to produce real changes.
When not to use these prompts
Don’t use these on healthy teams that aren’t complaining; solutions in search of problems create change-fatigue. Also don’t use these for crisis incidents; those need post-mortems, not process redesign.
Prompt anatomy / structure formula
A process-improvement prompt should always carry six elements:
- Role: who the AI plays (PM, chief of staff, ops lead, finance analyst, manager).
- Context: company / team / project / audience / what already happened.
- Goal: one concrete deliverable: memo, email, talking points, table, prioritized list.
- Constraints: what NOT to do (no marketing voice, no speculation past facts, no PII, fit under word count).
- Output format: numbered sections, markdown table, slack-friendly bullets, or 1-page memo.
- Examples / signal: 1-2 lines of “good” tone, or a previous example to mirror.
Best for
- Quarterly process review when cycle time has crept up
- Onboarding audit: why does it take new hires 3 months to be productive?
- Cross-team handoff that keeps dropping things
- Retro that produced 12 action items last quarter and zero changes
- Founder asking “where is the team’s time actually going?“
15 copy-ready prompt templates
1. Value-stream map (intake → done)
Run first. Forces you to name every step.
You are an ops consultant. Below is how work flows through {team / process}. Build a value-stream map. For each step: name | average time | wait time before | who owns | typical defect. Then identify the top 3 steps with the worst wait-time-to-work-time ratio. End with: "If you only fix one, fix this — and here is why."
Process description: {paste}Variables to swap: team / process (team or workflow name), paste (current process from intake to done)
Optimization: If output is vague, add: “Wait time = time work sits doing nothing. Be ruthless about distinguishing wait from work.”
2. Friction inventory (last 2 weeks)
Below are notes / Slack threads / tickets from the last 2 weeks. Extract a "friction inventory": every time someone said "this is annoying", "we always have to", "I wasted X time on". For each: friction description, frequency signal (how often it comes up), who feels it. Rank by total time lost across the team, not number of mentions.
{paste}3. Retro deep-dive (not the usual)
Below are retro notes from {N} retros. Most retros produce action items that never get done. Analyze: (1) Themes that repeat across retros (the unresolved ones), (2) Action items from past retros (which got done, which didn't, why), (3) Things people complained about but no action item was raised (the silent ones), (4) One change that would have the highest leverage. No "communicate better".
Retros: {paste}4. Handoff audit
Most process pain lives at handoffs.
Audit handoffs in {process}. For each handoff: from whom to whom, what is supposed to be passed (the artifact), what is often missing or wrong, how the receiver discovers the gap (immediately / next day / never). Score each handoff by failure rate. The top failure is the highest-ROI fix.
Process: {paste}Variables to swap: process (the process name)
5. Automation candidates
Below are recurring tasks the team does. For each: (1) Task description, (2) Frequency (daily / weekly / monthly), (3) Time per occurrence, (4) Inputs (where they come from), (5) Outputs (where they go), (6) Variability (always identical / minor variation / lots of judgment). Then rank automation candidates by (frequency × time) ÷ variability. Skip anything with high judgment; that's not automatable yet.
Tasks: {paste}6. Cycle-time decomposition
For {workflow}, the cycle time is currently {time}. Decompose where that time goes: (1) Active work, (2) Waiting on people, (3) Waiting on systems, (4) Rework, (5) Context-switching. Use the data I provide. Then identify the single largest bucket and propose 3 reductions specifically for that bucket. Do not propose changes to the other buckets.
{paste}Variables to swap: workflow (name), time (current cycle time)
7. “Why are we still doing this?” audit
Find rituals nobody can justify.
List every recurring meeting / ritual / report / artifact this team produces. For each, ask: (1) Who originally requested it, (2) Is that person / need still here, (3) What decision does this enable, (4) What would break if we stopped. Categorize each as: Keep / Slim / Kill / Investigate. Be biased toward Kill.
List: {paste}8. Onboarding friction map
A new hire just finished their first 30 days. Below are their notes on what was confusing, slow, missing, or broken. Group findings by: (1) Tools / access (the boring stuff that delays week 1), (2) Information (docs missing or stale), (3) Social (who do I ask), (4) Work intake (when do I get a real task). For each: severity (must-fix / nice-to-fix), owner, fix sketch.
Notes: {paste}9. “Approval debt” audit
Audit all approval gates in {process}. For each: (1) What is approved, (2) Who approves, (3) Median wait time, (4) Reject rate (real, not aspirational), (5) What changed in the last year that could let us delete this gate. Approval gates with > 95% approve rate are usually theater; flag them.
{paste}Variables to swap: process (the process name)
10. Comms / meeting load audit
Below are 2 weeks of calendar + Slack data for {team}. Identify: (1) Meetings > 30 minutes that could be async, (2) Slack threads > 20 messages that should have been a doc + decision, (3) Recurring meetings with attendance < 50% (cancel candidates), (4) "Always Friday at 4pm" meetings that lose 30% of the room. End with: 3 specific calendar changes for next week.
Data: {paste}Variables to swap: team (team name)
11. Tool-stack audit
Below is our tool stack: {list}. Audit for: (1) Overlap (two tools doing the same job), (2) Underuse (license cost ÷ active users > $X), (3) Integration gaps (work that gets manually copied between tools), (4) Tools nobody can name an owner for. Recommend: keep / consolidate / drop.
{paste}Variables to swap: list (current tool stack with seat counts if available)
12. Quarterly process retrospective
Below is data from the last quarter: cycle time, ticket backlog, escalations, retros, post-mortems. Write a quarterly process retrospective with: (1) Trends (improved / stable / worsened with numbers), (2) Three biggest process learnings, (3) Three changes for next quarter (specific, measurable), (4) One process I commit to NOT changing because it works.
Data: {paste}13. “Is this role still needed” prompt
Awkward but necessary at scale.
A role / function exists: {role}. Audit whether it is still load-bearing: (1) What problem did this role solve when created, (2) Does that problem still exist at the same scale, (3) Where would the work go if the role moved or absorbed, (4) Hidden value the role creates that isn't in the JD (institutional memory, glue work, escalation buffer), (5) Recommendation: keep / re-scope / merge / sunset. Treat this analytically, not personally.
Context: {paste}Variables to swap: role (role title or function)
14. Cross-functional dependency mapping
Below is what my team needs from other teams (and vice versa) over the last quarter. Map dependencies: (1) Strongest dependencies (we block each other often), (2) Asymmetric ones (we depend on them more than they depend on us; political risk), (3) Forgotten ones (we used to coordinate but stopped), (4) Manufactured ones (we ping them but don't really need to). Suggest one ritual to fix the top asymmetric dependency.
{paste}15. Pilot-then-roll-out plan
Don’t roll out process changes org-wide on day 1.
I want to change {process}. Help me design a pilot: (1) Smallest credible test (which team / scope / duration), (2) Success criteria (specific metric thresholds before rolling out), (3) Kill criteria (what we'd see that would make us scrap it), (4) Communication plan during pilot, (5) Decision date for go / no-go, (6) Rollback path if we ship and regret. End with one paragraph: "Why this is reversible, and why that matters."
{paste}Variables to swap: process (what to change)
Common mistakes
- Asking “how can we improve” without naming a specific process: output is platitudes.
- Counting mentions instead of total time lost: vocal pain ≠ biggest pain.
- Skipping wait-time decomposition: most cycle time is waiting, not working.
- Rolling out a process change org-wide before piloting: change-fatigue plus no learning loop.
- Treating “we should automate this” as a recommendation: automation is a project, not a sentence.
- Producing 12 retro action items: three is the max that will actually happen.
- Skipping the “keep” column: if everything is changing, nothing is stable.
How to push results further
- Quantify everything. “Cycle time” without numbers is poetry.
- Distinguish wait time from work time obsessively. Cutting wait is 10x cheaper than speeding up work.
- Run process audits per-process, not per-team. Teams own multiple processes; audit one at a time.
- Always end with a single biggest-leverage change, not a list. Lists don’t get acted on.
- For automation candidates, multiply frequency × time × low-variability. Skip judgment-heavy work.
- Pilot every change. “We tried it” beats “we discussed it” by a factor of 5.
- Re-run the audit 90 days after a change. Without measurement, you don’t know if it worked.
FAQ
- How often should we run process improvement?: Quarterly is the cadence that produces real change. Monthly creates fatigue. Yearly lets debt pile up.
- Who should run these prompts, managers or ICs?: ICs name the friction (they live it). Managers prioritize and pilot. Both should participate. AI helps surface patterns across both.
- What if leadership won’t prioritize the fix?: Re-run the cycle-time prompt and show the cost in dollars or shipped features. “We wait 4 days per ticket” becomes “We lose 2 features per quarter”.
- Should the process improvement output be public?: The findings yes. The role-audit (template 13) and individual performance signals: no. Be careful what gets pasted into shared docs.
- How big should the pilot be?: Smallest credible test, usually one team for one cycle (sprint, week, quarter, depending on the process). Big bang rollouts fail more often than they succeed.
- Will AI invent processes that don’t fit our context?: Yes. Always provide your actual workflow steps, not abstractions. And reject any recommendation that requires hiring or buying tools to “make work feel better”.
Related
- SOP drafting prompts
- Project planning prompts
- Action item extraction prompts
- Meeting notes prompts
- Productivity & Office Prompts hub
Tags: #Prompt #Productivity #Process #Ops