A recent CIO.com column posed a question that should make every MSP owner and IT manager squirm: is your architecture preventing you from calculating AI value? The author's argument is simple and brutal — measuring AI spend is now technically solvable, but only for organizations whose architecture attaches spend to something ownable. In most enterprises, it doesn't. A token call has no owner. One API key carries a dozen workflows across five teams. Spend flows everywhere; attribution goes nowhere. Nobody can calculate value.
If that gives you déjà vu, it's because MSPs live this exact problem every day — just with operational data instead of AI tokens. Your alerts live in the monitoring tool. Tickets live in the helpdesk. Devices live in the RMM. Patch data lives somewhere else. Technician time lives in the PSA. And none of it attaches to anything.
Try answering these with a fragmented stack:
- What was our true mean-time-to-acknowledge for Client B last month?
- How many technician hours did Client A's environment actually consume — per device, per category?
- Which clients are unprofitable right now, not at year-end?
If your honest answer involves CSV exports, Excel VLOOKUPs, and an afternoon you don't have, your architecture is the problem. Not your people. Not your process. Your architecture.
The Problem in Depth: Five Tools, Zero Attribution
Walk through a Tuesday in a typical MSP NOC and count the handoffs.
2:03 AM — the alert fires into the void. Your RMM (NinjaOne, Datto RMM, N-able) catches a disk filling up on a client's file server and emails an alert. Nobody watches that inbox at 2 AM. The ticket doesn't exist yet.
8:47 AM — a user calls. The helpdesk (ConnectWise Manage, Autotask, HaloPSA) opens a ticket. Your SLA clock starts here. Your helpdesk SLA report will later show a 12-minute response time. The six hours and forty-four minutes the problem actually ran? That lives in the monitoring tool, in data the SLA report never touches. Your reports aren't lying, exactly. They're blind.
9:15 AM — the tech plays detective. Which server? The ticket says "file server down" — the user's words. The tech opens the RMM to find the device, opens the monitoring tool to check whether anything triggered, opens a remote session, and starts switching. Interruption research consistently puts refocus time after a context switch at 20+ minutes. Five tools per ticket, eight tickets a day — do the math on what a technician actually loses.
10:30 AM — the duplicate fire. PRTG also alerted on the same disk, because nobody ever deleted the old check when the RMM took over monitoring. A second tech starts investigating the same issue. Two people, one problem, double the noise — and alert fatigue teaches the team to tune everything out, including the one alert that will matter next month.
Month-end — the archaeology. To build the QBR deck: export patch compliance from the RMM, export ticket stats from the PSA, export uptime from the monitoring tool, then reconcile device names by hand because naming conventions drifted in 2021. Four to six hours per admin, and the patch numbers are stale before the deck is presented.
Quarter-end — the reckoning. The client paying $1,800/month turns out to have consumed 55 technician hours. You discover this at close, when it's a negotiation instead of a management decision. Time was logged in the PSA against generic categories, device counts live in the RMM, and nothing joins them.
Why does this happen? Not because MSPs are careless. The stack is assembled from point solutions bought years apart, from vendors whose business model depends on being a separate line item. The "integrations" between them are API sync jobs that break silently and get noticed only during reporting week. The PSA vendor acquired a monitoring product and bolted it on. The RMM ships a "helpdesk module" nobody adopts because the team already lives in ConnectWise. Every tool is individually decent. The architecture between them is where value goes to die.
And here's the AI twist: your clients are asking about AI, and you're probably piloting AI triage or a copilot in the helpdesk. Good luck calculating its ROI — same architectural problem, with the spend attaching to nothing you can trace to an outcome. Fragmented architecture doesn't just hide today's margins. It makes tomorrow's investments unmeasurable.
How AlertMonitor Closes the Attribution Gap
AlertMonitor was built multi-tenant from day one — not retrofitted — so attribution is native to the data model instead of bolted on with sync jobs.
One platform, one record. Infrastructure monitoring, RMM, integrated helpdesk, network topology mapping, and patch management share the same data model. When a disk threshold trips on Client A's file server at 2:03 AM, the alert is the ticket — carrying the device, the client, the site, topology context (what depends on that server), and the SLA tier automatically.
SLA clocks that start at detection, not ticket creation. Because detection and ticketing are the same system, there's no blind spot between the alert and the record. Per-client SLA thresholds are configurable — Gold clients get 15-minute acknowledgment, Bronze gets 4 hours — enforced by per-client alert routing rather than whoever happens to remember.
One NOC view across every client. The unified dashboard shows all clients simultaneously, with strict client-level isolation underneath. The 2 AM tech sees the alert, the client, the device health, and the patch state, then opens the remote session from the same console. No swivel chair. No hunting for which tool holds the device list.
Patch compliance as a live state, not a snapshot. Patch data lives in the same model, so per-client compliance percentages are always current. Zero exports, zero staleness — the QBR deck builds itself from live data.
Cost-to-serve that computes itself. Because tickets are linked to clients and devices, technician hours roll up automatically. You see Client A's real consumption monthly, not at year-end.
The before/after is stark. Before: alert emails into an inbox, manual ticket creation, five open tabs, manual time entry, month-end spreadsheet archaeology. After: alert-to-ticket in one system, one console to resolve, time attributed automatically, reports pulled in minutes. Teams consolidating onto a unified platform typically cut alert-to-acknowledgment from hours to minutes and reclaim several admin-hours per week from reporting alone.
Practical Steps You Can Take This Week
1. Measure your architecture tax. Pull last month's ten most time-consuming tickets. For each: what detected the issue, when, did detection link to the ticket, how many tools did the tech open? Count the handoffs. That number is the cost of your architecture, and it's usually embarrassing.
2. Fix naming so attribution is even possible. If alerts, tickets, devices, and costs are ever going to join, CLIENTA-SRV-FS01 beats SERVER2. Enforce client prefixes in device naming across every tool today.
3. Baseline the four numbers that matter. MTTA, MTTR, patch compliance per client, hours per client. If pulling any of them takes more than a few minutes, you've found a gap.
4. Put real numbers behind the disk alerts. A per-client capacity sweep you can run today:
# Disk capacity sweep across a client's servers - feeds capacity planning
$servers = Get-Content "C:\MSP\clientA_servers.txt"
Get-CimInstance -ComputerName $servers -ClassName Win32_LogicalDisk -Filter "DriveType=3" |
Select-Object @{n='Server';e={$_.PSComputerName}},
@{n='Drive';e={$_.DeviceID}},
@{n='FreeGB';e={[math]::Round($_.FreeSpace/1GB,1)}},
@{n='FreePct';e={[math]::Round(($_.FreeSpace/$_.Size)*100,1)}} |
Sort-Object FreePct |
Export-Csv "C:\MSP\ClientA_Disk_$(Get-Date -f yyyyMMdd).csv" -NoTypeInformation
5. Spot-check patch compliance per client — the number every client asks about at QBRs:
# Pending Windows updates on a remote server - patch compliance spot check
Install-Module PSWindowsUpdate -Force -Scope CurrentUser
Get-WindowsUpdate -ComputerName SRV-FS01 | Select-Object ComputerName, KB, Title, Size
6. Verify critical services in one pass instead of five tools:
# Flag any stopped critical service across a client's app servers
$services = @('W3SVC','MSSQLSERVER','Spooler')
$servers = @('SRV-WEB01','SRV-SQL01','SRV-PRINT01')
Invoke-Command -ComputerName $servers -ScriptBlock {
Get-Service -Name $using:services |
Where-Object Status -ne 'Running' |
Select-Object @{n='Server';e={$env:COMPUTERNAME}}, Name, Status
}
And for the Linux estates you manage:
# Flag any filesystem over 80% used
df -h -x tmpfs -x devtmpfs | awk 'NR==1 || $5+0 > 80 {print $1, $5, $6}'
7. Kill duplicate monitors. Pick one source of truth per metric. If your RMM and your network monitor both check disk, delete one. In AlertMonitor there's a single monitoring layer, so duplication can't creep in between products.
8. Set per-client SLA tiers and routing — once. Configure Gold/Silver/Bronze thresholds and per-client escalation routes in AlertMonitor. The SLA clock starts at detection, and the report writes itself.
9. Recalculate one client's true cost-to-serve after consolidation and compare it to what your spreadsheet said. Then decide how fast to migrate the rest.
The Bottom Line
The CIO.com author's point generalizes far beyond AI: architecture decides what you can measure — and what you can't measure, you can't manage or sell. If your stack can't attach an alert to a ticket to a device to a client to a cost, then client profitability, SLA truth, and AI ROI are all the same thing to you: guesswork. AlertMonitor's unified, multi-tenant architecture makes attribution native, so the numbers come out of the platform instead of out of your weekends.
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.