Readiness isn't a maturity score. It's whether your ticket data can keep clients apart.
Picture the Tuesday morning your night-shift queue dumps into the day shift: 140 open tickets across 60-odd clients, three P1s, a dispatcher trying to remember which managed firewall belongs to which co-managed environment, and a tech who just closed a ticket using a runbook from the wrong tenant. That mess — not a strategy deck — is where a 200-person MSP finds out if it's ready for AI. Readiness is not a maturity score you self-grade. It's a concrete question: can the data in your PSA and RMM stay separated when a model starts reading across all of it at once?
AI is moving from novelty to operating reality for service businesses — both the U.S. Census AI business adoption analysis and the OECD SME AI adoption report show small and mid-sized firms adopting in earnest. But adoption stats don't tell you where to point it. For an MSP, the answer is almost always the one workflow that already bleeds margin and trust simultaneously: support triage and dispatch. Pick a single queue — say your Tier 1 endpoint/network tickets for one segment of clients — and prove AI can classify the issue, flag the missing context a tech would otherwise burn minutes hunting for, and stage the ticket for the dispatcher. The thing you are watching for is not a clumsy summary. It's the assistant that quietly mixes tenant context, buries an escalation under a tidy "resolved" label, or nudges a tech toward billable work that torches the SLA you already committed to.
What most MSPs get wrong: they measure drafts, not behavior
The trap is counting outputs. "The AI summarized 800 tickets this week" is not a result; it's activity. A 200-person shop already drowns in activity. What you actually need to know is whether the operating behavior moved — and for an MSP that behavior has four named numbers. Set your baseline on them before the pilot touches a live ticket: median queue age before first human touch, escalation misses (P2s that should have been P1s), technician reassignment rate (how often a ticket bounces because it landed wrong), and minutes spent collecting client-specific context per ticket. Those are the levers AI either improves or pretends to.
Then run a weekly review that inspects the failure surface, not the win highlights. Pull every customer-facing message the AI drafted that a dispatcher held back, every ticket where the model reached for the wrong tenant's documentation, every SLA exception by client, and every dispatch the service manager overrode. If those incident counts drop while queue age drops, you have a real case. If queue age drops but tenant-boundary slips tick up, you've traded a breach risk for a speed metric — a bad trade no margin improvement covers. Only once those measures sit with a named owner — your service delivery manager, not "the team" — should you let the AI Opportunity Score or the AI ROI Calculator put dollars against it. A number nobody owns is a number nobody will defend when it slips.
The three gates: tenant isolation, dispatch authority, protected margin
Before you widen the pilot past one queue, three gates have to hold. First, tenant isolation: the model gets read access scoped to the assigned account and nothing else. Block it from records outside that account at the data layer, not the prompt. The CISA AI data-security best practices should shape how you wire client separation, role-based PSA and RMM access, and retained audit trails — in a multi-tenant MSP, this is the gate that, if it fails once, ends the program. Second, dispatch authority: a human dispatcher or service manager signs off on anything customer-facing, and SLA exceptions get logged by client so you can see drift before a client does. Third, protected margin: the assistant must not be allowed to route a ticket in a direction that breaks an existing SLA commitment to manufacture billable hours.
The NIST AI Risk Management Framework gives you the spine to do this cleanly — map the intended use, the risk, how you'll measure it, and who's accountable, for this one triage-and-dispatch workflow specifically. Don't boil the ocean; govern the queue you actually piloted. The expansion rule writes itself from there: move from one queue to the next client segment only when you can show faster routing with zero tenant-boundary slips and no margin-eroding escalations across a full review cycle. Monday action: open your PSA, count how many open tickets a single Tier 1 tech can currently see across clients they aren't assigned to. If that number isn't zero, you have your first AI-readiness project — and it has nothing to do with AI yet.
