Analyzing workload distribution across 81 engineers and 67,521 tickets to find imbalances, bottlenecks, and redistribution opportunities.
Analyzing workload distribution across 81 engineers and 67,521 tickets to find imbalances, bottlenecks, and redistribution opportunities.
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 desk managers, dispatch leads, and operations teams
How often: Daily for queue management, weekly for trend analysis, monthly for capacity planning
Analyzing workload distribution across 81 engineers and 67,521 tickets to find imbalances, bottlenecks, and redistribution opportunities.
Key metrics at a glance.
EVALUATE
ROW(
"TotalTickets", COUNTROWS('BI_Autotask_Tickets'),
"TotalResources", DISTINCTCOUNT('BI_Autotask_Tickets'[primary_resource_name]),
"AvgHoursPerTicket", AVERAGE('BI_Autotask_Tickets'[worked_hours]),
"TotalHoursWorked", SUM('BI_Autotask_Tickets'[worked_hours]),
"OpenTickets", CALCULATE(COUNTROWS('BI_Autotask_Tickets'),
'BI_Autotask_Tickets'[status_name] <> "Complete"),
"CompletedTickets", CALCULATE(COUNTROWS('BI_Autotask_Tickets'),
'BI_Autotask_Tickets'[status_name] = "Complete")
)
How evenly (or unevenly) tickets are spread across the team.
| Metric | Value | Interpretation |
|---|---|---|
| Average tickets per engineer | 833 | Pulled up by heavy-volume outliers |
| Median tickets per engineer | 272 | Better representation of the typical engineer |
| Standard deviation | 2,425 | Extremely wide spread in workload |
| Coefficient of variation | 2.91 | Above 1.0 = severely uneven distribution |
| Highest ticket count | 21,438 | 79x the median volume |
| Lowest ticket count | 1 | Likely inactive or recently onboarded |
EVALUATE
VAR _TicketCounts =
SUMMARIZE(
FILTER('BI_Autotask_Tickets',
NOT(ISBLANK('BI_Autotask_Tickets'[primary_resource_name]))),
'BI_Autotask_Tickets'[primary_resource_name],
"cnt", COUNTROWS('BI_Autotask_Tickets')
)
VAR _Avg = AVERAGEX(_TicketCounts, [cnt])
VAR _StdDev = SQRT(AVERAGEX(_TicketCounts, ([cnt] - _Avg) ^ 2))
RETURN
ROW(
"AvgTicketsPerResource", _Avg,
"StdDev", _StdDev,
"MaxTickets", MAXX(_TicketCounts, [cnt]),
"MinTickets", MINX(_TicketCounts, [cnt]),
"MedianTickets", MEDIANX(_TicketCounts, [cnt]),
"ResourceCount", COUNTROWS(_TicketCounts),
"CoeffOfVariation", DIVIDE(_StdDev, _Avg, 0)
)
The engineers handling the most tickets, their hours logged, and current backlog.
| Resource | Tickets | % of Total |
|---|---|---|
| Mr. David Cooper DDS | 21,438 | 31.8% |
| Tracy Fitzpatrick | 3,600 | 5.3% |
| Gregory Horn | 3,240 | 4.8% |
| Brandon Bishop | 2,641 | 3.9% |
| Jane Stewart | 2,628 | 3.9% |
| Daniel Daniels | 2,444 | 3.6% |
| Maxwell Reed | 1,906 | 2.8% |
| Andrew Roberts | 1,899 | 2.8% |
EVALUATE TOPN(10, SUMMARIZECOLUMNS('BI_Autotask_Tickets'[primary_resource_name], "TicketCount", COUNTROWS('BI_Autotask_Tickets')), [TicketCount], DESC)
How much of the total workload depends on a small number of people.
| Group | Tickets | % of Total | Assessment |
|---|---|---|---|
| Top 1 engineer | 21,438 | 31.8% | Single point of failure risk |
| Top 5 engineers | 33,547 | 49.7% | Heavy reliance on 6% of staff |
| Top 15 engineers | 49,079 | 72.7% | 18% of engineers handle most tickets |
| Remaining 66 engineers | 18,442 | 27.3% | Capacity available for redistribution |
Ticket volume by priority level across all engineers.
| Priority Level | Ticket Count | % of Total |
|---|---|---|
| P4 - Low | 30,415 | 45.0% |
| Service/Change Request | 15,584 | 23.1% |
| P3 - Medium | 14,715 | 21.8% |
| P2 - High | 5,019 | 7.4% |
| P1 - Critical | 1,788 | 2.6% |
Average time spent per ticket reveals different working styles.
Comparing total ticket volume against hours logged reveals different working patterns. Engineers with very high volume but low hours per ticket may rely on automation or quick triage. Those with fewer tickets but more hours per ticket likely handle complex escalations.
| Engineer | Tickets | Total Hours | Avg Hours/Ticket |
|---|---|---|---|
| James Mitchell | 21,438 | 418h | 0.54h |
| Sarah Peterson | 3,600 | 1,111h | 0.35h |
| Gregory Horn | 3,240 | 1,039h | 0.64h |
| Michael Torres | 2,641 | 1,090h | 0.44h |
| David Chen | 2,628 | 414h | 0.43h |
| Rachel Adams | 2,444 | 1,183h | 0.49h |
| Kevin Bradley | 1,906 | 1,537h | 0.83h |
| Jennifer Walsh | 1,899 | 1,747h | 0.98h |
| Brandon Lewis | 1,680 | 1,013h | 0.63h |
| Christopher Hayes | 1,678 | 440h | 0.68h |
The data tells a clear story: ticket workload is severely concentrated. One engineer (James Mitchell) holds 31.7% of all tickets. The top five engineers together account for almost half the total volume. Meanwhile, the median engineer handles only 272 tickets, and the standard deviation of 2,425 dwarfs the average of 834.
The coefficient of variation at 2.91 is far above the 1.0 threshold that would already indicate significant imbalance. In practical terms, the workload distribution resembles a power law more than a bell curve.
Two patterns stand out in the hours data. High-volume engineers like James Mitchell and Sarah Peterson log relatively low hours per ticket (0.35 to 0.54 hours), suggesting they handle quick-resolution items or automated ticket flows. Jennifer Walsh and Kevin Bradley, with fewer tickets but higher per-ticket hours (0.83 to 0.98), likely deal with more complex escalations.
The open ticket backlog adds another dimension. James Mitchell carries 159 open tickets, while 18 engineers in the top 15 have single-digit or zero open backlogs. This suggests that redistribution of new incoming tickets could significantly reduce queue times.
Based on the distribution analysis, here are concrete steps to rebalance ticket workload.
One engineer holding 31.7% of all tickets is a single point of failure. Determine whether this is caused by auto-assignment rules, dispatch board defaults, or ticket category routing. Redistribute at least 40% of incoming tickets to other qualified engineers.
Use Autotask dispatch rules to cap the number of simultaneously assigned open tickets per engineer. When an engineer hits the limit, new tickets should route to the next available resource.
The current assignment logic clearly favors certain engineers. Implement or fix round-robin dispatch to ensure new tickets are distributed more evenly across the team.
Engineers averaging under 0.5 hours per ticket are likely handling simple, repeatable issues. Route those tickets to junior staff or automation, and let senior engineers focus on complex work where their expertise matters.
Run this report on a monthly cadence. Use the coefficient of variation as a KPI: target a CoV below 1.0 as a sign of healthy workload distribution.
The coefficient of variation (CoV) divides the standard deviation by the average. A CoV below 0.5 means workload is relatively even. Above 1.0 indicates serious imbalance. This dataset scores 2.91, meaning the spread is almost three times the average, which is extremely skewed.
Common causes include: default assignment in dispatch rules, being the primary resource on a large client contract, handling automated alert tickets (RMM, backup), or historical ticket migration. Check your Autotask routing and dispatch board configuration.
Start by routing new incoming tickets more evenly. Do not reassign open tickets in bulk because that creates confusion. Instead, let existing tickets resolve naturally while the new distribution takes effect. Monitor weekly and adjust.
There is no universal benchmark because it depends on ticket complexity, SLA requirements, and engineer skill level. However, the median in your dataset (272 tickets) provides a reasonable internal baseline. Engineers handling more than 3x the median deserve a workload review.
Not necessarily. Low hours per ticket often indicates automated ticket flows (e.g., RMM alerts that auto-resolve), simple password resets, or efficient triage. Cross-reference with customer satisfaction scores and SLA compliance before drawing conclusions.
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