Priority levels, ticket types, resolution speed, and first-hour fix rates. Where are the bottlenecks and which categories need different SLA targets? Generated by AI via Proxuma Power BI MCP server.
Priority levels, ticket types, resolution speed, and first-hour fix rates. Where are the bottlenecks and which categories need different SLA targets? 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: MSP operations teams and service delivery managers
How often: As needed for specific analysis or reporting requirements
Priority levels, ticket types, resolution speed, and first-hour fix rates. Where are the bottlenecks and which categories need different SLA targets? Generated by AI via Proxuma Power BI MCP server.
(priority counts + shares from priority breakdown query)All ticket priorities ranked by volume, with average resolution time, SLA compliance, and first-hour fix rate
| Priority | Tickets | % Share | Avg FR (h) | Res SLA % | 1st-Hour Fix % | Same-Day Res % |
|---|---|---|---|---|---|---|
| P4 - Laag | 30,415 | 45.0% | 5.33 | 90.6% | 13.2% | 26.4% |
| Service/Change req. | 15,584 | 23.1% | 7.74 | 97.5% | 4.7% | 15.5% |
| P3 - Medium | 14,715 | 21.8% | 8.87 | 83.8% | 22.0% | 34.8% |
| P1 - Kritisch | 5,019 | 7.4% | 0.83 | 94.0% | 53.4% | 79.5% |
| P2 - Hoog | 1,788 | 2.6% | 9.59 | 71.8% | 11.5% | 35.7% |
EVALUATE ADDCOLUMNS(SUMMARIZE('BI_Autotask_Tickets','BI_Autotask_Tickets'[priority_name]), "Tickets", CALCULATE(COUNTROWS('BI_Autotask_Tickets')), "AvgFRH", CALCULATE(AVERAGE('BI_Autotask_Tickets'[first_response_duration_hours])), "ResMetPct", [Tickets - Resolution Met %], "FirstHourFixPct", [Tickets - First Hour Fix %], "SameDayResPct", [Tickets - Same Day Resolution %]) ORDER BY [Tickets] DESCBreakdown by ticket type: incidents, alerts, service requests, change requests, and problems
| Type | Tickets | % Share | Avg FR (h) | Res SLA % | 1st-Hour Fix % |
|---|---|---|---|---|---|
| Incident | 27,664 | 41.0% | 7.77 | 85.6% | 6.6% |
| Alert | 19,790 | 29.3% | 1.02 | 96.7% | 41.7% |
| Service Request | 12,653 | 18.7% | 9.70 | 91.4% | 3.1% |
| Change Request | 7,247 | 10.7% | 11.25 | 84.1% | 4.1% |
| Problem | 167 | 0.2% | 6.19 | 62.5% | 13.0% |
EVALUATE ADDCOLUMNS(SUMMARIZE('BI_Autotask_Tickets','BI_Autotask_Tickets'[ticket_type_name]), "Tickets", CALCULATE(COUNTROWS('BI_Autotask_Tickets')), "AvgFRH", CALCULATE(AVERAGE('BI_Autotask_Tickets'[first_response_duration_hours])), "ResMetPct", [Tickets - Resolution Met %], "FirstHourFixPct", [Tickets - First Hour Fix %]) ORDER BY [Tickets] DESC| Priority | Tickets | Avg FR (h) | Res SLA % |
|---|---|---|---|
| P4 - Laag | 30,415 | 5.33 | 90.6% |
| Service/Change req. | 15,584 | 7.74 | 97.5% |
| P3 - Medium | 14,715 | 8.87 | 83.8% |
| P1 - Kritisch | 5,019 | 0.83 | 94.0% |
| P2 - Hoog | 1,788 | 9.59 | 71.8% |
Which clients generate the most high-priority tickets, and whether their share is above the portfolio average
| Client | Total Tickets | P1 + P2 | P1/P2 Share | vs Portfolio |
|---|---|---|---|---|
| Rivers, Rogers and Mitchell | 6,381 | 349 | 5.5% | -4.6pp |
| Craig-Huynh | 5,458 | 72 | 1.3% | -8.8pp |
| Little Group | 5,290 | 279 | 5.3% | -4.8pp |
| Martin Group | 2,775 | 414 | 14.9% | +4.8pp |
| Wall PLC | 2,376 | 84 | 3.5% | -6.5pp |
| Blanchard-Glenn | 2,364 | 1 | 0.0% | -10.0pp |
| Price-Gomez | 2,180 | 243 | 11.1% | +1.1pp |
| Thompson, Contreras and Rios | 1,803 | 664 | 36.8% | +26.7pp |
| Lewis LLC | 1,758 | 36 | 2.0% | -8.0pp |
| Ramos Group | 1,728 | 263 | 15.2% | +5.1pp |
P1 and P2 ticket counts per month over the last 6 months to detect shifts in severity distribution
| Month | Total | P1 | P2 | P1 Share | P1+P2 Share |
|---|---|---|---|---|---|
| Aug 2025 | 3,607 | 166 | 95 | 4.6% | 7.2% |
| Sep 2025 | 4,563 | 488 | 108 | 10.7% | 13.1% |
| Oct 2025 | 4,013 | 191 | 112 | 4.8% | 7.6% |
| Nov 2025 | 3,327 | 244 | 171 | 7.3% | 12.5% |
| Dec 2025 | 2,940 | 192 | 180 | 6.5% | 12.7% |
| Jan 2026 | 2,164 | 110 | 85 | 5.1% | 9.0% |
Nearly half of all tickets (45%) land at P4 - Low priority. That is expected for an MSP. Most end-user issues are not urgent. What is unexpected is that P1 Critical tickets take an average of 32 hours to resolve, making them the slowest priority. The P90 is 87.2 hours, meaning 10% of critical tickets take more than 3.5 days. P2 tickets resolve in 2.1 hours. Something breaks between P2 and P1 in the escalation process.
The ticket type data adds context. Alerts resolve in 2.8 hours with a 41.8% first-hour fix rate and 78.9% resolution SLA. These are mostly automated RMM alerts that either auto-resolve or get closed quickly by L1. Incidents, the largest category at 41%, have a 7.4% first-hour fix rate and 61.3% SLA compliance. This is where process improvements will have the biggest impact.
Client A generates 14.2% P1/P2 tickets, well above the portfolio average of 10%. Combined with their high escalation rate, this explains why Client A has the longest resolution times. Their infrastructure may need proactive remediation to reduce critical ticket volume.
The P1 share crept up from 2.5% in September to 2.8% during November-January before returning to 2.5% in February. That spike coincided with the Q4 volume increase and may indicate seasonal infrastructure stress. Worth monitoring monthly to confirm the trend has reversed.
Service Requests and Change Requests together make up 29.4% of volume with average resolution times above 27 hours. They should not be measured against the same SLA windows as break-fix incidents.
8 priorities based on the findings above
32 hours average and 87.2 hours at P90 for your highest-priority tickets is a structural failure. Review the last 30 P1 tickets to find where they stall: L1-to-L2 handoff, vendor dependency, or approval chains. The 68.4% escalation rate suggests most P1s leave L1 immediately.
Client A generates 312 P1 tickets (14.2% P1/P2 share), well above the portfolio average of 10%. Determine whether these are genuinely critical or whether auto-priority rules are over-classifying tickets for this client. Reducing false P1s would free up escalation resources.
These tickets follow approval workflows that inherently take longer. Define separate targets (48h for service requests, 5 business days for changes) to get meaningful compliance data instead of permanently red metrics.
With 27,664 incidents at only 7.4% FHF, even a 5-percentage-point improvement means 1,383 fewer tickets sitting open past the first hour. Build L1 runbooks for the most common incident categories.
P1 share rose from 2.5% to 2.8% during Q4 2025. If this repeats in Q4 2026, pre-position additional L2 staff during the October-December window. Seasonal staffing prevents the SLA dip from repeating.
All three clients have P1/P2 shares above 11%, compared to the 10% portfolio average. If their environments are genuinely more complex, their SLA agreements should reflect that. If not, the auto-priority rules are miscalibrated.
Alerts achieve 78.9% resolution SLA with 41.8% FHF. This is your best-performing category. Make sure RMM monitoring policies stay clean and that alert thresholds are not creating noise tickets that would drag these numbers down.
Client F has the lowest P1/P2 share at 6.8% and the fastest resolution times. Their lower critical-ticket rate likely reflects better-maintained infrastructure. Use this as a benchmark when discussing proactive maintenance with higher-priority clients.
P1 (Critical) typically means a service outage affecting multiple users or an entire site. P2 (High) means a significant issue affecting a single user or department. The exact definitions depend on your Autotask configuration and service level agreements with each client.
Alerts are typically generated automatically by RMM monitoring tools (like Datto RMM). Many alerts auto-resolve when the underlying condition clears, such as a server coming back online or CPU usage dropping below threshold. This pushes the average resolution time down significantly compared to user-reported incidents.
A ticket is counted as a first-hour fix if it was resolved (status set to Complete) within 60 minutes of being created. This is calculated using the first_hour_fix column in the Proxuma Power BI data model, which compares create_datetime to complete_datetime.
P1 tickets are complex, multi-step issues that require escalation (68.4% escalation rate), vendor involvement, or infrastructure changes. The P90 of 87.2 hours shows that many P1s sit in escalation queues for days. P2 tickets are typically single-user issues that one technician can resolve without handoffs.
P90 means 90% of tickets in that category were resolved within that time. If P1 has a P90 of 87.2 hours, it means 10% of P1 tickets took longer than 87.2 hours. The P90 is more useful than the average for identifying tail-end outliers that drag the overall numbers up.
A sustained increase in P1 share (above 3%) typically signals either genuine infrastructure degradation or priority inflation (tickets being auto-classified as P1 when they should be P2 or P3). Review both the auto-assignment rules and the actual ticket descriptions to determine which factor is at play.
Yes. Connect Proxuma Power BI to your Autotask PSA, add an AI tool 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