Create a practical process-improvement plan for the workflow below. Diagnose the current process before recommending changes. Use only the facts, metrics, constraints, and stakeholder information I provide; label assumptions and do not invent savings, capacity, root causes, approvals, or tool capabilities. Inputs: [PROCESS AND PROBLEM] [CURRENT WORKFLOW AND DATA] [PEOPLE AND DECISION RIGHTS] [CONSTRAINTS] [SUCCESS MEASURES AND DEADLINE] Map the current state from trigger to completion. For each handoff, identify the owner, input, output, system of record, wait time if known, rework loop, and approval. Separate observed evidence from likely causes. Look for bottlenecks, unclear decision rights, duplicate entry, queues, exception paths, and controls that create risk if removed. Produce: 1. A concise problem statement and current-state flow in numbered steps. 2. A root-cause table with evidence, confidence level, and the data needed to confirm uncertain causes. 3. A prioritized improvement backlog using impact, effort, risk, and dependency. Include quick wins and structural fixes separately. 4. A 30/60/90-day implementation plan. Every action must have one accountable owner, named contributors, a due date or sequence trigger, the change to make, and its acceptance criterion. 5. A measurement plan defining baseline, target, data owner, cadence, and a guardrail metric so a speed improvement does not quietly reduce quality or compliance. 6. A change-management section covering affected users, training or documentation, pilot scope, feedback route, and rollback condition. End with a one-page operating checklist that a team can follow weekly. Before answering, check that no action lacks an owner or success measure, and flag recommendations that depend on unverified assumptions. Ask up to 3 clarifying questions only if a required input is missing.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [PROCESS AND PROBLEM] | Describe the workflow, its customers, and the specific failure or opportunity you want to address. | Improve onboarding for new B2B customers; customers wait too long to reach first value after signing. |
| [CURRENT WORKFLOW AND DATA] | List the current steps, systems, volume, timing, error data, and examples of rework or delays. | Sales marks deal won in HubSpot, customer success manually creates an Asana project, implementation sends a questionnaire, then schedules kickoff. Median time to kickoff is 12 days; 31% of questionnaires need follow-up; contracts with custom integrations take longer. |
| [PEOPLE AND DECISION RIGHTS] | Name the roles involved, who performs work, and who can approve changes. | Sales Ops owns HubSpot fields; Customer Success Manager runs onboarding; Implementation Lead approves process changes; Product owns integration roadmap. |
| [CONSTRAINTS] | State budget, staffing, compliance, technical, contractual, or timing limits. | No new software before Q2; security questionnaire cannot be removed; two CSMs support 25 new customers per month. |
| [SUCCESS MEASURES AND DEADLINE] | Provide the outcome measures, existing baseline if known, and the deadline or planning horizon. | Reduce median time to kickoff from 12 to 7 days by March 31; preserve customer satisfaction above 4.5/5. |
How to use
- Paste the workflow as it operates now, including exception paths and evidence such as queue times, error counts, or customer complaints.
- Make the model assign accountable owners only to roles that actually have authority to make the change.
- Validate the baseline and the guardrail metric with the people who own the underlying data.
- Follow up with: “Convert the first 30 days into a meeting-by-meeting rollout plan with decision points and a pilot scorecard.”
Variations
Process map
Use this when the team first needs a shared view of the current workflow.
Map the current process for [PROCESS] from [TRIGGER] to [COMPLETION] using [STEP NOTES AND DATA]. Produce a numbered swimlane-style text map by role, showing inputs, outputs, system of record, handoffs, approvals, wait states, rework loops, and exceptions. Mark unknowns explicitly. Then list the five highest-risk failure points with their observable evidence and owner. Do not propose solutions yet or invent timing and ownership. Ask up to 3 questions only if required inputs are missing.
Pilot plan
Use this after selecting one improvement to test.
Create a controlled pilot plan for [PROCESS CHANGE] in [WORKFLOW] with [PILOT GROUP], [BASELINE DATA], and [CONSTRAINTS]. Define hypothesis, scope, exclusions, owner, participant responsibilities, training, start and end dates, success metric, guardrail metric, data collection method, weekly review, and rollback triggers. Include a decision rule for expand, revise, or stop. Do not claim benefits before measured results exist. Ask up to 3 questions only if required inputs are missing.
SOP rewrite
Use this when an improved workflow needs usable operating instructions.
Write a standard operating procedure for [PROCESS] based on [APPROVED WORKFLOW] for [USERS]. Include purpose, scope, roles, prerequisites, numbered steps, system fields or files to update, quality checks, exception handling, escalation path, and evidence of completion. Add a short change log and a checklist that can be used during the work. Do not fill in missing policies or tool actions; flag them for the process owner. Ask up to 3 questions only if required inputs are missing.
Tips
- Measure elapsed time at every handoff, not just total cycle time; the longest delay is often a queue awaiting a decision or missing input.
- Give a single accountable owner to each improvement action, while listing contributors separately so shared responsibility does not hide ownership.
- Pair every speed metric with a quality, compliance, or customer-experience guardrail to catch harmful shortcuts.
- Pilot changes on a defined segment before rolling them out across exceptions and high-risk cases.
FAQ
Do I need process data before using AI for improvements?
Some data is important, even if it is simple counts, dates, and examples. Without it, AI can help create questions and a map, but not reliably identify a root cause.
What is the difference between a quick win and a structural fix?
A quick win reduces a visible problem with low dependency, such as clarifying an intake field. A structural fix changes ownership, systems, policy, or workflow design and needs more validation.
How detailed should a 30/60/90 plan be?
It should be specific enough that each action has an owner, acceptance criterion, and dependency. Avoid calendar dates if the start date or approval timing is unknown.