Help Desk System: Architecture & Requirements
3. Trouble Ticket Structure
Headers. Inevitably, a trouble ticket begins with a number of fixed fields. These generally include:
- Time and Date of problem start.
- Name and user id of the customer opening the ticket.
- The customer contact info.
- Severity of the problem (possibly separating the "customer severity" and the "company priority", since these could be different).
- A one-line description of the problem for use in reports.
- Ticket "owner" (one person designated to be responsible overall).
There can be many other fixed fields for specific purposes. There may also be different kinds of tickets for different problems, where the ticket format differs mainly in fixed fields.
Incident updates. The main body of trouble tickets is usually a series of freeform text fields. Optimally, each of these fields is automatically marked with the time and date of the update, and with the user id of the operator making the update. Since updates are frequently recorded sometime after the problem is fixed, however, it is useful to allow the operators to override the current time stamp with the time the update was actually made. (In some implementations, both times may be kept internally).
The first incident update usually is a description of the problem. Since the exact nature of the problem is usually not known when the ticket is first opened, this description may be complex and imprecise. For problems that are reported by electronic mail, it is useful to be able to paste the original message in the ticket, particularly if it contains cryptic or extensive information (such as a user's traceroute output). At least one such arbitrarily-long freeform field seems necessary to contain this kind of output, although it is better to allow arbitrarily long messages at any stage.
Subsequent update fields may be as simple as "Called customer; no answer". Some systems allow these kinds of updates
to be coded in fixed fields; most use freeform text.
There should always be an indication of what the next action for this ticket ought to be. Again, this may be
implemented as a special fixed field, or by convention of using the last line of text.
Advanced systems may also need a facility to allocate the amount of time a ticket is open between multiple sources.
A company may use its help desk system to statistically track its performance on responding to problems. (e.g.,
Mean Time Between Failure and Mean Time To Repair reports). Frequently, though, repairs are stopped at the customer's
request. ("It's not that important a machine and I don't feel like coming in--can you defer it until Monday Morning?"). In
these cases the ticket needs to remain open, but there needs to be a notation that the ticket is now
in "customer time" rather than "company time". The durations of "customer time" need to be excluded from MTBF and
MTTR reports. Complicated problems could move back and forth between "company time" and "customer time" repeatedly. This probably implies
that each incident update may have a time and date of status change, and that these status changes
can be read and aggregated by reporting programs.
|
