What is a helpdesk? It is not a desk that helps people. It’s a team, usually at the first tier of your support model, that fixes what already has a known fix and hands everything else to someone who can find the cause. Everything below follows from that split between the band-aid and the doctor.
I wrote the first version of this in 2008, when most of the teams I talked to couldn’t say where their help desk ended and their engineering team started. That’s still the most common reason a support operation feels chaotic. I run a service delivery operation of 210 people today, 180 of them in support, and the first thing I check in any new team is whether people know which of the two jobs they’re doing. If you’re setting up a help desk, or trying to explain what yours is for, this is the version I’d hand you.
What is an incident?
An incident is anything that starts with a customer contact. An information request is an incident. So is an account update, a password reset or a report that something stopped working. Monitoring tools raise incidents too, without any customer picking up the phone, and I’ll come back to those another time.
Incidents arrive by phone first, email a close second, and chat third. Whatever the channel, they should all land in one place. For a small team that place can be a shared spreadsheet. Past a few dozen contacts a day it needs to be a real incident management tool, either something your developers built or an enterprise product. I’ve watched a team of 15 run perfectly well on a spreadsheet and a team of 60 drown in one. The tool should match the volume, not the budget conversation you had two years ago.
One rule matters more than the tool. Every contact becomes a record, even the five-second ones. If it isn’t logged, you can’t count it, and an uncounted contact can’t be staffed for. You’ll find that out the first time someone asks why the team feels busy but the numbers say otherwise.
How does incident management work at the help desk?
Your help desk reviews each incident and checks whether a solution already exists. Take an account update. The agent gets the new details, confirms the customer has passed the security questions, logs into the account, makes the change, tells the customer and closes the incident. Start to finish, that’s about as simple as it gets, and it’s the model for everything else.
A reported problem is different. The agent records every detail the customer gives, then looks for a known fix. If one exists, they pass it on and close the incident. If none does, the incident gets escalated. The easiest way to remember the line: if a band-aid exists, Tier 1 applies it. If the situation needs more than that, call the doctor.
This is where I see the first-line belief go wrong. People assume a good help desk is one that escalates less. It isn’t. A good help desk escalates cleanly. The agent who sends a well-documented incident to Tier 2 in three minutes has done the job better than the agent who spends forty minutes improvising a fix that won’t survive the next shift change.
It also means your knowledge base is part of the help desk, not an extra. If the agents have the answer every time, resolution on first contact is realistic. If they don’t, you’ve just turned your own Tier 1 team into a customer of the Tier 2 team. For a good grounding in how the formal definitions fit together, the ITIL framework is still the shared vocabulary most service organizations use.
Where does problem management start?
Problem management is where the interesting work happens. Incident work is repetitive by nature, and it drains your more skilled people if you leave them on it. If you have someone sharp who’s bored on the phones, move them into problem management. If you don’t have a problem management team, create one.
The reason is simple arithmetic. A single underlying problem is usually behind many incidents from many customers. Fix the problem once and the incidents stop. Keep applying band-aids and you pay for the same wound every day. That’s why you want your best people at this level, and why you’d normally think of it as Tier 2 or Tier 3 from a staffing and escalation point of view. Depending on your product, these are very technical people.
Their goal isn’t a patch. It’s to find out why the problem happened and fix it so it doesn’t happen again. A Tier 1 agent who closes 40 incidents a shift is doing useful work. A Tier 2 engineer who closes the problem that generated those 40 incidents has just given the help desk its shift back. I’d take that trade every time.
What should you tell customers while a problem is open?
Communication, communication, communication. Problem management is slower work, and that’s fine, but the customer-facing agents can’t be left guessing. They need to know what the issue is, what the team is doing about it and when to expect a resolution. When nobody can promise a resolution time, they must at least be given an update time. “We’ll tell you at 3pm either way” is a perfectly good answer. “We don’t know” with no follow-up is the one that fills your inbox.
I’d go further. If I had to pick one habit that separates a help desk customers trust from one they dread, it’s this. Not speed, not the knowledge base, not the tool. It’s whether the person on the phone can say something true about what happens next. How you measure it is a separate question, because Tier 1 and Tier 2 need different targets.
How do you size and structure the tiers?
Start with the incident volume, not an org chart. Count what comes in by type for a few weeks. You’ll almost always find that a handful of incident types account for most of the volume. Those become Tier 1 scripts and knowledge base articles. Everything that can’t be scripted becomes the definition of Tier 2.
From there you can decide how many tiers you actually need. Two is enough for a small product. Three earns its place when you have a genuinely specialist group, such as network engineers or developers, that you don’t want taking calls. If you want a worked example of how those levels connect to commitments, my tiered SLA matrix shows how I tie each tier to its own response and resolution targets.
Don’t let the structure harden into a wall. The best Tier 1 agents should be able to rotate into Tier 2 for a few weeks at a time. They learn why the problems happen, and Tier 2 learns what the customer actually sounds like at 8am. It’s cheap, it works, and it fixes more silos than any reorganisation I’ve seen.
A help desk that only applies band-aids is a cost. One that feeds its best incidents to a problem team that fixes causes is an investment. It’s the same people either way.
Hutch Morzaria is a Director-level CX and Support Leadership professional with 19 years of experience building global support organizations across SaaS, Fintech, and enterprise technology. He has hired dozens of support and CX leaders across his career and holds ITIL Expert certification across V3 and V4.
