The short answer
A help desk fixes problems. Someone is stuck, they ask, the help desk answers and closes the ticket.
A service desk manages services. It still fixes problems, but it also handles requests for new things (access, equipment, software), tracks incidents that affect many people, and connects all of that to how IT delivers and changes services.
Put another way: every service desk contains a help desk, but not every help desk needs to become a service desk.
Customer support teams almost always run a help desk. Internal IT teams often start with a help desk and grow into a service desk as the company and its compliance needs grow.
What a help desk is
A help desk is a single point of contact for questions and problems. Its job is to restore the person to a working state, quickly.
Typical help desk work:
- A customer cannot log in and needs a password reset link.
- A shopper asks where their order is.
- An employee reports that the printer on the third floor jams.
- A user found a bug and wants to know if there is a workaround.
The core tools are a shared inbox or ticketing system, a knowledge base, canned replies, basic routing and reports on response time and satisfaction.
The success measures are simple: how fast you reply, how fast you resolve, and whether the person was happy with the answer.
Where help desks work well
Help desks fit teams whose work is mostly reactive and conversational. That covers most customer support teams at SaaS and e-commerce companies, and IT teams at smaller companies where one or two people look after everything.
They also fit when you do not need formal approvals. If an employee asks for a new monitor and the office manager just orders it, you do not need a request catalog with an approval chain.
What a service desk is
A service desk is a help desk plus a structured way of delivering IT services. The ideas mostly come from ITIL, a widely used framework for IT service management, but you do not need to adopt all of ITIL to run one.
A service desk usually separates several kinds of work:
- Incidents: something that worked has stopped working. The aim is to restore service fast.
- Service requests: someone wants something standard, such as software access, a laptop or a new mailbox. The aim is to fulfil it through a known process, often with approvals.
- Problems: the underlying cause behind repeated incidents. The aim is to remove the cause, not just the symptom.
- Changes: deliberate modifications to systems, reviewed for risk before they happen.
It also tends to include a service catalog (a menu of what IT offers), an asset inventory and links to change management.
Where service desks work well
Service desks fit internal IT at companies of a few hundred employees and up, where many teams depend on shared systems, access needs approval, and auditors ask who approved what.
They also fit managed service providers that deliver IT to several client companies under contract, with agreed service levels per client.
Help desk vs service desk side by side
The table sums up the main differences. Treat it as a guide to the typical case, since plenty of teams sit somewhere in between.
| Aspect | Help desk | Service desk |
|---|---|---|
| Main goal | Answer questions and fix problems | Deliver and support IT services end to end |
| Typical users | Customers, or employees at a smaller company | Employees across a larger organization |
| Work types | Mostly incidents and questions | Incidents, service requests, problems, changes |
| Intake | Email, chat, web form | Portal with a request catalog, plus email and chat |
| Approvals | Rare | Common for access and purchases |
| Measures | First response, resolution time, satisfaction | The same, plus SLA attainment per service and request fulfilment |
| Setup effort | Hours to days | Weeks, often with process design |
| Related frameworks | None required | Often inspired by ITIL |
Where the two overlap
The overlap is bigger than the difference. Both need:
- One queue where every request is a ticket with an owner and status.
- Routing so the right team sees the right request.
- Service level targets with warnings before they are missed.
- A knowledge base, public for customers or internal for employees.
- Reports on volume, response time and resolution time.
- Automation for routine requests.
That is why many teams run a service desk on help desk software and add the few service desk processes they actually use, instead of buying a heavy IT service management suite.
A simple test: which one do you need
Answer these questions for your own team. Count the yes answers.
- Do more than a quarter of your requests ask for something new (access, hardware, software) rather than reporting a problem?
- Do some of those requests need a manager or system owner to approve them?
- Do you have to show an auditor who approved access to a given system?
- Do outages regularly hit many users at once, so you need to link many tickets to one incident?
- Does IT make changes to shared systems that other teams need warning about?
- Do you keep an inventory of laptops, licenses or devices tied to people?
Zero to one yes: run a help desk. You will move faster and your team will use the tool.
Two to three yes: run a help desk with a few service desk habits, such as request forms with required fields, an internal knowledge base and separate SLA policies for incidents and requests.
Four or more: you need service desk processes. Choose a tool that supports them without forcing you to adopt all of them on day one.
Common mistakes when choosing
Buying a service desk for a support team
A customer support team at a SaaS company does not need change management or an asset inventory. Buying a full IT suite for them means months of configuration and forms nobody fills in.
Staying on a help desk too long in IT
The opposite also happens. An IT team at a growing company keeps handling access requests through free-text emails, approvals happen in chat, and nobody can show who granted access to the finance system. When the first audit comes, the team rebuilds everything under pressure.
Treating the label as the decision
Vendors call almost everything a service desk or a help desk depending on who they sell to. Ignore the label. List the work types you handle and the processes you must prove, then check whether the tool supports those.
Copying a framework wholesale
ITIL is a set of practices, not a checklist to finish. Take the parts that solve a problem you have: incident vs request separation, a simple catalog, basic change notices. Skip the rest until you need it.
Two example teams
Picture a support team of twelve agents at an online store. Most tickets ask about orders, returns and payment. They need a shared inbox, routing by keyword and customer tier, SLA targets and a help center. That is a help desk.
Now picture an IT team of eight looking after 900 employees. About half of the tickets are requests: new starters, software licenses, VPN access. Access to the finance system requires the finance director to approve. That team needs service desk habits: request forms, approvals and separate targets for incidents and requests.
Both can run on the same kind of software. What differs is configuration, not the category printed on the box.
Where AI fits in either model
AI changes both models in the same place: the routine front line.
For a help desk, that means drafting answers from the knowledge base and resolving common questions such as "where is my order" or "how do I reset my password".
For a service desk, it means classifying tickets as incident or request, filling in the right form fields, answering how-to questions from internal articles, and in some cases looking up account status through an API before replying.
In both, the rules are the same: the team decides which intents the AI may resolve, sets a confidence threshold, and gets a clean handover with a summary when the AI is unsure. Our guide on ai ticket auto resolution covers where to start.