Act as an experienced operations analyst. Turn the information below into a practical operating plan that a cross-functional team can follow. [OPERATIONS PROBLEM] [CURRENT PROCESS AND EVIDENCE] [GOAL AND SUCCESS METRICS] [STAKEHOLDERS AND OWNERS] [CONSTRAINTS AND DEADLINE] [AVAILABLE DATA OR SYSTEMS] Begin with a concise problem statement that separates observed facts from assumptions. Then map the current process in a table: trigger, step, owner, system or handoff, expected time, failure point, and evidence. Do not invent steps that are not supported; list unknowns separately. Produce a recommended plan in three sections. First, give the likely root causes, ranked by evidence strength, and name what data would confirm or disprove each one. Second, provide a 30/60/90-day action plan or a deadline-based equivalent. Every action must have one accountable owner from [STAKEHOLDERS AND OWNERS], supporting roles, a due date or sequence dependency, a tangible deliverable, and a success measure. Use RACI only when it resolves a real decision conflict; otherwise keep ownership direct. Third, supply a KPI scorecard with metric definition, formula, source system, baseline if supplied, target, cadence, and owner. Separate leading indicators from outcome metrics. Include a risk register covering adoption, capacity, data quality, control failures, and cross-team dependencies, with a mitigation and escalation trigger for each material risk. End with the five most important decisions or questions for the next working session. Do not manufacture baselines, targets, policy requirements, or stakeholder commitments. Before answering, check that each action has a single accountable owner and that every KPI can be calculated from the named data. Ask up to 3 clarifying questions only if a required input is missing.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [OPERATIONS PROBLEM] | Describe the operational issue, affected customers or teams, and why it matters now. | Customer onboarding takes 18 days on average, delaying activation for mid-market accounts. |
| [CURRENT PROCESS AND EVIDENCE] | List the known workflow steps, observations, incident examples, and existing measurements. | Sales submits a form, implementation reviews within 2 days, customer data is manually checked, then training is scheduled. Forty percent of delays occur before data validation. |
| [GOAL AND SUCCESS METRICS] | State the desired outcome and any agreed targets or measures. | Reduce median onboarding time to 10 days by March while keeping implementation rework below 5%. |
| [STAKEHOLDERS AND OWNERS] | List people or roles who can own, support, approve, or be consulted on work. | Implementation manager Priya; Sales Ops lead Daniel; Product Ops analyst June; Security reviewer role. |
| [CONSTRAINTS AND DEADLINE] | State budget, staffing, compliance, system, timing, and change-management limits. | No new headcount; CRM changes require a two-week release window; March 31 deadline. |
| [AVAILABLE DATA OR SYSTEMS] | List data sources, dashboards, tools, and known data limitations. | Salesforce opportunity and handoff timestamps, implementation tracker, Zendesk tickets; training attendance is incomplete. |
How to use
- Paste the current workflow as it actually runs, including handoffs and exceptions, rather than an ideal process.
- Confirm that assigned owners have authority to deliver the listed action before circulating the plan.
- Replace any unsupplied baseline or target with a data-collection task instead of treating it as fact.
- Follow up with: “Convert the 30-day actions into a weekly tracker with status, dependency, and escalation columns.”
Variations
Process mapping
Use when the team needs a shared factual view of a messy workflow.
Map the current-state process for [PROCESS NAME] using these notes: [PROCESS NOTES]. Participants are [ROLES], systems are [SYSTEMS], and observed problems are [ISSUES]. Return a swimlane-style text table with trigger, action, decision, owner, input, output, system, expected turnaround, and exception path. Identify unclear ownership and missing evidence separately from confirmed steps. Then list the five highest-risk handoffs and a question to validate each. Do not invent process steps. Check that every handoff has both a sending and receiving owner.
Weekly business review
Use when preparing a decision-focused operations review.
Create a weekly business review for [TEAM OR PROCESS] using [METRICS AND RESULTS]. The goal is [GOAL], attendees are [ATTENDEES], and active initiatives are [INITIATIVES]. Produce a one-page agenda, KPI table showing current value versus target and trend, decisions needed, risks requiring escalation, and an action log with one accountable owner and due date per item. Distinguish facts from interpretations. Do not invent metrics or commitments. Check that each agenda item leads to a decision, action, or explicit monitoring choice.
SOP draft
Use when documenting a repeatable process for operators.
Draft a standard operating procedure for [PROCESS] used by [USER ROLE]. Source notes are [CURRENT NOTES], tools are [SYSTEMS], required controls are [CONTROLS], and exceptions are [EXCEPTIONS]. Produce purpose, scope, prerequisites, numbered steps, decision points, quality checks, escalation route, records to retain, and revision owner. Write instructions at the operator's level and identify gaps that need policy confirmation. Do not create approvals or compliance rules not in the source notes. Check that every exception has an owner and next action.
Tips
- Document the real process, including rework loops and side-channel handoffs; the official workflow is rarely enough to diagnose delays.
- Give one person accountability for an action even when several teams contribute, or work will stall at the handoff.
- Define KPI formulas before discussing targets so teams do not report different versions of the same metric.
- Use leading indicators such as queue age or validation completion alongside outcome measures such as cycle time.
FAQ
Can AI identify the root cause of an operations problem?
It can organize evidence and propose hypotheses, but it cannot establish causation without reliable process data and validation by the people doing the work.
What is the difference between an owner and a contributor?
The accountable owner is responsible for delivery and escalation. Contributors perform work or provide input but do not share final accountability.
Should a 30/60/90-day plan always be used?
No. Use it for an ongoing improvement effort; use milestone dates and dependencies for a fixed launch or compliance deadline.