The readiness test hides in your escalation queue
Picture a 100-person IT services shop on a Tuesday. A P2 ticket bounces from L1 to L2 to the one senior engineer who actually remembers how this client's hybrid Exchange setup is wired. He fixes it in twenty minutes. The handoff notes say "resolved, see Slack." That single ticket is your real AI readiness assessment, and most firms fail it before they ever evaluate a tool.
Here is what most leadership teams get wrong: they decide they are "ready" the day they buy everyone a chat license. Readiness has nothing to do with seat count. It is whether one service workflow has enough source discipline, clear ownership, and a review rhythm that you could safely point a model at it and trust the output. For an IT services firm, the strongest candidates are narrow and obvious — ticket summarization for shift handoff, escalation packet preparation, project-status cleanup before a steering call, runbook retrieval, and implementation QA against a scope of work.
The constraint at this size is almost never enthusiasm. It is that your service desk notes, project records, runbooks, and client obligations live in three ticketing systems, a wiki nobody updates, and the head of the engineer who has been there eight years. Readiness begins the moment those inputs can be named, located, and reviewed without paging that one person. Before you score anything, run a candidate workflow through the AI use-case scoring model on repeatability, data availability, human review, and business value. If a workflow can't clear that screen, it is not your first move no matter how exciting the demo looked.
For an MSP, the data boundary is the assessment
An IT services firm carries something a marketing agency or a law office does not: privileged access to other companies' infrastructure. Credentials, incident timelines, network architecture, VPN configs, client security postures. The moment you let a model search or summarize across tickets, the question stops being "is this useful" and becomes "which client's environment just got exposed to which other client's account team." That is why, for an MSP, governance is not a phase that comes after the pilot. It is the pilot.
The NIST AI Risk Management Framework gives an executive team a workable sequence — map the context, measure the risk, then manage the controls. Translated into your shop: decide which client tenants' data may be retrieved, which tickets are walled off entirely (anything touching a security incident, a credential, or an under-NDA architecture), which outputs a service manager must sign before they reach a client, and where exceptions route — security lead or account owner. The CISA AI Data Security Best Practices should set that boundary on day one: role-based access, retention rules, and logging on the corpus before you expand a single retrieval workflow. An MSP that gets breached through its own AI tooling does not lose a feature. It loses the account.
The output of a real readiness assessment is not a maturity score on a slide. It is a 90-day operating plan with six named things: the first workflow, the baseline metric, the source owner, the human reviewer, the blocked data types, and the escalation route. A score tells your board you thought about AI. The plan tells your service desk what changes on Monday. That gap — between AI readiness and tool availability — is exactly where most firms stall for a year.
Measure it in handoffs and review burden, not logins
The vanity metric is "percent of staff using the tool." Ignore it. For a 100-person services firm, the numbers that matter sit in the work: ticket-handoff completeness across shift change, time to assemble an escalation packet, project-status accuracy before a steering committee call, the missing-source rate when a summary cites something that does not exist, how much of your senior managers' week gets eaten by review, and client-impact exceptions caught before they turn into an angry account call. Those you can read every week. A login count tells you nothing about whether the work got better.
And expect the first workflow to embarrass you a little. Point it at ticket summarization and you will discover your categories are inconsistent across three technicians, half your runbooks are stale, and nobody can say cleanly which client data a given tech is permitted to see. That is not a failure of the AI — that is the assessment doing its job. The honest next move is often service-process repair before any further automation. Fixing the ticket taxonomy is unglamorous and it is also the highest-leverage thing you can do.
Keep the business case honest, too. Measuring AI ROI without fake savings stops leadership from booking every auto-summarized ticket as "value created." The defensible claim is narrower and more credible — faster service decisions, cleaner delivery handoffs, fewer 9pm pings to the one engineer who knows everything. If you want the named workflow, owner, reviewer, and 90-day metric set written down rather than improvised, that is what an AI roadmap is for. Start with one queue, prove it, then earn the second.
