Service Desk Guide: Requests, Triage, SLAs and Knowledge

A service desk is the function that receives requests, questions and reports of problems from the users of a service and makes sure that each reaches resolution. In ITIL, it is described as the single point of contact between the service provider and its users. The people on it may be a dedicated team or a rota of engineers. The form matters less than the behaviour: users know where to go, someone responds and nothing is lost.

The terms service desk and help desk overlap. A help desk is usually described as reactive and focused on fixing a user's immediate problem. A service desk is the broader function: it also handles requests and changes, supports the wider service management processes and works on preventing problems. Many teams use the words interchangeably. What matters is the scope you commit to.

Step 1: One front door

The first rule is a single, well-known place to ask. People will use email, chat, a form and a desk visit if you let them, and each channel creates its own pile. Choose a primary channel, usually a form or a shared address, and route everything else into it. Tell people where it is, and make it the answer to every "who do I ask?"

In Atlas, public forms create a task in a destination project for every submission, using the title field as the task title and writing other answers into the description. Required fields are enforced before the task is created, and a form can be switched off without losing its history. Email-to-task gives your workspace inbound addresses, each with a default project and assignee, so that an email becomes a task with the subject as its title. Email-to-task depends on a mail gateway connected by whoever operates your Atlas, so confirm with your administrator that it is connected. Whichever channel is used, the request lands in the same project.

Step 2: Collect what you need to act

The most expensive part of a request is the exchange of messages needed to understand it. Design the form to ask the questions you would otherwise ask: who is affected, what they were trying to do, what happened, when it started and how urgent it is for them. Use conditional fields so that only relevant questions appear. Fewer fields means more completed requests, so remove anything you do not use.

Step 3: Triage

Triage is the decision about what each request is and what happens next. Classify it as a request, an incident, a question or a change. Set a priority from impact and urgency. Assign an owner. Decide whether it needs an escalation. The ticket triage guide gives a priority matrix.

Triage should be fast and routine. In Atlas, the inbox triage view presents tasks that still need a decision one at a time, with the reason each is there. A task qualifies when it has no assignee, no due, start or snooze date, or neither a priority nor an estimate. A key press sets the due date to today, sets it to the next Friday, snoozes it for two weeks or archives it. Use it to clear the new queue at set times each day.

If the request is really an incident, such as many users reporting the same outage, declare an incident rather than working each request alone. See the incident management guide.

Step 4: Resolve and communicate

Acknowledge each request promptly, even if you cannot resolve it yet, with an honest expectation of when you will. Keep the requester informed of progress, in the channel they used. When you resolve, state what was done and ask whether it fixed the problem. Closing a request that the user considers unsolved produces repeats.

Step 5: Service levels

A service level states what response and resolution users can expect. Without one, urgency is whatever the loudest person says. The SLA guide explains how to set realistic targets. Atlas tasks have due dates and priorities, which you can use to express targets, and incidents carry response targets per severity level. Atlas does not have a dedicated request SLA timer that pauses and breaches automatically, so if you need that, use a dedicated ITSM suite or manage the target with due dates and a regular review.

Step 6: Knowledge

Every question asked twice should become an article. Write short, searchable answers in the words users use, link them from the request form, and assign an owner and a review date. Good articles let users solve problems without raising a request, which is the cheapest outcome. Atlas has a wiki for this, available from the Pro plan.

Step 7: Automate the routine

Automation rules in Atlas match an event such as a task being created and then set a field, apply a label, notify a user or call a webhook. Use them to label requests by category, notify the right team and set a default due date. Choose triggers that your own actions do not cause, or a rule can run repeatedly. Keep rules few and visible. A desk run by dozens of hidden rules is hard to reason about.

Step 8: Measure and improve

• Volume by category, to see what to fix at its source or to answer with an article.
• Time to first response and time to resolution, by priority.
• Reopened requests, as a sign of poor resolution.
• Requests raised about an outage, as a sign that communication failed.
• User satisfaction, asked in one question after closure.
• The oldest open requests. Review them weekly.

Support tiers and escalation

Many desks organise work in tiers. First line handles the common requests and known issues using scripts and articles, and resolves what it can. Second line takes what needs deeper skill or access. Third line is the engineers or vendors who own the underlying system. The purpose of tiers is to match the cost of the person to the difficulty of the work, and to protect expensive time from routine questions.

Tiers fail when work bounces between them. Define what first line may do, when it must escalate and what information it must pass on, so that second line does not start again. Make the escalation a hand-off with a note and an owner, and not a reassignment into a pool. A request that is escalated should still have one named person who is responsible for the requester hearing back.

For a small team, tiers may simply be a rota. Whoever is on desk duty takes first line and calls on colleagues by name. What matters is that the person on duty knows they are accountable and that the queue is cleared at set times.

Writing replies that resolve

Most of the experience of a service desk is in the replies. A few habits make them better.

• Open with the answer or the next step, not with an acknowledgement of receipt.
• Use the requester's words for the problem so that they know it was read.
• Give numbered steps for anything they must do, and say what they should see after each.
• Say what you will do and when, and then do it. A promised update that does not arrive costs more trust than a slow fix.
• Close with how to reopen the request if the fix does not hold.
• Keep a small library of reply templates for common cases and edit them for the person. A template sent unedited reads as such.

Self-service and deflection

The cheapest request is the one that never needs a person. Articles, short videos and clear forms let users solve common problems themselves. Measure which articles are used and which questions still arrive despite an article, because the second list shows where the article is hard to find or unclear.

Place help where the user is. Link an article from the request form for the topic they are about to raise. Link the form from the article that did not solve the problem. Do not hide the way to reach a person. Users who feel trapped by self-service are more annoyed than those who were simply told to call.

When many requests are really one incident

A sudden burst of similar requests usually means an incident. The desk is often the first to see it, because users report symptoms before monitoring does. Train the desk to recognise the pattern, which is several reports of the same symptom in a short time, and to declare an incident instead of working each report separately. Link the individual requests to the incident, tell the requesters what is known and update them when it is resolved. See the incident management guide, which describes how to declare, assign roles and communicate.

Quality and satisfaction

Review a small sample of closed requests each week. Ask whether the first reply was useful, whether the right priority was set, whether the requester had to chase, and whether the resolution was recorded in a way that would help the next person. Share the findings with the team as observations about the process and not as criticism of individuals.

Ask the requester one question after closure, such as whether the problem was resolved, with room for a comment. The answer matters less as a score than as a prompt: read every negative comment, and look for patterns across them.

Staffing, hours and coverage

Decide the hours the desk is staffed and say them where users will see them. A desk that implies round-the-clock cover and delivers working hours loses trust the first time a request waits overnight. If the service has out-of-hours obligations, route urgent matters to the on-call rota and state clearly what counts as urgent. Atlas keeps these separate on purpose: routine requests become tasks, and incidents with on-call and escalation are a different path.

For a small team, rotate desk duty so that no one carries it all the time, and give the person on duty protected time to do it well. A desk staffed by whoever happens to look at the queue produces slow, inconsistent answers and resentful engineers.

Setting up in the first week

• Choose the front door and publish it where everyone will see it.
• Build the intake form with the six or seven questions you always ask. See the intake form design guide.
• Create the destination project, with statuses for new, in progress, waiting on the requester and done.
• Write the priority matrix on one page and agree it with the people who will use it.
• Set the triage times and name who is on duty each day.
• Write the ten most common answers as articles and link them from the form.
• Agree how an outage is declared, and where the desk hands over to incident management.
• Pick three measures and record the starting values: time to first response, time to resolution and the age of the oldest open request.

Handling difficult requests

Some requests cannot or should not be granted: access that policy forbids, a change that conflicts with another, work outside the desk's remit. Say no clearly and early, give the reason in a sentence and offer the nearest thing you can do. A refusal that explains itself and points to an alternative is received far better than silence or a vague delay.

Some requesters are frustrated, often because their previous request was handled badly. Acknowledge the frustration briefly, restate the problem accurately to show you understand it, and give a concrete next step with a time. Do not argue about the history. If the complaint is about the process, record it for the weekly review rather than defending it in the thread.

Employee-facing desks

Internal requests to HR follow the same pattern. Atlas has a separate HR helpdesk within the People module, which is included from the Business plan. The IT desk described above is different: it uses forms, email and tasks, available according to your plan.

What Atlas does not do here

• No customer-facing request portal for IT tickets with live status for the requester. Requesters see the outcome through your replies.
• No configuration management database or service catalogue.
• No request SLA timers.