There is a distinction worth making early, because almost every organization we meet has collapsed it. Deploying Copilot is a productivity change: it lands on individuals, it changes work habits, and success looks like usage. Deploying an agent is a process change: it lands on a workflow, it redistributes who does what, and success looks like the workflow running differently.
Those two things need different work. A Copilot rollout needs training. An agent rollout needs the thing that no MSP wants to sell and no board wants to fund, which is change management. Prosci’s 2024 research puts it plainly: organizations with excellent change management practices are seven times more likely to meet or exceed project objectives than those with poor practices. Seven times is not a rounding error. It is the difference between the agent being used and the agent being a line item somebody defends at the next budget meeting.
Microsoft’s own adoption guidance names six sources of resistance. They are not sector-specific, and that is exactly the problem: each one lands differently in a forty-person nonprofit than it does at Vodafone. Here is what each looks like in the organizations we serve, and what actually moves it.
Job security, and the fact that you cannot honestly promise nothing changes.
In a Fortune 500, “agents augment, they do not replace” is a defensible statement because the work absorbed by an agent gets redistributed across thousands of roles. In a forty-person nonprofit where one person is the grants department, an agent that drafts letters of inquiry is visibly doing part of a named individual’s job. She knows it. Telling her otherwise costs you her trust and the pilot.
The honest version works better, and we have watched it work: the agent takes the part of the work nobody went to graduate school to do, and the time comes back to the part they did. Then you have to actually give the time back rather than quietly absorbing it as capacity.
What to do: name the affected roles before you build, in a room with the people in them. Ask what they would do with six hours a week. Write the answer down. It becomes the success metric.
Data security, which in this sector is not an abstraction.
Staff want to know where the data goes. In a hospital that means protected health information. In a foundation it means the grantee who disclosed something in confidence. In a nonprofit serving vulnerable populations it means case notes that could get somebody hurt.
“It stays in the Microsoft tenant” is true and insufficient. What people are actually asking is whether the agent can surface something to someone who should not see it. The answer depends on permissions and labels, not on the agent, which is why the governance baseline comes before the pilot rather than after it.
What to do: link the existing data policy in the launch communication, and explain in one paragraph how permissions and sensitivity labels bound what the agent can reach. Do not send this from IT. Send it from the executive who signed the policy.
The people who will use it were brought in after it was built.
This is the most common failure and the most preventable. IT scopes an agent, builds it in Copilot Studio, demonstrates it to the program team, and discovers in the demo that the workflow it automates is not the workflow the team runs. It was the workflow described in a process document written four years ago.
Change management that begins at deployment is not change management. It is an announcement.
What to do: put two people who will use the agent daily on the project team, from the first scoping conversation. Have them test the agent’s answers against real cases before it ships. They become your champions, and they will tell you the thing the process document did not.
Change management that begins at deployment is not change management. It is an announcement.
Nobody explained the why, because “we bought Copilot” is not a why.
Staff will not adopt a tool whose purpose they cannot state. If the reason the agent exists is that the licensing came bundled, or the board asked what the organization is doing about AI, people can smell it. Mission-driven staff are unusually good at detecting work that does not serve the mission, which is a feature, not an obstacle.
What to do: tie the agent to a number the organization already cares about. Not “productivity.” Time from intake to first contact. Days to close a grant report. Percentage of donor thank-yous sent within 48 hours. If you cannot name the number, you have not found the scenario yet.
Trust in the outputs, which is rational and should be preserved.
The agent will be confidently wrong occasionally, and the cases where it is wrong are correlated with the cases that matter. A miscited giving total in a donor brief. An eligibility criterion misstated in a grant summary. A number in a 990 that nobody caught.
Staff who are skeptical of AI outputs are not obstacles to adoption. They are the quality control layer, and an organization that trains that instinct out of them has traded a slow rollout for a fast liability.
What to do: train people to find the agent’s errors rather than to trust it. Give them a checklist for verifying outputs. Celebrate the first person who catches a mistake, publicly. Human oversight is the design, not a transitional phase.
Change fatigue, and the thing you are not counting.
Before you schedule the agent pilot, ask what else is happening. A rural hospital mid-way through an EHR migration cannot absorb an AI rollout, and the staff who tell you so are correct. A nonprofit that changed CRMs in the spring and payroll systems in the fall has spent its appetite for new systems, regardless of how good this one is.
What to do: pace it. One agent, one workflow, one team, until it is boring. Agent sprawl is a governance problem; agent enthusiasm is an adoption problem. Both are solved by going slower than the technology allows.
Pick a first scenario you can actually finish.
Most of the six reasons above are downstream of one decision: which workflow you chose. Score candidate scenarios on two axes, business impact and implementation complexity, and be ruthless about what belongs where.
High impact · Low complexity
Quick wins
Start here. Always. This is the first agent, and its real job is to earn the organization’s permission to build a second one.
High impact · High complexity
The real prize
Worth doing, second. These are the process changes that move a budget line. Attempt one before you have a quick win behind you and you will spend your credibility on it.
Low impact · Low complexity
First successes
Cheap practice. Useful for building maker skills and champion confidence. Do not report these to the board as outcomes.
Low impact · High complexity
Do not
Every organization has one of these, and someone senior is attached to it. This is the conversation the partner is paid to have.
Measure three things, in this order, and know which one the board is asking for.
The most common measurement mistake is reporting the first rung as though it were the third. Usage is not impact. It is the leading indicator that impact is possible.
Adoption metrics
Are people using it, and do they come back. Repeat usage is the only number here that means anything; first-week usage measures your launch email. Agent sessions, repeat users, resolution rate, satisfaction score.
Operational KPIs
Did the process get better. This is the rung most organizations never reach, because it requires having captured a baseline before the agent existed. Days to close a grant report, time from intake to first contact, support case resolution time.
Business outcomes
Did the mission move. Lagging, noisy, attributable only in aggregate, and the only rung a board actually cares about. Grant dollars won, donor retention, staff turnover, cost per constituent served.
Capture the baseline before you deploy. This sounds obvious and is skipped roughly nine times out of ten. If you do not know how long a grant report took in March, you cannot claim the agent improved it in September, and the claim is what funds the next agent.
Once it is live, two numbers tell you what to do next.
Cross resolution rate, whether the agent completes the task, against satisfaction, whether people like using it. The four cells prescribe four different actions, and treating them the same is why agents get quietly abandoned instead of fixed.
Low resolution · Low satisfaction
Retire it
Check the configuration once, then redesign or retire. Do not iterate on an agent that is failing on both axes; ask whether the scenario was ever right.
Low resolution · High satisfaction
Widen it
People like it but cannot get what they need. Usually the scope is too narrow or it lacks access to a data source. Expand it, or fix the escalation path.
High resolution · Low satisfaction
Fix the experience
The work gets done and the process is unpleasant. Read the conversation logs. Tone, length, and number of turns are the usual culprits.
High resolution · High satisfaction
Study it, then copy it
Your benchmark. Work out what makes it good and replicate the pattern in the agents that are not. This is also the one you show the board.
The uncomfortable conclusion is that the agent is the easy part. Copilot Studio will build a competent retrieval agent in an afternoon. What takes ninety days is finding a workflow worth changing, capturing the baseline, putting the affected staff on the project team, being honest with the person whose job partially goes away, and then reinforcing the change long enough that going back to the old way stops being an option.
That is the work. It is the work our Agent Launchpad is organized around, and it is why Managed AgentOps exists as an ongoing service rather than a handoff: the resolution-rate and satisfaction numbers above only become useful when somebody is looking at them every month.
If you are about to run an agent pilot, the question to answer first is not which agent. It is which workflow, whose job it touches, and what number you will be able to show the board in September that you can prove was different in March.
Run the pilot properly.
Agent Launchpad is six weeks from Copilot license to a first production agent, with the scenario chosen against the matrix above, the baseline captured, and the affected staff on the team from week one.
See Agent LaunchpadKeep it alive after launch.
Managed AgentOps watches resolution rate, satisfaction, drift, and cost every month, and does something about them. Agents fail quietly. This is how you hear about it.
See Managed AgentOps