Service Management Blog

Service Desk TIPS Explained: Ticket, Incident, Problem, Service Request

Joe Hertvik
5 minute read
Joe Hertvik
image_pdfimage_print

If you’re reading this, you’re probably interested in running a Service Desk inside your ITSM environment. Unfortunately, good methodology in setting up a Service Desk can spawn confusing terminology. And there are no more confusing components in the Service Desk world than these four terms:

  • Ticket
  • Incident
  • Problem
  • Service request

Let’s take a look at what these four terms mean and use them to come up with a unifying theme for how a Service Desk works. And it all starts with a simple acronym.

TIPS for Service Desk success

It’s easy to remember the difference between our Service Desk concepts by remembering the word TIPS, which is made up of the first four letters of our target terms. The TIPS acronym forms a hierarchy and chronology for how a Service Desk works. It explains a lot of how a Service Desk does its job.

T = Ticket

All Service Desk events start with a ticket. A ticket is an historical document that details a service event, such as an incident, problem, or service request. Tickets govern and control how a service event is processed. They are used to route events between different resources for resolution. They record all relevant information about a request, including:

  • User notes
  • Technician notes
  • Workflow information for how the ticket was handled
  • Ticket resolution
  • Other critical processing information

Tickets can document a single incident or service request. They can also group together, control, and document several incidents as a single problem. The ticket is the backbone of your Service Desk. It is used for every single service item that hits the Service Desk.

I = Incident

ITSM frameworks, such as ITIL v3 and ITIL 4, generally have separate management areas for Incident Management and Problem Management. There’s a reason for that. An incident is not the same as a problem. In its ITIL glossary, Axelos defines an incident as:

“An unplanned interruption to an IT service or reduction in the quality of an IT service. Failure of a configuration item that has not yet affected service is also an incident – for example, failure of one disk from a mirror set.”

When an incident is recorded on the Service Desk, it’s generally a break/fix issue. Some examples of incident tickets include:

  • The user’s mouse is broken
  • Microsoft Office or other software needs to be installed
  • The user is having a problem with their email
  • A personal device won’t start
  • A non-intrusive hardware failed, such as a single RAID disk failure or fan going out on a server

There are two keys to understanding incidents:

  1. They are unplanned.
  2. They have a limited effect on one user or service.

Notice I didn’t call incidents problems. Problems have a different definition from incidents when discussing the service desk. It’s wise not to mix the two up.

In the ITIL world, incidents are handled through the Incident Management process under Service Operations in ITIL v3. ITIL 4 handles incidents in the Incident Management practice under Service Management.

P = Problem

Problems are related to and different from incidents. Axelos defines a problem as:

 “A cause of one or more incidents. The cause is not usually known at the time a problem record is created, and the problem management process is responsible for further investigation.”

A problem is the root cause of one or more incidents that pertain to the same issue. For example, you have an internet outage. Dozens of people report their internet connectivity is out. Each call is a single incident, which spawns a service desk ticket that has the same basic subject line: Internet out. For each incident, we don’t know whether the cause is hardware, network routing, software, or the telecommunications provider.

The Service Desk is alerted and realizes that dozens of incidents all relate to the same root cause—the problem. The Service Desk agents create a problem ticket, escalate the problem to the next level, and then link all the incident tickets to the new problem ticket. When the Internet connection issue is solved, the tech closes the root cause problem ticket, which in turn closes all the incident tickets associated with it. Dozens of incidents are handled and documented in one place.

Some examples of problems (root cause issue) include:

  • Server failures
  • Network issues
  • Telecommunications issues
  • Vendor Web app outages

Problems differ from incidents in that they are usually identified in one of three ways:

  1. By multiple incidents all showing the same symptoms, such as when multiple users all report an internet outage.
  2. When there is a single significant error or incident, for which the cause is unknown, such as when an alarm goes off on a monitoring system.
  3. When a problem is discovered before it impacts service, such as when a tech discovers a failed RAID drive, a server fan starts making noise, or a technician makes a mistake.

In ITIL v3, problems are handled in the Problem Management process under Service Operation. ITIL v4 handles problems under the Problem Management practice under Service Management.

S = Service Request

Incidents and problems deal with needs. Something is broken and needs to be fixed. Service requests deal with wants. Someone wants a service that’s advertised in the Service Catalog, and they submit a Service Desk request to get it. A service request ticket is created and routed to the appropriate resource for fulfillment.

As Axelos puts it, a service request is:

“A formal request from a user for something to be provided – for example, a request for information or advice; to reset a password; or to install a workstation for a new user. Service requests are managed by the request fulfilment process, usually in conjunction with the service desk. Service requests may be linked to a request for change as part of fulfilling the request.”

Service request tickets aren’t as urgent as incidents and problems. They can be scheduled, whereas incidents and problems need immediate resolution. Service requests are formal requests, they are planned and offered in the service catalog, and there is a predefined process to take for fulfilling a service request.

Some examples of service request tickets are:

  • Ordering upgraded hardware
  • Requesting an account for a new user
  • Moving a telephone extension
  • Creating an email group

TIPS for putting it all together

Let’s return to our TIPS acronym to finalize the differences between these four terms.

Put it all together and you get the word TIPS, which is a handy acronym for remembering how Service Desk events are handled.

Additional service desk resources

For more information on successful service desks, check out these BMC Blogs:

Access the 2020 Gartner Magic Quadrant for ITSM

The Gartner Magic Quadrant for ITSM is the gold-standard resource helping you understand the strengths of major ITSM software vendors, insights into platform capabilities, integration opportunities, and many other factors to determine which solution best fits your needs.


These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.

See an error or have a suggestion? Please let us know by emailing blogs@bmc.com.

BMC Bring the A-Game

From core to cloud to edge, BMC delivers the software and services that enable nearly 10,000 global customers, including 84% of the Forbes Global 100, to thrive in their ongoing evolution to an Autonomous Digital Enterprise.
Learn more about BMC ›

About the author

Joe Hertvik

Joe Hertvik

Joe Hertvik works in the tech industry as a business owner and an IT Director, specializing in Data Center infrastructure management and IBM i management.

Joe owns Hertvik Business Services, a content strategy business that produces white papers, case studies, and other content for the tech industry. Joe has produced over 1,000 articles and other IT-related content for various publications and tech companies over the last 15 years.

Joe also provides consulting services for IBM i shops, Data Centers, and Help Desks.

Joe can be reached via email at joe@joehertvik.com, or on his web site at joehertvik.com.