Authored by Pam Didner
TL;DR: Most Microsoft 365 Copilot rollouts stall because accountability sits in the wrong place—IT owns deployment, L&D owns training, and nobody owns adoption. The fix is not more training or a better rollout plan. It’s assigning operational ownership of the adoption number to someone with the authority to change how teams work. That person is almost always a COO, VP of Operations, or someone with equivalent business-side accountability—not IT.
In most organizations, Microsoft 365 Copilot was deployed by IT. Configured by IT. Supported by IT. So when the adoption numbers disappoint, IT gets the call.
This is the wrong call. And it’s a significant reason why Copilot adoption plateaus in most organizations at exactly the point where it should be accelerating.
Let me explain why—and what the alternative looks like.
What IT Can Own and What IT Cannot
IT is excellent at deployment. License provisioning, security configuration, tenant settings, integration with existing systems—these are legitimate IT responsibilities, and IT does them well.
What IT cannot own is organizational behavior change. Making a tool available is not the same as integrating it into how people work. Getting Copilot onto every desktop is the beginning of the adoption problem, not the solution to it.
Adoption requires answering questions that IT is not equipped to answer: Which workflows should change first? Who needs to change how they work, and in what specific ways? How will we know if the change is happening? Who is accountable if it isn’t?
These are operations questions. They require someone who understands the business processes, has authority to change them, and is accountable for the productivity outcomes that Copilot is supposed to deliver.
That person is not in IT. That person is a COO, a VP of Operations, or someone with an equivalent operational accountability.
Want to understand
AI Marketing in less
than 2 hours? It starts
with this book!
The Accountability Vacuum
The most common adoption failure mode I see is what I call the accountability vacuum: IT owns deployment, L&D owns training, and nobody owns adoption. The outcome metrics sit in a reporting system that nobody looks at until the CFO asks—and by then the rollout has been floundering for six months.
I worked with a VP of Operations at a mid-market B2B technology company who identified this problem in week two of their Copilot rollout. She didn’t hire a consultant or schedule another training session. She assigned a dedicated adoption owner—someone on the business side with operational authority—and built adoption into the quarterly business review agenda. They hit 71% active usage by week twelve. The training hadn’t changed. The tool hadn’t changed. The accountability had.
Closing the accountability vacuum requires one thing: a named person with authority who owns the active usage number and is accountable for it in a business review. Not IT. Not L&D. Someone from the business side who has both the motive and the authority to change how teams work.
What COO Ownership of Copilot Adoption Actually Looks Like
This doesn’t mean the COO is personally running Copilot training sessions. It means four specific things.
Setting the adoption target. Defining what “success” looks like in operational terms, not just IT terms. Not “80% license activation” but “70% of licensed users integrate Copilot into at least one core workflow by Q3.” License activation is a deployment metric. Workflow integration is an adoption metric. They are not the same thing.
Assigning the operational owner. Naming someone on the business side who tracks the adoption metric and brings it to a regular operational review. This person does not need to be technical. They need to understand the workflows, have access to the usage data, and have the authority to escalate when adoption is lagging.
Prioritizing the workflows. Deciding, with input from department leads, which workflows are the highest-value targets for Copilot integration—rather than letting adoption be self-directed and random. Self-directed adoption produces power user islands. Prioritized adoption produces team-level behavior change.
Creating accountability at the management layer. Making Copilot adoption a management expectation, the same way productivity and quality are management expectations. When managers know they’ll be asked about their team’s active usage in a business review, the conversations about Copilot start happening at the team level without prompting.
This is a different model from how most organizations think about software adoption. It treats Copilot not as a tool to deploy but as a capability to build—and capability building is an operations function, not a technology function.
Why This Pattern Repeats
The reason IT ends up holding the Copilot accountability bag is structural, not intentional. IT is the team that processed the purchase order, configured the licenses, and sent the rollout announcement. In most organizations, whoever launches the tool implicitly owns it until someone explicitly takes it away.
The problem is that nobody explicitly takes it away. Operations assumes IT is handling it. L&D assumes IT will flag when training needs to scale. IT assumes the business will tell them if something isn’t working. The accountability sits in the gap between all three functions—which is functionally the same as sitting nowhere.
The COO’s job is to close that gap. Not by taking over IT’s deployment work, but by naming the adoption outcome, assigning it to a business-side owner, and holding that owner accountable in the same review where revenue, productivity, and operational efficiency are discussed.
The First Question to Ask
If you’re a COO reading this, the first question is a simple one: who currently owns the Copilot adoption number in your organization? Not the deployment number—the adoption number. If the answer is IT, or L&D, or “it’s distributed across several teams,” you have your diagnosis. The accountability is in the wrong place.
Where most teams get stuck: Copilot ownership sits with IT because that’s who deployed it, and nobody has explicitly assigned it to the business side.
What actually works: A named COO-level owner with a specific adoption target, a business-side operational lead tracking the metric weekly, and adoption on the agenda in the same business review where productivity outcomes are discussed.
If you want to see exactly where the accountability and strategy gaps are in your current Copilot program—before you bring in training or additional resources—the 5-Point Microsoft 365 Copilot QuickCheck will give you that picture in five minutes. And if the results point to training as the gap, my Copilot curriculum for B2B sales and marketing teams is built specifically for what comes next—role-specific, hands-on, and built around the workflows your teams actually run.
Key Takeaways:
- Copilot adoption is an operations problem, not an IT problem—IT owns deployment, not behavior change
- The accountability vacuum—IT owns deployment, L&D owns training, nobody owns adoption—is the most common reason rollouts plateau
- COO ownership means setting an adoption target, assigning a business-side owner, prioritizing workflows, and making adoption visible in business reviews
- The fix is not more training. It is assigning the adoption number to someone with the authority to change how teams work
- Ask one question: who is accountable when the Copilot active usage number doesn’t hit target? If the answer is unclear, you have your diagnosis
Want to brainstorm where Copilot adoption accountability fits in your organization? Or if you’d like to know more about Pam’s AI Training, including exclusive AI Copilot Training for enterprises? Schedule a call with Pam.
Want to understand AI Marketing in less than 2 hours? It starts with this book! Grab Your Copy of The Modern AI Marketer in the GPT Era.
About Pam Didner
Pam Didner is a B2B AI strategist, fractional CMO, and 5x author who helps marketing and sales teams get AI-ready, aligned, and focused on revenue. With 20+ years in the corporate world – across accounting, supply chain, marketing, and sales enablement – she knows how big organizations actually work, and how to move them. She does that through fractional CMO engagements, keynote speaking, workshop training, private coaching, and hands-on consulting. Contact her or find her on LinkedIn. She also leads Microsoft Copilot training programs for enterprise marketing and sales teams.
Frequently Asked Questions
Why is Copilot adoption an operations problem rather than an IT problem?
IT is responsible for deployment—licenses, configuration, access, security. Adoption is a behavior change problem: getting teams to integrate a new tool into their daily workflows. Behavior change requires operational authority, workflow knowledge, and business-side accountability. Those capabilities sit in operations, not in IT. IT can tell you how many people have access to Copilot. Operations needs to be accountable for how many people are actually using it to change how work gets done.
What does it mean to “own” Copilot adoption?
Owning Copilot adoption means being accountable for the active usage number—the percentage of licensed users who are using Copilot in a meaningful workflow at least three times per week. The owner tracks this metric, reports on it in a business review, identifies teams or individuals who are lagging, and coordinates the interventions (targeted training, workflow guidance, manager conversations) needed to move the number. It is a business-side accountability, not a technical one.
What if our COO isn’t interested in owning this?
The COO doesn’t have to be the hands-on owner—they need to be the executive sponsor who assigns the accountability and makes it visible in a business review. The operational lead can be a VP of Operations, a Head of Productivity, a Sales Enablement Director, or any role with workflow authority and business-side accountability. What matters is that the owner is not in IT or L&D, and that the adoption number appears in a business performance context—not just an IT rollout dashboard.
How is the accountability vacuum different from normal cross-functional coordination challenges?
The accountability vacuum is specific to technology deployments where IT handles the launch. In most cross-functional work, accountability is negotiated explicitly at the start. In technology deployments, it defaults implicitly to whoever pressed the launch button—which is IT. The vacuum exists because nobody claimed the adoption accountability explicitly, not because the functions failed to coordinate. The fix is an explicit claim, not better coordination.
How do I know if our Copilot rollout has an accountability vacuum?
Ask one question: who is accountable when the Copilot active usage number doesn’t hit target? If the answer is a pause, a shrug, or three people pointing at each other—you have an accountability vacuum. If the answer is a specific person’s name and a specific business review where that number appears—you don’t. Most organizations, when they ask this question honestly for the first time, discover they have a vacuum.
