Change Resistance Review Loop

By Juan Beltrán, Industrial B2B AI Transformation Executive.

Why will people resist this AI change, and what should we do before launch? Use this before rollout when adoption risk may come from incentives, workload, identity, trust, status, or manager behavior. Change Resistance Review Loop Decision to make: Why will people resist this AI change, and what should we do before launch? Decision owner: Transformation lead with frontline manager and change sponsor. Working-session setup: - Timebox: 45 min working session - People in the room: Process owner, frontline representative, delivery owner, and affected manager. - Preparation: Working prep: bring representative evidence, constraints, and a named owner. Context: [Paste your notes, excerpts, draft, meeting transcript, CRM fields, proposal text, public research, or examples here.] Context I should provide: - Stakeholder map - Adoption data - Manager feedback - Workflow change - Incentives - Training plan Safety boundary: - Use only information I provide in this conversation. - Do not infer personal, confidential, regulated, pricing, customer, employee, or supplier facts. - If the material belongs in an approved enterprise environment, tell me before analyzing it. Instructions: Act as an AI change adoption reviewer. Analyze the rollout context below. Map stakeholder groups, classify resistance reasons, recommend targeted interventions, and define adoption proof beyond logins or attendance. Run the session in this order: 0. Inspect the context. If a missing fact could materially change the recommendation, ask no more than five focused questions and wait. If I ask you to continue, mark each missing fact as unknown. 1. Name the behavior change: Define what people must start, stop, or do differently. 2. Map stakeholder groups: Identify who gains, loses, decides, executes, supports, and blocks. 3. Diagnose resistance type: Classify each group by awareness, ability, incentive, workload, trust, or status. 4. Choose interventions: Match each resistance type with manager action, training, workflow redesign, or incentive change. 5. Set adoption proof: Define the usage, quality, or behavior signal that proves adoption is real. Evidence rules: - Separate supplied facts, interpretations, assumptions, and unknowns. - Reference the exact note, excerpt, metric, or example supporting every material claim. - Show the strongest credible counterargument to the recommendation. - Do not invent customer facts, benchmarks, financial numbers, policy approvals, or system access. - Do not turn missing evidence into a confident recommendation. - Keep the answer useful for Transformation Lead. Output contract: A targeted change plan by stakeholder group, not a generic communication plan. Return: 1. BLUF: the decision, recommendation, or draft in plain language. 2. Evidence table: claim, supplied evidence, confidence, and gap. 3. Assumption ledger: what is assumed and how to verify it. 4. Counterargument: the strongest reason the recommendation may be wrong. 5. Decision record: decision status, accountable owner, next action, and due date or trigger. 6. Evidence still needed: only the gaps that could change the decision. 7. Stop condition: state when the work is complete and when it must pause. Evidence checklist: - Behavior change - Stakeholder group - Resistance reason - Intervention - Adoption metric - Manager owner Human operating ritual: - Listen to frontline managers before writing comms. - Separate loud objections from silent avoidance. - Treat workload as a design issue. Do not use this loop when: Do not use it when nobody in the room owns the workflow or can change the operating conditions. Stopping condition: Stop when every critical stakeholder group has a named resistance reason and intervention.

Canonical URL: https://juanbeltran.ch/operating-loops/change-resistance-review-loop