Every MSP is currently telling its clients it uses AI. I want to be more specific than that, because the interesting part is not what we automated. It’s what we tried and stopped.
Where it genuinely earns its place
Turning bad ticket descriptions into useful ones
The single most valuable thing we do with a language model is unglamorous: taking a ticket that says “computer not working” and generating the three clarifying questions a technician would have asked, before a human picks it up.
It doesn’t diagnose anything. It just removes the first round-trip, which historically cost half a day because the user was in a classroom and unreachable until lunch.
Drafting documentation from work already done
Documentation is the thing every MSP knows it should do and doesn’t, because at 5pm on a Friday the incentive to write up what you just fixed is zero.
Generating a first draft from the ticket trail and the engineer’s notes changes the task from writing to editing, and people will edit when they won’t write. Our documentation coverage improved more from this than from three years of asking nicely.
Summarising noisy monitoring
Not deciding what matters. Summarising. “Overnight there were 340 alerts across 22 devices; 300 relate to one flapping interface at one site.” That’s a genuinely useful morning briefing and it saves someone twenty minutes of scrolling.
First-pass log reading
Pointing a model at a wall of log output and asking what’s unusual is a reasonable way to generate hypotheses. It is not a way to reach conclusions. Treated as a colleague who reads fast and is sometimes confidently wrong, it’s useful.
What we tried and abandoned
Automated ticket resolution
The pitch is irresistible: let the system resolve password resets, mailbox permissions, simple requests, end to end.
The problem is that the tickets simple enough to safely automate are also the ones a competent human resolves in ninety seconds. The saving is small. Meanwhile the failure mode is not small: a system that confidently takes the wrong action on an identity request creates a security incident, and the effort of building sufficient guardrails exceeded the effort saved.
We kept the drafting, dropped the acting.
Customer-facing chat as first-line support
Our clients are schools and small businesses who pay us specifically so that a person answers. Putting a bot in front of that relationship optimises the wrong variable. We are not high enough volume for the economics to justify the goodwill cost.
Larger providers may reasonably land differently. At our scale it was clearly a bad trade.
Anything touching client data without a clear boundary
This is the one that should give every MSP pause. We hold administrative access to client environments containing student records, health information and financial data. Piping any of that into a third-party service because it makes a workflow slightly faster is not a decision to make casually, and in several cases the client contract simply doesn’t permit it.
Our rule is straightforward: client data does not leave systems we have explicitly told the client about. That rules out several genuinely useful applications, and I’m comfortable with the trade.
The pattern
Everything that stuck has the same shape: the model produces a draft, a human decides. Everything we abandoned had the model taking an action.
That’s not a permanent law of nature, and the boundary will move. But it’s a decent heuristic for anyone deploying this in an operational environment where being wrong has consequences. The value is in compressing the time to a good draft, not in removing the person who knows whether the draft is right.
A question worth asking your provider
“Which of your AI tooling has access to our data, and where does that data go?”
You are entitled to a specific answer. If you get a vague one, that is itself informative.