Guide
AI for Tier-1 Tickets at ISPs and MSPs: What to Automate First
Tier-1 is where good technicians burn out: the same resets, the same "is it down?", the same Wi-Fi questions. Here's how to pick which tickets to hand to AI first, which ones never to, and how to tell whether it's working.
Every service provider's queue has the same shape. A small set of ticket types makes up most of the volume, they're resolved the same way almost every time, and they're handled by the people you'd most like to free up for real problems. That's the opportunity for AI in tier-1 support. It's also where it's easiest to make a mess: automate the wrong ticket type and you get confident wrong answers, angry subscribers and techs cleaning up after a bot.
We've worked those queues from the inside, at service providers and in the help desks behind them. This guide is the sorting method we use, the ticket types we'd automate first and the ones we never would, the metrics that tell you whether it's working, and a first-month plan. It applies whether you run a regional ISP, a WISP or an MSP, and whether your tickets live in ConnectWise, HaloPSA, Autotask or the like. For the broader picture, see our page on AI for ISPs and MSPs.
Sort your tickets before you automate anything
Start with an export of a few months of tickets from your PSA or help desk. Ignore the tool's AI features for now; the question is which work is worth handing off at all. Score each ticket category on three things:
- Volume. How much of the queue is it? High-volume categories are where time comes back.
- Repeatability. Does the fix follow the same steps nearly every time, or does it depend on judgment and investigation?
- Risk. What's the damage if it's done wrong? A wrong Wi-Fi tip costs a few minutes. A wrong account change can cost a customer, or a security incident.
You want high volume, high repeatability and low risk. Here's how the common categories usually score for ISPs and MSPs:
| Ticket type | Volume | Repeatable | Risk | Verdict |
|---|---|---|---|---|
| "Is there an outage?" | High during incidents | High | Low | Automate first |
| Password resets, lockouts, MFA re-enrollment | High | High | Medium | Automate, with strong identity checks |
| Wi-Fi and router basics | High | Medium to high | Low | Automate guided steps, escalate on hardware signs |
| New-user onboarding, offboarding | Medium | High | Medium | Automate the checklist; a person approves access |
| Billing questions | Medium | Medium | Medium | Answer from the bill; disputes go to a person |
| Printers and peripherals | Medium | Low | Low | Triage and route only |
| Firewall, routing or network changes | Low | Medium | High | Never automate the change |
| Security incidents | Low | Low | High | Never; page a person |
One honest warning: ticket categories in most PSAs are unreliable, because they were picked from a dropdown by a busy tech. Before you trust your own numbers, re-categorize a sample of historical tickets from their actual text. That's a good first job for AI on its own, and it often surprises people about what their queue really contains.
What to automate first
Outage and status questions
When something is down, the queue floods with the same question. Connect your monitoring or status source so the phone agent, chat and email replies all know what's actually down, who's affected and when the next update is due. Link duplicate tickets to the parent incident instead of letting them pile up as separate work. This is low risk, high volume and immediately visible to your team, which makes it the best first win in most ISP queues.
Password resets and locked-out accounts
High volume and very repeatable, but only safe with real identity verification: an MFA prompt, a code to a phone or email already on file, or a callback to the number on the account. Knowledge-based questions alone ("what's your street address?") aren't enough. Social engineering attacks target exactly this workflow. Log every reset with how the caller was verified.
Wi-Fi and router basics
Guided troubleshooting works well when it can see the device. For ISPs, that usually means reading status from your device management or Wi-Fi controller. For MSPs, it means your RMM. The steps (restart, check lights, change channel, forget and rejoin the network) are scripted. The important part is knowing when to stop: specific light patterns or repeated failures point to hardware, and that ticket should go to a person with everything the AI already tried.
Onboarding and offboarding steps
For MSPs especially, a new hire or an exit is a predictable checklist of accounts, licenses, groups, mailboxes and devices. AI can turn the request into that checklist, run the low-risk steps your tools allow, and hold anything that grants access, removes data or costs money until a person approves it. Offboarding deserves extra care: a missed step there is a security problem, not just an inconvenience.
What never to automate
- Security incidents: a clicked phishing link, a suspected compromise, anything that smells like ransomware. Page a person immediately.
- Changes to firewalls, routing or network configuration. AI can draft the change for review; it shouldn't make it.
- Credits, refunds and anything else that's a decision about money.
- Changes of account ownership or authorized contacts.
- Any ticket where the customer has asked for a person.
- Your most critical customers, until the workflow has a long track record.
Escalation is a feature, not a failure
A good AI tier-1 setup escalates a lot, especially at first. What matters is the quality of the handoff. A useful escalation tells the tech, at a glance, what the customer said in their own words, what's already been tried, the relevant account and device details, and how the customer is feeling. A bad one says "customer needs help" and forces the tech to start from scratch, which is slower than if the AI had never been involved.
Write the handoff format down and make it the same every time. Your techs will tell you within a week whether it's useful, and you should ask them.
How to measure whether it's working
Measure your current baseline before you switch anything on. Then compare like with like: the categories the AI handles against how those same categories were handled before.
| Metric | What it tells you | Watch out for |
|---|---|---|
| First-contact resolution | Whether AI-handled tickets actually end with the problem fixed | Tickets closed because the customer stopped replying |
| Reopen rate | Whether "resolved" really meant resolved | A rising reopen rate is the earliest sign of confident wrong answers |
| Escalation quality | Whether handoffs save techs time | Have techs rate a sample of handoffs as usable or not |
| Time to first response | How fast customers hear something useful | A fast but useless reply isn't a win |
| Satisfaction on AI-handled tickets | How customers feel about the experience | Compare with human-handled tickets of the same type, not the whole queue |
| Recontact | Whether customers came back by another channel | The email that "resolved" a ticket, followed by an angry phone call |
Be wary of deflection as a headline number. A ticket that disappears because the customer gave up isn't a success. It's churn you haven't seen yet.
Knowledge base hygiene comes first
AI answers from your documentation. If your knowledge base has three conflicting articles about the same router, or an article written for a modem you stopped deploying, the AI will repeat it with total confidence. Before you automate a category:
- Make sure there's exactly one current article for it, and delete or merge the duplicates.
- Write it for the customer, not for a tech. Plain steps, no internal shorthand.
- Put the escalation rule in the article itself: "if the light is red after a restart, stop and send to a tech."
- Give each article an owner and a last-checked date, and review them when equipment or plans change.
This is unglamorous work, and it's the difference between AI that helps and AI that generates reopened tickets.
Your first 30 days
| Week | Do | Done when |
|---|---|---|
| Week 1 | Export tickets, re-categorize a sample, score by volume, repeatability and risk, record your baseline metrics | You've picked one category to start with |
| Week 2 | Fix the knowledge base for that category, write escalation rules and the handoff format, connect read-only to your PSA | A tech agrees the article and rules are right |
| Week 3 | Run the AI in suggest mode: it drafts replies and actions, techs approve or edit every one | Techs are approving most drafts without edits |
| Week 4 | Let it resolve the safest subset on its own, keep sampling, compare against the week 1 baseline | The metrics hold, or you know exactly why they don't |
Then pick the next category and repeat. Going one category at a time feels slow, and it's how you avoid the incident where the bot told every customer in a town to factory-reset their router.
A word on tools
Most PSAs and help desk platforms now ship AI features, and some of them are perfectly good. The tool matters less than the design around it: which tickets it's allowed to touch, how callers are verified, what the handoff looks like and how you measure it. The same approach works for any support desk, not just service providers. See AI for your help desk for how we apply it more broadly.
If you'd like a second opinion on which category to start with, bring a ticket export to a free 30-minute call.