What is a Helpdesk and what is it used for?

In every company I have ever worked in, there is a mythical creature: “the guy you ask in the hallway.” He has no official title and does not appear anywhere in the support organization chart but, leaving a trail of coffee cups behind him, he fixes the printer in the back room, the salesperson’s misconfigured VPN and that laptop making “the weird noise.” And when he goes on vacation… chaos arrives to take his place, because all that work was being done as a favor. To prevent these fires, a Helpdesk is essential: the technical support function that centralizes the reception, tracking and resolution of user incidents, usually through a ticketing system and well-defined processes.
By turning random favors into a systematic service, requests stop falling through the cracks, fixing something no longer depends on ambushing someone in a hallway, there is a clear prioritization logic when five urgent issues arrive at once, and there is also a history to consult when “that” problem resurfaces in March. It also provides data to discuss budgets with the CEO, preventing the conversation from becoming a dialogue of the deaf based on subjective perceptions of workload, performance or stress.
Like the hallway hero nobody will ever write songs about, the Helpdesk keeps the organization running behind the scenes.
That is why we are going to take an in-depth look at how it works.

What is a Helpdesk: the function and the software

Before explaining it, we need to clarify something, because the term is used for two things that are related, but different.

• On the one hand, the Helpdesk is the support function or the team that carries it out. In other words, it is both the defined procedure and the people who implement it, receiving user requests, prioritizing them, fixing issues, closing incidents…
• On the other hand, Helpdesk also refers to the software that this team works with. That is why the concept is also used to describe the specific tool where tickets are logged, passed around like a hot potato, working times are tracked and all this work is documented.

An organization can have the former without the latter, using a shared inbox… which works until it stops working at minute two. Life in IT stopped being simple a long time ago, and specialized software is necessary to tame the eternal chaos of support.
What we cannot have is the latter without the former.
A tool without processes behind it is an empty shell that merely produces better-tabulated chaos, not better-resolved chaos.
That is why a Helpdesk that works combines these two sides. Technicians and processes on one side, together with a management tool based on tickets, automation, a knowledge base, SLA monitoring…

What is a Helpdesk used for?

Star Trek: Deep Space Nine bases 80% of its plot on making Chief O’Brien suffer, the technician everyone brings their problems to. “The hallway guy,” although in this case he actually has an official position. First the replicator breaks, then the command center screen, then a Cardassian sabotages the computer… Every technical failure converges on O’Brien, and that is exactly what a Helpdesk does. The difference is that O’Brien is a genius who keeps everything in his head, but we cannot afford that luxury, so we need to implement a Helpdesk in order to:

• Centralize the logging of requests, regardless of the channel they come through (email, phone, the dedicated portal nobody uses…).
• Classify and prioritize those records. If the printer is not working, it may delay a specific task, but if the e-commerce platform goes down, it delays an entire department and bleeds money. Both will arrive with the same level of outrage, but not with the same priority.
• Assign requests and escalate them appropriately. So that every open case is handled by whoever has the necessary knowledge or permissions. And if the fix gets stuck, it moves up a level.
• Track resolution times. With a good Helpdesk, we will always know how long each case has been open and, above all, which ones are about to test the boss’s patience or, worse… affect the SLA (Service Level Agreement we are required to meet).
• Keep users informed about their issue. Strange as it may seem to an engineering mindset, a large part of support is emotional. Uncertainty causes the greatest dissatisfaction among users and, for that reason, the Helpdesk must prevent the feeling that nobody is responding.
• Document what was resolved and measure how well it was done. Hopefully this will help us improve next time and, in addition, allow us to send a report on the work completed to whoever needs it.

How does a Helpdesk work?

Like those old TV shows, let’s take a look at “a day in the life of a Helpdesk” by following the journey of an incoming request:

• The user reports an incident to us by phone, email or, if we believe in miracles, opens a ticket in the system just as we have told them a thousand times.
• The request is logged in a ticket containing the (almost always vague) details of what happened.
• The ticket needs to be classified so that we know what to do with it. Depending on how the tool has been configured and according to our organization’s processes, this is usually done by incident type, affected service, etc.
• Once classified, it is prioritized according to urgency and business impact.
• Based on the above, it is assigned to the appropriate specialist technician or team.
• The technician investigates, asks the user for even more vague information… And responds.
• If that response is beyond their capabilities (or the scope needs to be broader), the case is escalated to another level.
• If not, it is resolved and confirmed with the user that everything is working correctly.
• Now, the solution is documented before the matter is closed.
• After that, the ticket is closed and the case becomes part of our history and performance reports.

Obviously, every organization is different, and those 10 steps take a different form in each one. The above is a good-practice framework, not a set of commandments.
For example, in our case certain requests may require prior approval according to procedure, or we may separate incidents from other types of requests, such as requests for new features, at an early stage.

Main functions of Helpdesk software

The work of a Helpdesk revolves around ticketing, around a system based on this way of working, but what separates a useful tool from a nicely formatted log are the functions that surround ticketing and that we have already seen in action above:

• Categorization.
• Prioritization.
• Assignment.
• Workflows.
• Automation.
• Notifications and information.
• SLA management.
• The ability to escalate complex cases.
• An information portal.
• A knowledge base to make resolution easier.
• A historical record for the same purpose.
• Integration with other systems, such as SIEM or monitoring tools, for example…

Again, this is the ideal scenario, but every tool is different too. Some products place a strong emphasis on automation, but their portal capabilities may be little more than a footnote.
That is where the ability to choose the tool that best suits our needs comes into play, something we will look at later.

What is a ticket in a Helpdesk?

Since everything revolves around this way of working, the ticket is its fundamental unit, the record of an incident (or a technical query or request to IT). Thanks to the ticket, we know who opened it, when they opened it, what happened, who handled it and how the story ended. For what concerns us today, this is the essential part to understand. To go deeper into lifecycles, priorities or specific management practices, here we explain what a ticketing system is.

The different types of Helpdesk

Here is something that is rarely said: “textbook classifications” tend to invent categories just to fill space, but these five describe quite well what actually exists in IT when we talk about Helpdesk:

• Internal Helpdesk. The long-suffering department that supports the employees of its own organization.
• External Helpdesk. This one provides support to customers or users of a product or service, such as when we subscribe to an external CRM that includes support. If we are the ones providing that service, it involves a wide range of expectations and contractual commitments.
• Centralized Helpdesk. Another classification in which all requests are concentrated within a single team. It acts as both gatekeeper and distributor of headaches.
• Distributed Helpdesk. Here, support is spread across locations, departments, levels… The advantage of this type of Helpdesk is its proximity to the issue and its specialization. The potential price to pay is that everyone may end up doing things their own way.
• Managed Helpdesk. Here we are talking about an external provider that delivers the support service. This is usually an MSP (Managed Service Provider) with which we will have agreed on an SLA.

Bear in mind that these categories are not mutually exclusive: a Helpdesk can be internal, distributed and managed at the same time.
You may also come across categories such as SaaS or on-premise, but those are deployment models for the support software, not types of Helpdesk.

Support levels and escalation

L1, L2 and L3. That is the support level structure that almost all of us end up adopting by convention, but it is not mandatory and, above all, it does not make much sense when there are only two people on the team. What it usually means is:

• The first level (L1) handles the usual issues, the bumps in the road of everyday work.
• L2 takes care of what requires specialized knowledge.
• L3 usually handles matters related to the product, architecture or provider.

And how far up should the ticket go?
Good question, and the answer is something we need to define clearly in our procedures according to our specific situation. A typical example would be escalating a ticket if:

• The current “L” does not have the necessary knowledge.
• The case is critical.
• It is causing issues, such as blocked users or applications.
• It has been unresolved for too long.
• Permissions are required that the current level does not have…

With well-defined reasons, we avoid “escalation by exhaustion,” which means throwing a ticket upwards simply because we have no idea what to do with it.
If we do not know how to resolve it, but it belongs at that level, we need to go back to the drawing board and improve how the service works instead of overloading the next level just because “they know more about these things.”
Frameworks such as ITIL have been formalizing these practices for years, and the official ITIL 4 framework from PeopleCert is a good starting point for going into detail when we write our escalation process.

Helpdesk and SLA

In IT, we have too many masters to serve, and “I’ll take a look when I can” stopped being good enough a long time ago. A Service Level Agreement, or SLA, turns that vague phrase into a verifiable commitment and, in the context of a Helpdesk, translates into indicators that the tool monitors automatically. This means that metrics such as time to first response or resolution time, calculated according to the agreed service hours (so that the clock on a midnight ticket does not start running until the office opens, if that is what we agreed in the SLA), help us manage and meet the required service level. The key is that the Helpdesk can give us a warning that things are not going well when those three tickets have been open forever or resolution times are moving at a snail’s pace. That helps us correct course before the February report tells us that the SLA was breached in January. For anyone who wants to know more, here is what an SLA is, and to prevent it from coming back to bite us when we draft one, we also have a guide to best practices for Service Level Agreements. For the formal service management framework, it is better to refer to the ISO/IEC 20000-1 standard.

The “who’s who” game: Helpdesk, ticketing, Service Desk and ITSM

When these terms come up in meetings, they are often used as if they were twins, but nothing could be further from the truth.
Here is a table to quickly see how they differ.

Concept	Main function	Scope
Ticketing	Log and track cases	Tool/process
Helpdesk	Resolve incidents and requests	Support
Service Desk	Point of contact for IT services	Service management
ITSM	Manage the service throughout its lifecycle	Global

And here is what each one actually is:

• Ticketing is the tool (or process) that logs support requests and makes it possible to track them. Within the Helpdesk, it is key to the practical management of incidents, but it is only one part of a much broader whole.
• The Service Desk is the “one-stop shop,” the point of contact between users and IT. Its scope is broader than that of the Helpdesk because it does not simply “fix breakdowns.” A Service Desk can manage user onboarding and offboarding, the service catalog… Helpdesk and Service Desk often overlap, but in this article about what a Service Desk is, we explain more clearly where the boundary lies.
• ITSM (IT Service Management) refers to the practices and processes used to design, manage and improve an IT service. Obviously, the Helpdesk can be an important operational function within our technology services but, once again, it is important not to confuse the part (Helpdesk) with the whole (ITSM).

Helpdesk and automation

As a child, I loved mythology, and one of my favorite monsters was the Hydra. You cut off one head and two more grew back… It was unbeatable! Then, when it grew up, the Hydra had to find a job just like I did and decided to become the support queue of pretty much any technology service… because that is exactly how every technician working in a Helpdesk feels. You finish one case and already have three more waiting.
The sword we use against this Hydra is automation. It will not cut off every head, but it may be able to chop them off faster than new ones can grow.
With a good rules engine in a Helpdesk, we can automate:

• The assignment of requests, by category or group.
• The prioritization according to impact and urgency guidelines.
• The categorization according to the content or origin of the ticket.
• The notification of changes (to users and technicians).
• Escalation when deadlines have been exceeded, etc.

In fact, in some cases we can even build complete workflows with conditional rules and automatic responses for those issues that rear their heads every week.
That can give time back to our team and fit into a broader IT task automation strategy.
The main thing, if we do not want to cut ourselves with that sword, is not to automate what we do not understand and not to remove humans from the loop when it matters.
Otherwise, automation will simply help us make bigger mistakes, faster.

The self-service portal and knowledge base

What is the best ticket? The one that never gets opened. But how do we obtain that holy grail? Complicated, if we remember the Indiana Jones movie, but two tools can help us get closer:

• The self-service portal. It allows users to create their own requests with the necessary information, check their status instead of writing to us every minute, or access information and resolve simple issues on their own (utopian, I know, but it has been known to happen).
• The knowledge base is the other side of that coin. Every resolved request can become a piece of content, so that the next user who encounters the same issue can also find the answer without consuming a technician’s time.

The key is that, if we have followed what we mentioned a little earlier and implemented the practice of documenting before closing, the knowledge base grows almost by itself and we can make it available through the self-service portal.

Key Helpdesk metrics

We have to choose: either we have indicators or we have arguments about how support is working, based on personal impressions. Since shouting and management do not go particularly well together, it is better to rely on metrics that provide us with real information, such as:

• First Response Time. In other words, how long it takes the user to receive the first human response to their request. Bear in mind that this has a major impact on their perception of the service and helps avoid a great many arguments.
• Resolution Time. How long it takes to close the case, which is a very different conversation from the previous one.
• SLA compliance. Measured as the percentage of cases handled within the agreed timeframes. If we really want this figure to mean something, it is better to break it down by priority.
• Backlog. The technical name for that tower of accumulated pending requests reaching all the way to the ceiling. More than the absolute value, what matters here is the trend.
• Reopen Rate. The percentage of tickets that are reopened. Ultimately, a prematurely closed ticket is worse than an open one, because it inspires very little confidence.
• Ticket volume. Measured by how many tickets are handled over a given period. This is useful for sizing our team and detecting underlying issues within support.
• Customer satisfaction (Customer Satisfaction Score or CSAT). Measured as the level of satisfaction reported by the user after resolution, usually through a numerical score or similar rating, which may also be accompanied by friendly comments.

The key is to understand that there are no “universal” benchmarks for these indicators, and it is better to be skeptical of those we may come across. For example: what does the optimal resolution time for a consulting firm have in common with that of a hospital?
Nothing. That is why setting universal values without considering our specific situation is a case of the blind leading the blind.

Benefits of Helpdesk software

If our repressed masochistic tendencies have led us to work in support, this article will probably have switched on a few light bulbs, especially when it comes to the benefits of implementing good Helpdesk software. The main ones include:

• Traceability. Every case is recorded along with its history, so nobody has to reconstruct from memory what was done back in August.
• Real prioritization. Requests are classified according to impact or urgency, rather than persistence or how loudly someone shouts.
• Less manual work. Automated workflows take care of repetitive operations that previously had to be performed by hand.
• SLA monitoring. Identifying cases that put it at risk before they blow up in our faces.
• Reusable knowledge. Solutions no longer live inside the head of the “hallway guy” from the beginning of our story, but move into the knowledge base instead.
• Data-driven decisions. With reports that show trends, bottlenecks, workload imbalances…
• Scalability. So that support can cope as the number of users increases.

How to choose Helpdesk software

Prosopagnosia is a strange word that describes the inability to distinguish people’s faces, and also a common condition when looking at Helpdesk software options, because on websites and in marketing presentations, they all look the same. Demos usually do not help much either, because everything looks wonderful and works perfectly in them, but when you sit down on Monday to actually get some work done… That is why, before anything else, here is some advice based on experience: ask for a trial and put your own cases into it, not the ones from the demo script. That will tell us whether the tool falls apart when faced with that unusual request that only happens in our organization. With this in mind, what truly separates the best Helpdesk software from the rest is:

• A ticketing system with custom ticket types and fields.
• The ability to create automated workflows.
• The ability to monitor SLA compliance.
• Good multi-level escalation.
• A self-service portal and knowledge base that are not last-minute additions.
• Robust, customizable reporting.
• Role- and group-based permissions.
• Integration capabilities and API…

These are the basics and we should use them as a checklist during those trials. Then, depending on our own requirements, we should consider other aspects such as multichannel support, SaaS or on-premise options depending on how we work, security, customization capabilities, scalability…
But above all, we need to make sure it plays well with others and can connect and integrate with the rest of the ITSM processes within our IT service.

How Pandora ITSM fits into the Helpdesk

The time has come to talk about ourselves and how we approach Helpdesk. In our experience, the final sentence of the previous section contains the key: integration. To achieve it, Pandora ITSM approaches Helpdesk as part of a broader service management platform aligned with ITIL processes. In other words, more than 20 years of experience and best practices turned into a tool. That is why the support side of Pandora ITSM includes:

• Ticket organization with custom types and fields.
• Categorization by groups.
• Automatic assignment through workflows.
• A unified history for each case.
• Cost and time tracking associated with projects.
• And also bulk operations, public and private notes…

One of the features we are asked about most often is automation.
For this, we provide workflows with criteria-based rules, automatic functions to change status, department or priority, event-based email notifications, SLA management with business hours, multi-level escalation…
If we remember what we discussed earlier, support should not simply be about putting out fires, but about service management.
That is why tickets display the remaining response and resolution time, precisely the advance warning we mentioned earlier to prevent SLA degradation or angry calls from customers.
In addition to this, we have incorporated a self-service portal, REST API, a knowledge base that can be linked from tickets, satisfaction surveys and incident management by email, so that support can provide the best possible user experience.
It is precisely when things fail that people will scrutinize us most closely, which is why we have created a polished environment… and one designed for the future, integrating additional features such as an AI chatbot trained with our knowledge base.
The key to our Helpdesk approach is that, because it is integrated into our general ITSM management tool, it naturally works alongside inventory and CMDB, change management, projects, CRM or wiki.
That integration is even easier if you already use our monitoring platform, because you can install it directly from the Pandora FMS console.
Frankenstein is one of the greatest novels ever written, but a terrible philosophy when applied to IT. That is why we have chosen the integration I mentioned, preventing infrastructure from becoming a monster stitched together from different pieces that eventually causes disasters and brings customers to the door with torches and pitchforks.
Which does not mean it is necessarily the answer for your situation. Seriously.
If your support operation consists of two people and fifteen tickets a month, deploying our solution would be like using a tank to kill a mosquito, and we will tell you plainly: do not choose us.
But if you have multiple locations, SLAs and an inventory that nobody quite knows where to find, we are probably what you have been looking for… but do not buy from us either: try us first, because we do not want to convince you, we want you to convince yourself.
And perhaps that poor “hallway guy” from the beginning can finally get back to doing his actual job, although by now he has probably forgotten what it was.

Frequently asked questions about Helpdesk

Once again, we have taken a long and comprehensive journey, so it is worth revisiting the main points on the map through the most common questions.

What is a Helpdesk?

The support function (not just the software) responsible for incidents and for centralizing their reception, tracking and resolution. It almost always relies on a ticketing system and defined processes to log cases, prioritize them, assign them to someone responsible and close them, while keeping a record of what was done.

What does Helpdesk mean in IT?

In IT, Helpdesk refers to the technical support service that manages the issues users experience with IT, whether they involve applications, networks, systems, devices… It may be internal (for employees within the organization) or external (for customers of a product or service). The term is also used to refer to the software used to manage that support.

What is a Helpdesk used for?

To organize and measure technical support so that it can operate more effectively. To achieve this, it provides a unified channel for receiving, logging, prioritizing and assigning incidents. It also makes it possible to track times, keep users informed, document solutions and generate the necessary reports.

How does a Helpdesk work?

The basic workflow begins when a user reports an incident or submits a request. This is logged as a ticket in the system, where it is classified, prioritized and assigned to the appropriate team. The investigation and response then begin, with the case being escalated to another level if it exceeds the scope of the person or team assigned to it. Once it has been resolved, the solution is documented, the ticket is closed and the work carried out becomes part of the historical record, where it can be used in reports or as a reference for similar issues in the future.

What functions does Helpdesk software provide?

They vary depending on the vendor, but the functions commonly found in a modern Helpdesk include: ticketing, categorization, priorities, assignment, automation, notifications, SLA monitoring, escalation, a self-service portal, knowledge base, reporting, user surveys, a permissions system and integrations with other systems. Quite a lot.

What is the difference between Helpdesk and ticketing?

Ticketing is one specific part of the Helpdesk, the mechanism that logs user requests and makes it possible to track their status. The Helpdesk consists of the complete support function, which relies on that ticketing mechanism to track cases.

What is the difference between Helpdesk and Service Desk?

The Helpdesk is responsible for resolving technical issues and support requests. The Service Desk is a single point of contact for all IT services, not just failures. As a result, the latter has a broader scope that may include the service catalog, business-related services, capacity expansions…

What is the difference between Helpdesk and ITSM?

Helpdesk is a specific operational function within ITSM, focused on resolving incidents and user requests. ITSM is the broader discipline covering the design, improvement and management of IT services as a whole. Therefore, Helpdesk may form part of an ITSM strategy, but it is not the whole of ITSM and does not replace it.

What metrics are used in a Helpdesk?

Many, and the most important ones depend on what is critical to keeping the organization running properly. The most common include:

• Time to first response to the incident.
• Resolution time.
• The percentage of SLA compliance.
• The incident reopen rate (which should be minimized).
• Ticket volume handled and backlog volume (the accumulated unresolved issues).
• User satisfaction (measured through surveys or numerical support ratings, like school grades).

These are not all the metrics that exist, nor are all of them strictly necessary for every organization.
As always in IT, the key indicators depend on the organization’s activity.

What should good Helpdesk software include?

“Good” is a relative concept in IT and, once again, the word “depends” enters the dance, because Helpdesk software that is ideal for a large organization may be excessive for a small one, getting in the way more than it helps. That said, a flexible and customizable ticketing system, automation, SLA management, effective escalation, reporting, permissions, integration, and a self-service portal or knowledge base are almost essential today.

Can a Helpdesk be automated?

To a large extent, yes and, given the current IT landscape, it may be essential for many organizations. Ticket assignment, priority and category based on content, notifications or certain escalations can all be automated, such as an escalation triggered when something has remained unresolved for too long. Likewise, through a self-service portal or AI chatbots such as the one included in Pandora’s solution, it is possible to automate a first level of service for basic matters, reducing the typical stream of recurring queries caused by a lack of basic technical knowledge.

What is the relationship between Helpdesk and SLA?

SLAs define the level of service we are required to provide and the consequences of failing to meet it, meaning that the Helpdesk commits to fulfilling those requirements within the support function. What the Helpdesk does (providing a quick first response, resolving issues, etc.) is essential to meeting SLAs, and Helpdesk tools make it easier to manage that service level because they show how long we take, how long a ticket has been sitting unresolved… In this way, the Helpdesk helps minimize breaches and warns us when we are heading toward an SLA violation.