Issue tracking system

from Wikipedia, the free encyclopedia

An issue tracking system ( ITS ; synonyms: help desk system, service ticket system, ticketing system, task tracking system, support ticketing system, trouble ticket system, request tracking system (RTS), partly also case processing system) is a type of software to handle the receipt, confirmation, classification and processing of customer inquiries (tickets or cases). Incoming customer calls, e-mails, faxes and the like are regarded as inquiries.

Modern issue tracking systems often have interfaces to other systems such as B. Customer databases .

What all these systems have in common is the ability to assign a ticket to a workstation or to a person within a workstation for further processing until the solution ( closed ticket ). The ticket system is intended to ensure that no message is lost and that a general overview of the processes to be processed is possible at any time.

important functions

The inquirers' concerns can be divided into different urgency levels in accordance with the Service Level Agreements (SLA) and the Operational Level Agreements (OLA), with the associated escalation levels - if the SLA or OLA are not complied with.

Issue tracking systems are used to maintain or restore the smooth flow of task processing.

Issue tracking systems perform various functions, in particular

  • Recording of malfunctions and errors and inquiries (for example through email response management systems )
  • Distribution and assignment of the agents
  • Monitoring of the processing and the processing time and quality
  • Guaranteeing compliance with internal processes through forced control via workflows
  • statistical evaluation of the ticket volume
  • automatic generation of tickets by alarm systems such as B. a network monitoring
  • Compliance with external service commitments ( Service Level Agreement )
  • Systematic collection of questions and answers for FAQs


A ticket is the electronic form of a request (which is usually reported by the IT user). This can

  • an incident
  • another request (service request) , such as B.
    • a change request ( request for change)
    • an informative request (Request for Information / Education)
    • a request for (functional) enhancement (request for enhancement)

to the service desk or the support units (according to ITIL ).

Data of a ticket

Examples of the content of a ticket

  • unique (consecutive) ticket number
  • Ticket creator (support, request)
  • Time of creation
  • Personal details (name, telephone number, address, availability)
  • Priority level
  • Urgency (appointment requests)
  • category
  • Problem Description
  • Troubleshooting
  • Overview of previous agents with time information
  • Processing status (open, assigned, in progress, follow-up, resolved)
  • Affected / disturbed asset (system, device, PC, printer, screen, program, etc.)

Areas of application

Case management systems (FBS) are used in different areas of application. Examples are:

  • Contact points in the administration system
  • Technical projects

In the EDP , an FBD is used for adjustments, extensions, troubleshooting and the system test of a project. Reasons for using an FBS are:

  • improve the quality of the activity delivered
  • make the process more transparent
  • preserve the history of the case
  • to draw conclusions from the histories for the future and to optimize the process

A ticket system is also part of a service management software or an enterprise resource planning software. The ticket system can also be used, for example, in project management to delegate project tasks and monitor progress. In order to be able to assign employees to the individual tickets, functions such as resource planning and planning boards are often used.

Example IT support

Case processing in the IT

As a rule, the process within the framework of support is such that a request for adaptation, change, expansion or errors is entered by the user in the FBS. The entry can be made online or by calling the hotline . In this case, the hotline employee will enter the information into the system. The employee finds a solution for the request in the error database. The customer accepts the solution and the case is closed.

If this is not possible, the hotline will illustrate the case as a storyboard or record it in some other way. Verbal descriptions are avoided as far as possible, especially in the case of changes in complex applications . Because the spoken word often leads to misunderstandings between the skilled hotline employee or the customer and the technically skilled, but not so well-trained technical developer of the technology. A case analysis is then carried out by the hotline. System settings or reinstallation may fix the problem .

If this step does not solve the problem, the

  • Takeover of the technology: the technical department insists on the case study, which explains the technical requirement in an easily understandable, clear manner. The analysis can possibly provide an overlooked or new way of troubleshooting, which in this case is communicated to the hotline. If this is not the case or if the hotline cannot get the problem under control with the proposed technology, it usually comes to
  • Code change: a draft specification is made here. If it is not an error , the customer must be informed of the costs ( effort ) incurred . After the code change, every developer must test his / her module (s) in order to then verify the whole thing in the system or integration test .
  • The system test department, which is often identical to the hotline, now takes over the case, tests it with realistic data and returns it to the technology department if there are any discrepancies. Otherwise the solution of the case will be completed by handing over the customer.

Advantages and disadvantages


  • Uniform system for suggested changes, extensions and error handling avoids bureaucratic effort.
  • Automatic notification to the project manager, developer / maintenance staff of the code part, test department and finally to the customer when the error has been corrected.
  • Online check by the project manager and the customer of the current status of an adjustment / extension / correction.
  • Since the system is not customer-specific, but a general solution for projects and customers, it can be quickly adapted for individual use. It is thus an inexpensive, unified solution for case handling.
  • The transparency of the process significantly improves the quality of the work.
  • Standardization of processes: by analyzing the case histories, it is possible to improve the processes of the organization
  • Most of the time, cost savings are achieved by standardizing and improving processes. Unnecessary steps are eliminated and employees who often cause errors are retrained.
  • For clear communication between the parties involved, a clear designation, e.g. B. an ID can be assigned.


  • Costs: the FBS is developed and maintained in-house. When buying a finished FBS, running costs are to be expected (host computer, server, infrastructure, administrator, time for entering and analyzing, etc.).
  • Required training and familiarization of employees and customers. The associated costs are lower, the more user-friendly the application is, which, however, makes the design more complex and increases the costs for the system.


Known issue tracking systems (selection):

Legal Aspects

The use of issue tracking systems in companies also makes it possible to determine the work performance of individual employees and teams - with all the associated labor and data protection implications. Issue tracking systems could be used to monitor employee performance and behavior . It should also be checked whether employees within a group can observe each other's work. In this context, the book authors of the open source program Request Tracker mention the “peer pressure” that arises from the use of issue tracking systems.

Where employee codetermination applies, the introduction and use of such tools may be subject to codetermination ( Section 87 Paragraph 1 Number 6 of the Works Constitution Act ). The use can then be regulated with company agreements, e.g. B. in the public service, where there are corresponding service agreements. The application results, for example, in the possibility of intensifying work and increasing the degree of external control . For this reason, a risk assessment may be necessary.

Web links

Individual evidence

  1. "This kind of system ensures high visibility… This information will bring in, all by all, peer pressure to get your tickets closed." From Jesse Vincent, Robert Spier, Dave Rolsky, Darren Chamberlain & Richard Foley: RT Essentials , 2005, ISBN 0-596-00668-3
  2. Example of a service agreement for “RT” in use in the RRZ of the University of Hamburg ( memento of the original from December 31, 2015 in the Internet Archive ) Info: The archive link was automatically inserted and not yet checked. Please check the original and archive link according to the instructions and then remove this notice. (PDF; 391 kB) @1@ 2Template: Webachiv / IABot /
  3. Specification of § 5 ArbSchG through § 3 Paragraph 1 Sentence 3 of the Workplace Ordinance (ArbStättV)