Skip to main content

IT Help Desk

Ask an IT director what their team is working on and you will usually get a roadmap. Ask what the team actually did last week and you get password resets, a laptop that would not join the VPN, and someone locked out of MFA before a client call. The gap between those two answers is the whole argument for outsourcing the front line, and the useful question is not whether to do it but exactly where to draw the line.

Aureon · Contact Center & IT Help Desk

An internal IT team and an outsourced help desk are not competing for the same work. They are competing for the same calendar. Every hour spent on a password reset is an hour not spent on the migration, and the migration is the reason the team was hired. Outsourcing the front line is mostly a decision about which of those two things you want your salaries buying.

What to outsource, and what to keep

The Split

Three buckets, and the boundaries matter more than the labels. Get them wrong in either direction and you either escalate everything or you hand somebody else decisions they should not be making.

Send it out

Tier 1: outsource this

Password resets · Account provisioning · Access requests · MFA lockouts · Known device fixes

This is the easiest call in the whole exercise. Password resets, account provisioning, access requests and MFA lockouts are high-volume, well-documented, and completely disconnected from anything strategic. They are also urgent in a way that makes them impossible to batch: a locked-out employee is not working, so the ticket jumps the queue regardless of what your engineer was doing. Handing this out does not lose you anything, because there is nothing here that benefits from being done by someone who also knows your network architecture.

Where the boundary usually goes wrong

Two failure modes, and they look nothing alike. The first is drawing the line too high, keeping Tier 2 in-house because it feels technical, which leaves your engineers interrupted all day by application faults and defeats most of the point. The second is drawing it too low, pushing decisions out with the tickets, so a provider ends up quietly setting access policy because nobody wrote down who was allowed to approve what.

The line is not really about difficulty. It is about whether the work resolves something or decides something.

When a ticket should move to Tier 2

Escalation rules tend to get written as a list of issue types, which stops working the moment something arrives that is not on the list. Three tests hold up better.

Is there a documented fix?

If yes, it is Tier 1 work regardless of how technical it sounds. If no, it needs someone who can investigate rather than follow. This single test resolves most escalation arguments, and it has the useful side effect of turning every genuine escalation into a documentation gap somebody can close.

Does it affect one person or many?

One user with a broken application is a Tier 2 diagnosis. Fifteen users with the same broken application in the same hour is an incident, and it should route straight past the queue to whoever owns that system. Volume changes the category, not just the priority.

Is this a fix or a decision?

Granting someone access to a system they are already approved for is a fix. Deciding whether they should be approved is not, and no amount of technical skill makes it a help desk call. This is the test that keeps outsourced tiers from quietly drifting into policy.

The rule
If a whole category of ticket keeps escalating, that is a training or permissions gap at Tier 1, not evidence you need more people at Tier 2.

What a handoff has to carry

Whatever the employee already explained, and whatever the first agent already tried, has to travel with the ticket. This gets diagnosed as a tooling problem constantly. More often it is a habit problem: agents working under handle-time pressure write two-line notes, and the next person repeats diagnostics the user already sat through once. From the employee's side that is indistinguishable from nobody having read the ticket at all.

The same applies at the boundary with your internal team. When something does reach your engineers, it should arrive with steps to reproduce, what has been ruled out, and a name on the provider side who still owns the relationship. Otherwise you have not removed work from your team, you have just added a delay before they start it.

What your internal team gets back

The business case usually gets written as cost per ticket, which is the least interesting number available. Two things matter more.

Uninterrupted time, not just fewer tickets

Ticket volume understates the damage because it counts the work and ignores the interruption. An engineer pulled out of a migration for a ten-minute lockout does not lose ten minutes. They lose the ten minutes plus however long it takes to get back into what they were doing, and that is assuming nothing else arrives in the meantime. A day with six small interruptions is not a day with fifty minutes of support work in it. It is a day with no deep work in it at all.

Salary mix

When senior engineers spend their day on Tier 1, you are paying senior rates for routine work while the projects that justified the headcount slip another quarter. That is the real cost, and it does not show up anywhere in a ticket-cost calculation. It shows up in a roadmap that keeps moving.

On the employee side, Nexthink's IT downtime research puts the loss at roughly two weeks per employee per year waiting on IT problems, which works out near a hundred hours going to issues that mostly should take minutes. Multiply that across a workforce and a slow help desk stops being an IT budget line and becomes a productivity one.

Worth measuring first
Before deciding what to outsource, spend two weeks tagging tickets by tier. Most teams substantially underestimate what share of their volume is Tier 1, and the number tends to settle the argument without anyone needing to win it.

This is usually a co-sourced model

Outsourcing the front line rarely means replacing internal IT, and it should not. The common arrangement has a provider absorbing Tier 1 and most of Tier 2 while your team keeps architecture, projects and security, with a defined path for the small percentage that genuinely needs them. Agreeing that path in advance, including who owns the employee relationship while something is being fixed, is most of the difference between an outsourced help desk that works and one that becomes another queue to chase.

Help Desk Readiness Checklist

The Checklist

Fifteen questions across the five areas that decide whether your help desk is supporting the business or quietly draining it. Tick the ones you can answer without going and asking someone, and the score updates as you go. Use it yourself or share it with your team.

0 of 15 answered confidently

Tick what you can answer without checking. The blanks are the gaps.

Response Times

Do you have a response SLA that somebody actually reports against?

An SLA nobody measures is a paragraph in a document. It is not a commitment to anyone waiting.

How long does an employee really wait on a locked account?

Not the target. The number from last month. A locked account stops productive work cold, so this is the most expensive wait you have.

Do your targets separate "cannot work at all" from "mildly annoying"?

One SLA across every severity means you are over-serving trivia and under-serving the person who cannot log in.

After-Hours Coverage

Who helps your night shift or your remote staff at 10pm?

If the honest answer is whoever they can reach, you have a shadow help desk staffed by whoever picks up.

Do you know what share of tickets arrive outside headquarters hours?

Remote workers, shift patterns and time zones move this number more than most teams expect.

Is your internal team the escalation path of last resort at 2am?

Coverage that depends on an engineer's phone is not coverage. It is an attrition plan.

First-Contact Resolution

What share of tickets close without ever touching your internal team?

The single number that tells you whether a front line is absorbing work or just forwarding it.

Do you know what percentage of your volume is genuinely Tier 1?

Most teams guess low. Two weeks of tagging tickets by tier usually settles the outsourcing argument on its own.

Can the front line reset, provision and unlock without asking your team?

Authority is what separates a help desk from a message-taking service. Knowledge alone does not close a ticket.

Escalation Paths

Is what gets escalated written down, or does it depend who is on shift?

Undocumented rules produce inconsistent routing, and inconsistency is what employees experience as unfairness.

When a ticket reaches your engineers, does it say what was already tried?

Without that, you have not moved work off your team. You have added a delay in front of it.

Who decides an access request should be approved, as opposed to fulfilled?

Fulfilling is a help desk job. Approving is a policy decision, and it should never drift out with the tickets.

Project Time Lost to Tickets

Could you say what share of your IT team's week went to tickets?

If nobody has measured it, the roadmap is being funded with whatever is left over after interruptions.

How many times a day does a senior engineer get pulled off project work?

Six ten-minute interruptions do not cost an hour. They cost the whole day's deep work.

Which project slipped last quarter, and was ticket volume the reason?

Everyone knows which one. Whether support volume caused it is the part nobody writes down.

Frequently asked questions

Outsource Tier 1 first: password resets, account provisioning, access requests, MFA lockouts and device problems that have a known fix. These are high volume, well documented, urgent enough that they interrupt whatever your engineers were doing, and completely disconnected from anything strategic. Most organizations then move the majority of Tier 2 as well, meaning application faults and configuration problems that need diagnosis. What stays in-house is anything that sets direction rather than resolves an incident.

The difference is who is being helped. An IT help desk supports your own employees with the technology they use to do their jobs, so passwords, devices, access and business applications. Technical support is customer-facing and helps the people who buy your product use it. The two need different training and different escalation paths, because a help desk agent needs to know your internal environment while a technical support agent needs to know your product. They can be scoped separately or together.

It varies enough by organization that a borrowed benchmark is not much use, and most internal teams significantly underestimate their own figure. The reliable way to find out is to tag every ticket by tier for two weeks and count. Teams that do this are routinely surprised by how much of the queue is passwords, access and lockouts, and the number tends to settle the outsourcing discussion more effectively than any argument about principle.

Usually yes, provided the provider is genuinely trained on your environment rather than working from a script. Tier 2 covers application faults, configuration errors and problems with no documented fix, which is where judgment starts. The test for a real Tier 2 is whether they can diagnose something nobody has written up yet. If they cannot, everything will escalate back to your internal team anyway and you will have added a step rather than removed one.

Anything that decides something rather than resolves something. Architecture, projects and migrations, security posture, vendor selection, and the policies governing what the help desk is permitted to do. The practical test is fix versus decision: granting access to someone already approved is a fix and belongs at Tier 1, while deciding whether they should be approved is a policy call that should never drift out with the tickets. Freeing your team to do this work properly is the point of outsourcing the rest.

No, and an arrangement built that way tends to fail. The common model is co-sourced: a provider absorbs Tier 1 and most of Tier 2 while your team keeps architecture, projects and security, with a defined path for the small percentage that genuinely needs internal expertise. Agreeing that path in advance, including who owns the employee relationship while an issue is being worked, is most of the difference between a help desk that works and another queue your team has to chase.

More than ticket counts suggest, because the count measures the work and ignores the interruption. An engineer pulled off a migration for a ten-minute lockout loses the ten minutes plus the time it takes to get back into the task, so a day with six small interruptions can contain no deep work at all. On the employee side, Nexthink's IT downtime research puts the loss at roughly two weeks per employee per year, close to a hundred hours spent waiting on problems that should take minutes.

Track the share of tickets that close without ever touching your internal team, because that is what the arrangement was bought to change. Alongside it, watch how long employees actually wait on the highest-impact requests such as locked accounts, and how often a category of issue escalates repeatedly, since a whole category escalating points at a training or permissions gap rather than a staffing shortage. Cost per ticket is the least informative measure of the three.

Related
This covers supporting your own employees. If the people contacting you are customers using your product, the tiers work differently and Tier 3 enters the picture. Technical Support Tiers Explained covers that side.

Want to know what share of your queue is Tier 1?

Get a free help desk assessment. We'll walk the checklist with you and show you where your team's week is going.

Build Your Help Desk Plan