Automation Divide
AI use is spreading, but readiness is uneven, and the operational expectations around speed and productivity are outpacing most organizations’ ability to keep up.
Start with what’s happening inside day-to-day IT support. Channel Dive reported on a Fixify study that analyzed more than 50,000 support tickets across 30-plus organizations over 14 months, and the headline number is hard to ignore: tickets that were at least 75% automated were resolved in an average of 4.4 hours, compared to roughly three days for teams not using automation. To be clear: this isn’t saying every ticket becomes a 4.4-hour ticket. This is about the categories that are repeatable and rules-driven—things like password resets, access requests, permission changes, and onboarding/offboarding. And the metric that matters isn’t just ‘touch time’—it’s elapsed time to closure, because that’s what sets user expectations. Fixify also found that nearly half of all ticket volume lands on Mondays and Tuesdays, and a lot of those requests are the kinds of things automation can handle—password resets, access requests, permission changes, onboarding and offboarding. That’s observable evidence that the baseline for “how fast support should move” is being reset in real environments, not just in demos.
Now zoom out to small and mid-sized business adoption. ITPro cites survey data from OpenAI showing that in London, 93% of SMBs are using AI tools in daily operations, but that uptake is uneven across the UK. In Yorkshire and Humber, 26% of SMBs report not using AI at all, and similar gaps show up in Scotland and the South West. Among the businesses that are using AI, OpenAI reports average time savings of more than 5.2 hours per week, with that time going to creative thinking, strategic planning, and product and service improvement. Same market, same toolset availability—very different levels of usage.
And then there’s the signal from the public sector, where rollout pace tends to be cautious by design. GeekWire reports that Seattle has paused the planned citywide expansion of Microsoft Copilot for city employees under the new mayor, even after a pilot with 500 employees where participants collectively reported saving more than 450 hours of work per week. A pause like this doesn’t necessarily invalidate the productivity claim—it usually reflects governance maturity and leadership risk tolerance. New leadership often rechecks: how were savings measured, what data was exposed, and who is accountable when outputs are wrong?” The city says the education and governance work continues, alongside foundational work in data governance and data readiness. Again, that’s not a debate about whether the tools exist—it’s evidence that adoption is being gated by readiness, policies, and comfort, even when early results look positive.
And that’s the real signal: AI adoption is no longer being limited by tool availability. It’s being limited by workflow coherence, policy readiness, and the ability to govern faster work.
Coordination Debt
The underlying driver here is that most organizations don’t actually run as one system, even if they buy technology as if they do. They run as a collection of half-connected workflows, legacy habits, and handoffs that only “work” because people compensate for the gaps. AI doesn’t eliminate that problem — it exposes it. And the moment work gets faster, more automated, or more distributed, the first thing that breaks isn’t the tool. It’s the coordination.
HP’s Workflow Wakeup research backs this up: more than half of IT leaders at SMBs say they spend their time fixing issues rather than improving systems. That’s not an AI problem — that’s coordination debt showing up as operational drag.
That coordination problem also explains the pricing shift. If automation compresses routine labor, clients stop valuing visible effort and start valuing managed throughput, governed workflows, and measurable outcomes. In other words, the more AI removes human touch from repeatable work, the less defensible labor-based pricing becomes. That is why readiness, integration, and governance start to carry the premium. And here’s where the buying process shifts: once leaders see measurable deflection and faster closure, they stop asking, ‘How many techs do we get?’ and start asking, ‘What outcomes do you guarantee—and what happens when the automation is wrong?’ That’s when procurement compares you on reporting, controls, exception handling, and liability—not effort.”
Automation Liability
Once automation sits inside the workflow, the provider managing the environment becomes the default owner of the exceptions it creates.
The consequence for MSPs is that “automation in the workflow” is turning into an operational surface area that someone has to control, monitor, and be accountable for. And increasingly, that “someone” is going to be you — whether you priced it or not.
One proof point is what InformationWeek flagged as Microsoft expands Copilot: the security problem shifts from simply controlling access to controlling the interaction layer, because AI doesn’t just move data, it reshapes it. As Dan Lohrmann at Presidio put it, users are pasting sensitive material into AI tools as part of normal work, creating persistent shadow AI behavior even when policies say otherwise. And the risk isn’t limited to obvious exfiltration. AI can summarize, recombine, and infer meaning in ways that don’t trip classic controls, and it can do that inside the tools where people already work — email, browser tabs, documents, and chats. For an MSP, that’s not a “Microsoft feature update.” That’s a change in what it means to secure a client environment when the day-to-day work interface is also an AI execution layer.
The second proof point is the Kaseya INKY Email Security Report, covered by Technology Reseller, which is blunt about what’s happened to phishing: AI-generated phishing is now the baseline. The old tells — bad grammar, obviously sketchy domains, clumsy formatting — are disappearing. The report notes phishing accounts for 26% of FBI cybercrime complaints, with $2.8 billion in reported Business Email Compromise losses, and it highlights how attackers are moving into formats like calendar invites and protected documents. This isn’t just “more spam.” It’s automation on the adversary side, forcing defenders to shift toward intent and context rather than simple indicators. And that shift is operational: it changes what you have to tune, what you have to train, and what you have to prove after an incident.
Put those together, and the consequence is straightforward: clients are going to run automation inside the workflow, and attackers are going to run automation against it. That creates a fork for MSPs. Either you become the provider that simplifies and governs the automation layer — with defined controls, visibility, and boundaries — or you get trapped absorbing the mess: exceptions, escalations, incident cleanup, and blame, without being paid for it.
Why Do We Care?
The automation readiness gap is not a technology problem — it’s a coordination debt problem, and MSPs are positioned to be either the creditor or the collector. Because the external pressure won’t just be users demanding speed—it’ll be audits, insurance renewals, and customer security reviews asking you to prove where AI touched data, what controls existed, and what logs you can produce.
If an MSP misreads this as a tooling wave instead of a business-model shift, they will keep selling ticket work while automation resets response expectations and expands operational liability inside the client workflow. That is the bad decision: pricing for activity when the market is moving to accountability.
The MSP who builds governance and maturity assessment into their service model gets paid for managing complexity. The MSP who doesn’t gets paid for managing tickets — while quietly absorbing the liability for everything the automation layer touches.
What to Consider
- Reprice SLAs immediately against the automation benchmark. If 4.4-hour resolution is achievable on automatable ticket categories, your current SLA tiers need to reflect that — or you need to explicitly define which ticket categories are excluded and why.
- Build a shadow AI audit into every QBR. Add a standing agenda item: what AI tools are in use, what data is touching them, and what the policy boundary is. Charge for this as a governance service, not a freebie.
- Develop a “readiness gap” assessment product. Seattle’s pause proves that even successful pilots get blocked by governance unreadiness. Package a pre-deployment maturity assessment — data governance, policy readiness, workflow coherence — as a billable engagement.
- Restructure at least one client contract toward outcome-based pricing this quarter. The seat model erodes as headcount shrinks. Pick a client with measurable automation potential, define the outcome metric (resolution time, ticket deflection rate, hours recovered), and pilot a contract structure that ties your fee to that outcome. This is the proof-of-concept you need before the model forces the conversation.
If this trend continues, SMB buyers will stop asking who can deploy AI and start asking who can govern it, prove the outcome, and carry the risk. MSPs still selling hours will be pushed into low-margin cleanup, while firms packaging automation maturity will win the premium contracts.