research
Measuring how often tickets close without user confirmation
A sampling method for finding tickets marked resolved before the user confirmed the fix, and for comparing that rate with the reopen data.
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
A ticket can be marked resolved while the user is still waiting for the problem to disappear. The closure looks efficient in the report, but the user either reopens the ticket or stops reporting the issue. This study measures the share of closed tickets that lack a user confirmation and compares it with the reopen rate. The result shows whether the service desk is closing work or closing records.
Question and scope
This study asks what share of closed tickets had a recorded user confirmation, which request types are most likely to close silently, and how the silent-close rate relates to reopens. The unit is one ticket closed during a declared month, and the population is every resolved or closed ticket in the service desk. The result describes that desk and that period, not the performance of an individual technician. Freeze the month and the ticket source before sampling.
Include incidents, service requests, and access requests that reached a resolved state. Exclude tickets that were cancelled by the requester, duplicates merged into another ticket, and test records. Record the channel and the assignment group so the sample can be checked against the monthly report. State whether the desk uses one status for resolved and closed or two separate statuses. Record the ticket source because a merged record can inherit the wrong status.
Define the close event
Define the close event as the moment the ticket entered its final state, not the moment the technician finished working. Record whether the system closes the ticket automatically after a timeout, because an automatic close is not a user confirmation. Note the last outbound message and the last inbound message before the close. The gap between them is the evidence the study needs.
Distinguish a user's explicit reply from an inferred confirmation. A reply that says thanks is explicit, while a message that asks a new question is not. An automated survey response counts only if the user chose the positive option. Record the type rather than a simple yes or no, because the types carry different weight.
Build the ticket frame
Export the ticket identifier, the request type, the priority, the assignment group, the technician, the created date, the resolved date, and the closed date. Add the message count and the direction of the last message. Include the reopen flag and the reopen date where the system stores them. Reconcile the export total with the service desk's monthly report. Save the query and the export date with the sample so the frame can be rebuilt.
Normalise request types into a small set such as incident, service request, access, and hardware. Keep the original type text so the mapping can be reviewed. Note any ticket that moved between groups, because a transfer can hide the owner who closed it. Record the export date and the report used for the count.
Sample closed tickets
Select a random sample of at least fifty closed tickets across request types and groups. Read the final messages rather than relying on the status field. Record whether the user confirmed the fix, asked a follow-up question, or never replied. Use two reviewers for a subset and compare their classifications. A sample drawn only from one week can miss month-end patterns.
Include tickets closed by automation and tickets closed after a long period of inactivity. These are the cases most likely to be counted as confirmed when they are not. Record the number of days between the last user message and the close. A long silent gap is a strong signal that the closure was administrative rather than user-verified.
Separate confirmation types
Classify each ticket as explicit confirmation, positive survey, no response, negative response, or auto-closed. Report the share of each type so the reader can see the composition behind the headline rate. Do not collapse no response and negative response into one category, because they lead to different fixes. A negative response is a quality problem, while no response may be a communication problem. A positive survey response is still weaker evidence than a direct reply from the requester.
Record the time between the resolution note and the close for each type. A ticket closed minutes after the resolution note rarely gives the user time to respond. A ticket closed after seven days of silence may have followed a clear request for confirmation. The timing helps distinguish an impatient close from a policy that closes on a timer.
Estimate the silent-close rate
Divide the number of tickets without explicit confirmation by the sampled total and present the result as a range. Show the rate for each request type and each assignment group. Report the sample size beside the rate so a small group is not overinterpreted. Round the result to a level that reflects the sampling uncertainty.
Apply the rate to the monthly closed count only as an estimate, and show the calculation. Do not present the estimate as a count of specific tickets, because the sample identifies a pattern rather than every case. Keep the raw sample in an appendix. The owner should be able to see how the headline number was produced. Show the arithmetic in a footnote rather than hiding it in a spreadsheet.
Compare against reopen data
Compare the silent-close rate with the reopen rate for the same month and request types. A high silent-close rate with a low reopen rate may mean users have stopped reporting the problem. A low silent-close rate with a high reopen rate suggests the confirmation was given too early. The two measures together are more useful than either alone.
Check whether reopened tickets are linked to the original or counted as new tickets. A desk that creates a new ticket on every reopen will understate the reopen rate. Reconcile a sample of reopens with the original closure messages. Record the linking method so the comparison is honest.
Report to the owner
Lead with the silent-close rate, the sample size, and the request types most affected. Show one example of a ticket closed without a reply and one example of a clear confirmation. Explain how the desk's status rules and auto-close policy affect the number. Keep individual technician names out of the headline. Use one chart that separates confirmed, silent, and negative closures.
Ask for a specific decision such as requiring a user reply before closure, changing the auto-close timer, or adding a confirmation step to the ticket template. Name the owner and the review date. If the decision is to keep the current policy, record the reason and the accepted risk. A documented decision is better than an unexplained metric.
Limits and next use
The study measures the messages recorded in the ticket system. It does not capture a confirmation given by phone or in a corridor, and it cannot tell whether the user's problem truly disappeared. It also depends on the desk's status rules and the completeness of the export. State those limits so the rate is read as a lower bound on unconfirmed closures.
Repeat the sample after a policy change and compare the same request types. If the silent-close rate falls but reopens rise, the new confirmation step may be closing tickets before the fix is stable. That is a different problem from a communication gap. Record the change date so the two samples are not mixed.
Pilot the check
Run the check on one month and one assignment group before applying it to the whole desk. Read every ticket in the pilot rather than sampling, so the classification rules can be tested against real messages. Ask the technicians to review a handful of the classifications. Adjust the rules before expanding the sample. Read the messages slowly enough to notice a question hidden in a thank-you note.
Keep the pilot short and publish the result with its limits. Use it to agree on what counts as confirmation, not to rank people. Once the definition is stable, move to a monthly sample of fifty tickets. The check should take less time each month as the rules become familiar.
Sources and next step
Use the NIST Cybersecurity Framework 2.0 and the CISA Cross-Sector Cybersecurity Performance Goals as primary references for the recovery, software inventory, service desk, DNS, and endpoint protection 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 endpoint encryption coverage study and the public DNS change authority audit 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 how often tickets close without user confirmation 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 how often tickets close without user confirmation, 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 |
|---|---|---|
| Sample floor | 50 tickets | Study protocol |
| Confirmation types | 5 | Study protocol |
| Comparison measures | 2 | Study protocol |
Sources
- NIST SP 800-53 Rev. 5Incident handling and audit record controls for service desk records.
- CISA Cross-Sector Cybersecurity Performance GoalsIncident response and reporting goals relevant to ticket closure.
- NIST Cybersecurity Framework 2.0Respond and improve outcomes for incident and request handling.
- GAO Assessing Data ReliabilitySampling and classification checks for operational evidence.
- Computer Support SpecialistsOccupational context for helpdesk and support work.
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