A Government Case Study in Paying Twice for the Wrong Stack
The Register reported in October 2026 that the UK Cabinet Office took a £7.8 million hit to decommission its own recruitment system — killed not because it stopped working, but because it never aligned with the department's Shared Services Strategy. Add the separate £8.9 million fine over IR35 compliance failures, and you get a rare, public, line-item view of what it costs when your technology doesn't match your operating model: you pay to run it, you pay when it causes failures, and then you pay a third time to make it go away.
Most MSPs and internal IT teams will never see a number that large on a single system. But the pattern is identical at small scale, and it shows up in your P&L every month: five tools doing four jobs, integration duct tape holding the workflow together, SLA reports that don't survive contact with reality, and technicians who spend their day alt-tabbing instead of fixing things.
The Problem in Depth: Your Tool Stack Is the Recruitment System Nobody Wants to Kill
Think about the stack at a typical 10-tech MSP right now:
- A PSA — ConnectWise Manage or Autotask — as the system of record
- An RMM — NinjaOne, Datto RMM, N-able — for endpoint management and patching
- Standalone monitoring — PRTG, SolarWinds, or a pile of Zabbix instances — because the RMM's monitoring wasn't granular enough for the network
- A separate helpdesk — Freshdesk, Zendesk, or the PSA's half-adopted service desk module
- A documentation tool — IT Glue or Hudu — because passwords have to live somewhere, right?
Each tool was purchased at a different time, for a different client demand, by a different person who has since left. None of them share a data model. And that is exactly where the workflow breaks.
Where the Workflow Actually Breaks
Follow one incident through this stack. A file server at your largest client starts filling up at 9:00 AM. PRTG catches it at 90% and emails a shared inbox that nobody has filtered since 2022. The PSA automation rule that was supposed to convert monitoring emails into tickets creates one — with no severity, no client SLA policy attached, and no correlation to the three other alerts firing from the same host. A technician eventually sees it at 10:45 AM, after two users have already called the service desk and the receptionist has walked over to someone's desk.
Now the technician needs context. That means the monitoring tool (what exactly is alerting?), the RMM (can I remote in?), the documentation tool (whose server is this, what's the runbook?), and the PSA (open the ticket, start the clock — which started when the user called, by the way, not when your monitoring detected the problem).
That last point is the killer. At the monthly service review, your SLA report says you responded in 40 minutes. Your monitoring data says you detected the issue in under five. Both numbers are true. Neither system can see the other. Your client hears "40 minutes." Your techs know it was really a detection-to-response failure buried in an inbox. Morale takes the hit; the tooling gets a pass.
Why These Gaps Exist
These are not lazy teams. The gaps exist because of structural choices:
- Siloed architecture. Every tool owns its own datastore, its own concept of a "device," "ticket," and "client." Integrations map fields between them — badly, and only for the fields someone thought to map in 2021.
- Legacy tooling accreted over years. Like the Cabinet Office's recruitment system, each platform made sense when it was bought. The strategy changed; the tools did not.
- Per-seat licensing that punishes consolidation. When every tool bills per technician or per endpoint, removing one requires a migration project nobody has time to run.
- Swivel-chair operations. The "integration" between tools is a human copying a device name from one window into another.
The measurable cost: UC Irvine's research on context switching puts refocus time after an interruption at over 20 minutes. Multiply that across a tech touching five tools, thirty times a day. Add onboarding: a new hire needs weeks to learn five UIs and your team's undocumented bridges between them. Add the monthly licensing line — easily £150–£300 per technician across the full stack.
And then there is the Cabinet Office's real lesson: sunk cost. "We've already paid through next year." "Migration is too risky right now." Deferred consolidation does not avoid the write-off. It just means you pay the full cost later, with interest, in downtime, churn, and burned-out techs.
The IR35 fine has a parallel too: compliance failures born of records scattered across systems. Your version is the client audit where you cannot produce one coherent patch report — because patch data lives in the RMM, ticket history in the PSA, and the monitoring system disagrees with both. Three tools, three versions of the truth.
How AlertMonitor Eliminates the Swivel Chair
AlertMonitor was built multi-tenant from day one, because this is precisely the problem it exists to solve.
One platform, one data model. Infrastructure monitoring, RMM, helpdesk, network topology mapping, patch management, and intelligent alerting share the same device inventory, the same client hierarchy, and the same timeline. An alert is not an email that might eventually become a ticket — it is a ticket, created with the right client, severity, and SLA policy attached at the moment of detection.
Multi-tenancy that MSPs actually need. Isolated client dashboards, per-client alert routing (your night-shift NOC gets the Tier-1 client's pages; email summaries cover the quieter clients), and customizable SLA thresholds per client — not one global threshold that is wrong for everyone. The unified NOC view shows all clients simultaneously, so a tech on a 2 AM shift sees one screen instead of twelve tabs across five tools.
The workflow difference is concrete. Before: PRTG email → shared inbox → manual ticket in the PSA → tab over to the RMM for remote access → tab to IT Glue for the runbook → copy-paste → resolve → write up the ticket from memory. Roughly six manual hops and 30–45 minutes of context gathering per incident.
After: the disk alert fires at 90% → AlertMonitor creates the ticket with the client's SLA policy already attached → the technician opens the alert and sees device health, patch status, and the network topology map in the same pane → one click into an integrated remote session → resolve → the timeline, actions, and resolution are auto-documented on the ticket. The SLA clock started at detection, because detection and ticketing are the same system.
Reporting finally matches reality. Because the SLA clock, the alert, and the resolution live in one system, the monthly service review shows detection-to-response in minutes — the number your clients actually care about — instead of a phone-call-started figure that understates your team. Patch compliance rolls up per client from the same inventory, with no CSV stitching between tools.
The economics. Replace four or five per-seat licenses with one platform. Onboard a new technician in days — one UI, one alert language, consistent runbooks. Technicians spend less time switching screens and more time actually fixing things, which is the only metric that compounds.
Practical Steps You Can Take This Week
1. Audit your stack honestly. One spreadsheet: tool, annual cost, which techs actually log in weekly, which reports it feeds. Most MSPs find one or two tools that exist only because cancelling feels risky.
2. Map your alert-to-ticket path. Count the manual hops from monitoring detection to a ticket with full context. If the number is above two, you are paying for integration with technician time — the most expensive integration available.
3. Script the checks your team still does by hand. Here are three that every MSP tech runs manually today. Inside AlertMonitor these become scheduled checks feeding the same unified timeline — but start by automating them wherever you are:
Last installed patch per server — the evidence behind every client patch report:
$servers = Get-Content .\clientA-servers.txt
$report = foreach ($srv in $servers) {
try {
$last = Invoke-Command -ComputerName $srv -ErrorAction Stop -ScriptBlock {
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 1
}
[PSCustomObject]@{
Server = $srv
LastKB = $last.HotFixID
Installed = $last.InstalledOn
AgeDays = (New-TimeSpan -Start $last.InstalledOn -End (Get-Date)).Days
}
} catch {
[PSCustomObject]@{ Server = $srv; LastKB = 'UNREACHABLE'; Installed = $null; AgeDays = $null }
}
}
$report | Sort-Object AgeDays -Descending | Export-Csv .\clientA-patch-compliance.csv -NoTypeInformation
Disk usage across a client's estate — the check that catches the 9:00 AM file server incident before the users do:
$servers = Get-Content .\clientA-servers.txt
Invoke-Command -ComputerName $servers -ScriptBlock {
Get-CimInstance Win32_LogicalDisk -Filter 'DriveType=3' |
Select-Object @{n='Server';e={$env:COMPUTERNAME}},
DeviceID,
@{n='UsedPct';e={[math]::Round(($_.Size - $_.FreeSpace) / $_.Size * 100, 1)}},
@{n='FreeGB';e={[math]::Round($_.FreeSpace / 1GB, 1)}}
} | Where-Object { $_.UsedPct -ge 85 } |
Sort-Object UsedPct -Descending |
Format-Table Server, DeviceID, UsedPct, FreeGB -AutoSize
A quick service guard for Linux hosts you have not fully onboarded yet:
# Restart a critical service if it is not running, and log the action
systemctl is-active --quiet nginx || { systemctl restart nginx && logger 'nginx was down - restarted by health check'; }
4. Consolidate deliberately, not eventually. Pick the client with the most fragmented history. Migrate their monitoring, ticketing, and patching into one platform first. Measure detection-to-response before and after. That number — not the licensing invoice — is what you take to the rest of your client base and to your own leadership.
The Lesson the Cabinet Office Paid £7.8M to Teach
Systems that do not match your operating model do not get cheaper to keep. They get more expensive every quarter you defer the decision — in licensing, in technician hours, in SLA misses, and eventually in one very painful write-off. The difference between a £7.8 million government write-off and a smooth consolidation is simply timing. The Cabinet Office waited until the misalignment was undeniable.
You do not have to. One multi-tenant platform — monitoring, RMM, helpdesk, patching, and alerting that already speak the same language — turns that future write-off into a decision you make on your own schedule, with numbers that prove it worked.
Related Resources
AlertMonitor MSP Operations & Team Efficiency AlertMonitor Platform Overview Book a Demo MSP Operations & Team Efficiency Resources
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.