Are you meeting your SLA targets? Where are the gaps, and which priorities need the most attention? Generated by AI via Proxuma Power BI MCP server.
Are you meeting your SLA targets? Where are the gaps, and which priorities need the most attention? 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
Are you meeting your SLA targets? Where are the gaps, and which priorities need the most attention? Generated by AI via Proxuma Power BI MCP server.
EVALUATE
ROW(
"TotalTickets", COUNTROWS(BI_Autotask_Tickets),
"FirstResponseMetPct", [Tickets - First Response Met %],
"ResolutionMetPct", [Tickets - Resolution Met %],
"SLABreached", CALCULATE(
COUNTROWS(BI_Autotask_Tickets),
BI_Autotask_Tickets[resolved_due_age_days] > 0)
)
The direct answer: how each priority level performs against first response and resolution SLA targets
| Priority | FR % | Res % | Avg FR (hrs) | Avg Res (hrs) |
|---|---|---|---|---|
| P1 | 52.3% | 91.6% | 0.83 | 2.09 |
| P2 | 35.7% | 54.0% | 9.59 | 31.99 |
| P3 | 34.4% | 69.9% | 8.87 | 21.58 |
| P4 | 61.1% | 70.4% | 5.33 | 16.29 |
| Service/Change | 56.5% | 36.2% | 7.74 | 23.82 |
EVALUATE SUMMARIZECOLUMNS('BI_Autotask_Tickets'[priority_name], "TicketCount", COUNTROWS('BI_Autotask_Tickets'), "AvgFR", AVERAGE('BI_Autotask_Tickets'[first_response_duration_hours]), "FRMet", CALCULATE(COUNTROWS('BI_Autotask_Tickets'), 'BI_Autotask_Tickets'[first_response_met] + 0 = 1), "AvgRes", AVERAGE('BI_Autotask_Tickets'[resolution_duration_hours]), "ResMet", CALCULATE(COUNTROWS('BI_Autotask_Tickets'), 'BI_Autotask_Tickets'[resolution_met] + 0 = 1))
Current non-complete tickets that could become SLA breaches if not addressed
| Priority | Complete | In Progress | New | Waiting/Planned | Other |
|---|---|---|---|---|---|
| P1 - Critical | 1,769 | 8 | 6 | 0 | 5 |
| P2 - High | 5,014 | 2 | 1 | 0 | 2 |
| P3 - Medium | 14,625 | 18 | 52 | 0 | 20 |
| P4 - Low | 29,859 | 170 | 77 | 187 | 122 |
| Service/Change | 15,410 | 0 | 33 | 125 | 16 |
EVALUATE
SUMMARIZECOLUMNS(
BI_Autotask_Tickets[priority_name],
BI_Autotask_Tickets[status_name],
"TicketCount", COUNTROWS(BI_Autotask_Tickets)
)
Critical and high-priority tickets carry the strictest SLA targets and the highest client impact when breached
P1 tickets are your biggest SLA problem. At 1,788 tickets, the volume is manageable, but 31.4% of first responses and 28.2% of resolutions are missing their targets. For tickets that should receive the fastest possible attention, that failure rate is unacceptable. The average resolution time of 82.1 days for critical tickets suggests that many P1s are either misclassified or stuck in long-running escalation loops.
P2 performs well on resolution (94.0%) but the first response rate of 82.4% still means roughly 1 in 5 high-priority tickets does not get an initial response within the SLA window. That 12-point gap between first response and resolution suggests the team recovers well once engaged, but there is a dispatch or acknowledgment bottleneck at the front end.
Currently, 8 P1 tickets are still in progress and 6 are sitting as new. Those 14 open P1 tickets represent the highest-risk items in the backlog. Every day they remain open increases the chance of a breach and a difficult client conversation.
EVALUATE
SUMMARIZECOLUMNS(
BI_Autotask_Tickets[priority_name],
BI_Autotask_Tickets[status_name],
FILTER(
ALL(BI_Autotask_Tickets[priority_name]),
BI_Autotask_Tickets[priority_name] IN {
"P1 - Kritiek (Critical)",
"P2 - Hoog (High)"}),
"TicketCount", COUNTROWS(BI_Autotask_Tickets),
"FirstResponseMetPct", [Tickets - First Response Met %],
"ResolutionMetPct", [Tickets - Resolution Met %],
"AvgResolveDays", AVERAGE(BI_Autotask_Tickets[resolved_due_age_days])
)
The headline numbers tell a mixed story. Resolution rates are acceptable at every priority level except P1, where 71.8% is the weakest performance in the entire dataset. First response rates are the real problem: the overall 52.9% is dragged down by P3 tickets, which make up 21.8% of all tickets and hit only 55.2% on first response.
There is a clear pattern in the data: the team is better at resolving tickets than at responding to them initially. P2 shows a 12-point gap between first response (82.4%) and resolution (94.0%). P3 shows a 29-point gap (55.2% vs 83.8%). This points to a dispatch or triage bottleneck rather than a technical capability problem. Once a tech picks up a ticket, they resolve it within SLA most of the time.
Service and change requests perform best at 97.3% first response and 97.5% resolution, likely because they have the most generous SLA windows. The 165-day average resolution time is not a concern here because these are typically planned work items with longer expected timelines.
The 360 breached tickets (resolved past their due date) represent 0.5% of total volume. That number looks small as a percentage, but each breach is a potential client conversation about contract compliance. If those 360 are concentrated among a few clients, the risk multiplies.
The backlog tells its own story. P4 has 434 open tickets across various statuses, which is normal for a queue of 30,415. P3 has 90 open tickets out of 14,715. The risk is concentrated at P1, where 14 open tickets out of 1,788 total (0.8%) means there are critical issues sitting unresolved right now.
P3 tickets make up 14,715 of the total volume and nearly half of them miss their first response SLA. This single priority level is the primary driver of the 52.9% overall first response rate. Fixing P3 triage would move the global number significantly.
At 68.6% first response and 71.8% resolution, P1 is the only priority level that fails both SLA targets. Critical tickets should be the best-performing category, not the worst after P3. The 82.1-day average resolution time suggests misclassification or stalled escalations.
Every priority level shows a gap between first response and resolution performance. This is a systemic triage and dispatch issue, not a per-priority problem. The team resolves tickets well once they engage, but the initial acknowledgment window is being missed too often.
High-priority tickets are being resolved within SLA at a rate that meets most contract requirements. P4 and service requests also perform well above 90%. The resolution engine works. The bottleneck is upstream.
With 15,584 tickets at 97.3% first response and 97.5% resolution, planned work is handled consistently. This is the benchmark the other priorities should aim for, adjusted for their tighter SLA windows.
5 priorities based on the findings above
P3 tickets are missing their first response SLA nearly half the time. With 14,715 tickets at this priority level, this is the highest-volume problem in the dataset. Review your dispatch rules for P3. Check whether auto-assignment is configured, whether the SLA clock starts correctly, and whether the first response window is realistic for your team size. A 10-point improvement here would move the overall first response rate from 52.9% to roughly 60%.
An 82.1-day average resolution for critical tickets is a red flag. Either tickets are being classified as P1 when they should not be, or they are getting stuck in escalation queues without resolution. Pull the 1,788 P1 tickets and check how many were reclassified during their lifecycle. If more than 20% were downgraded, the classification criteria need tightening. If they stayed P1 the entire time, the escalation process is broken.
There are 8 P1 tickets in progress and 6 sitting as new. Every one of those is a potential SLA breach and a client escalation waiting to happen. Pull that list into your morning standup. If any of them are misclassified, reclassify them. If they are legitimate, assign a dedicated resource to drive them to resolution this week.
The consistent gap between first response and resolution across all priorities points to a dispatch bottleneck. Consider setting up automated first response confirmations in Autotask for P1 and P2 tickets. Even a templated acknowledgment that says “We have received your ticket and a technician will be assigned within [X] minutes” counts as a first response and stops the SLA clock. This alone could push P1 first response from 68.6% above 85%.
P2 resolution at 94.0% shows what your team is capable of when the ticket gets to the right person. That is your ceiling for the other priorities. Set 90% resolution as the minimum target for P1 and P3. Track it weekly. The resolution engine works. The focus should be on getting tickets to technicians faster, not on changing how they resolve them.
The Tickets - First Response Met % measure in Proxuma Power BI checks whether the first technician response on each ticket was recorded before the SLA-defined first response deadline. The field first_response_met is stored as an integer (1 = met, 0 = missed). The percentage is the sum of met responses divided by total tickets, filtered with first_response_met + 0 = 1 to handle the int64 data type correctly.
The Tickets - Resolution Met % measure checks whether each ticket was resolved before its SLA resolution deadline. Similar to first response, the resolution_met field is an integer (1 = within SLA, 0 = breached). The percentage counts all tickets where resolution_met + 0 = 1 divided by total ticket count.
In this report, SLA breaches are tickets where resolved_due_age_days > 0, meaning the ticket was resolved after its SLA due date. The 360 breached tickets counted here are specifically those that were completed but missed their resolution deadline. Open tickets that are past due are not counted in that number but represent ongoing risk.
The overall percentage is a weighted average across all 67,521 tickets. P3 tickets (14,715) have a 55.2% first response rate, which drags the average down significantly. If you exclude P3, the remaining priorities average above 80%. The problem is concentrated, not systemic.
Yes. The DAX queries in this report can be filtered by adding conditions on BI_Autotask_Tickets[company_name] or a date range on BI_Autotask_Tickets[create_date]. For QBR preparation, filter to the last quarter and a specific client to show their SLA performance in isolation.
Yes. Connect Proxuma Power BI to your Autotask PSA instance, add an AI tool (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.
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