30 Claude Prompts for Operations Managers

You are an operations manager forecasting whether the team can handle next quarter's workload. <context> Leadership wants to know if current headcount can absorb projected volume before committing to a plan. </context> <inputs> - Current headcount and roles: [PLACEHOLDER, e.g. "6 fulfillment associates, 1 lead"] - Average throughput per person per day: [PLACEHOLDER] - Projected volume next quarter by month: [PLACEHOLDER] - Planned time off or attrition: [PLACEHOLDER] </inputs> <task> Build a capacity model comparing available capacity to projected demand month by month, flag any month over 85% utilization, and recommend hiring or overtime action with lead time. </task> <constraints> - Show the formula used to calculate capacity per month, not just the conclusion. - Use realistic seeded numbers, clearly labeled, if the given inputs are incomplete. - State the utilization threshold used and why. </constraints> <format> A month-by-month table (Month | Demand Units | Capacity Units | Utilization % | Flag | Recommended Action) plus a 3-sentence summary. </format>

You are an operations manager building a staff schedule that matches coverage to demand. <context> Coverage needs to match demand across the day and week without over- or under-staffing any shift. </context> <inputs> - Operating hours: [PLACEHOLDER] - Demand pattern by hour or day: [PLACEHOLDER] - Available staff and their max hours: [PLACEHOLDER] - Labor rules, such as minimum rest between shifts: [PLACEHOLDER] </inputs> <task> Generate a weekly shift schedule that covers peak demand windows, respects the stated labor rules, and minimizes total scheduled hours. </task> <constraints> - No employee scheduled back-to-back in a way that violates the stated rest rule. - Show total weekly hours per employee. - Flag any demand window that current staff cannot cover. </constraints> <format> A 7-day by employee grid (table) plus a coverage gap callout list. </format>

You are an operations manager preparing a backup plan in case a key vendor cannot meet demand. <context> A key vendor or supplier might not meet demand during a peak period, and the team needs a plan ready before it happens. </context> <inputs> - Vendor and what they supply: [PLACEHOLDER] - Normal lead time and capacity: [PLACEHOLDER] - Peak period and expected demand spike: [PLACEHOLDER] - Backup vendor options, if known: [PLACEHOLDER] </inputs> <task> Build a contingency plan with trigger thresholds, for example "if lead time exceeds X days, activate backup", the activation steps, and a cost and quality tradeoff note for each backup option. </task> <constraints> - Define at least one measurable trigger metric. - Include a rough cost delta estimate, labeled as an estimate. - Name who owns the decision to activate the backup. </constraints> <format> A one-page contingency plan with a trigger table and an activation checklist. </format>

You are an operations manager tracking spend against budget for the current period. <context> Ops spend needs to be tracked against budget across labor, tools, and vendor lines every month. </context> <inputs> - Budget line items with monthly budget: [PLACEHOLDER] - Actuals so far this period: [PLACEHOLDER] </inputs> <task> Build a tracker comparing budget to actuals per line, compute the variance percentage, and write a 3-bullet narrative explaining the biggest variance drivers. </task> <constraints> - Flag any line with variance over 10% in either direction. - Use realistic seeded sample numbers, clearly labeled, if none are given. - Keep the narrative factual, do not present speculation as fact. </constraints> <format> A table (Line Item | Budget | Actual | Variance $ | Variance % | Flag) plus a narrative summary block. </format>

You are an operations manager monitoring team workload to catch burnout risk early. <context> Sustained overtime and rising absence often precede turnover, and catching the pattern early lets a manager rebalance before someone quits. </context> <inputs> - Team roster with hours worked over the last 4 weeks: [PLACEHOLDER] - Standard full-time hours: [PLACEHOLDER] - Recent turnover or absence notes: [PLACEHOLDER] </inputs> <task> Identify employees trending toward burnout based on sustained overtime and rising absence, rank by risk level, and recommend a specific rebalancing action per flagged person. </task> <constraints> - Base flags only on the data given or clearly labeled seeded sample data, no assumptions about personal circumstances. - Recommendations must be concrete scheduling or workload actions, not generic wellness advice. - Note at the top that this is a private report not meant to be shared with the team. </constraints> <format> A ranked table (Employee | Avg Weekly Hours, 4wk | Trend | Risk Level | Recommended Action) with a one-line confidentiality note at the top. </format>

You are an operations manager building a visual health snapshot for leadership. <context> Leadership wants a glanceable view of the operation's core health metrics, not another spreadsheet to dig through. </context> <inputs> - KPIs to track: [PLACEHOLDER, e.g. "on-time %, error rate, throughput, cost per unit"] - Current values and targets: [PLACEHOLDER] - Reporting period: [PLACEHOLDER] </inputs> <task> Build a single self-contained HTML dashboard with a metric card per KPI showing current vs target, a color-coded status, and a short narrative line per metric. </task> <constraints> - Inline all CSS, no external dependencies or linked files. - Use color coding (green, yellow, red) tied to explicit thresholds you state on the page. - Use realistic seeded sample numbers, clearly labeled, if none are given. </constraints> <format> One self-contained HTML file with inline CSS, previewable directly in a browser. </format>

You are an operations manager writing the recurring Monday report to leadership. <context> This report needs to be one leadership actually reads, not a wall of text they skim past. </context> <inputs> - Key metrics this week vs last week: [PLACEHOLDER] - Notable incidents or wins: [PLACEHOLDER] - Upcoming risks: [PLACEHOLDER] </inputs> <task> Write a weekly ops report with a 3-sentence executive summary, a metrics table comparing this week, last week, and target, a "what changed" section, and a risks and asks section. </task> <constraints> - The executive summary must lead with the single most important number. - No more than 5 bullet points in the "what changed" section. - End with explicit asks if any, such as decisions or resources needed. </constraints> <format> A Markdown report ready to paste into email or Slack, under 400 words excluding the table. </format>

You are an operations manager settling a dispute over how a metric is calculated. <context> Teams disagree on how a KPI is actually calculated, which is causing conflicting reports. </context> <inputs> - KPIs in dispute or in use: [PLACEHOLDER] - Current informal definitions per team, if known: [PLACEHOLDER] </inputs> <task> Write a precise, single source of truth definition for each KPI, including the exact formula, data source, calculation frequency, and owner. </task> <constraints> - Every KPI needs a literal formula, for example "On-time % = orders shipped by promised date divided by total orders shipped, times 100". - Flag any KPI where teams currently disagree and state the reconciliation decision made. - No vague definitions such as "measures efficiency". </constraints> <format> A definitions table (KPI | Formula | Data Source | Frequency | Owner | Notes). </format>

You are an operations manager preparing a quarterly performance review for leadership. <context> The QBR needs to be a tight, data-driven deck, not a recap of every activity from the quarter. </context> <inputs> - Quarter and key results: [PLACEHOLDER] - Wins: [PLACEHOLDER] - Misses and root causes: [PLACEHOLDER] - Next quarter priorities: [PLACEHOLDER] </inputs> <task> Outline a 10-slide QBR deck with slide titles, 2-3 bullets of content per slide, and speaker notes for the hardest slide, the one covering misses. </task> <constraints> - Slide 1 must be a one-line headline result, not an agenda slide. - The misses slide must state the root cause, not just "we missed target". - Keep bullets under 15 words each. </constraints> <format> A slide-by-slide outline (Slide # | Title | Content bullets | Speaker notes where relevant). </format>

You are an operations manager explaining a sudden metric swing before the next leadership meeting. <context> A KPI moved sharply and leadership wants to know why before the meeting, without waiting for a full investigation. </context> <inputs> - Metric and the anomaly: [PLACEHOLDER, e.g. "error rate jumped from 2% to 9% on Tuesday"] - Known context or changes around that time: [PLACEHOLDER] </inputs> <task> Write a short memo listing the plausible causes ranked by likelihood, what data would confirm or rule out each one, and the immediate mitigation already in place or recommended. </task> <constraints> - Never state a cause as confirmed unless the input data actually confirms it, use "likely" language otherwise. - Cap the list at 3 ranked causes. - Include one recommended next diagnostic step. </constraints> <format> A one-page memo in Markdown, under 300 words. </format>

You are an operations manager running a structured root cause analysis on a recurring problem. <context> A recurring problem keeps resurfacing and surface-level fixes have not worked. </context> <inputs> - Problem statement: [PLACEHOLDER] - What's been tried already: [PLACEHOLDER] </inputs> <task> Run a structured 5 Whys analysis down to a root cause that is actually fixable, then propose one corrective action and one preventive action. </task> <constraints> - Each "why" must be a factual, checkable statement, not a guess. - Reject "human error" as a final root cause and dig one level deeper. - The preventive action must address the system or process, not just retrain the person. </constraints> <format> A 5-step numbered why-chain followed by a two-row action table (Corrective | Preventive). </format>

You are an operations manager applying Lean principles to spot waste in a process. <context> A process likely has non-value-add steps, but it takes an outside eye to spot them when you're the one running it every day. </context> <inputs> - Process steps as currently performed: [PLACEHOLDER] - Cycle time per step, if known: [PLACEHOLDER] </inputs> <task> Classify every step as Value-Add, Necessary Non-Value-Add, or Waste using Lean categories, and propose a redesigned process that removes or merges the waste steps. </task> <constraints> - Classify every step given, none skipped. - The redesigned process must have fewer or the same total number of steps. - State an estimated cycle time saved. </constraints> <format> A classification table, followed by a numbered "Redesigned Process" list and a one-line savings estimate. </format>

You are an operations manager making the case for a process change to leadership. <context> Leadership needs a clear, data-backed case before approving a process change, not just "this would be better". </context> <inputs> - Current process pain points: [PLACEHOLDER] - Proposed change: [PLACEHOLDER] - Cost or effort to implement: [PLACEHOLDER] </inputs> <task> Write a one-page proposal with a current-state vs future-state comparison, the expected impact on time, cost, or errors with the calculation method shown, implementation steps, and the risk of not changing. </task> <constraints> - Impact numbers must show the calculation, not just state a final claim. - Include at least one concrete risk of keeping the status quo. - Keep the whole proposal to one page. </constraints> <format> A one-page Markdown proposal with a two-column current-state vs future-state comparison table. </format>

You are an operations manager analyzing a raw error log to find the underlying pattern. <context> A raw log of errors or defects exists, and the goal is to find what's actually driving it, not just count incidents. </context> <inputs> - Raw error log for the period (date, type, brief description): [PLACEHOLDER, or generate a seeded sample of 20 rows] </inputs> <task> Categorize the errors into a small number of root cause buckets, quantify each bucket's frequency and cost or time impact, and rank which bucket to fix first using an impact-versus-effort view. </task> <constraints> - Use the actual log rows given; if none are given, generate a realistic 20-row seeded sample log for a mid-size operations team and label it clearly as sample data. - Every bucket must map back to specific log rows. - The ranking must state the reasoning, not just the rank order. </constraints> <format> A category summary table (Bucket | Count | % of Total | Est. Impact | Fix Priority) plus the categorized log as an appendix table. </format>

You are an operations manager deciding which manual tasks are worth automating first. <context> Several manual, repetitive tasks eat up team time, but not all of them are worth the effort to automate. </context> <inputs> - Manual or repetitive tasks the team does: [PLACEHOLDER] - Rough time spent per task per week: [PLACEHOLDER] - Tools already available, such as Zapier or internal scripts: [PLACEHOLDER] </inputs> <task> Score each task on frequency, time cost, and error-proneness, then rank into a shortlist of the top automation candidates with a rough build-effort estimate for each. </task> <constraints> - Score using a stated simple rubric, such as a 1-5 scale per factor, shown in the output. - Cap the shortlist at the top 5 candidates. - Note which items likely need engineering help versus a no-code tool. </constraints> <format> A scored table (Task | Frequency | Time Cost | Error Risk | Total Score | Effort Estimate | Tool Suggestion), sorted by score descending. </format>

You are an operations manager preparing for a quarterly vendor review call. <context> The quarterly check-in with a vendor needs data-backed talking points, not a vague "how's it going". </context> <inputs> - Vendor name and service: [PLACEHOLDER] - SLA terms: [PLACEHOLDER] - Actual performance data this period: [PLACEHOLDER] </inputs> <task> Build a scorecard comparing SLA commitments to actual performance, grade each dimension, and draft the opening talking points for the vendor review call. </task> <constraints> - Every grade must reference the specific SLA clause and the actual number behind it. - Include at least one item where the vendor exceeded expectations if the data supports it, keep it balanced rather than all complaints. - Talking points must be assertive but professional, no ultimatums unless the data clearly warrants one. </constraints> <format> A scorecard table (SLA Metric | Commitment | Actual | Grade) plus a "Call Talking Points" bullet list. </format>

You are an operations manager escalating a pattern of missed vendor commitments in writing. <context> A vendor has missed commitments repeatedly and it's time to escalate formally rather than raise it verbally again. </context> <inputs> - Vendor and contact: [PLACEHOLDER] - Specific incidents and dates of missed commitments: [PLACEHOLDER] - Desired resolution: [PLACEHOLDER] </inputs> <task> Draft a firm, professional escalation email that documents each incident with dates, states the business impact, and specifies the exact resolution and deadline requested. </task> <constraints> - List incidents as a dated bullet list, not prose. - State one concrete deadline for a response. - No threats, keep the tone professional and factual throughout. </constraints> <format> A ready-to-send email with Subject and Body. </format>

You are an operations manager sending a status update across several active projects. <context> Multiple stakeholders across several projects need a single organized update rather than separate scattered messages. </context> <inputs> - Active projects or initiatives with status: [PLACEHOLDER] - Blockers per project: [PLACEHOLDER] - Audience receiving this update: [PLACEHOLDER] </inputs> <task> Write a status update grouped by project with a one-line status tag, the blocker if any, and what's needed from the reader. </task> <constraints> - Every project needs an explicit status tag: On Track, At Risk, or Blocked. - Any project marked At Risk or Blocked must state the specific ask. - Keep each project block to 3 lines maximum. </constraints> <format> A grouped Markdown update, one section per project, suitable for email or Slack. </format>

You are an operations manager onboarding a new vendor before work begins. <context> A new vendor or supplier is coming online and needs a clear brief on expectations before any work starts. </context> <inputs> - Vendor and scope of work: [PLACEHOLDER] - Key contacts on both sides: [PLACEHOLDER] - SLAs and reporting cadence expected: [PLACEHOLDER] </inputs> <task> Write an onboarding brief covering scope, communication protocol, SLAs, escalation path, and a first 30-day check-in plan. </task> <constraints> - Include a named escalation contact and a response-time expectation. - State the exact reporting cadence and format expected from the vendor. - Include a 30/60/90-style early check-in schedule. </constraints> <format> A structured onboarding brief in Markdown with clear section headers. </format>

You are an operations manager announcing a change that affects other departments. <context> An operations change, such as a new process, tool, or schedule, affects other departments and needs a clear announcement. </context> <inputs> - What's changing: [PLACEHOLDER] - Effective date: [PLACEHOLDER] - Who's affected and how: [PLACEHOLDER] - Where to get help: [PLACEHOLDER] </inputs> <task> Write a change announcement that leads with what's changing and why, states exactly what each affected group needs to do, and where to get help. </task> <constraints> - The lead paragraph must state the change and effective date in the first two sentences. - Include a "what you need to do" section broken out by audience if more than one group is affected. - No jargon without a one-line explanation. </constraints> <format> A ready-to-send announcement in email or Slack post format, under 250 words. </format>

You are an operations manager writing the formal writeup for a resolved operational incident. <context> An operational incident, such as an outage, fulfillment error, or safety near-miss, needs a formal writeup after it's resolved. </context> <inputs> - Incident summary and timeline of events: [PLACEHOLDER] - Impact (customers, cost, or time affected): [PLACEHOLDER] - Immediate fix already applied: [PLACEHOLDER] </inputs> <task> Write a blameless postmortem with a timeline, impact assessment, root cause using a 5 Whys approach if needed, and specific action items with owner and due date placeholders. </task> <constraints> - The timeline must use timestamps, not vague sequencing words like "then". - Keep the language blameless, describe what the system or process allowed, not who failed. - Every action item needs a named owner placeholder and a due date placeholder. </constraints> <format> A structured Markdown postmortem: Summary, Timeline, Impact, Root Cause, Action Items table. </format>

You are an operations manager standardizing how incidents get classified the moment they're reported. <context> The team needs a consistent way to classify how serious an incident is the moment it comes in, rather than deciding case by case. </context> <inputs> - Types of incidents this team handles: [PLACEHOLDER] - Business impact tiers that matter, such as customer-facing, revenue, or safety: [PLACEHOLDER] </inputs> <task> Create a severity matrix, such as SEV1 through SEV4, with clear objective criteria for each level and the required response, including who's paged and the response time SLA per level. </task> <constraints> - Criteria must be objective and checkable in the moment, not a subjective judgment call. - Every severity level needs a response-time SLA. - Include a one-line example incident per level. </constraints> <format> A severity matrix table (Severity | Criteria | Response SLA | Who's Notified | Example). </format>

You are an operations manager looking for patterns across many past incidents. <context> Individual incidents get fixed one at a time, but it matters whether the same type keeps happening. </context> <inputs> - Incident log for the period (date, type, root cause if known): [PLACEHOLDER, or generate a seeded sample of 15 incidents] </inputs> <task> Group incidents by root cause category, show the trend over the period as increasing, flat, or decreasing, and recommend the single highest-leverage systemic fix. </task> <constraints> - Use the actual log if given; otherwise generate a clearly labeled realistic seeded sample of 15 incidents across a plausible operations context. - Any trend claim must be backed by the counts shown, not simply asserted. - The recommendation must target the largest or fastest-growing category. </constraints> <format> A trend table (Root Cause Category | Count | Trend | % of Total) plus a 3-sentence recommendation. </format>

You are an operations manager writing a customer-facing notice about an incident. <context> An incident affected customers and they need an honest, calm notice, without legal overreach or unnecessary alarm. </context> <inputs> - What happened, internal facts: [PLACEHOLDER] - Customer impact: [PLACEHOLDER] - Fix status and timeline: [PLACEHOLDER] </inputs> <task> Draft a customer-facing incident notice that states what happened in plain language, the impact, what's being done, and what the customer should do if affected. </task> <constraints> - No internal jargon or system names customers wouldn't recognize. - Do not over-apologize into an admission of liability, state facts and the remedy instead. - Include a clear next step or contact for affected customers. </constraints> <format> A ready-to-publish notice for a status page or email, under 200 words. </format>

You are an operations manager making sure postmortem action items don't get forgotten. <context> Postmortems produce action items that quietly get forgotten without a tracker pulling them together. </context> <inputs> - Open postmortem action items across recent incidents: [PLACEHOLDER] </inputs> <task> Consolidate the action items into a single tracker, flag any item open past its due date, and group by owner so each owner sees only their own list. </task> <constraints> - Flag anything past its expected due date clearly as "OVERDUE". - Group the output by owner as separate sub-tables. - Include a summary line stating total open and total overdue. </constraints> <format> A one-line summary followed by a table per owner (Action Item | Related Incident | Due Date | Status). </format>