Every managed service contract carries a hidden tax: the first-line questions that arrive constantly, are already documented, and get answered by an engineer who was in the middle of something else.
Nobody sells against this. Everybody pays it. And it scales with the client base, which means the better you do commercially, the more of your capacity it consumes.
Sort your tickets by resolution, not subject
Most MSPs categorise tickets by what they were about. More useful is categorising by how they got closed.
Three buckets emerge. Tickets resolved by pointing at documentation that already existed. Tickets resolved by explaining something that turned out not to be documented anywhere. And tickets that required someone to log into a system and look.
The first bucket is deflectable today. The second is deflectable once you write the thing down, and the fact that it was never written down is the finding. The third is what your engineers should be doing.
Run that exercise before configuring anything. It tells you what the ceiling actually is, and it usually turns out to be higher than people expect.
What deflection looks like in practice
The recurring first-line set is remarkably consistent across MSPs: mailbox full, printer not responding, VPN will not connect, shared drive missing, Teams audio, licence requests, new starter setup questions, mobile device enrolment.
A bot pointed at your knowledge base handles the documented resolution path for each, in the user's own words rather than yours. That last part matters. Users describe symptoms; documentation describes systems. "I can't get on the shared drive from home" and "Configuring VPN split-tunnel access to mapped network resources" are the same article and the user will never search their way to it.
Where the bot cannot resolve, it should open a ticket with the diagnostic detail already gathered: what they were doing, what happened, what device, whether it affects one user or several, and whether they have restarted. An engineer picking that up starts several steps ahead.
The two things it must never do
Never facilitate a credential reset. Identity verification is the entire purpose of that workflow. A chatbot cannot verify who it is talking to, and social engineering against helpdesks is one of the most reliable attack paths in existence. It explains the process and routes to your self-service tool or an authenticated channel. Nothing else.
Never triage a security incident. Anything mentioning ransomware, a suspicious email that was clicked, unexpected account activity, files that have been encrypted or renamed, or a device behaving oddly after an install goes straight to a human, immediately, with urgency flagged.
Write both as explicit rules before any content is loaded. Test them adversarially, including the phrasings a user under pressure would actually type.
Scope questions are worth automating
There is a category of question that generates friction on every managed contract: is this covered.
Is my home printer in scope. Does the contract include my personal laptop. Who pays for the new licence. Is out-of-hours support included on this tier. What is the response time for a low-priority issue.
These produce awkward conversations because the answer depends on a contract nobody has read since it was signed. A bot answering consistently from your published service descriptions removes an entire class of dispute, and it removes it before the work is done rather than at invoicing.
New business, at the hours it arrives
Prospects evaluating an MSP are usually doing it because something went wrong with the current one, and they research in the evening after dealing with the consequences.
What they ask is predictable: what your response times are, whether you cover out-of-hours, how onboarding works and how disruptive it is, what happens to their existing documentation, how you price, and whether you work with businesses their size.
Answer those and capture the useful qualifiers: headcount, current arrangement, when that contract ends, and what prompted the enquiry. That last one tells your sales team everything about how urgent this is.
Internal use, which is often the bigger win
Point the same tool at your own process documentation and it answers your engineers.
What is the escalation path for this client. Which RMM policy applies. Where is the template for a new starter. What is the change process for a production system. Who is on call this weekend.
New technicians consume a disproportionate amount of senior time asking questions that are documented but scattered. That drain is invisible on any report and substantial in practice.
Setup order
Knowledge base first, service descriptions second, sales content third. Write the two hard rules before any of it.
Then set the ticket-creation fields so anything the bot cannot resolve arrives with diagnostics attached rather than as "it's broken".
Measuring honestly
Count first-line tickets in your top ten subjects before and after. That is the direct effect.
Then track the questions the bot could not answer, because that list is your documentation backlog, ranked by frequency and written by the people who actually needed it. For most MSPs it is more useful than the deflection number itself.