MSP Automation Starts With Alert Noise, Not Ticket Routing

Ask an MSP owner what to automate first and the answer is almost always ticket routing. It's the wrong first move, and the reason is arithmetic rather than philosophy.

Routing gets tickets to the right engineer faster. Good. But if a large share of the queue shouldn't be tickets at all, you've just built an efficient system for delivering noise to the correct person. The engineer still has to look at every row to decide it doesn't matter, which is the expensive part, and now it arrives sorted.

Alert volume is the thing making every other number in the business untrustworthy. Fix that first.

Your queue metrics are describing a process nobody follows

Time to first response. SLA attainment. Tickets per engineer per day. Utilization. Every one of those is computed over the queue, and the queue is whatever the RMM decided to put in it.

So when a chunk of that queue is machine-generated rows that get bulk-closed on a Monday morning:

• Time to first response includes tickets nobody ever intended to respond to. Closing forty disk-space alerts in one click does wonders for the average.
• SLA attainment is a blend of real client commitments and monitoring chatter that inherited an SLA policy by accident.
• Utilization counts triage as work. It is work. It's work that shouldn't exist.
• Tickets per engineer is a productivity metric whose denominator is controlled by your monitoring thresholds, not by anyone's effort.

The tell is that your engineers already know all this. Ask how the queue is doing and they'll answer by telling you which alerts they've learned to ignore. That's a team quietly informing you the dashboard is fiction, and it holds until the alert that mattered arrives looking exactly like the ones that didn't.

You cannot manage a service desk on numbers computed over a queue that's mostly noise. That's the case for doing alert reduction first, and it doesn't depend on how much time the automation saves.

Step one: baseline the alert-to-ticket ratio

Before you build anything, count. Pull four weeks from the RMM and four weeks from the PSA and get four numbers:

1. Total alerts raised, broken out by monitor type and by client
2. How many became tickets
3. How many of those tickets required a human to change something on a device or speak to a client
4. How many closed with no action, no notes, or a note along the lines of "cleared on its own"

Out of that come two ratios worth putting on a wall. Alerts per actionable ticket tells you how badly monitoring is over-firing. Actionable tickets as a share of all tickets tells you how badly the queue is lying to your reporting.

Get this per monitor definition, not as one company-wide number. The single number tells you there's a problem you already suspected. The per-monitor breakdown tells you which four things to fix, and the noise is nearly always concentrated: disk thresholds still sitting at a default nobody revisited, backup jobs raising a warning because one locked file got skipped, agent check-in failures for every laptop whose lid closed on a train.

If your PSA can't tell you which tickets were actionable, that's fixable in an afternoon. Add a required close code with four options: Fixed, No action needed, Duplicate of another ticket, Client-side change. Then wait a month. One month of honest close codes settles an argument that otherwise runs for a year.

Do this part yourself. It costs nothing, it needs no consultant, and it determines the entire scope of whatever comes next. It also occasionally shows that your ratio is already fine and routing genuinely is your problem, in which case skip ahead and I'll happily have been wrong about the order.

Step two: deduplicate and correlate

Deduplication is the easy half. Same device, same monitor, inside a time window, one ticket. Everything after the first attaches to it as an event rather than opening a sibling. Most RMMs do some version of this natively and it's usually configured badly or not at all, so start there before writing a line of anything.

Correlation is the half that matters. One underlying fault routinely produces alerts across unrelated monitors on unrelated devices:

• A switch drops and forty devices behind it fail their checks
• A hypervisor host reboots and every guest on it alerts independently
• An ISP link flaps and every site behind that circuit looks dead for ninety seconds
• A UPS goes to battery and the entire rack complains at once

These arrive as separate rows. A human takes minutes to spot that they're one event, and those minutes happen during the exact window when the client is calling.

Three correlation rules cover most real-world cases. Topology: if a parent device is unreachable, suppress the children and raise a single ticket against the parent. Time window plus client: alerts from one client inside a few minutes group into a candidate incident, which is coarse but catches site-wide outages reliably. Signature grouping: the same alert text appearing across many devices at once is one pattern, usually a bad patch, an expired certificate, or a DNS change.

Be honest about where this stalls. Topology correlation needs to know parent-child relationships, and in most MSPs that data is either missing from the CMDB or wrong. The fix is a week of documenting device dependencies, not a smarter rule engine, and that week is the actual project. Anyone who sells you correlation without mentioning it hasn't done one.

The rule we hold to: one underlying fault should raise one actionable ticket, not forty rows, and all forty should still be visible inside that one ticket. Suppressing evidence isn't deduplication, it's just a different way to lose information.

Step three: suppression and maintenance windows

Then there's the category that should never have raised anything in the first place.

Scheduled maintenance. If you patch Sunday at 2am and Sunday at 2am produces a wall of alerts every single week, that isn't monitoring, it's a calendar. Maintenance windows should be driven off the same schedule that drives the patching, not maintained by hand in a second system where they drift.

Known and accepted conditions. The client's ancient line-of-business server that sits at 92% disk on purpose and always will. Suppress it, but suppress it with an owner and an expiry date. A permanent suppression is how you discover eighteen months later that nobody was watching a box that has since filled up.

Flapping. Require a condition to persist across several consecutive checks before it raises anything. This one rule removes a large amount of link-state and agent check-in noise on its own, and it's usually a checkbox.

Business hours. Some alerts genuinely aren't worth waking anyone for. Deciding that explicitly, per monitor and per contract, beats the current arrangement, which is an on-call engineer making the same call at 3am on instinct and being right most of the time.

Every suppression rule needs an owner and a review date, and the review should open a ticket rather than sit as a recurring calendar invite that gets declined for six months. Suppression without expiry is how monitoring quietly switches itself off.

Step four: now build classification and routing

Once the queue is mostly real work, routing is worth the money, and it works better than it would have, because you're no longer training rules and thresholds against a stream where most of the volume is junk.

Routing should decide four things: which client and contract tier this belongs to, which skill it needs, whether it's contract-covered or billable, and which SLA clock applies. Keyword rules handle that fine until the category list grows past a handful, at which point they start misfiring in ways nobody notices because nobody audits routing rules. A model reading the ticket body alongside device and client context does better, provided you give it a confidence threshold and a human triage queue for everything it isn't sure about. An automation that guesses confidently is worse than one that asks.

Build SLA escalation the same way. A clock that reports a breach afterwards is reporting, not managing. A ticket that crosses some fraction of its response window, say three quarters, should raise its own flag while there's still time to do something about it.

The money problem that never makes it onto the roadmap

Here's the second-order issue, and for a lot of MSPs it's worth more than every hour the alert work saves.

An engineer takes a call, solves something in eleven minutes, and never opens a ticket. Or opens one, resolves it, and never logs time against it. Or logs the time and marks it contract-covered, because that's the default and deciding otherwise would mean reading the agreement.

None of that appears as a loss anywhere. There's no report for work you did and didn't bill, because the record of the work doesn't exist. Measuring the leak is itself manual, so it doesn't get measured, so it doesn't get fixed, and every year somebody estimates it in a meeting and everyone agrees the estimate feels low.

Automation gets at it from a few angles:

• Build the ticket from an artifact that already exists. The phone system logged the call. The remote-control tool logged the session. Teams logged the message. A remote session against a client device with no ticket in the same window is a flag, and reconciling those two lists weekly surfaces the gap without asking a single engineer to change a habit.
• Nudge at resolution, not at month-end. A ticket closed with zero time entries prompts the engineer in Slack or Teams the same afternoon, while they still remember what they did.
• Make contract-covered versus billable a decision the automation defends. Derive a default from the contract terms and the ticket category, and make the engineer override it rather than choose it from scratch. Defaults decide outcomes.
• Report contracted hours against logged hours, per client, monthly. Overage discovered in month eleven of a twelve-month agreement is a renegotiation you've already lost.

That last one is usually the strongest business case in the whole project, because it produces revenue instead of saving time, and revenue arguments survive budget meetings that efficiency arguments don't.

Most MSPs already automate. That was never the gap.

This is not a market that needs persuading about automation. There are PowerShell scripts, RMM policies, scheduled tasks, PSA workflow rules, a Power Automate flow somebody built during lockdown. The work exists.

The gap is durability, and it has a very specific shape: a script that runs from a scheduled task on one person's workstation, under that person's stored credential. It works perfectly. Then they change roles, or IT rebuilds the laptop, or the credential rotates on schedule. Nothing errors, because nothing runs. Weeks pass before anyone notices, and they notice through a downstream symptom rather than an alert.

Same failure, different costumes:

• Automation owned by a personal account, a personal API token, or a mailbox rule
• No source control, so nobody can say what the current version does or when it changed
• Error handling that consists of a try/catch writing to a log file no human has opened
• No idempotency, so re-running after a failure creates duplicates and the team learns never to re-run it, which means failures just stay failed

Durable means something different. It runs somewhere whose name isn't a person's name. Its code is in version control. It retries transient failures and can't double-write when it does. It reports success as well as failure, so silence becomes a signal instead of an assumption. That standard is the one we ship every build against, and it's written out on the reliability page.

For MSPs there's one more piece: you're holding other people's client data, and your automation platform ends up holding it too. We self-host n8n inside the client's own infrastructure precisely so execution data (ticket bodies, user lists, device inventories) never lands on a vendor's servers, ours included.

What this costs

Our rate is $150 an hour and it's published, so the bands are just hours. A baseline measurement plus dedupe and suppression configuration usually lands in Starter, $900 to $1,800 over one to two weeks, or low Workflow, $2,400 to $6,000 over two to four, depending on how many monitor definitions are in scope and how bad the CMDB is. Correlation across RMM and PSA with topology awareness, then classification, routing, and SLA escalation on top, is Orchestration work: $6,000 to $13,500 across four to eight weeks. Project minimum is $2,500.

Doing all of it across a multi-tenant estate, with per-client rules and the billing reconciliation piece attached, is Platform tier, $15,000 to $30,000 over eight to twelve weeks. Very few MSPs should start there. Start with the count.

Where to start

The measurement is the part you can begin on Monday without hiring anyone. Four weeks of alerts, four weeks of tickets, a ratio per monitor definition, and you'll know inside an afternoon whether your problem is the queue or the routing. Almost everyone who runs it is surprised by which handful of monitors is generating the bulk of the volume.

If it turns out to be the queue, the IT and security automation catalogue lists the specific builds with prices attached, and the MSP use case page covers the other places margin tends to leak in this business. If you're not yet sure the problem is big enough to justify a build, 10 signs your ops team needs automation is the cheaper read first.