Service desk glossary

These are plain definitions of the terms IT support teams and managed service providers use most, written to be neutral and usable with any tool. Where ActiveQ handles a term in a specific way, a short note says so.

First response time

First response time is the time between a request being created and the first reply from a person. It answers the requester’s first question: has anyone seen this? It is a measure of attention, not of progress.

Definitions differ on what counts as a response. Most teams exclude automatic acknowledgements, because the requester still has no human answer, and count the first public reply rather than an internal note. Whatever you choose, write it down so every technician measures the same way.

It is usually set per priority and paused or counted in business hours according to the agreement. In ActiveQ, a policy sets a first response target for each priority, and each ticket shows a countdown. See the IT SLA guide.

Resolution time

Resolution time is the time between a request being created and the moment it is resolved. It measures how long the problem or need stayed open from the requester’s point of view.

The details matter. Some teams stop the clock when the fix is delivered, others when the requester confirms it, and they disagree about which waiting periods pause it. A short resolution time for easy tickets can hide a long tail of hard ones, so look at the distribution as well as the average.

In ActiveQ, a policy sets a resolution target for each priority. A status can be marked “Pauses SLA”, and the clock is paused while a ticket is in it.

SLA (service level agreement)

A service level agreement is a documented commitment about the service a provider will deliver, often with measurable targets such as first response time and resolution time. In IT support the provider may be an internal IT team and the customer its employees, or an MSP and its client.

Two related terms are worth knowing. A service level objective (SLO) is an internal target, usually stricter than the promise. An operational level agreement (OLA) is a commitment between teams inside the provider, such as a network team agreeing how fast it picks up work handed to it, that supports the SLA the customer sees.

An SLA should state what is measured, how, when the clock runs and pauses, and what happens on a miss. Some agreements attach credits or reviews to a miss. See the IT SLA guide for sample targets, clearly labelled as examples.

Incident vs service request

An incident is an unplanned interruption to a service or a reduction in its quality: email is down, a printer fails, a VPN drops. The goal is to restore service quickly. A service request is a formal request for something expected and repeatable: a new account, access to a shared folder, a laptop. Nothing is broken, and the work follows a known path.

The difference changes how you handle them. Incidents are prioritised by impact and urgency and are measured on speed of restoration. Requests are fulfilled from a catalogue or form, often with an approval, and are measured on being delivered as promised. Mixing the two makes both targets meaningless.

A problem is the underlying cause of one or more incidents, and a change is a modification to a service. ActiveQ starts a workspace with Incident, Request and Task types, and lets you add types such as problem and change. See ITSM lite.

Ticket triage

Ticket triage is the first sorting of an incoming request. A person or a rule decides what kind of request it is, how urgent it is, who should take it, and if it needs more information before work starts.

Good triage uses a small, clear set of categories and priorities, and a rule for deciding between them, such as impact and urgency. The aim is that the right person sees the right ticket in time, and that urgent tickets are not buried under newer ones.

In ActiveQ, a staff member can ask AI to suggest a category, priority, sentiment and language for a ticket. It is a suggestion that the person accepts or changes. Nothing runs automatically. See the AI guide.

PSA vs helpdesk

A helpdesk, or service desk, tool is built around handling requests: tickets, queues, deadlines and communication with requesters. A professional services automation (PSA) tool is built around running a services business. It usually combines ticketing with time entry, contracts, billing and invoicing, project work and sometimes sales.

Managed service providers often choose a PSA because it connects the work done on tickets to what is billed. A team that does not bill by the hour, such as an internal IT department, usually needs only the helpdesk part. Teams sometimes pair a helpdesk with a separate billing system. The guide to helpdesk ticketing vs PSA covers when you need which.

ActiveQ is a helpdesk with client portals, so invoicing and billing stay in a separate tool.

Customer satisfaction score

CSAT, short for customer satisfaction, is a measure collected by asking requesters to rate an interaction, often with a one-to-five rating or a thumbs up or down after a ticket is resolved. The score is usually the share of positive answers or the average rating. In ActiveQ, each portal can email a one-click 1 to 5 rating link when a ticket is resolved, and staff see the answer on the ticket. The satisfaction report in Reports shows the average score, the share of answers that are satisfied and the response rate.

Response rates are typically low, so a score from a handful of answers can swing widely. It is most useful alongside the comments, and for spotting trends rather than ranking individuals. Surveys sent after every ticket can also annoy requesters who have many.

Shared inbox

A shared inbox is a single email address, such as support@ or help@, that several people can read and answer. It is the usual starting point for a support team because it needs no new software.

It works well at low volume. As volume grows, its limits show: no clear owner for each message, duplicated or missed replies, no priorities or deadlines, no history beyond a thread, and no way for a requester to see progress. A ticketing system adds those on top of the same email address.

In ActiveQ you forward the shared address to a mailbox ActiveQ provides, and each message becomes a ticket. See from a shared inbox to ticketing.

Escalation

Escalation is passing a request to someone with more skill or authority, or raising its attention. There are two kinds. Functional escalation moves the work to a more specialised group, such as from first-line support to a network team. Hierarchical escalation brings in a manager when a deadline is at risk or a customer is unhappy.

Escalation works well when the triggers are written down: a priority, a deadline reaching a percentage elapsed, a customer waiting beyond a set time. Otherwise it depends on someone remembering, and happens late.

In ActiveQ, a service level policy can have escalation steps at a percentage of the target. Each step can notify the assignee, notify a team, assign the ticket to a team or set its priority.

Business hours

Business hours, in a support agreement, are the hours during which the provider’s clock runs for targets that are measured in business time. A request that arrives outside them does not start using its target until the next opening time.

A schedule normally defines the days and times a team works, its time zone and its holidays. The alternative is calendar hours, which count every hour of every day. Many teams measure urgent incidents in calendar hours and everything else in business hours.

In ActiveQ, a business hours schedule has a time zone, weekly windows and holidays, and a policy can use it or use calendar hours. See Settings, then Service levels.

Impact and urgency

Impact is how much of the organization a problem affects: one person, a team or everyone. Urgency is how quickly the effect becomes costly. Together they are the usual inputs for deciding a ticket's priority.

Using both avoids two common errors. A loud request from one person is not automatically urgent for the business, and a quiet outage that affects a whole department is not low priority because nobody complained. A small matrix that maps the two inputs to priority levels keeps technicians consistent. See the priority matrix guide.

In ActiveQ, a person sets the priority, optionally starting from an AI suggestion, and each priority can have its own response and resolution targets.

Ticket deflection

Ticket deflection is solving a request before it becomes a ticket, usually by giving people a way to help themselves. Common methods are help articles, a portal that shows the status of existing requests, and forms that ask for the right details up front so fewer follow-up questions arrive.

It is easy to overstate. A request that is deflected is not necessarily solved, so teams that track it usually check if the person came back. Deflection suits repeated, simple questions and does little for one-off problems.

In ActiveQ, a portal shows requesters the status and conversation for their requests, which cuts the emails that ask for an update, and forms collect structured details. A knowledge base adds a help center where portal users can search articles and see suggestions while they write a request.

Ticket backlog

A ticket backlog is the set of open requests that no one has finished. Its size matters less than its age: fifty tickets that are all a day old are normal, while ten that are two months old suggest that something is stuck.

Watching both the count and the age of the oldest items is a quick health check for a small team. A backlog that grows week after week means more work arrives than the team completes, and the fix is capacity, scope or fewer repeat problems, not working faster.

In ActiveQ, the All open, Waiting and SLA at risk views show the open work, and the Backlog health report in Reports shows open tickets by age, assignee and first-response status. The API also lists tickets with their created and resolved times. See help desk metrics to track.

First contact resolution

First contact resolution is the share of requests solved in the first reply or the first interaction, without the requester having to come back. It is a measure of how well the first technician understood the problem and how much they were able to fix themselves.

It can be improved by asking for the right details on the form, giving technicians what they need to act without escalating, and writing replies that answer and ask in one message. Pushing it too hard can backfire if technicians close requests early to count them, so pair it with the share of requests that are reopened.

ActiveQ cannot tell if a problem was solved on first contact. The one-touch resolution rate in Reports is a close measure: the share of resolved tickets that had exactly one staff reply. It counts replies, so it cannot see a requester who had to come back.

MTTR

MTTR is an abbreviation that stands for mean time to repair, recover, resolve or respond, depending on who is speaking. In a help desk it usually means the average time to resolve a ticket. Say which meaning you use before comparing numbers.

An average is pulled up by a few very long tickets, so look at the median and a high percentile as well. See help desk metrics defined.

Backlog age

Backlog age is how long the open tickets have been open, usually reported as the age of the oldest ticket or the share older than a set number of days. It is a better warning sign than the count of open tickets.

It shows work that is stuck even when the queue looks small. See ticket backlog and help desk metrics defined.

SLA pause

An SLA pause stops the clock while the next move belongs to someone else, most often while the team waits for the requester. Time spent paused does not count against the target.

Teams disagree about waiting for a vendor: some pause the clock and some do not, so write the rule into the agreement. In ActiveQ, any status can be marked “Pauses SLA”. See the IT SLA guide and business-hours SLA math.

Operational level agreement (OLA)

An operational level agreement is a commitment between teams inside the same provider, such as a network team agreeing how fast it picks up work handed to it. It supports the SLA that the customer sees.

An OLA is internal and is not shown to customers. See SLA.

Major incident

A major incident is an incident with high impact and high urgency, such as an outage affecting most users, that is handled with a different, faster process than normal tickets. A team usually names one lead, communicates on a fixed rhythm and reviews the cause afterwards.

Small teams often write the criteria in one sentence so that nobody has to debate it during an outage. See the priority matrix guide.

Problem and change

A problem is the underlying cause of one or more incidents. A change is a planned modification to a service, usually with a review before it is made. Treating them separately from incidents keeps the fix for a cause from being lost in the rush to restore service.

In ActiveQ, problem and change are ticket types that you link to other tickets. See ITSM lite.

Ticket status

A ticket status says where a ticket is in its life and who must act next, for example New, Open, Waiting on customer, Resolved and Closed. A short list that names the owner of the next move is easier to apply than a long one.

Some statuses pause the SLA clock. See ticket lifecycle and statuses.

Webhook signature

A webhook signature is a keyed hash of a webhook message, sent in a header, that lets the receiver confirm the sender and that the body was not altered. ActiveQ uses HMAC-SHA256 over the timestamp and the raw body.

See what a webhook signature is and how to verify ActiveQ webhook signatures. The developers page covers the API.

For ActiveQ’s own plans and price, see pricing, or learn about ActiveQ.

Last updated October 16, 2026