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.

The first thing we do with those numbers is sort by monitor type rather than by volume, because the two orders disagree and only one of them is useful. The noisiest monitor is usually device-offline, which is also the one you least want to touch, since it is the monitor that catches real outages. The monitor worth killing first is normally further down: a disk-space or backup-warning check on a threshold nobody has revisited since it was set.

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. Every mainstream RMM does some version of this natively and it is usually configured badly or not at all, so start there before writing a line of anything.

Where it is configured matters more than people expect, because there are two places it can live and they do not know about each other. The RMM decides whether to raise an alert (a monitor set in ConnectWise Automate, a monitor and response policy in Datto RMM, a condition in NinjaOne), and the integration into the PSA decides whether that alert becomes a ticket. Configure suppression on only one side and you get the classic result: the RMM correctly groups forty alerts into one, and the PSA opens forty tickets anyway because the integration fires per alert. Check both before concluding the dedup does not work.

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 or wrong. The tooling to collect it usually already exists and is usually half-deployed: network probes in Automate, network discovery in Datto RMM, and the Configurations records in ConnectWise Manage that are supposed to hold the result. What you typically find is a probe deployed at one site out of nine, and Configurations last touched during onboarding.

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 has not 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 is the category that should never have raised anything in the first place. In the instances we have seen, this is consistently the largest single bucket, and it is the cheapest to remove, which is a good combination for the first week of a project.

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 is usually a checkbox rather than a build.

Worth separating the two things that flap, because they need different thresholds. An agent heartbeat missing once is almost always a blip and should need three or four consecutive misses to matter. An SNMP trap is a fire-and-forget event with no state behind it, so "consecutive checks" is meaningless for it and you need a time-window count instead. Applying one rule to both is why device-offline noise survives the first pass at this.

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 $200 an hour and it's published, so the bands are just hours. A baseline measurement plus dedupe and suppression configuration usually lands in Starter, $1,200 to $2,400 over one to two weeks, or low Workflow, $3,200 to $8,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: $8,000 to $18,000 across four to eight weeks. The $2,500 minimum applies to custom scoped work; packaged catalogue items start at $1,200.

Doing all of it across a multi-tenant estate, with per-client rules and the billing reconciliation piece attached, is Platform tier, $20,000 to $40,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.