Issue tracking system

From Wikipedia, the free encyclopedia
  (Redirected from Issue tracking)
Jump to: navigation, search

An issue tracking system (also ITS, trouble ticket system, support ticket, request management or incident ticket system) is a computer software package that manages and maintains lists of issues, as needed by an organization. Issue tracking systems are commonly used in an organization's customer support call center to create, update, and resolve reported customer issues, or even issues reported by that organization's other employees. An issue tracking system often also contains a knowledge base containing information on each customer, resolutions to common problems, and other such data. An issue tracking system is similar to a "bugtracker", and often, a software company will sell both, and some bugtrackers are capable of being used as an issue tracking system, and vice versa. Consistent use of an issue or bug tracking system is considered one of the "hallmarks of a good software team".[1]

A ticket element, within an issue tracking system, is a running report on a particular problem, its status, and other relevant data. They are commonly created in a help desk or call center environment and almost always have a unique reference number, also known as a case, issue or call log number which is used to allow the user or help staff to quickly locate, add to or communicate the status of the user's issue or request.

These tickets are so called because of their origin as small cards within a traditional wall mounted work planning system when this kind of support started. Operators or staff receiving a call or query from a user would fill out a small card with the user's details and a brief summary of the request and place it into a position (usually the last) in a column of pending slots for an appropriate engineer, so determining the staff member who would deal with the query and the priority of the request.

Issues[edit]

Issues can have several aspects to them. Each issue in the system may have an urgency value assigned to it, based on the overall importance of that issue. Low or zero urgency issues are minor and should be resolved as time permits. Other details of issues include the customer experiencing the issue (whether external or internal), date of submission, detailed descriptions of the problem being experienced, attempted solutions or work-arounds, and other relevant information. As previously noted, each issue maintains a history of each change.

Workflow[edit]

An example scenario is presented to demonstrate how a common issue tracking system would work:

  1. A customer service technician receives a telephone call, email, or other communication from a customer about a problem. Some applications provide built-in messaging system and automatic error reporting from exception handling blocks.
  2. The technician verifies that the problem is real, and not just perceived. The technician will also ensure that enough information about the problem is obtained from the customer. This information generally includes the environment of the customer, when and how the issue occurs, and all other relevant circumstances.
  3. The technician creates the issue in the system, entering all relevant data, as provided by the customer.
  4. As work is done on that issue, the system is updated with new data by the technician. Any attempt at fixing the problem should be noted in the issue system. Ticket status most likely will be changed from open to pending.
  5. After the issue has been fully addressed, it is marked as resolved in the issue tracking system.

If the problem is not fully resolved, the ticket will be reopened once the technician receives new information from the customer. A Run Book Automation process that implements best practices for these workflows and increases IT personnel effectiveness is becoming very common.

See also[edit]

References[edit]

  1. ^ Joel Spolsky (November 8, 2000). "Painless Bug Tracking". Retrieved 29 October 2010. 

External links[edit]