The Service Desk

What the service desk does

Wednesday, 08:40, at Kestrel Energy. A billing clerk cannot print invoices, a new hire needs access to the customer database, a field engineer's tablet will not sync, and someone wants to know whether the virtual private network (VPN) outage email was a phishing test. All four contact the same place.

The service desk is the team, and the set of channels, through which users reach the IT organization for anything they need: reporting that something is broken, asking for something, or asking a question. Its job is to capture every contact, resolve what it can straight away, route the rest to the right people, and keep the user informed until the matter is done.

The idea behind it is a single point of contact (SPOC): users should not need to know whether their problem belongs to the network team, the billing application team or the cloud provider. They contact one place, and the IT organization sorts out the rest. Without a SPOC, users phone the colleague they know in IT, work is invisible and unrecorded, and the same few helpful people are interrupted all day.

What it handles

Contacts at the service desk fall into three broad kinds:

• Incidents: something is broken or degraded. The printer error and the tablet that will not sync are incidents. See Incident management.
• Service requests: a user asks for something normal that is already on offer, such as access, a new laptop or a password reset. Nothing is broken. See Service request management.
• Questions: "How do I share a calendar?", "Is the portal down or is it me?" Often answered from the knowledge base.

Telling these apart matters because they follow different paths: an incident is about restoring service as quickly as possible, while a request follows a predefined, often pre-approved fulfillment path. Reports about suspicious emails or lost devices are also captured here, then handed to the security team as possible security incidents; see Incident response.

Channels

Users reach the desk in different ways, and each channel suits different situations:

A self-service portal is a website where users can log incidents, order items from the service catalog, follow their tickets and search knowledge articles without contacting an agent. It works when using it is faster than calling. Virtual agents, chatbots that answer in natural language and can trigger simple automations, are covered in AI in service management.

Whatever the channel, every contact becomes a ticket in the same tool. Common IT service management (ITSM) tools include ServiceNow, Jira Service Management, TOPdesk and Freshservice; they differ in scale and price but share the same basic ideas.

Support tiers and escalation

A support tier (or line) is a level of support with its own skills and responsibilities. Most organizations use three, plus self-service and external suppliers:

• Self-service (sometimes called tier 0): the portal, knowledge articles and automated fixes.
• First line: the service desk agents. They register, diagnose, resolve common issues with known solutions, and route the rest.
• Second line: specialist teams, such as network, desktop, the billing application or the cloud platform team.
• Third line: deep experts, developers and architects who can change code or design.
• Suppliers: the cloud provider, the colocation data center, the telecom carrier or a software vendor, engaged through their own support processes.

Escalation

Escalation means involving additional people because the current handler cannot resolve the matter in time on their own. It is not a failure; it is how the tiers are meant to work. There are two kinds, and they often happen together:

• Functional escalation passes the ticket to a team with more specialist knowledge or access. Amara at the service desk cannot fix the billing print service, so she assigns the ticket to the billing application team.
• Hierarchical escalation informs or involves people with more authority, because a decision is needed, resources must be freed up or a target is about to be missed. When the month-end billing run is at risk, the service desk manager is told, and she asks the application manager to pull a second engineer onto it.

Good escalation rules are written down: which categories go to which team, and at what point (time, impact, an executive or a regulatory deadline) managers must be informed. Most ITSM tools can trigger these automatically.

Shift-left and self-service

Shift-left is the deliberate effort to resolve work at a lower, earlier tier: what needed the second line becomes something the first line can do, and what the first line does becomes something users can do themselves or that happens automatically. In the diagram, that is a move to the left.

Why it matters:

• Users get help faster: no handover, no queue.
• Each step to the left is cheaper: a self-service fix costs a fraction of a phone call, and a phone call a fraction of an engineer's hour.
• Specialists spend their time on the work only they can do, including fixing root causes.

Shift-left runs on knowledge. When Joost in the billing team solves the print-service issue, he writes the diagnosis and the fix as a knowledge article, so the next time the service desk can handle it in five minutes. The page Knowledge, supplier and relationship management explains how a knowledge base is kept useful. Shifting left also means giving the first line safe permissions and tools, such as restarting a print service through a tested script rather than logging into the server.

The life of a ticket

A ticket is the record of one contact or piece of work in the ITSM tool: what was reported, by whom, how it was classified, who worked on it and what was done. Tickets are how work becomes visible, measurable and transferable; an issue solved in a hallway conversation never happened, as far as the organization's data is concerned.

State names differ between tools, but most follow this pattern:

Resolved is not closed. The person who fixed something believes it is fixed; only the user can confirm that they can work again. Many organizations close resolved tickets automatically after a few working days without a response, and a reply such as "still broken" reopens the ticket.

Ticket        INC-20419
Opened        2026-09-30 08:42 via phone
Caller        Lucía Romero, Billing
Service       Billing system
Summary       Cannot print invoices: "print service unavailable"
Impact        Medium (billing team, 12 people)
Urgency       High (month-end run today)
Priority      P2
Assigned to   Billing application team (second line)
Status        Resolved, awaiting confirmation

Work notes
08:42  Amara (SD)    Same error for a colleague; KB-0391 does not apply.
08:56  Amara (SD)    Functional escalation to Billing application team.
09:05  Amara (SD)    Service desk manager informed: month-end run at risk.
09:31  Joost (Bill)  Print service hung on bill-app-02.example.com after
                     last night's patch. Restarted. Problem PRB-0231 raised.
09:40  Joost (Bill)  Test print OK. Resolved; waiting for Lucía to confirm.

First contact resolution and other measures

First contact resolution (FCR) is the share of contacts that are resolved during the first interaction, without a callback, a handover or a second contact by the user. It is popular because it reflects what users value most: one contact, problem solved. Some organizations leave out contacts that could never be resolved at first contact, such as a hardware order, so read the definition before comparing numbers.

# One morning of contacts at the Kestrel service desk.
# (ticket, channel, resolved during the first contact?, handling minutes)
contacts = [
    ("INC-20417", "phone", True, 6),
    ("INC-20418", "chat", True, 9),
    ("REQ-2811", "portal", False, 4),
    ("INC-20419", "phone", False, 14),
    ("INC-20420", "phone", True, 11),
    ("INC-20421", "chat", True, 7),
    ("INC-20422", "email", False, 5),
    ("INC-20423", "phone", True, 8),
    ("REQ-2812", "chat", True, 3),
    ("INC-20424", "phone", False, 19),
]

resolved_first = sum(1 for _, _, first, _ in contacts if first)
fcr = resolved_first / len(contacts)
average = sum(minutes for *_, minutes in contacts) / len(contacts)
print(f"First contact resolution: {resolved_first}/{len(contacts)} = {fcr:.0%}")
print(f"Average handling time:    {average:.1f} minutes")

print("\nPer channel:")
for channel in sorted({channel for _, channel, _, _ in contacts}):
    rows = [c for c in contacts if c[1] == channel]
    first = sum(1 for c in rows if c[2])
    print(f"  {channel:<7}{first}/{len(rows)} at first contact")

First contact resolution: 6/10 = 60%
Average handling time:    8.6 minutes

Per channel:
  chat   3/3 at first contact
  email  0/1 at first contact
  phone  3/5 at first contact
  portal 0/1 at first contact

Other common measures are average handling time, the share of calls abandoned before an agent answers, the reopen rate, and user satisfaction after a ticket closes. Each tells part of the story; used alone, a speed measure such as handling time pushes agents to end calls early. The page Continual improvement explains why metrics must be balanced.

Empathy and communication

A service desk is judged as much on how it treats people as on what it fixes. A user who calls is usually stuck, sometimes stressed, occasionally angry, and rarely interested in technical detail. Skills that matter:

• Active listening: let the user finish, then summarize what you heard. It catches misunderstandings early and shows you took them seriously.
• Empathy: acknowledge the impact. "You can't send invoices on the last day of the month; that's urgent, let's look at it now" works better than "I'll log a ticket".
• Plain language: say "the print service on the billing server stopped", not "the spooler hung after the KB patch".
• Managing expectations: say what happens next and when you will update them, and then do it. Silence feels longer than waiting.
• Clear written notes: the next person reading the ticket, perhaps at 3 a.m., must understand what was tried.

Service desk models

How a service desk is organized depends on size, locations and the hours it must cover:

Kestrel runs a centralized desk at its head office during business hours, with agents working from home part of the week, which makes it partly virtual. Outside business hours, calls about critical services go to the 24/7 network operations center (NOC). Many organizations combine models like this, or outsource part of the desk, for example the out-of-hours shift, to a supplier.