Every MSP I know has a version of the same pitch sitting in a draft email. "We can add AI to your helpdesk." The demo looks fine. Password resets get answered. The VPN article gets quoted. Someone on the client side nods like they just bought a future. Then the tickets start flowing the way they actually flow, and the model spends half its day guessing whether "Outlook is broken" means a mailbox quota, a bad profile, or a user who closed the wrong window and wants you to open it again.
If your triage is a mess, AI does not fix it. It accelerates the mess. That is the whole post, but people keep skipping the boring part, so here is the boring part with the edges still on.
What triage actually means in an MSP queue
Triage is not a priority field your techs forget to set. It is the first decision that shapes everything after it: who owns the ticket, what "done" looks like, whether the client gets a reply in five minutes or a scheduled window next Tuesday, and whether this is billable project work wearing a ticket costume.
Walk a real Monday morning for a sixty-seat accounting firm on a standard managed agreement. You get fourteen new tickets before 10 a.m. Three are password resets. Two are printer drama on the same floor. One is a CFO who cannot open a shared Excel file the day before month end. One is a vague "network feels slow." Two are onboarding leftovers from last week's new hire. The rest are noise that still needs a human decision: vendor portal access, a phishing forward that is actually spam, a request to install personal software the contract does not cover.
A clean triage path answers a handful of questions in order. Is this an outage or a request? Is it covered under the agreement or a change order? Is there a known fix with a known owner? Does it need a callback, a remote session, or an onsite? Can a junior tech close it, or does it need someone who has touched that client's firewall before?
If your board shows "unassigned" for forty minutes while three techs argue in chat about who "owns printers," you do not have an AI problem. You have an ownership problem with a software costume.
Why AI fails first on classification, not conversation
Most helpdesk AI products sell the chat layer. That is the shiny bit. The failure mode that hurts MSPs is classification. The model has to map messy human language onto your categories, SLAs, and routing rules. Those rules are usually half documented, half tribal, and half whatever the last dispatcher typed when they were late for lunch.
Take "cannot print." In one client that means the Kyocera on the second floor needs a toner swap your onsite tech already knows about. In another it means the print server queue is stuck after a Windows update. In a third it means the user is printing to a ghost printer from a laptop that left the domain two months ago. Same subject line. Three different owners. Three different time boxes. One wrong auto-route and you burn a senior tech on a toner run while the print server ticket ages into a breach.
Or take "VPN not working." Half the time the user is on the wrong Wi-Fi at a hotel. A quarter of the time MFA is locked. The rest is cert expiry, split tunnel weirdness, or a client who changed their home router and now thinks your appliance is haunted. An AI that answers with a generic split-tunnel article looks helpful in a demo and looks reckless when the ticket was actually a locked Entra account for a traveling sales manager who needs access before a client meeting.
I have watched MSPs feed six months of ticket history into a vendor "training" pipeline and then act surprised when the model inherits every bad habit in that history. If your techs used to close password resets under "General Support" and VPN issues under "Network" and also under "User Error" depending on the day, the model will learn that chaos with high confidence. Garbage in still wins. It just wins faster and with a confidence score.
The triage cleanup that actually moves the needle
Before you buy a bot, spend two weeks making the queue boring in a good way.
Pick your top twenty ticket types by volume across a representative slice of clients. Not by vibes. Export from the PSA and count. For an SMB-heavy book you will usually see password and MFA, email access, printer and scanner, VPN and remote access, new user and offboarding, file share permissions, workstation performance, and a long tail of one-offs. Write a one-page definition for each type: intake questions, first response template, escalation path, and what "resolved" means. Keep it short enough that a new dispatcher can use it without a seminar.
Then force the board to match those types. Kill duplicate categories. Kill "Other" as a dumping ground unless you have a weekly review that turns "Other" into real types. If a ticket cannot be typed in under thirty seconds, your taxonomy is wrong or the ticket is project work and should leave the queue.
Route by type and client risk, not by who happens to be online in Teams. A manufacturing client with a plant floor outage should not wait behind a marketing intern's Canva install, even if both landed as "priority medium" because nobody wanted to argue with the portal defaults. Build a small set of VIP and outage rules and make them visible. Techs should not need folklore to know the CFO ticket jumps the line.
Close the loop on duplicates. Two tickets about the same printer outage should become one ticket with watchers, not three parallel threads and an AI that answers each one like it discovered a unique incident. Dedup is unglamorous. It is also where a lot of "AI saved us time" claims quietly die, because the bot happily answers the same incident six times.
Finally, measure triage lag. Time from create to first correct assignment. Not first auto-reply. Not first public note that says "we are looking into this." Correct assignment. If that median is already twenty minutes on a quiet Tuesday, bolting on a chatbot will not make your service feel faster. It will make your wrong answers arrive sooner.
Once typing and routing are consistent, AI earns a seat. Start with the ticket types that already have a crisp definition and a known fix path. Password resets with a clear identity provider. Known VPN client version mismatches. "How do I..." questions that map to a current runbook you actually maintain. Keep a human in the loop for anything that touches permissions, billing disputes, security alerts, or a client who already yelled once this quarter.
Use the model as a dispatcher assistant before you use it as a client-facing voice. Draft the type suggestion, the likely KB article, and the first internal note. Let a human confirm for a month. Review the misses in a short weekly standup. You will learn whether your taxonomy is real or aspirational. That review is the product. The model is just the speed layer.
When you do go client-facing, scope it per agreement. A dental office that wants a soft landing on password resets is a different risk profile than a law firm that will treat a wrong answer like a discovery problem. Put the scope in the SOW in plain language: which ticket types the bot may touch, what it must escalate, and who gets paged when confidence is low. If you cannot write that paragraph without hedging, you are not ready to turn the bot on.
If your sales deck needs AI on the helpdesk to win the renewal, and your queue still runs on tribal knowledge, you are selling theater. Clients feel triage quality in the first hour of an incident. They feel AI quality later, if at all. Fix the hour they feel first.
I am not anti-AI. I am anti-skipping the work that makes AI cheap to run and hard to embarrass you with. Clean types, clean routing, measured assignment lag, then a narrow bot with a human gate. That sequence is dull. It also survives contact with a real Monday morning, which is more than I can say for most demos.