Service Management Blog

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

5 minute read
Joe Hertvik

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.

Discover the impact intelligent automation can have on creating and deploying innovative services.

Additional service desk resources

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

New strategies for modern service assurance

86% of global IT leaders in a recent IDG survey find it very, or extremely, challenging to optimize their IT resources to meet changing business demands.

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

Business, Faster than Humanly Possible

BMC works with 86% of the Forbes Global 50 and customers and partners around the world to create their future. With our history of innovation, industry-leading automation, operations, and service management solutions, combined with unmatched flexibility, we help organizations free up time and space to become an Autonomous Digital Enterprise that conquers the opportunities ahead.
Learn more about BMC ›

About the author

Joe Hertvik

Joe Hertvik PMP owns Hertvik & Associates, an IT infrastructure and marketing management consultancy. Joe provides contract services for IT environments including Project Management, Data Center, network, Infrastructure, and IBM i management.

His company also provides Marketing, content strategy, and content production services for B2B IT industry companies. Joe has produced over 1,000 articles and IT-related content for various publications and tech companies over the last 15 years.

Joe can be reached via email at or LinkedIn.