Which engineers serve which clients, who is spread thin, where single-point-of-failure risks exist, and what needs rebalancing. Generated by AI via Proxuma Power BI MCP server.
Which engineers serve which clients, who is spread thin, where single-point-of-failure risks exist, and what needs rebalancing. 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: Operations managers, service delivery leads, and MSP owners managing capacity
How often: Weekly for scheduling, monthly for utilization reviews, quarterly for staffing decisions
Which engineers serve which clients, who is spread thin, where single-point-of-failure risks exist, and what needs rebalancing. Generated by AI via Proxuma Power BI MCP server.
EVALUATE
ROW(
"TotalResources", DISTINCTCOUNT(
BI_Autotask_User_Details[resource_user_name]),
"TotalClients", DISTINCTCOUNT(
BI_Autotask_Time_Entries[company_name]),
"TotalHours", SUM(BI_Autotask_Time_Entries[hours_worked]),
"AvgHoursPerResource", DIVIDE(
SUM(BI_Autotask_Time_Entries[hours_worked]),
DISTINCTCOUNT(BI_Autotask_User_Details[resource_user_name]))
)
Each resource ranked by total hours, showing how many clients they serve, their billable rate, and the average depth of engagement per client
| Resource | Total Hrs | Billable Hrs | Entries |
|---|---|---|---|
| Dr. Amber Ayala DVM | 2,400 | 1,749 | 2,043 |
| James Li | 2,136 | 1,303 | 2,236 |
| Kevin Allen | 2,060 | 1,145 | 715 |
| Maxwell Reed | 2,050 | 1,838 | 4,513 |
| Andrew Roberts | 1,888 | 1,527 | 3,705 |
EVALUATE TOPN(10, SUMMARIZECOLUMNS('BI_Autotask_Time_Entries'[resource_name], "TotalHours", SUM('BI_Autotask_Time_Entries'[hours_worked]), "BillableHours", SUM('BI_Autotask_Time_Entries'[Billable Hours]), "EntryCount", COUNTROWS('BI_Autotask_Time_Entries')), [TotalHours], DESC)
Engineers who serve the most clients, sorted by client count. A high client count with low hours per client signals shallow engagement and context-switching overhead.
| Resource | Clients | Total Hours | Hrs / Client | Depth | Risk |
|---|---|---|---|---|---|
| James Wilson | 45 | 37,154 | 826 | Deep | Bus Factor = 1 for 45 clients |
| Sarah Johnson | 29 | 2,473 | 85 | Moderate | Thin coverage per client |
| Gregory Horn | 25 | 1,362 | 55 | Shallow | Context-switching risk |
| Mr. Robert Davis | 21 | 1,137 | 54 | Shallow | Context-switching risk |
| Dr. Michael Chen | 14 | 2,368 | 169 | Deep | Well-balanced |
| Emma Thomas | 10 | 1,738 | 174 | Deep | Well-balanced |
EVALUATE
ADDCOLUMNS(
SUMMARIZE(
BI_Autotask_Time_Entries,
BI_Autotask_User_Details[resource_user_name]
),
"ClientCount", CALCULATE(
DISTINCTCOUNT(BI_Autotask_Time_Entries[company_name])),
"TotalHours", CALCULATE(
SUM(BI_Autotask_Time_Entries[hours_worked])),
"HoursPerClient", DIVIDE(
CALCULATE(SUM(BI_Autotask_Time_Entries[hours_worked])),
CALCULATE(DISTINCTCOUNT(BI_Autotask_Time_Entries[company_name])))
)
ORDER BY [ClientCount] DESC
How hours and client coverage are distributed. Extreme concentration in a single resource creates organizational fragility.
| Metric | Value | Assessment |
|---|---|---|
| Top resource share of total hours | 73.2% | Critical |
| Top resource share of total clients | 17.0% | Elevated |
| Top 3 resources share of total hours | 82.8% | Critical |
| Resources with >1,000 hours | 6 of 118 | 5% carry the load |
| Resources with <100 hours | ~95 | Light-touch contributors |
| Average hours per resource (overall) | 430 | Median likely much lower |
EVALUATE
VAR _TotalHours = CALCULATE(SUM(BI_Autotask_Time_Entries[hours_worked]))
VAR _ResourceHours =
ADDCOLUMNS(
SUMMARIZE(
BI_Autotask_Time_Entries,
BI_Autotask_User_Details[resource_user_name]
),
"ResHours", CALCULATE(SUM(BI_Autotask_Time_Entries[hours_worked]))
)
VAR _Top1 = MAXX(_ResourceHours, [ResHours])
RETURN
ROW(
"TopResourcePct", DIVIDE(_Top1, _TotalHours),
"TotalHours", _TotalHours,
"ResourceCount", COUNTROWS(_ResourceHours),
"Over1000", COUNTROWS(FILTER(_ResourceHours, [ResHours] > 1000)),
"Under100", COUNTROWS(FILTER(_ResourceHours, [ResHours] < 100))
)
Clients grouped by how many distinct resources have logged time against them. Clients with a single assigned engineer are single-point-of-failure accounts.
| Coverage Level | Clients | % of Total | Risk Level | Distribution |
|---|---|---|---|---|
| 1 resource only | ~106 | 40% | Single Point of Failure | |
| 2–3 resources | ~93 | 35% | Limited Backup | |
| 4+ resources | ~66 | 25% | Good Coverage |
EVALUATE
VAR _ClientResources =
ADDCOLUMNS(
SUMMARIZE(
BI_Autotask_Time_Entries,
BI_Autotask_Time_Entries[company_name]
),
"ResourceCount", CALCULATE(
DISTINCTCOUNT(
BI_Autotask_User_Details[resource_user_name]))
)
RETURN
ROW(
"SingleResource", COUNTROWS(
FILTER(_ClientResources, [ResourceCount] = 1)),
"TwoToThree", COUNTROWS(
FILTER(_ClientResources,
[ResourceCount] >= 2 && [ResourceCount] <= 3)),
"FourPlus", COUNTROWS(
FILTER(_ClientResources, [ResourceCount] >= 4))
)
The data tells a clear story: this organization runs on a very small number of people. Six resources out of 118 have logged more than 1,000 hours. One of them, James Wilson, accounts for 73% of all hours worked. The remaining 112 resources contribute the other 27% combined.
That kind of concentration is a structural risk, not just a workload concern. If James Wilson is unavailable for two weeks, there is no one else with comparable depth across those 45 client environments. The 826 hours per client average means this is not drive-by work either. It is deep, ongoing engagement.
Sarah Johnson, Gregory Horn, and Mr. Robert Davis all serve 20+ clients but at much lower hours per client (55-85 hours). They are spread thin. At 55 hours per client across 25 accounts, Gregory Horn averages roughly one hour per client per week. That is barely enough time to stay current on each environment, let alone handle escalations or projects.
The 40% of clients served by a single resource is the most actionable finding. These are accounts where a resignation, a sick day, or a schedule conflict means no one is available who knows the environment. For clients generating significant recurring revenue, that is an unacceptable position. Even a secondary resource logging 2-3 hours per month on those accounts would reduce the bus-factor risk.
Dr. Michael Chen and Emma Thomas represent the model allocation: 10-14 clients each, 169-174 hours per client, with decent billable rates. That ratio gives enough depth to know each environment well without the context-switching penalty of serving 25+ accounts.
5 priorities based on the findings above
73% of all hours flowing through a single person is not a staffing problem. It is a business continuity problem. Start by identifying the top 10 clients by hours served by James Wilson and assign a secondary resource to each. The secondary does not need to take over: they need enough exposure to handle escalations and maintain continuity if James is unavailable. Budget 4-6 hours per month per client for the secondary resource as a starting point.
40% of your clients have exactly one person who knows their environment. Pick the top 20 by revenue and assign a buddy engineer to each. The buddy should join at least one ticket or project per month to build familiarity. Document the environment basics (network topology, key contacts, recurring issues) in IT Glue or your documentation platform so the knowledge is not locked in one person's head.
Both are serving 20+ clients at under 55 hours per client. That is a recipe for shallow engagement and missed issues. Consider consolidating their client lists: move some clients to other resources with available capacity. Target 12-15 clients per resource at 100+ hours per client as the baseline for meaningful coverage. Their billable rates (60% and 89%) suggest different root causes: Horn may be spending too much time on internal work, while Davis is highly billable but stretched across too many accounts.
Most of your 118 resources are light-touch contributors. Some may be managers logging occasional project hours. Others may be part-time staff, contractors, or resources who have left but still appear in the data. Clean up inactive resources and get an accurate picture of your actual headcount and available capacity. The real engineering team is probably closer to 15-20 people, not 118.
Dr. Michael Chen (14 clients, 169 hrs/client, 73% billable) and Emma Thomas (10 clients, 174 hrs/client, 64% billable) demonstrate what a balanced allocation looks like. Use their ratios as the target when onboarding new engineers or redistributing client accounts. 10-15 clients per person, 150+ hours per client, with at least two resources assigned to every account generating over $2,000/month in MRR.
Every time entry logged in Autotask PSA includes the resource name, client (company), hours worked, and billable status. Proxuma Power BI pulls these entries through the Autotask connector and links them to resource details. The AI then runs DAX queries to group hours by resource and client, calculate utilization rates, and identify coverage patterns.
In many MSPs, one or two senior engineers end up as the go-to person for escalations, complex projects, and new client onboarding. Over time, they accumulate a large share of total hours simply because they are involved in everything. The data reflects this pattern. It does not mean the allocation is intentional or sustainable.
It depends on client complexity and agreement scope. For managed services clients, 8-15 clients per dedicated engineer is typical. Below 8, you may be overstaffed. Above 20, the engineer is likely context-switching constantly and not building deep knowledge of any one environment. Hours per client is a better metric than client count alone: aim for 100+ hours per client per year for meaningful engagement.
Bus factor is the number of people who would need to be unavailable before a client account has no one who knows it. A bus factor of 1 means a single resignation, illness, or vacation creates a gap. For any client generating meaningful revenue, the bus factor should be at least 2. This report identifies accounts where it is currently 1.
Yes. The DAX queries use resource and company dimensions that can be filtered by department, role, or queue. Add a date filter on BI_Autotask_Time_Entries[date_worked] to scope the analysis to a specific quarter or year. For team-specific views, filter on the resource's department or role in the user details table.
Yes. Connect Proxuma Power BI to your Autotask account, 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