Trouble Ticket System

Contents:

1. Abstract
   1. What is a Trouble Ticket System?
   2. What is a Problem?
   3. What is an Incident Report?
   4. What is a Trouble Ticket?
   5. What is an Action?
   6. What is a Systematic Problem?
   7. Who are the parties in this system?
2. Architecture
   1. User Interface
   2. Alarms and Events
   3. Notification
      1. Requester notification
      2. Owner notification
      3. Coordinator notification
   4. Forms and Reports
   5. Trouble Ticket Database
3. Work Flow
   1. Requester sends incident report
   2. Coordinator triages incident report
   3. Has a ticket for this problem been opened already?
   4. Is a site visit required?
   5. Provider takes action
   6. Can ticket be closed?
   7. Is ticket old or has scheduled visit passed?
   8. Periodic activities
4. Timing
5. Security -- Authorization and Authentication
   1. Requester
   2. Owner
   3. Collaborator
   4. Coordinator
6. Database Entities
   1. Incident Report
      1. Fields
      2. Events
      3. Interface
   2. Trouble Ticket
      1. Fields
      2. Events
      3. Interface
   3. Action Report
      1. Fields
      2. Events
      3. Interface
   4. Systematic Problem
      1. Fields
      2. Events
      3. Interface
   5. User
      1. Fields
      2. Events
      3. Interface
   6. Department
      1. Fields
      2. Events
      3. Interface

1. Abstract

1.1. What is a Trouble Ticket System?

Professional quality handling of problems requires a problem tracking system. Such a system is referred to as a "trouble ticket" system. A basic trouble ticket system acts like a hospital chart, coordinating the work of multiple people who may need to work on a problem.

The trouble ticket system should be a reference "knowledge database," providing information on solving similar problems in the future.

1.2. What is a Problem?

A problem is any situation that reduces the effectiveness or job satisfaction of a user or a group of users as long as it goes unresolved. A problem is also a condition that impairs the operation of a computer, network, or other system. The resolution of problems requires action on the part of either the user (hereafter "requester" to distinguish from users of the Trouble Ticket System) or a technical support professional (hereafter "provider").

Problems that a requester can resolve himself or herself do not require the attention of a provider. When problems could have been solved by the requester provided that training, documentation or other resources were available, the provider needs to be aware of this and make efforts to make the training, documentation or other resources available to the requester.

1.3. What is an Incident Report?

An incident is a problem experienced by a requester or by event detectors. The incident is reported to the Trouble Ticket System either manually or automatically, in the case of event triggers.

Because the same problem may be reported by more than one source, the system must allow individual incidents reported by alarms and by requesters to refer to a single trouble ticket. It is important to track all incident reports for a problem. The reports help to accurately gauge the problem and its scope.

1.4. What is a Trouble Ticket?

A trouble ticket is a representation of a problem and the resolution of the problem. A ticket is opened upon the receipt of an incident report for a new problem. Multiple incident reports may refer to the same ticket. If the incident report refers to the problem covered by an existing ticket, the incident report will be linked or attached to the existing ticket. A ticket is "owned" by the provider who is responsible for the resolution of the problem. A ticket is closed when the problem is resolved.

Tickets have a priority based on the urgency and scope of the problem. The higher the priority, the greater the need for expedient action.

Trouble tickets become the central repository for information concerning a particular problem. The ticket tracks the problem from its initial identification to its correction and closure. The trouble ticket system coordinator creates trouble tickets in response to incident reports.

A trouble ticket might need to be reissued or reopened when, after a short period, the problem resurfaces or when the ticket should not have been closed in the first place.

1.5. What is an Action?

An action is an individual step taken by a provider in response to a problem reported in a trouble ticket. The action may include calling the user, rebooting a machine, reinstalling software, or replacing defective equipment. There may be one or more actions required to resolve a particular problem.

1.6. What is a Systematic Problem?

A systematic problem is the abstraction of one or more problems. It has one or more trouble tickets attached to it. Individual problems recorded in trouble tickets are often part of a greater, systematic problem. For example, a particular machine crashing is reported as a problem. In the process of determining why the machine crashes, the support staff learn that there is a problem with this model. Other machines of this model can be expected to crash. Therefore, the staff are prepared for the eventuality of further crashes and proactive steps can be taken.

Systematic problems have predictive benefit and form a knowledge base and a basis for the generation of Frequently Asked Questions.

1.7. Who are the parties in this system?

The three categories of users of the system are:

1. Requesters -- request assistance by creating Incidence Reports
2. Providers -- technical support staff who resolve problems; a provider may be the trouble ticket owner or a collaborator, one who assists the owner
3. Coordinators -- manage trouble ticket system

Back to top

2. Architecture

2.1. User Interface

A user interface is provided by a Web browser acting as a front end to the system. To support all features of the system, the browser should be HTML 3.2-compliant and in particular should support frames, tables, and forms.

Through the interface the requester submits new incident reports, checks the status of open trouble tickets, and checks the status of billing information, which includes charges pending, charges paid month-to-date, and charges paid year-to-date.

2.2. Alarms and Events

Incident reports can be created automatically by intelligent systems programmed to generate alarms based on trigger events.

2.3. Notification

2.3.1. Requester notification

The system sends e-mail confirmation notices to the requester when an incident is assigned to a trouble ticket, when a trouble ticket is closed, and when the account has been paid.

2.3.2. Owner notification

The system sends an e-mail notice or other notification to the provider who is assigned as the ticket owner by the coordinator. Urgent priority incidents will generate a signal to a pager for immediate action. The generation of high, medium, and low priority tickets will generate e-mail notification indicating a problem needs attention.

Tickets aged beyond their resolution time limit will generate notification messages to the ticket owner. The time limit depends on the priority of the trouble ticket. See "Timing" below.

2.3.3. Coordinator Notification

The coordinator is notified when the system receives an incident report or when an incident report is updated or deleted.

When a trouble ticket ages beyond its resolution time limit, the system sends the coordinator a warning. The time limit depends on the priority of the trouble ticket. See "Timing" below. The ticket may require having the priority increased.

2.4. Forms and Reports

Forms generated by the system include:

• Service request and agreement
• Trouble ticket completion acknowledgement
• Billing authorization

Reports generated by the system include:

• Staff on-call schedule
• Ticket status month-to-date
• Ticket status by owner
• Ticket status by requester and by requester's department
• Problems by system

2.5. Trouble Ticket Database

Entities in the database include:

• Trouble Ticket -- Core repository of information on problems; may have more than one incident report refer to a particular trouble ticket and may have more than one action refer to a particular trouble ticket.
• Incident Report -- Report of a problem for resolution. Incident reports are attached to a particular trouble ticket.
• Systematic Problem -- Abstraction of trouble ticket problems; may have more than one trouble ticket refer to a particular problem.
• Action -- Each site visit or other action by provider warrants a separate action report.
• User -- An individual associated with the Trouble Ticket System, either a requester, a provider, or a coordinator.
• Department -- Lookup table of user's department (English, Telecommunication Services, etc.)

Back to top

3. Work Flow

The work flow defines the events and actions performed by agents on objects.

3.1. Requester Sends Incident Report

Includes user information, problem description

Report includes three preferred time slots for on-site visit.

3.2. Coordinator Triages Incident

If incident report is submitted by a new user, create new user.

3.3. Has a ticket for this problem been opened?

• Yes -- attach to existing ticket and remind owner, reprioritize
• No -- create new ticket and notify owner.
• In either case, send requester acknowledgement and notification of trouble ticket number.

3.4. Is a site visit required?

• Yes -- schedule a visit
• No -- continue

3.5. Provider takes Action

• call requester
• visit site
• assess problem
• run diagnostics
• call vendor
• order parts
• call in repair

3.6. Can ticket be closed?

• Yes
  1. close ticket
  2. send notice to requester
  3. send notice to owner
  4. update statistics
  5. send billing information to accounting
  6. abstract problem to knowledge base: include links to vendor site, other on-line references
• No -- continue

3.7. Is Ticket old or has scheduled visit passed?

• Yes -- remind owner. If ticket is very old, send reminder to coordinator. Increase priority.
• No -- Repeat starting with 1.3.1 or 1.3.5 until the ticket is closed.

3.8. Periodic Activities

• Owner report: all open tickets for owner
• Progress report: status of all tickets open and closed to date
• All tickets by department, by requester, by owner
• Archive incidents and tickets at end of FY
• Send update to accounting of unpaid tickets
• Mark the tickets confirmed as paid by accounting [manual]

Back to top

4. Timing

Depending on the severity of a problem, each trouble ticket has a period within which a response is required and another period within which the problem should be resolved.

Response time:

1. Urgent: 1 hour
2. High: 8 hours
3. Medium: 3 days
4. Low: 4 weeks

Resolution time:

1. Urgent: 8 hours
2. High: 3 days
3. Medium: 2 weeks
4. Low: 2 months

Back to top

5. Security -- Authorization and Authentication

Authorized users will gain access to the system using a username and password. Depending on the security level of the user according to the user's record in the User table, the user will have different access capabilities.

Access by requesters who are not in the User table will be limited to creating incident reports only. On receipt of an incident report submitted by a new user, the coordinator will contact the user to verify the information, then create a new user record.

5.1. Requester

Requesters may create new incident reports, view and update their own incident reports, view trouble tickets to which their incident reports are attached, and get status reports.

5.2. Owner

Trouble Ticket owners may view and update their own trouble tickets and attached incident reports. They may create and edit actions. The Coordinator assigns ownership of a trouble ticket to a Provider.

5.3. Collaborator

Collaborators may view trouble tickets and attached incident reports and can create and update actions. Collaborators on a problem are drawn from Providers. No previous authorization of a provider is required, though coordination with the owner is expected.

5.4. Coordinator

Coordinators have full access privileges to the system.

Back to top

6. Database Entities

6.1. Incident Report

The Incident Report is the requester's report of a problem or incident and a request for action to correct the problem. Incident reports may also be generated automatically by alarm systems.

Multiple events can occur for the same problem, requiring a single point of action. Hence, separate incident reports may refer to a single trouble ticket. All incidents should be tracked. This permits providers to more accurately track the problem and to assess the severity and scope of the problem.

The option of attaching a new incident to an existing and open trouble ticket should be permitted but not required. The requester attaches an incident to a trouble ticket by entering the trouble ticket number in the incident report. It is the responsibility of the coordinator, who is aware of the full scope of the trouble ticket system, to ensure an incident is attached to the correct trouble ticket.

When an incident report is received by the system, the coordinator must determine whether the incident refers to an open trouble ticket or whether a new trouble ticket needs to be opened. If the incident refers to a recently closed trouble ticket, the coordinator must reissue the trouble ticket.

Immediate feedback tells the requester that the system has received the incident report. The message will say that the incident will be triaged and that the requester will receive confirmation notification with the trouble ticket number to which the incident has been attached. Notification will be by e-mail, or if e-mail is not preferred, by phone.

If an incident is not attached to a trouble ticket within the response time limit, the coordinator will be notified of the untriaged incident report. See "Timing" above.

6.1.1. Fields

1. incident_no -- Auto-assigned index number
2. open_date -- Auto-assigned creation date
3. open_time -- Auto-assigned creation time
4. user_name -- Reporter of problem. Foriegn key into User table.
5. ticket_no -- Incident reports for new trouble tickets are attached by Coordinator; Requester may enter existing ticket_no if known. Foriegn key to Trouble Ticket table.
6. system -- Affected system name, e.g., "Macintosh IIci"
7. platform -- Macintosh, Win3.x, Win95, WinNT, UNIX, Other
8. product -- Product kind, e.g., "cpu", "monitor"
9. serial_no -- serial number of device
10. inventory_no -- property tag number of device. Could be foriegn key into Inventory table for linkage with inventory maintance and problem tracking.
11. problem_title -- Summary of problem
12. problem_desc -- In-depth, free-form description of the problem
13. priority -- Severity of problem and extent of its impact
14. location -- site of problem or affected system
15. problem_start_date
16. problem_start_time
17. problem_stop_date
18. problem_stop_time

6.1.2. Events

• Create New Incident Report
• Update Existing Report: Similar to Create New Incident Report, except fields are prefilled with current information and RequesterName and TTNumber fields cannot be changed. System will notify Coordinator of changes.
• Find Incident Report -- by requester, date reported, site, platform, subject
• Delete Incident Report -- should only be performed when the Incident was created erroneously, and not after being attached to a trouble ticket. System will notify Coordinator of deletion.
• Attach to New Trouble Ticket -- for Coordinator only -- creates a new Trouble Ticket record and prefills the Priority, Site, Subject, and Description.
• Attach to existing Trouble Ticket

6.1.3. Interface

6.2. Trouble Ticket

6.2.1. Fields

1. ticket_no -- Auto-assigned index
2. date_init -- Auto-assigned creation date
3. time_init -- Auto-assigned creation time
4. owner -- Assigned by Coordinator from among Providers. Foriegn key into User table.
5. problem_title -- summary of problem
6. problem_desc -- in-depth description of problem
7. priority -- Urgent, High, Medium, Low
8. status -- Opened, Held, Closed
9. due_date -- When must problem be resolved
10. scope -- Workstation, Server, LAN, Router, Department, Campus
11. type -- Scheduled, OneTime, Ongoing, Emergency
12. resolution -- Summary of what was done to take care of the problem.
13. date_closed -- Auto-assigned at closure
14. time_closed -- Auto-assigned at closure
15. notes -- information about solution of problem, comments.
16. problem_no -- foreign key to problem table

6.2.2. Events

• Create New Trouble Ticket -- creates a new trouble ticket from an incident report. Ticket will inherit description from incident.
• Update Existing Trouble Ticket
• Find Trouble Ticket -- by number, priority, owner, status, date opened, site, platform, subject
• Delete Trouble Ticket -- should only be performed when the trouble ticket was created erroneously and not after being attached to a Systematic Problem or when it has attached incident reports or actions
• Show related incident reports
• Show related actions
• New Action
• Close Trouble Ticket
• Reissue -- Reopen a trouble ticket when the problem reappears within a short period or when the ticket was closed by mistake.
• Attach to new Systematic Problem -- creates a new Systematic Problem record and prefills the Subject, Description, and Resolution
• Attach to existing Systematic Problem

6.2.3. Interface

New	Find
object zone
Status: Found: 17

Scrollable List:

Ticket Number	Status	Priority	Subject	Start Date/Time
000987	Open	High	AppleTalk network down	12-06-97 08:23:42

The scrollable list shows each trouble ticket on a single line. Clicking on the ticket number displays the data for that ticket in full.

6.3. Action Report

6.3.1. Fields

1. ticket_no -- ticket number to which Action is attached. Foriegn key into Trouble Ticket table.
2. provider -- name of collaborator performing action. Foriegn key into User table.
3. service_desc -- description of service rendered
4. date_actual_start
5. time_actual_start
6. time_spent -- actual time spent providing service
7. time_billed -- 1 hour minimum: default to if (time_spent <=1, 1, time_spent)
8. billing_rate -- Provider rate or time-and-a-half for evenings and weekends
9. billing_charge -- TimeBilled * BillingRate
10. action_no -- Auto-assigned index number
11. status -- Started, Completed, Delayed.
12. date_created -- Auto-assigned creation date
13. time_created -- Auto-assigned creation time
14. date_scheduled_start
15. time_scheduled_start
16. date_actual_stop
17. time_actual_stop
18. date_scheduled_stop
19. time_scheduled_stop

6.3.2. Events

• Create New Action
• Update Existing Action
• Find Action -- by performer, date started, date finished, title
• Delete Action -- should only be performed when the action was created erroneously

6.4. Systematic Problem

6.4.1. Fields

1. problem_no -- Auto-assigned by system
2. date_created -- Auto-assigned by system
3. time_created -- Auto-assigned by system
4. title
5. description
6. resolution
7. opener -- name of provider creating Systematic Problem record. Foriegn key into User table.

6.4.2. Events

• Create New Systematic Problem
• Update Existing Systematic Problem
• Find Systematic Problem -- by subject
• Delete Systematic Problem -- should only be performed when the systematic problem was created erroneously and not after trouble tickets have been attached
• Show attached Trouble Tickets

6.5. User

6.5.1. Fields

1. last_name
2. first_name
3. full_name -- last_name, first_name
4. department
5. location
6. mail_code
7. phone_no
8. pager
9. email
10. billing_contact -- name of accounting person
11. billing_phone
12. billing_address
13. billing_mail_code
14. billing_account -- UT account or CCA
15. billing_authority -- Signature authority on account
16. security_level -- Requester, Provider, Coordinator
17. password

6.5.2. Events

• Create New User
• Find User
• Update Existing User
• Delete User

6.6. Department

6.6.1. Fields

1. department
2. mail_code
3. building
4. room

6.6.2. Events

• Create New Department
• Update Existing Department
• Delete Department
• Find Department

Back to top

Trouble Ticket System Outline

Last updated on December 10, 1997.