How much detail should people put in tickets

By ITIL® from Experience ©

Some people do not intuitively know what to write in a ticket like an incident, a service request or a problem.

From experience, here is some best practice when it comes to the information and details to put in a ticket, work notes or actions. The information in the ticket should:

• Tell a story;
• Enable anyone to work on it at anytime;
• Be easily understood at a glance; and
• Provide a status the client understands.

What follows is guidance for this best practice.

1. Tell a Story

A story starts with a title. Similar to the subject line of an email, the title should announce/summarize the nature of the request or issue (e.g. request access to the financial system). A story has a beginning, a middle and a conclusion. The ticket’s entries should flow in a similar fashion.

The beginning or introduction is a detailed description of what the client is looking for, or in the case of a call to the Service Desk why the client called. It is critical that all the requirements be clearly stated otherwise the likelihood of not meeting the client's expectation is extremely high (See Should a service request be reopened or a new one logged and Should the incident be reopened or a new one logged).

The middle contains work notes or actions taken which are discussed below. Finally, the conclusion explains how the incident was resolved, the delivery status of the service request or the cause and solution to the problem (e.g. known error, workaround or RFC).

The story can be told in a bullet point format. Few IT specialists have a degree in English Literature and there is a good reason for it: it is not needed for technical work. Moreover, having a lot of text to read cost time and thus, money.

2. Anyone must be able to work on it at anytime

Even though the ticket might be assigned to someone, anyone must be able to pick it up and continue the work. The goal is for IT to keep working even if someone calls in sick or is reassigned to deal with an emergency. The ticket must include:

• The work that was done and the result (e.g. test performed in the lab gave the same error)
• A proposed next step to resolve the incident (e.g. instead of simply writing WFM meaning “works for me” a suggestion of what might be causing the fault should be provided)
• If IT is waiting for the client it must:
  • Say if a voice mail was left, an email was sent or an on-site visit was made or scheduled; and
  • Provide a detailed description of what the client was asked (see Users are not getting back to us. How to avoid breaching our SLAs).

Clients do not care who they talk to if they get good service. However, nothing irritates a client more than being asked questions they previously answered. Good documentation avoids frustration, saves time and effort.

3. Is Easily understood at a glance

When the ticket is escalated1 , a manager or anyone that needs to work on the ticket must be able to quickly review it and understand:

• What the issue/request is about;
• What has been done to date;
• If there were delays (e.g. the cause of the SLA breach); and
• What lead/might lead the customer or the user to be dissatisfied (see What is another term for User).

Moreover, the information must clearly demonstrate the work done. As mentioned previously, the work notes or actions should mention every email sent to the customer, another team member or, that a voice mail was left. If the ticket does not contain the last action taken, it is incomplete.

As a Service Desk Team Leader said: “Everything you put in the ticket is like padding on your behind; so that if it comes back to bite you in the arse it won’t hurt as much.”

4. Provide a status the client understands

Even though a self-service tool like an actionable Service Catalogue may not be in place today, the ticket can be printed at any time and shown to the client. Therefore, it is advisable to:

• Use business language that it is respectful (e.g. no RTFM2 or mention that it`s a user problem.
• Avoid techno-babble as it may cause an unnecessary call to the Service Desk (if it cannot be avoided to help IT specialists it should be in private notes).
• State what has been done and what is being done.
• Say if IT is waiting for something from the client or a supplier – and say what it is waiting for.

More importantly, if it doesn’t say that IT is working on it, from the client’s perspective IT is not working on.

Finally, what is in the ticket must be useful to the reader, thus, it should:

• Help colleagues (point no.2)
• Enable Managers and Team Leaders to quickly make decisions (point no. 3)
• Keep the client informed on the progress (point no. 4)
• Provide information to enable other ITIL Processes, while not giving away security information.

In closing, no one ever got their hand slapped for putting too much information in a ticket (unless it’s a security issue). However, people have been criticized for not putting enough. The other challenge of course is to get people to log tickets in the ITSM tool and to keep them updated (see How to get people to log tickets).

Published on: 2018-03-10

Related:

• How to get people to log tickets
• How to explain that following a process does not cause delays
• Should everyone be allowed to log problems
• Who should log the RFC
• Should incidents be closed or kept open for monitoring
• How to close incidents and request for service when users are not getting back to us
• How can we tell that no one has taken ownership of an Incident before we get a complaint

More on People

From Around the Web:

• 6 Reasons Why Ticket Tracking Software is Better than Email

ITIL Process > Request Fulfillment

Disclaimer

Copyright 2018 - ITIL® from Experience - D.Matte