research
Measuring the age of unassigned tickets in a small helpdesk
A queue-ageing method that shows how long tickets wait before anyone owns them, which request types wait longest, and where routing rather than staffing is the real problem.
Use this benchmark to size repeatable IT work, set the review cadence, and decide what stays with the technical owner before assigning the workflow to an IT virtual assistant.
Research playbook
On this pageJump to section
Key stats
Key takeaways
An unassigned ticket can look like a small backlog item while it quietly ages past every service promise. The queue report may show a healthy average handling time because the clock only starts when someone picks up the work. This study measures the time a ticket spends without an owner, which is often the longest and least visible part of the wait. The result points to routing and intake problems that a staffing increase would not fix.
Question and scope
This study asks how long tickets remain unassigned, which request types and queues wait longest, and whether the delay clusters around particular times or people. The unit is one ticket, and the population is every ticket created during a declared month. The result describes that service desk and period, not the effort of individual technicians. Freeze the definition of unassigned and the observation window before exporting data.
Include tickets from every intake channel, including email, chat, phone, walk-up, and the self-service portal. Exclude tickets that were intentionally parked in a waiting state with a named owner. Record the source and the queue for each ticket. A measure that covers only one channel will understate the problem and mislead the staffing discussion.
Define unassigned
Define unassigned as the period between ticket creation and the first named owner assignment. A queue or team assignment is not the same as a named person, because a team queue can wait for days without anyone feeling responsible. Record the assignment event and the assignee role. If the system does not capture a named assignment, use the first individual response as a proxy and state that choice.
Decide how to handle tickets that are reassigned after the first owner. The study measures the first assignment, not later transfers, so the initial wait is comparable across request types. Record any subsequent transfer separately for context. A ticket that bounces between teams is a different problem from one that never found an owner.
Build the queue frame
Export the ticket identifier, the creation time, the first assignment time, the queue, the request type, and the priority. Add the current status and the closure time so open tickets can be separated from closed ones. For open tickets, calculate the age up to the export time and mark the value as censored. A young open ticket is not evidence of a fast queue. State the export time so the censored values can be interpreted correctly.
Reconcile the export with the service desk's monthly ticket count and explain any difference. Check for duplicates, test tickets, and records created by automation. Normalise the queue names so a renamed team is not treated as two queues. Record the mapping in the method note so the next study can repeat it.
Separate queues and severities
Report the unassigned age by queue and priority rather than as one average. A critical ticket that waits an hour is more serious than a low-priority request that waits a day. Use buckets such as under one hour, one to four hours, four to eight hours, and over one business day. Show the count and the oldest ticket in each bucket.
Check whether the priority is set at intake or changed later, because a ticket can be reclassified after it has already waited. Record the priority history where the system keeps it. If most tickets arrive as medium priority, the priority field is not helping anyone triage. That finding belongs in the report even though it is not a routing metric. Show the priority distribution beside the age results.
Measure time to first owner
Calculate the median, the ninetieth percentile, and the longest wait for each queue. Use business hours if the service promise is expressed in business hours, and state the calendar used. A weekend should not make a Friday ticket look older unless the desk operates at weekends. Present the working-hours and calendar-hours results separately when the difference is large.
Compare the result with the published service promise for each priority. A queue that meets its promise on average but fails the ninetieth percentile still has a tail that users experience. Report both numbers. The tail is often where the escalations and the reputational damage come from. Show the count of tickets beyond the promise, not only the percentage.
Sample the long waits
Read the full thread for the twenty oldest unassigned tickets in the month. Look for the reason nobody took ownership: an unclear request, a missing access path, a queue nobody monitors, or a routing rule that sends the ticket to the wrong team. Record the reason in a small set of categories. The sample explains the number and suggests the fix.
Ask the technicians who eventually claimed the tickets what made them pick up the work. A short interview with two of them is usually enough to see the pattern. Their answer often reveals that someone recognized the requester or happened to check the queue. A queue that depends on recognition is not a process. Write down who checks the queue at the start and end of each shift. Record that dependency as a finding rather than a personal habit. If the same technician claims most of the old tickets, the queue lacks a shared routine.
Find the routing gap
Compare the intake categories with the queues they route to. Export the routing rules and keep the version with the study evidence. A category that has no clear owner will sit unassigned until someone improvises. Check whether the routing rules were updated after the last team change. Record every category that maps to a generic queue or to a person who has left. A category without an owner is the most common source of a long wait.
Review the monitoring of each queue and the schedule of the people expected to watch it. A queue monitored only during one shift will accumulate overnight work. A queue with no named monitor is not a queue at all. The report should name the owner and the monitoring window for each intake path. Check the window against the hours when tickets actually arrive.
Report and act
Lead with the share of tickets that waited more than four business hours before assignment and the queues that produced them. Show the oldest cases and the routing gaps that explain them. Keep the technician-level detail out of the summary unless a specific case needs review. The report is about the queue design, not individual speed.
Recommend one routing change and one monitoring change for the next month. Name the owner and the date for each. A small number of changes is easier to test than a full redesign. Measure the same buckets afterward so the effect is visible. Keep the first report so the comparison uses the same definitions.
Limits and next use
The study measures tickets that were recorded and assignment events that the system captured. It does not capture requests resolved in a corridor or messages sent to a personal phone. It also cannot prove that the first owner was the right owner. State those limits so the queue age is read as a lower bound on the real wait.
Repeat the measurement after the routing change and compare the same queues and priorities. If the unassigned age falls but reopen rates rise, the faster assignment may be sending work to people without the right access. The next study should link queue age to resolution quality rather than speed alone. A faster assignment that produces more reopens is not an improvement.
Repeat the measurement
Run the same export on the first working day of each month and keep the results in one place. A monthly cadence catches seasonal patterns without becoming a reporting burden. Compare the same buckets and the same business calendar. A changing definition makes the trend meaningless. Note any system change that altered how assignment is recorded.
Review the trend with the service desk lead and the queue owners each quarter. Choose one queue for a deeper review if its tail is not improving. Keep the raw export with the report so a new analyst can reproduce the number. The measurement is useful when it becomes a routine, not a one-time project.
Sources and next step
Use the NIST Cybersecurity Framework 2.0 and the CISA Cross-Sector Cybersecurity Performance Goals as primary references for the identity, asset, and vendor controls discussed here. The GAO data reliability guidance supports the sampling and verification approach used in these methods. Apply your own policies, contracts, and system documentation when adapting the method.
Compare this study with the asset record accuracy study and the account provisioning lead time study before combining them into one review cycle. If the measurement work is recurring and your technical owner can define the scope, review the service areas and contact ITVirtualAssistant to discuss a limited pilot.
Benchmark brief
What this research page must produce
A practical estimate for volume, review time, escalation rate, and assistant capacity.
A clear split between routine support, preparation work, and technical ownership.
What the measuring the age of unassigned tickets in a small helpdesk data shows
Treat this as a planning benchmark, not a universal number. Compare the benchmark against your ticket volume, SaaS stack, documentation backlog, and support risk before assigning recurring work.
The useful output is a decision about capacity, not a static statistic. If the workflow is high volume and low judgment, an IT virtual assistant can absorb coordination and upkeep. If the workflow is low volume but high risk, keep it with the technical owner and use the assistant only for preparation, reminders, and documentation.
Workflow
Recommended operating workflow
Collect a baseline
Pull the last 30 to 90 days of examples related to measuring the age of unassigned tickets in a small helpdesk, including completed work and unresolved exceptions.
Classify the work
Tag each item by routine admin, manager approval, technical decision, security risk, or vendor dependency.
Set the operating number
Use the median weekly volume and review time to decide how many assistant hours the workflow deserves.
Refresh the benchmark
Recheck the numbers quarterly so tool growth, new systems, and security requirements do not silently change the scope.
Decision rules
| Metric | Use it to decide | Manager action |
|---|---|---|
| Weekly volume | Whether the workflow is worth assigning as recurring assistant work. | Approve a weekly capacity target and backlog threshold. |
| Access sensitivity | Whether the assistant can work directly or only prepare review notes. | Set least-privilege permissions and removal dates. |
| Escalation rate | Whether the workflow is stable enough to delegate. | Rewrite the SOP when exceptions exceed the agreed threshold. |
Consolidated statistics
| Statistic | Figure | Source |
|---|---|---|
| Review window | 1 month | Study protocol |
| Age buckets | 4 | Study protocol |
| Sample cases | 20 | Study protocol |
Sources
- CISA Cross-Sector Cybersecurity Performance GoalsPractical response and monitoring goals for small organizations.
- NIST SP 800-61 Rev. 2Incident handling guidance covering triage and ownership.
- NIST Cybersecurity Framework 2.0Detect and respond outcomes relevant to queue monitoring.
- GAO Assessing Data ReliabilityCompleteness and accuracy checks for ticket exports.
- Computer Support SpecialistsOccupational context for helpdesk staffing and routing.
Measurement checklist
| Field | What to capture | Owner |
|---|---|---|
| Volume | Weekly request count, backlog age, and repeat issue patterns | Assistant prepares, manager reviews |
| Risk | Access level, customer impact, security sensitivity, and approval needs | Technical owner |
| Cadence | Daily, weekly, monthly, or quarterly review rhythm | Manager |
| Evidence | Sample tickets, logs, screenshots, and before-after examples | Assistant collects, owner validates |
| Escalation | Triggers, approval path, response time, and stop-work rules | Technical owner |
How to read the result
A good research page should leave the manager with a working number and a clear boundary: what the assistant can do every week, what the assistant can prepare for review, and what must never move without the accountable technical owner.
Source and refresh note
This planning page is dated for 2026 and should be refreshed quarterly as tool stacks, ticket patterns, and security expectations change.
How should teams use this benchmark?
Use it to define task volume, access limits, review cadence, and escalation rules before assigning work.
Get free benchmark review