Open tickets with no updates in 30+ days, ranked by volume and age. Generated by AI via Proxuma Power BI MCP server.
Open tickets with no updates in 30+ days, ranked by volume and age. 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 desk managers, dispatch leads, and operations teams
How often: Daily for queue management, weekly for trend analysis, monthly for capacity planning
Open tickets with no updates in 30+ days, ranked by volume and age. Generated by AI via Proxuma Power BI MCP server.
EVALUATE
TOPN(15,
SUMMARIZECOLUMNS(
'BI_Autotask_Tickets'[company_name],
FILTER('BI_Autotask_Tickets',
ISBLANK('BI_Autotask_Tickets'[complete_date]) &&
'BI_Autotask_Tickets'[last_activity_date] < TODAY() - 30
),
"stuck_count", COUNTROWS('BI_Autotask_Tickets'),
"avg_age_days", AVERAGE('BI_Autotask_Tickets'[resolved_due_age_days])
),
[stuck_count], DESC
)Open tickets with no activity for 30+ days, grouped by client and ranked by count. Horizontal bars show relative volume.
| Status | Count |
|---|---|
| Planned | 213 |
| In progress | 205 |
| New | 169 |
| Waiting Customer | 116 |
| Customer responded | 102 |
EVALUATE SUMMARIZECOLUMNS('BI_Autotask_Tickets'[status_name], "Count", COUNTROWS('BI_Autotask_Tickets'))How long these 844 tickets have been idle, segmented into three age brackets
Nearly half of the stuck backlog (48.7%) is between 30 and 60 days old. These tickets are the easiest to recover: the original context is still relatively fresh, and the client may not have noticed yet. The 324 tickets in the 60-to-90-day range are harder. Technicians will need to re-read the history and likely reach out to the client for an update.
The 109 tickets older than 90 days are the real problem. At that age, the original requester has probably found a workaround, and the ticket exists only as a broken promise in the system. Each one either needs to be resolved immediately or closed with a proper explanation to the client.
EVALUATE
SUMMARIZECOLUMNS(
"age_bucket",
SWITCH(TRUE(),
DATEDIFF('BI_Autotask_Tickets'[last_activity_date], TODAY(), DAY) <= 60, "30-60d",
DATEDIFF('BI_Autotask_Tickets'[last_activity_date], TODAY(), DAY) <= 90, "60-90d",
">90d"
),
FILTER('BI_Autotask_Tickets',
ISBLANK('BI_Autotask_Tickets'[complete_date]) &&
'BI_Autotask_Tickets'[last_activity_date] < TODAY() - 30
),
"ticket_count", COUNTROWS('BI_Autotask_Tickets')
)Why idle tickets are more expensive than they look
SLA exposure. Every stuck ticket is an active SLA timer. Even if the ticket was opened as low-priority, 60+ days of inactivity means you are almost certainly past the resolution target. If the client runs a report on their side, or brings it up during a QBR, the conversation shifts from service delivery to breach. Rivers Rogers Mitchell alone has 113 tickets averaging 68 days old. That is 113 potential SLA violations sitting in one account.
Technician ramp-up cost. Picking up a ticket after 30 days is not the same as picking one up from yesterday. The technician needs to re-read the history, check whether the environment has changed, and often contact the client to confirm the issue still exists. Industry estimates put the ramp-up cost at 15 to 30 minutes per stale ticket. For 844 tickets, that is 210 to 420 hours of recovery work just to get back to where these tickets were a month ago.
Client perception. The worst outcome is not the SLA number. It is the client who opens a new ticket for the same issue, gets a different technician, and realizes the first ticket was never resolved. That is a trust problem, and trust problems drive churn. Martin Group (65 stuck, avg 72 days) and Hernandez Ltd (37 stuck, avg 65 days) are both at risk of exactly this scenario.
Rivers Rogers Mitchell (113), Martin Group (65), and Wall PLC (63) together hold 241 of the 844 stuck tickets. Fixing just these three accounts removes nearly a third of the backlog. Martin Group has the highest average age at 72 days, meaning their tickets have been idle the longest.
These tickets have been idle for three months or more. In most cases, the original issue has either been resolved through a workaround or the client has stopped waiting. Each one should be reviewed individually: either close it with a client notification, or escalate it if the issue is still open. Leaving them in the queue inflates the backlog and skews reporting.
411 tickets (48.7% of the total) are between 30 and 60 days old. These are recent enough that the original context is still useful and the client probably has not escalated yet. A focused two-week sprint targeting this bracket would cut the stuck backlog in half and prevent 411 tickets from aging into the harder-to-fix 60-to-90-day range.
Triage process and escalation rules based on the data above
Pull the full ticket list for Rivers Rogers Mitchell, Martin Group, and Wall PLC. Sort by age (oldest first). For each ticket, decide in under two minutes: close with client notice, reassign to a named technician with a 48-hour deadline, or escalate to the account manager. Do not let technicians "look into it later." Assign a name and a date, or close it.
Add a 15-minute standing agenda item to the weekly dispatch meeting: review any ticket where last_activity_date is older than 14 days. The 30-day threshold in this report catches tickets that are already stuck. A 14-day check catches them before they get there. Filter the Autotask queue by last activity date, sort ascending, and work down the list.
Configure an Autotask workflow rule that flags any open ticket with no activity for 21 days. Send an email to the assigned resource and their team lead. If the ticket hits 30 days with still no activity, automatically reassign it to the service manager. This prevents tickets from silently aging into the 60-day and 90-day brackets.
For the 109 tickets older than 90 days, send a batch email per client: "We have [X] open tickets on your account that have not been updated in over 90 days. Please review the attached list and let us know which ones are still needed." Any ticket not claimed within 7 days gets closed with a standard resolution note. This clears dead weight and gives clients a chance to re-prioritize what matters.
Any ticket that is still open (no complete_date) and where the last_activity_date is more than 30 days ago. This includes tickets in any queue and any priority level. The 30-day threshold is a starting point. You can adjust it in the DAX query by changing the "TODAY() - 30" filter to a shorter or longer window.
Average age is the mean of resolved_due_age_days across all stuck tickets for a given company. This measures how many days each ticket has been open relative to its due date. A higher number means the ticket has been past its resolution target for longer.
Yes. The query filters on complete_date being blank and last_activity_date being older than 30 days. It does not exclude tickets in a "waiting on client" status. If you want to exclude those, add a filter on the ticket status column in the DAX query. That said, a ticket waiting on a client for 60+ days still needs follow-up. The client may have forgotten or moved on.
Yes. Add a FILTER clause on BI_Autotask_Tickets[queue_name] or BI_Autotask_Tickets[priority] to the DAX query. For example, filtering to only "Service Desk" queue would narrow the results to tickets in that queue. Copy the query from any section, modify it in Power BI Desktop, and run it against your dataset.
Yes. Connect Proxuma Power BI to your Autotask PSA 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