A service desk that fixes things, not just logs them.
L1 to L3 technical support to ITIL practice, with incident management that restores service fast and problem management that stops it recurring. High first-contact resolution, real people who can act — available white-label for MSPs, and run inside the EU.
An IT service desk is the single point of contact between your people and IT, handling incidents and service requests to ITIL service-management practice across support tiers from first contact through to specialist engineering. It is broader than a help desk, which is reactive break-fix: a service desk also runs incident management to restore service fast and problem management to stop issues recurring, and it owns the whole relationship rather than one ticket at a time. Argus Root runs the service desk as a managed function — available white-label for MSPs — inside the EU, staffed to resolve at first contact rather than to log and pass along.
In short
- A help desk is reactive break-fix; a service desk is ITIL service management — incidents, requests, problems and the user relationship.
- Support tiers run L0 self-service → L1 first contact (resolves ~70–80%) → L2 deeper technical → L3 specialist/engineering.
- Incident management restores service fast; problem management stops it recurring — the fire brigade and fire prevention, run together.
- Pricing models: per-ticket (~$1–40), per-user (~$20–60/mo), or per-agent (~$2–4.5K/mo) — chosen to fit your volume and predictability.
- White-label lets an MSP offer full, extended-hours support under its own brand; the real measure is first-contact resolution, not ticket volume.
What is the difference between a help desk and a service desk?
The terms are used interchangeably, but they describe different ambitions. A help desk is reactive: its job is to fix what breaks, ticket by ticket, and its horizon ends at the problem in front of it. That is useful, and for some organisations it is enough. A service desk is wider in scope and longer in view. It is the single point of contact for all IT support, handling not only things that break but service requests — access, provisioning, how-to — and it works to ITIL service-management practice rather than ad hoc.
The deeper difference is that a service desk looks past the individual ticket. It notices when the same issue keeps arriving and treats that as a problem to be solved at the root, not a queue to be cleared again tomorrow. It owns the relationship between your people and IT, the knowledge that lets issues be resolved faster over time, and the service quality your users actually experience. A help desk answers "my thing is broken"; a service desk owns whether your people can get their work done, which is a different and larger responsibility.
That distinction shapes how we run it. We operate a service desk, not merely a ticket queue: incidents and requests handled to process, recurring problems driven to root cause, a knowledge base that grows, and the outcome — people working — held as the goal rather than tickets closed as the metric. The difference is felt most by the user who stops having the same problem every month.
The support tiers, from self-service to specialist.
A service desk works because it resolves issues at the lowest tier that can properly handle them, and escalates cleanly when it must. At the base sits L0, self-service: a good knowledge base and automation that let users resolve common issues — a password reset, a known fix — without an agent at all, which both helps the user immediately and keeps the queue clear for the things that need a person. L1 is first contact, the team that answers and resolves the majority of tickets, ideally seventy to eighty percent of them, on the first interaction. L2 handles the deeper technical issues L1 cannot close, and L3 is specialist or engineering-level work, often the people who actually built or run the system in question.
The discipline that makes tiering work is escalating with context rather than tossing a raw ticket up the chain. When an issue does need L2 or L3, it arrives with the diagnosis so far, the steps already tried and the user's situation attached, so the specialist starts solving rather than re-gathering. Equally important is the dashed loop in the picture: the recurring issues the desk sees are fed into problem management and fixed at the root, so the queue gets lighter over time instead of cycling the same tickets forever.
What is ITIL incident management, and how is it different from problem management?
Incident management has one priority: restore normal service as fast as possible and keep the business impact small. When something is down and a user is stuck, the job is to get them working again, not to write a thesis on why it broke. The incident is logged, categorised, prioritised by impact and urgency, worked to resolution and closed, and a major incident — one hitting many people or a critical system — triggers a heightened process with tighter communication and senior involvement. Speed of recovery is the measure.
Problem management is the other half, and it is what separates a service desk that improves from one that firefights forever. Where incident management restores service, problem management asks why the incident happened and removes the cause, so the same thing does not recur next week. The drive that failed gets a permanent fix; the stale mount that keeps recurring after reboots gets engineered out. Run incident management without problem management and you resolve the same issue endlessly; run both and the volume of incidents actually falls over time. The lifecycle below shows the two working together on a single ticket.
# INC-4821 — restore service first, find the root cause after [NEW] 14:02 user cannot access shared drive P2 [TRIAGE] 14:04 L1: known issue? check runbook KB-118 [RESTORE] 14:09 L1: remounted drive · service restored → resolved at L1 [PROBLEM] later L2: root cause = stale mount after reboot → permanent fix INC-4821 closed · first-contact resolution · CSAT 5/5 · within P2 SLA # incident = restore fast. problem = stop it recurring.
How is a service desk priced?
There are three common models, and the right one is a question of how your demand behaves rather than which looks cheapest on a slide. Per-ticket pricing, roughly one to forty dollars depending on complexity, charges for what you use and suits variable or genuinely low volumes, though it can become unpredictable if demand spikes. Per-user pricing, around twenty to sixty dollars per user per month, trades that variability for a predictable line in the budget and fits steady estates where the user count is the natural unit. Per-agent or per-FTE pricing, roughly two to four and a half thousand dollars a month for a dedicated resource, suits organisations that want named people who learn their environment rather than a shared pool.
The honest guidance is that the cheapest headline rate is rarely the cheapest outcome. A desk priced per ticket that resolves slowly and escalates often can cost more in lost time than a slightly dearer one with high first-contact resolution. We help you choose the model against your real volume, its predictability and how much you value a dedicated team that knows you — and we are explicit about the trade-offs rather than steering you to whichever model is most profitable for us.
White-label service desk for MSPs.
For a managed service provider, the service desk is both the most visible part of the offering and one of the hardest to staff well, especially once clients want extended or round-the-clock hours. A white-label service desk solves that by running behind your brand: the desk answers in your name, works in your tools, follows your processes and reports under your logo, while the operation itself stays invisible to your client. It lets you extend your hours, absorb volume spikes and offer depth across L1 to L3 without hiring and retaining the whole team yourself.
Our role in that arrangement is to be the silent partner who upholds your standards. We hold the first-contact resolution, the response times and the tone you have promised your clients, and we stay deliberately out of view so the relationship between you and them is undisturbed. For a growing MSP, it turns a capability that is expensive and slow to build into something available now and scaled to the clients it serves, while you remain the single, trusted face.
Which metrics show a service desk actually helps?
It is easy to measure a service desk by the wrong things. Raw ticket volume is the classic trap: a high number can mean a busy, productive desk or it can mean a recurring problem nobody has fixed, and the metric alone cannot tell you which. Counting tickets closed rewards activity rather than outcomes, and can even reward a desk for churning the same issue repeatedly. The numbers that matter are the ones that reflect whether your people were actually helped.
Those are first-contact resolution, the share of issues fixed on the first interaction; customer satisfaction, whether the user felt helped; and time to resolve and service-level adherence, which show speed and reliability against what was promised. Read together, they describe a desk that resolves quickly, leaves people satisfied, and reduces recurring work over time. We report these outcome metrics and use them to drive improvement — feeding recurring issues into problem management, growing the knowledge base, sharpening the runbooks — rather than presenting a ticket count that looks impressive and tells you nothing.
What we run for you.
We deliver the service desk as a managed function built to resolve, not to relay. That means a single point of contact across the channels your people actually use, first-line staff equipped with knowledge and runbooks to close the bulk of tickets directly, and clean escalation to L2 and L3 with context attached when an issue genuinely needs it. It means running incident management to restore service fast and problem management to remove recurring causes, fulfilling service requests to process, and growing a knowledge base so the desk gets better over time rather than starting cold on every repeat. Around the work sits reporting on the outcome metrics that matter, and a choice of pricing model that fits how your demand behaves.
The desk connects to the rest of what we run rather than standing alone. It shares context with our 24/7 NOC, so an outage the NOC is already resolving and the user reports arriving at the desk are one coordinated response rather than two. Security-related tickets route to managed security; issues with the systems themselves meet server management; and the governance and audit story ties into our compliance and sovereignty practice. The service desk is the human face of all of it, and we run it so contacting support means reaching someone who can actually act.
Run inside the EU, by people you can place.
Supporting users is more sensitive than it sounds. To help someone, the desk handles their data and often holds access to their systems — and where that support operates, and under whose law, is a real decision rather than a back-office detail. Routing your people's problems and credentials through an offshore operation you cannot see reintroduces exactly the exposure careful organisations work to avoid, and it shows up in the moments that matter, when an agent has access to something they should not, or cannot be held to the standard you assumed.
We run the service desk ourselves, inside the EU, with user data and the access it implies kept under EU law and a team you can actually place. It is the same principle that runs through everything Argus does — a European operator that does the work itself rather than reselling a chain of subcontractors — applied to the function your people touch most often. When the person helping your user at the other end of the line is accountable under the same rules you are, support stops being a risk you have quietly outsourced and becomes one you can stand behind.
Questions buyers ask.
What is the difference between a help desk and a service desk?
What are the support tiers, L0 to L3?
What is ITIL incident management?
How is incident management different from problem management?
How is a service desk priced?
What is a white-label service desk?
Does the service desk just log tickets, or actually resolve them?
How does the service desk fit with the NOC?
Can the service desk run 24/7?
What metrics show a service desk is actually good?
Why run the service desk inside the EU?
Give your people support that resolves.
Tell us how support works today — the channels, the volume, where tickets get stuck — and we will map what a service desk built around first-contact resolution would change, for your own users or white-label for your clients. You get a clear picture of the tiers, the incident and problem process, the pricing model that fits, and the metrics we would hold ourselves to, before any commitment.