Evidence-Based Operating Model Diagnosis Prompt

Public field comparison

Operating Model Diagnosis Prompt

Evidence-Based Operating Model Diagnosis Prompt

Analyze how work moves through a business and identify bottlenecks, ownership gaps, and process improvements.

Diagnose how work, decisions, information, and accountability move across a business; identify evidenced bottlenecks and control gaps; and design a measurable, approval-aware improvement roadmap.

—

Use this prompt to turn process records, performance data, role definitions, and stakeholder evidence into a structured operating model diagnosis and a controlled improvement roadmap.

Operating Model Diagnosis
Operating Review
Decision Planning
Risk Review
Implementation Planning

End-to-end workflow and bottleneck diagnosis
Cross-functional handoff and exception-path analysis
Decision-right and accountability gap assessment
Evidence-based operating model redesign
Controlled pilot and performance measurement planning

Goal or task
Current context
Constraints
Files, data, or examples
Definition of done

Diagnosis objective
Operating context and scope
Evidence pack
Constraints and decision rights
Success measures and time horizon

Replace every bracketed placeholder before running. Give the model enough context to inspect assumptions, ask only blocking questions, and produce a concrete deliverable. For code prompts, include relevant files, errors, logs, and test commands.

Replace all five bracketed variables, then paste the prompt into Claude. Provide the relevant process maps, procedures, organization and role records, decision logs, workflow data, service metrics, backlog or rework reports, control requirements, stakeholder notes, and known approval boundaries. Redact unnecessary sensitive data, attach or paste the evidence Claude may inspect, and run the prompt.

Use this when you need a production-ready operations result in Business, not a generic brainstorm. The expected output should include findings, implementation steps, risks, and verification checks.

A service organization has rising case backlogs and repeated escalations across sales, operations, and compliance. Supply Claude with the case workflow, queue and cycle-time data, service levels, role definitions, approval rules, exception records, and interview notes to identify evidenced handoff delays, unclear decision rights, root-cause hypotheses, controlled redesign options, and pilot acceptance measures.

Advanced

Advanced

Claude

Claude

operations

operations

Business
ops
systems
claude

business-operations
Operating Model
process-improvement
Organizational Design
claude

Operating Model Diagnosis Prompt | AMO.ng

Operating Model Diagnosis Prompt | AMO.ng

Analyze how work moves through a business and identify bottlenecks, ownership gaps, and process improvements.

Diagnose workflow bottlenecks, decision-right gaps, and ownership failures using evidence, controls, and a measurable implementation roadmap.

Prompt-body line comparison

Removed Added Unchanged context

−Act as a senior Business specialist using Claude. Your task is: [Goal or task].
+Produce an evidence-based operating model diagnosis for the following assignment.
 
−Context:
−- Current situation: [Current context]
−- Constraints: [Constraints]
−- Available materials: [Files, data, examples, URLs, logs, notes]
−- Success criteria: [Definition of done]
+Diagnosis inputs
+- Diagnosis objective: [Diagnosis objective]
+- Operating context and scope: [Operating context and scope]
+- Evidence pack: [Evidence pack]
+- Constraints and decision rights: [Constraints and decision rights]
+- Success measures and time horizon: [Success measures and time horizon]
 
−Workflow:
−1. Restate the objective in operational terms and identify any missing information that would block a reliable answer.
−2. Make reasonable assumptions only when they are low risk, and label them clearly.
−3. Produce the main deliverable for "Operating Model Diagnosis Prompt" with enough detail that a skilled operator can execute it immediately.
−4. Include edge cases, failure modes, dependencies, and tradeoffs that a junior prompt would usually miss.
−5. Add a verification checklist with concrete tests, review questions, metrics, or acceptance criteria.
−6. End with the smallest safe next action.
+Input requirements
+The minimum inputs are a defined business outcome or problem, the in-scope value stream or organizational boundary, at least one description of the current workflow, and any known authority constraints. Reliable conclusions normally also require process maps or procedures, demand and workload data, service levels, cycle-time or backlog records, quality and rework data, organization charts, role descriptions, decision logs, control requirements, system boundaries, customer feedback, and stakeholder observations.
 
−Output format:
−- Executive summary
−- Detailed plan or implementation
−- Risks and mitigations
−- Verification checklist
−- Next action
+Treat interview statements and notes as stakeholder evidence, not automatically as verified fact. Use only material actually available in the conversation or attachments. Claude may analyze supplied content and formulate recommendations, but it must not imply access to internal systems, live dashboards, employees, meetings, or records that were not provided.
 
−Do not give generic advice. Optimize for a production-quality operations outcome.
+If the objective, scope, unit of analysis, or available evidence is too ambiguous to support a meaningful diagnosis, ask no more than five consolidated blocking questions before proceeding. If gaps are non-blocking, continue with a bounded preliminary diagnosis, state the limits, and record the missing evidence. Preserve conflicting accounts instead of silently choosing one. Do not invent process steps, measurements, owners, approvals, or causal explanations.
+
+Diagnostic method
+1. Define the diagnostic boundary. State the business outcome, customers or beneficiaries, in-scope value streams, start and end events, organizational units, geographies, channels, products, systems, time period, and explicit exclusions. Identify whether the analysis concerns the formal operating model, actual practice, or both.
+2. Build an evidence ledger. For every consequential conclusion, identify the supporting source and classify it as supplied fact, direct observation recorded in the materials, stakeholder assertion, calculated result, assumption, hypothesis, conflict, or unknown. Note the source date, scope, reliability limitation, and whether corroboration exists. Never manufacture a baseline from absent data.
+3. Reconstruct the current operating model. Map demand triggers, work units, major activities, queues, handoffs, decision points, approvals, controls, exception paths, escalation routes, enabling systems, data dependencies, roles, and accountable owners. Distinguish documented workflow from reported actual practice. Show where work or information crosses team, vendor, system, or jurisdictional boundaries.
+4. Analyze flow performance using only available evidence. Examine demand volume and variability, capacity, work in progress, backlog age, throughput, end-to-end lead time, processing time, waiting time, first-pass yield, defects, rework, abandonment, service-level attainment, escalation frequency, and failure demand where relevant. Report the metric definition, period, population, calculation, and limitations. If measurements are unavailable, specify the observation or data collection needed rather than estimating values.
+5. Analyze accountability and decision effectiveness. Identify unclear ownership, duplicate accountability, decision-right mismatches, excessive approval layers, unowned exceptions, overloaded roles, separation-of-duties concerns, and gaps between responsibility and authority. Use an appropriate responsibility or decision-right model, such as RACI or RAPID, only when the supplied evidence can support it. Do not infer individual performance or intent from structural evidence.
+6. Identify constraints and root-cause hypotheses. Separate symptoms from plausible causes across process design, policy, governance, incentives, skills, capacity, technology, data quality, control design, and external dependencies. For each hypothesis, provide supporting and contradicting evidence, confidence, and the test needed to confirm or reject it. Avoid claiming causation from correlation or isolated stakeholder reports.
+7. Prioritize diagnosed issues. Score each issue on outcome impact, frequency, affected volume, control or compliance exposure, customer impact, implementation effort, reversibility, dependency load, and evidence confidence. Explain the scoring basis. Do not use false numerical precision when inputs are qualitative.
+8. Design improvement options. For each priority issue, compare at least two credible responses when alternatives exist, including process simplification, policy clarification, decision-right changes, role or capacity changes, control redesign, automation, system integration, or measurement changes. Explain expected benefits, trade-offs, displaced workload, new failure modes, prerequisites, and why an option may be unsuitable.
+9. Define the recommended future state. Describe changed workflow steps, handoffs, ownership, decision rights, controls, exception handling, information requirements, system implications, and governance cadence. Identify what remains unchanged. Separate no-regret actions from structural changes requiring executive, functional, legal, compliance, security, finance, HR, works-council, customer, or vendor approval.
+10. Build a controlled implementation roadmap. Sequence validation, design, pilot, review, rollout, and stabilization. Assign a proposed accountable owner and required approver by role, not by invented name. Include dependencies, resources, communications, training, migration or cutover needs, operational continuity controls, rollback triggers, and recovery steps. Prefer a reversible pilot where uncertainty or operational impact is material.
+11. Define verification and acceptance. For every recommendation, specify the baseline, target, metric owner, data source, measurement frequency, comparison period, expected observation, acceptance threshold, guardrail metric, and decision rule. Include reconciliation checks for workload moved between teams, hidden queues, exceptions, customer outcomes, control performance, and unintended consequences. Mark baselines and targets as unavailable when they were not supplied.
+
+Authority and safeguards
+- This is diagnosis and planning, not authorization to reorganize teams, change employment terms, modify production systems, alter controls, commit spending, contact stakeholders, publish findings, or implement recommendations.
+- Do not expose unnecessary personal, customer, commercially sensitive, security, or regulated data. Recommend aggregation or redaction when individual-level detail is not essential.
+- Do not make legal, regulatory, audit, safety, or employee-performance determinations. Flag those matters for qualified human review.
+- Stop and request direction if the requested recommendation would bypass a mandatory control, create an unmanaged service interruption, rely on materially conflicting evidence, expose sensitive data, or exceed stated decision rights.
+- Recommendations affecting critical operations must include approval, continuity, monitoring, rollback, and post-change review controls.
+
+Required deliverable
+A. Diagnostic scope and confidence
+- Objective, business outcome, scope, exclusions, time horizon, units of analysis, constraints, and overall confidence
+- Blocking gaps and material limitations
+
+B. Evidence ledger
+A table with: evidence ID; source and date; relevant scope; evidence classification; claim supported; corroboration or conflict; reliability limitation.
+
+C. Current-state operating model
+- Concise value-stream narrative
+- Workflow and handoff table with: stage; trigger/input; activity; output; performing role; accountable role; decision or control; system/data dependency; queue or exception; evidence ID
+- Documented-versus-observed differences
+
+D. Performance and flow analysis
+A table with: metric or indicator; definition; period and population; baseline; actual observation; data source; interpretation; limitation. State explicitly where no measurement is available.
+
+E. Accountability and decision-right analysis
+A table with: decision or outcome; current participants; current accountable owner; authority required; observed delay or ambiguity; control implication; evidence; proposed clarification.
+
+F. Diagnosis register
+A table with: issue ID; symptom; root-cause hypothesis; supporting evidence; contradicting evidence; affected outcome; impact and frequency; confidence; validation test; consequence if left unresolved.
+
+G. Options and recommendations
+A table with: issue ID; options considered; recommended option; rationale; expected benefit; trade-offs; displaced workload; dependencies; new risks; proposed owner; required approval.
+
+H. Future-state design
+Describe the revised flow, handoffs, decision rights, controls, exception routes, governance, systems, data, and capabilities. Clearly label assumptions and unresolved design choices.
+
+I. Implementation and control roadmap
+A table with: phase; action; deliverable; proposed owner; approver; dependency; pilot or rollout boundary; continuity safeguard; rollback trigger; completion evidence; status as proposed, blocked, or ready for human decision.
+
+J. Measurement and acceptance plan
+A table with: recommendation; baseline; target; metric definition; data source; metric owner; frequency; expected observation; actual observation if supplied; guardrail; acceptance rule; unresolved state.
+
+K. Decision brief
+List decisions required now, decisions deferred pending evidence, the smallest safe next action, and the evidence or approval needed to take it.
+
+Claim discipline
+Keep proposed, approved, executed, measured, verified, blocked, and unavailable states distinct. Do not say a workflow was changed, a stakeholder agreed, a control passed, a metric improved, or a recommendation was implemented unless the supplied material contains direct evidence of that event. If no execution evidence is available, present all changes and expected results as proposals.