RMM-generated tickets meet resolution SLAs at 84.0%, far above the 55.0% for non-RMM tickets. But first response rates tell a different story. Generated by AI via Proxuma Power BI MCP server.
RMM-generated tickets meet resolution SLAs at 84.0%, far above the 55.0% for non-RMM tickets. But first response rates tell a different story. Generated by AI via Proxuma Power BI MCP server.
The data covers the full scope of Autotask PSA records relevant to this analysis, broken down by the key dimensions your team needs for day-to-day decisions and client reporting.
Who should use this: Service delivery managers, operations leads, and MSP owners tracking service quality
How often: Weekly for operational adjustments, monthly for client reporting, quarterly for contract reviews
RMM-generated tickets meet resolution SLAs at 84.0%, far above the 55.0% for non-RMM tickets. But first response rates tell a different story. Generated by AI via Proxuma Power BI MCP server.
EVALUATE ROW("RMMTickets", CALCULATE(COUNTROWS('BI_Autotask_Tickets'), 'BI_Autotask_Tickets'[source_name] = "Datto RMM"), "RMMAvgRes", CALCULATE(AVERAGE('BI_Autotask_Tickets'[resolution_duration_hours]), 'BI_Autotask_Tickets'[source_name] = "Datto RMM"), "RMMFRMet", CALCULATE(COUNTROWS('BI_Autotask_Tickets'), 'BI_Autotask_Tickets'[source_name] = "Datto RMM", 'BI_Autotask_Tickets'[first_response_met] + 0 = 1), "RMMResMet", CALCULATE(COUNTROWS('BI_Autotask_Tickets'), 'BI_Autotask_Tickets'[source_name] = "Datto RMM", 'BI_Autotask_Tickets'[resolution_met] + 0 = 1))Alert tickets (RMM) vs all other ticket types, compared on first response and resolution SLA rates
| Metric | RMM (Alert) | Non-RMM | Difference | Verdict |
|---|---|---|---|---|
| Total tickets | 19,790 | 47,731 | — | 29.3% of total |
| First response met | 45.4% | 56.0% | −10.6pp | RMM trails |
| Resolution met | 84.0% | 55.0% | +29.0pp | RMM leads |
| Avg resolution hours | 0.581h | — | — | 35 min avg |
EVALUATE
ROW(
"RMM_Tickets", CALCULATE(COUNTROWS(BI_Autotask_Tickets), BI_Autotask_Tickets[ticket_type_name] = "Alert"),
"RMM_FR_Met", CALCULATE(COUNTROWS(FILTER(BI_Autotask_Tickets, [first_response_met] + 0 = 1)), BI_Autotask_Tickets[ticket_type_name] = "Alert"),
"RMM_Res_Met", CALCULATE(COUNTROWS(FILTER(BI_Autotask_Tickets, [resolution_met] + 0 = 1)), BI_Autotask_Tickets[ticket_type_name] = "Alert"),
"Non_RMM_Tickets", CALCULATE(COUNTROWS(BI_Autotask_Tickets), BI_Autotask_Tickets[ticket_type_name] <> "Alert"),
"Non_RMM_FR_Met", CALCULATE(COUNTROWS(FILTER(BI_Autotask_Tickets, [first_response_met] + 0 = 1)), BI_Autotask_Tickets[ticket_type_name] <> "Alert"),
"Non_RMM_Res_Met", CALCULATE(COUNTROWS(FILTER(BI_Autotask_Tickets, [resolution_met] + 0 = 1)), BI_Autotask_Tickets[ticket_type_name] <> "Alert")
)The Monitoring queue is where most RMM-generated tickets land. Here is how that queue performs on SLAs compared to the RMM ticket type overall.
| Segment | Tickets | FR Met | Res Met | Avg Hours |
|---|---|---|---|---|
| Monitoring Queue | 17,082 | 34.0% | 74.8% | 0.833 |
| RMM Alert (all queues) | 19,790 | 45.4% | 84.0% | 0.581 |
| Monitoring/RMM Source | 13,379 | 38.9% | 95.3% | 0.507 |
| Global Average | 67,521 | 52.9% | 63.5% | — |
EVALUATE
ROW(
"MonitoringQueue_Tickets", CALCULATE(COUNTROWS(BI_Autotask_Tickets), BI_Autotask_Tickets[queue_name] = "Monitoring"),
"MonitoringQueue_FR_Pct", DIVIDE(
CALCULATE(COUNTROWS(FILTER(BI_Autotask_Tickets, [first_response_met] + 0 = 1)), BI_Autotask_Tickets[queue_name] = "Monitoring"),
CALCULATE(COUNTROWS(BI_Autotask_Tickets), BI_Autotask_Tickets[queue_name] = "Monitoring")),
"MonitoringQueue_Res_Pct", DIVIDE(
CALCULATE(COUNTROWS(FILTER(BI_Autotask_Tickets, [resolution_met] + 0 = 1)), BI_Autotask_Tickets[queue_name] = "Monitoring"),
CALCULATE(COUNTROWS(BI_Autotask_Tickets), BI_Autotask_Tickets[queue_name] = "Monitoring")),
"MonitoringQueue_Avg_Hours", CALCULATE(AVERAGE(BI_Autotask_Tickets[resolution_duration_hours]), BI_Autotask_Tickets[queue_name] = "Monitoring")
)RMM tickets are structurally different from manually created tickets, which explains the SLA split
First response is low because no human triggers the ticket. When a user emails or calls, a technician picks it up and the first response is immediate. RMM alerts land in the Monitoring queue automatically. The SLA clock starts at creation, but a tech may not see it for minutes or hours depending on queue volume and dispatch rules. The 45.4% first response rate reflects that delay.
Resolution is high because RMM tickets are often simple and predictable. Many RMM alerts follow known patterns: disk space, service restart, offline device. Technicians resolve them quickly because the root cause is already identified by the monitoring tool. The average resolution time of 0.581 hours (about 35 minutes) confirms this. Compare that to the global resolution SLA rate of 63.5%, and RMM tickets are outperforming the rest of the service desk by a wide margin.
The Monitoring queue has a first response rate of just 34.0%. That is 11 points below the RMM ticket type average of 45.4%, which means some RMM tickets that land outside the Monitoring queue (in other queues via dispatch rules) actually perform better on first response. Focusing SLA improvement efforts on the Monitoring queue specifically would have the most impact.
Tickets tagged with the Monitoring/RMM source represent the subset that came directly through the RMM integration
| Metric | Value | Context |
|---|---|---|
| Tickets from Monitoring/RMM source | 13,379 | 19.8% of total volume |
| Avg resolution hours | 0.507 | 30 minutes on average |
| First response met | 5,204 | 38.9% |
| Resolution met | 12,745 | 95.3% |
| Total resolution hours | 1,021 | For Alert ticket type overall |
EVALUATE
ADDCOLUMNS(
FILTER(
SUMMARIZE(BI_Autotask_Tickets, BI_Autotask_Tickets[ticket_source_name]),
BI_Autotask_Tickets[ticket_source_name] = "Monitoring/RMM"
),
"TicketCount", CALCULATE(COUNTROWS(BI_Autotask_Tickets)),
"AvgHours", CALCULATE(AVERAGE(BI_Autotask_Tickets[resolution_duration_hours])),
"FR_Met", CALCULATE(COUNTROWS(FILTER(BI_Autotask_Tickets, [first_response_met] + 0 = 1))),
"Res_Met", CALCULATE(COUNTROWS(FILTER(BI_Autotask_Tickets, [resolution_met] + 0 = 1)))
)The headline number is clear: 84.0% resolution SLA met for RMM tickets, versus 55.0% for everything else. That is a 29 percentage point gap in favor of RMM. These tickets are fast to close because the monitoring tool has already identified the issue. A disk space alert does not require investigation; the technician knows what to do before opening the ticket.
The first response rate of 45.4% is a different story. It is 10.6 points below the non-RMM average of 56.0%, and the Monitoring queue itself drops even lower to 34.0%. The reason is mechanical: RMM creates the ticket the moment the threshold triggers. Nobody is waiting on the phone. Nobody expects an immediate reply. The SLA clock starts at a moment when no human is involved on either side.
This does not mean the first response SLA should be ignored. It means it should be configured differently. If your SLA policy applies the same first response target to auto-generated tickets as to user-submitted tickets, you are measuring the wrong thing. A 15-minute first response SLA on an automated disk space alert penalizes your team for not responding to something that did not need an immediate response in the first place.
The Monitoring/RMM source data (13,379 tickets) shows an even more extreme version of this pattern. These tickets resolve in 0.507 hours on average (about 30 minutes) with a 95.3% resolution rate, but first response is just 38.9%. The resolution side is excellent. The first response side is a policy problem, not a performance problem.
One practical improvement: set auto-acknowledgment rules for RMM tickets in your PSA. If an alert ticket is created by the RMM integration, auto-send an internal first response so the SLA clock records a hit. This does not game the metric. It reflects reality: the system received the alert, it was logged, and it is being processed. The meaningful SLA for these tickets is resolution time, not first response.
4 priorities based on the findings above
Configure your PSA to automatically send an internal first response when an Alert-type ticket is created via the RMM integration. This stops the first response SLA from failing on tickets where no human interaction is expected at creation. Your team already resolves 84.0% of these within the resolution window. The first response failure is a policy gap, not a service gap. Auto-acknowledgment aligns the metric with reality.
A user who emails the help desk and a disk space alert from the RMM tool should not share the same first response target. Consider a dedicated SLA profile for Alert ticket types with a longer first response window (e.g. 60 minutes instead of 15) and a tighter resolution window (e.g. 4 hours instead of 8). This better reflects the nature of automated tickets and gives your team credit for the work they already do well.
The Monitoring queue is 11 points below the RMM ticket type average on first response. That means tickets dispatched to other queues do better. Check your dispatch rules for the Monitoring queue: is it understaffed during off-hours? Are alerts piling up without round-robin assignment? A small change to routing could bring this number up significantly.
An 84.0% resolution SLA rate on almost 20,000 auto-generated tickets is a strong proof point. Your RMM catches problems before users notice them, and your team resolves them fast. Present this alongside the 0.581h average resolution time in client QBRs. It demonstrates that your monitoring investment is paying off and your service desk handles automated work efficiently. Clients rarely see the work that goes into silent problem resolution. This report makes it visible.
RMM tickets are auto-created by monitoring tools without any human involvement at the point of creation. The SLA clock starts immediately, but a technician may not see the ticket until their next queue check. With user-submitted tickets, the first response often happens during the initial interaction (phone call, email reply), so the clock barely ticks. The lower first response rate for RMM is a structural difference, not a performance failure.
RMM alerts typically follow predictable patterns. Disk space warnings, service failures, and device offline events have known remediation steps. Technicians can resolve them quickly without extensive troubleshooting. Many are also auto-resolved by scripts or runbooks triggered by the RMM tool itself. The combination of known root cause and scripted fix drives the 84.0% resolution rate.
The Alert ticket type (19,790 tickets) captures all tickets classified as alerts in Autotask, regardless of how they were created. The Monitoring/RMM source (13,379 tickets) is a narrower filter that only includes tickets where the ticket source field is explicitly set to the RMM integration. Some alert tickets may come from other sources, and some RMM-sourced tickets may be classified as different ticket types. This report uses ticket_type_name = "Alert" as the primary filter for RMM SLA analysis.
Yes, for most MSPs this is the right move. Auto-acknowledgment records a first response at the moment of ticket creation, which means the first response SLA is met by default. This is not gaming the metric. It reflects that the system received and logged the alert. The SLA that actually matters for RMM tickets is resolution time, and your team already meets that at 84.0%. Check with your PSA vendor documentation for how to configure workflow rules that auto-respond on Alert ticket types.
Yes. Connect Proxuma Power BI to your Autotask PSA and RMM tool, add an AI assistant (Claude, ChatGPT, or Copilot) via MCP, and ask the same question. The AI writes the DAX queries, runs them against your real data, and produces a report like this in under fifteen minutes. The DAX queries in this report are ready to copy and execute.
Connect Proxuma Power BI to your PSA, RMM, and M365 environment, use an MCP-compatible AI to ask questions, and generate custom reports - in minutes, not days.
See more reports Get started