LO
Get told when a verified record lands on this occupation →
IT support specialist / helpdesk
The first person you reach when something at work has stopped working: resets it, explains it, or works out that what you said happened is not what happened.
This is not a probability of losing your job. It combines how much of the role's task load is exposed to automation with how far adoption has actually gone — useful for comparing occupations on one consistent basis, and for nothing else.
Covers internal end-user support — service desk, desktop support, first and second line. It does not cover infrastructure engineering or SRE, which have their own page, and it does not cover consumer product support, where the caller is a customer rather than a colleague and the economics are different. In outsourced service desks the ticket volume target changes this job more than any tool does.
The evidence base holds verified records for other occupations, but not one for this one yet. Until it does, the analysis below is reasoning about task structure and known technical capability — for this job in particular it is not backed by traceable sources, and we would rather say so than cite things we have not verified. An empty section here is a gap in our coverage, not a finding about the work.
What is actually changing#
The unit of analysis is the task, not the job title. A role is not replaced — its task mix shifts.
Is this your job? Say so and this page narrows to your share of it.
A job title is a bundle of tasks bought together, and no two people hold the same bundle. Nothing is sent anywhere — it stays in this browser.
The ticket you have seen four hundred times
Automating≈ Platform inferencePassword resets, account unlocks, access requests, the printer, the VPN — the same twenty problems that make up most of the queue.
This is the single clearest automation target in an office, and it had already been half-automated by self-service portals before any model arrived: the problem is narrow, the resolution is a known sequence, and success is machine-checkable — the account unlocks or it does not. That last property is what lets a system retry without a person watching, which is the property that separates tasks that moved from tasks that did not.
Removing the easy tickets does not leave a smaller version of this job, it leaves a harder one: what remains is the queue's long tail, where the user's description is wrong and the fault is in the gap between two systems. Teams sized on ticket volume that automate the volume and keep the sizing end up with the same headcount doing work the metric no longer describes — and appraisals built on tickets-closed start measuring the wrong thing the week the tool lands.
Finding out what actually happened
Still human-led≈ Platform inferenceReconstructing the real sequence of events from a report that is confident, well-meaning and wrong about a key detail.
The diagnostic input here is not the ticket, it is the correction of the ticket — asking the question that reveals the user did something they did not mention because it did not seem relevant. A tool given the same written report inherits the same wrong premise, and this occupation's whole skill is refusing to accept it.
Human-led here is about who can solve it, not about how many are employed to. A team that automates the easy half and shrinks by that half leaves the hard half to fewer people, and the hard half is where the burnout in this occupation has always been. The task surviving is not the same as the post surviving.
Going to the desk
Still human-led≈ Platform inferenceThe physical half: hardware swaps, cabling, the meeting room that will not project, setting up the new starter.
Nobody is automating a hardware swap in an office, and the reason is economics rather than difficulty — the volume in any one building is far too low to justify a machine. What has actually reduced this task is not automation at all: remote work and cloud services removed the desk rather than the person who walks to it.
This half being safe from automation is what makes the whole occupation look safer than it is, because the physical half is small and shrinking for reasons unrelated to technology. Measure the ratio in your own week before reading any reassurance into it — in most organisations it is a minority of the hours and falling.
Which technologies matter here#
Four separate signals. They are deliberately not added together — a job exposed to two technologies is not twice as exposed.
How it got here#
The index is not a static number. This is where it would have sat at each capability checkpoint since ChatGPT — reconstructed, and labelled as such.
The steepest curve in the technology group, and the mechanism is the cleanest on the site: the repeat half of a service-desk queue is a narrow problem with a known resolution sequence and a machine-checkable outcome — the account unlocks or it does not — so a system can retry unattended. The climb starts before generative models because self-service portals had already taken the password half. It flattens where the long tail begins: a user's description that is confident and wrong about a key detail gives a tool the same false premise it gives a person, and this occupation's whole skill is refusing it. Read the height as the easy tickets, and note what the curve cannot show — the hard half being left to a team sized on the volume that was automated.
A flat line is not a forecast of safety. It says which tasks automation has reached so far — the occupations that moved least here are the ones where the constraint is physical or regulatory, and both of those can change.
Recent changes#
No verified events recorded yet.
This section will fill from the monitoring pipeline as events are collected, de-duplicated, graded and linked to the tasks above. An empty list here means we have not verified anything — it does not mean nothing is happening.
"We found no news" is not the same as "you are safe."
What this means for you#
This has been one of the main doors into technology work for thirty years, and it is the door with the clearest automation mechanism pointed at it — the easy tickets are the ones that hire beginners. The route through is unchanged in shape but shorter in time: get to the tickets nobody can script, and get named on the tooling that closes the rest, because operating the automation is the version of this job that is being funded.
Your organisation will size the team on ticket volume and then automate the volume. The argument that works is not that the tickets are hard, it is that the metric stopped describing the work — and it has to be made before the headcount is set, because afterwards you are arguing against a number that already looks good.
Your options#
Four directions, each with its real constraints and one thing you can test this week. Continuing as you are is a legitimate choice — it just has to be a chosen one.
Own the automation instead of competing with it
Someone has to decide which tickets the system may close by itself and what it does when it is unsure, and the only person who knows is whoever worked the queue.
It is a different job with a different title, and in many organisations it sits in a team you have to transfer into rather than grow into.
Take last month's tickets and sort them into ones with a machine-checkable resolution and ones without. The first pile is the roadmap; the second is your job.
Cross into security operations
The desk is the most targeted entry point in most organisations, so you already have the context a security team spends months acquiring: what a normal request from this company looks like.
Security roles usually want a certification before they will interview, and the on-call is heavier than the desk's.
Write down every request this month that felt off, whatever the outcome. If the list is not empty, that instinct is the thing the other team is hiring for.
Common questions#
The repeat half of the queue has the clearest automation mechanism of any office task: narrow problem, known resolution sequence, and success that a machine can check — the account unlocks or it does not, so a system can retry unattended. The long tail does not, because it starts from a user's description that is confident and wrong about a key detail. What that produces is not a smaller version of this job but a harder one, and teams sized on ticket volume that automate the volume usually discover the metric stopped describing the work.
No date. Sort last month's tickets into two piles: the ones where a machine can tell whether the fix worked, and the ones where only a person can. The first pile is what the tooling will take and the ratio between the piles is your exposure — you can compute it this afternoon, and it is far more informative than any industry figure because it is about your queue and not an average of everyone's.
A large share, and worth noticing that this happened before any model arrived — password self-service has been standard for years. That matters for reading the current wave correctly: the easy tickets were already being taken, and what language models add is handling the ones where the user cannot describe the problem in the portal's categories. The direction is the same as it has been for a decade; what changed is the pace.
Safe from automation, yes — nobody is building a machine to swap a laptop, and the reason is volume rather than difficulty. But it is a small and shrinking share of the hours, and what shrank it was not technology either: remote work and cloud services removed the desk rather than the person walking to it. Measure what share of your own week it actually is before treating it as a plan.
Method and sources#
- Assessment date
- 2026-09-14
- Basis of the task judgements
- 0 evidence-backed · 4 platform inference · 0 not enough evidence
- Verified events
- 0