I need an operations analysis of [PROCESS OR PROBLEM] for [COMPANY OR TEAM]. The process currently involves [CURRENT WORKFLOW AND TOOLS], and the business goal is [TARGET OUTCOME]. Use these facts and measures: [AVAILABLE DATA AND CONSTRAINTS]. Work as an operations analyst preparing a decision-ready first draft. Do not assume missing volumes, costs, staffing levels, system capabilities, or root causes. State assumptions separately and label them for validation. Produce: 1. A one-paragraph problem definition that distinguishes the symptom from the likely operational failure. 2. A current-state workflow table with each step, trigger, owner, handoff, system or document used, expected turnaround time, and known failure point.
3. A bottleneck analysis ranked by impact and confidence. Consider queue time, rework, approvals, duplicate entry, unclear decision rights, capacity imbalance, supplier or customer dependency, and missing controls. 4. A root-cause section using a concise five-whys chain for the two highest-impact issues. Separate evidence from hypotheses. 5. A future-state workflow with changes that remove or reduce the bottlenecks without creating an unowned handoff. 6. A 30/60/90-day action plan. For every action, name one accountable owner role, supporting roles, dependency, due date or timing, success metric, and the first observable deliverable. 7. A risk register covering implementation risks, operational-control risks, and what to monitor after launch. End with a one-page executive summary: decision needed, expected benefit, trade-offs, and the three questions leadership must answer. Before answering, check that every recommendation links to a stated problem or data point, and flag any timeline or benefit estimate that cannot be supported by my inputs. Ask up to 3 clarifying questions only if a required input is missing.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [PROCESS OR PROBLEM] | Name the process being analyzed and the operational problem it is causing. | Customer refund handling is taking too long and cases are reopened after resolution. |
| [COMPANY OR TEAM] | Describe the team, function, or business unit responsible for the work. | Northline Home Goods, ecommerce operations and customer support. |
| [CURRENT WORKFLOW AND TOOLS] | List the main steps, people, handoffs, and systems used today. | Support agents receive tickets in Gorgias, check Shopify orders, request warehouse confirmation in Slack, then issue refunds in Shopify. |
| [TARGET OUTCOME] | State the measurable result the team wants, such as faster fulfillment or fewer errors. | Reduce median refund resolution time from 4.2 business days to 1 business day without increasing incorrect refunds. |
| [AVAILABLE DATA AND CONSTRAINTS] | Provide relevant volumes, timing, costs, complaints, staffing limits, policies, and known constraints. | About 180 refund requests weekly; two warehouse shifts; agents cannot access the warehouse system; finance reviews refunds above $500. |
How to use
- Paste the prompt and replace each bracketed input with the current process, not the process you hope exists.
- Attach a process map, ticket export, SOP, or sample cases if you have them.
- Check that each proposed action has one accountable owner and that every handoff is represented.
- Follow up with: “Turn the 30/60/90-day plan into a weekly implementation tracker with status fields and escalation rules.”
Variations
Process mapping
Use this when the process is undocumented and you need the current state before proposing changes.
Map [PROCESS] as it operates in [TEAM]. Based only on [NOTES OR INTERVIEWS], create a SIPOC summary and a detailed swimlane-style table: trigger, activity, owner role, input, output, system, handoff, control, and typical wait time. Identify contradictions or missing steps without filling them in. End with 10 focused interview questions needed to validate the map. Ask up to 3 clarifying questions only if a required input is missing.
Incident review
Use this after a service failure, fulfillment miss, or recurring operational incident.
Prepare a blameless operations incident review for [INCIDENT] on [DATE OR PERIOD]. Use [TIMELINE AND EVIDENCE] and [IMPACT]. Produce an incident summary, minute-by-minute or step-by-step timeline, customer and business impact, contributing conditions, root causes, controls that failed or were absent, and corrective actions. Assign each action an owner role, due date, verification method, and closure criteria. Do not attribute intent or invent facts. Flag statements that need evidence. Ask up to 3 questions only if essential facts are missing.
Capacity plan
Use this when demand is rising and you need to test staffing or throughput options.
Create a capacity plan for [PROCESS] for [PLANNING PERIOD]. Use [DEMAND FORECAST], [CURRENT CAPACITY], and [OPERATING CONSTRAINTS]. Calculate demand by week, available productive hours, required capacity, utilization, and the shortfall or buffer under base, high, and low demand cases. Show formulas and assumptions. Recommend staffing, scheduling, automation, or demand-shaping actions with lead times and trigger thresholds. Do not fabricate productivity rates; label unknown inputs. Ask up to 3 clarifying questions only if required values are missing.
Tips
- Map handoffs separately from work steps: most delays sit in queues between owners, not in the task itself.
- Give the model actual timestamps from a small sample of cases; averages alone hide long-tail delays and rework loops.
- Assign one accountable role per action, even when several teams contribute; “operations and finance” is not ownership.
- Treat a future-state process as incomplete until it includes exception handling, escalation rules, and a metric that signals drift.
FAQ
Can AI identify the root cause from a process description alone?
It can generate credible hypotheses and structure the investigation, but it cannot prove causation without evidence such as timestamps, samples, interviews, or system logs.
What data makes an operations analysis more useful?
Case volumes, timestamps by step, error or rework rates, staffing schedules, cost per case, and examples of exceptions are especially useful.
Should the action plan use names or roles?
Start with roles in a shareable draft. Add individual names only when the plan is ready for the team that will execute it.