A service desk's most common request is not necessarily its best automation opportunity. A password reset may take a few minutes of analyst attention. A less frequent access request may require several consoles, approvals and follow-ups. Ticket counts alone do not show that difference.
A useful assessment connects three things: how much work arrives, how much human effort it consumes, and how much of that effort a safe change can remove. It then checks whether the change improves service rather than simply closing tickets faster.
This method applies to internal IT desks and outsourced teams. MSPs should also separate customer environments, permissions and service commitments before treating similar requests as one automatable workflow.
Separate the clocks
Use explicit definitions before comparing reports:
| Measure | What it tells you | What it does not establish |
|---|---|---|
| Ticket volume | How often requests are recorded | The effort required for each request |
| Elapsed resolution time | Time between defined start and finish events | Continuous analyst labor |
| SLA time | Time counted under the configured service rules | Necessarily calendar time or active handling time |
| Active analyst effort | Human work across all relevant touches and analysts | Customer waiting or work outside the observed scope |
| End-user disruption | Time or impact experienced by the requester | The same thing as desk labor cost |
Check your actual report definitions. For example, Atlassian documents differences between its resolution-time reporting and time-to-resolution SLA measures, including calendars and pauses. Do not assume similarly named metrics are interchangeable. Atlassian explanation
A request can wait overnight for approval but require only 12 minutes of analyst work. Another can close in 20 minutes and consume nearly all of that time. One may be a waiting problem; the other may be an execution problem.
Worked example: the busiest category is not the largest effort pool
The following weekly assessment is invented. Its values illustrate a method, not service desk benchmarks or HourBack results. Active effort includes all analyst touches in the defined scope.
| Request category | Tickets | Average active minutes | Total active hours | Share eligible for first change | Reduction per eligible ticket | Gross capacity estimate |
|---|---|---|---|---|---|---|
| Password resets | 300 | 3 | 15 | 80% | 2 minutes | 8 hours |
| Standard access requests | 100 | 18 | 30 | 60% | 10 minutes | 10 hours |
| Ticket triage | 200 | 2 | 6.67 | 70% | 1 minute | 2.33 hours |
For access requests, the calculation is 100 × 60% × 10 ÷ 60 = 10 hours. The current 30-hour effort pool does not mean all 30 hours can disappear. Review, approvals and noneligible requests remain.
Assume the proposed access workflow needs 90 additional minutes of weekly monitoring and maintenance beyond retained per-ticket handling. Its net capacity estimate becomes 8.5 hours a week. A reset improvement with a 30-minute operating allowance estimates 7.5 hours.
Access requests look promising despite having one-third as many tickets. But that is not yet an instruction to build them first: privileged access, unclear approval rules or unreliable identity matching may disqualify a workflow until those issues are resolved.
The triage row also exposes a counting risk. If triage is already included in reset and access handling times, do not add all three rows as independent savings. Use disjoint steps or case populations when calculating a total.
Assess real work around the ticket
Start with ticket categories, but review a sample of completed cases with the analysts. Include routine requests, reopened cases, escalations and exceptions. Ask:
- Which steps happen in identity, endpoint, knowledge or business systems?
- Is a status change evidence that work happened, or just a record entered afterward?
- Are repeat contacts and reassignment counted?
- Does the analyst copy details between systems or chase missing approvals?
- Which decision requires judgment, and which follows an agreed rule?
Use existing ITSM analytics, time records, workshops or approved work observation where useful. No single evidence source sees everything. Desktop activity does not by itself prove correct authorization, and a ticket timestamp does not prove active labor. Validate the interpretation with the people doing the work.
Apply safety gates before ranking benefits
For a first access-request trial, write the boundaries in operational terms: approved catalog items only; verified requester identity; named approver or policy; least-privilege access; auditable action; failure and rollback path. Missing approval should stop fulfillment. A model's interpretation is not approval.
Use deterministic rules for stable policy checks and actions where appropriate. AI may help interpret a request, summarize context or suggest a category, while the existing ITSM and identity tools enforce permissions. Check native capabilities and existing licenses before commissioning additional components.
For an outsourced desk, determine whether the same procedure is genuinely allowed for every customer. Similar ticket labels do not guarantee identical access policies or contractual requirements.
Reusable asset: the service desk assessment worksheet
Fill this out for each candidate:
| Question | Evidence to record |
|---|---|
| What exactly is the unit? | Ticket, touch, fulfillment action or request; how duplicates are handled |
| Where is the effort? | Active minutes across analysts, systems and review steps |
| What can the first change handle? | Eligible request types and excluded conditions |
| What effort remains? | Human checks, approvals, corrections and escalations |
| What can go wrong? | Identity mismatch, excess access, wrong routing or missing audit evidence |
| What can existing tools do? | Native workflow, self-service, script, integration or AI assistance |
| Who owns it? | Service owner, technical owner and escalation contact |
| How will it be measured? | Effort per eligible request, successful completion, reopen/correction rate and user outcome |
| When should it stop? | Predefined incident or quality trigger and manual fallback |
Classify the candidate as ready for a limited trial, needs process repair, needs more evidence, or defer. Do not average a serious access-control problem into a favorable numerical score.
Measure net benefit and service quality together
Baseline a defined period and compare a similar post-change population. Record sample size, case mix, changes in staffing and major incidents. Separate eligible requests from requests actually processed through the new route.
Track active effort per successful request, manual review, reopens, corrections, routing accuracy and requester experience. “Automation ran” is not the same as “the request was fulfilled correctly.” A workflow that deflects a request into another channel has not necessarily removed demand.
Allow time for setup, training and maintenance in the business case. Remeasure after the workflow settles and whenever catalog items, policies or connected systems change. Assess the process at team level rather than turning the exercise into a ranking of analysts.
Where HourBack fits
HourBack helps connect the ticket picture with the work around it, bring analyst knowledge into the assessment and monitor whether an agreed change returns useful capacity. It can inform implementation in your existing ITSM, identity and automation tools, including tools with their own analysis features.
You can implement the recommendations internally, use your preferred partner, ask HourBack for consulting, or agree implementation support. Explore the service desk assessment and sample reports. To choose evidence methods, see task mining, process mining and manual mapping.