For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone
Note: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
The Itil Community Forum: Forums
ITIL :: View topic - Terminology - tickets and incidents
Posted: Tue Sep 19, 2006 7:18 pm Post subject: Terminology - tickets and incidents
Hi
On my ITIL course our trainer was adamant that the word ticket is not an ITIL term stating that every problem raised with a Service Desk should be referred to as an incident. I still see 'ticket' used ......any thoughts?
Well, it is not a problem that is raised, but an incident
You are right and you are right. The word "ticket" is not an ITIL term. The correct ITIL term is 'Incident'. However, some argue that the ticket is the incident record, while the incident itself is the occurence of the interruption of service. In that case, calling both an incident could be misleading.
To be honest, as long as the team knows what an incident is and that they call it an incident, I don't get anal about what they call the incident record. Historically it has been called a ticket and if it can raise the level of comfort of your team, I don't see why you would push for a change. _________________ BR,
Fabien Papleux
Accenture
Technology Consulting | Service Excellence
Red Badge Certified
Still though, ITIL does not talk about "creating a ticket", it says "logging an incident". Both actions are identical but ITIL does not give a name to an incident record. _________________ BR,
Fabien Papleux
Accenture
Technology Consulting | Service Excellence
Red Badge Certified
I never tell my students in Foundations classes that their terminology is wrong unless there is a conflict between the organization's terminology and ITIL terminology [...]
I believe that's exactly what I said when I wrote:
Quote:
[...] as long as the team knows what an incident is and that they call it an incident, I don't get anal about what they call the incident record.
I would like to note that I had never heard someone making the case to call the record of an automated incident and a manual incident by two different names. Would you mind expanding on that?
Also, when you write:
Quote:
[...]the Service Desk may only create tickets for incidents which it cannot resolve and must escalate
Don't you tell your students that *all* incidents must be recorded? _________________ BR,
Fabien Papleux
Accenture
Technology Consulting | Service Excellence
Red Badge Certified
Joined: Aug 20, 2006 Posts: 25 Location: Indonesia
Posted: Thu Sep 21, 2006 3:46 pm Post subject:
It is only a term. It doesn't matter what name you want to give to the record when you log an incident or request whether you want to name it "ticket" or "incident record" or else. In my customer, when there is an incident related to PC hardware, the Service Desk will log the incident, print it and send the printed incident record (my customer call this a "ticket") to the hardware support vendor for troubleshooting. I never say that they are wrong because that "ticket" term already used widely in their IT organization and as long as they have and perform a good incident management process (including the Service Desk function that logs any incident and request), it is fine. So the answer is up to you what do you want to call it as long as you make sure that everyone understand and follow the defined processes.
In most shops a ticket is opened when the situation requires that support staff perform activities to correct the issue or support the user/client. You can get a call from a user, for example, reporting another instance of a known incident that affects a widely used service. You can record the information into the database for statistical reasons, but that specific incident that is being reported is already known and no ticket needs to be opened because the issue is already being worked on.
I'm sorry Juan. I have to disagree with this statement, but it's probably only a language issue.
Whenever an incident is reported, it needs to be recorded. If the user is reporting the same incident that one that is already being worked on, whether it will have its own ticket or whether it will be piggy backed onto another one mainly depends on the system you will be using, but each instance of the incident reported to the Service Desk needs to be recorded. The number of instances is actually important to determine its impact, and the impact of the subsequent problem.
For instance, a printer failure is likely to impact more than one user. The number of times the incident is reported is at least the number of affected users. You need the information for more than statistical reasons, especially if it happens at an odd moment like on a Sunday in a Bank. Furthermore, if the user has taken the time to contact the Service Desk, I would recommend that the Service Desk returns the favor and contact the user once the incident is solved, which makes the creation of a record of the contact even more essential. _________________ BR,
Fabien Papleux
Accenture
Technology Consulting | Service Excellence
Red Badge Certified
I'm just summarizing the operations of Service Desk.
For the first time the Customer Calls up for Incident, Service Request or Information, The Service Desk Creates a Ticket to record the call which, should be given to the customer for reference.
If the customer calls up the SD with reference to the ticket, before the committed time for solution, the SD can either view the status of the ticket and update the customer or use the same ticket for modification.
In case of a new issue, The Service Desk creates a new ticket.
In case of a same incident which was worked upon, the SD creates a ticket and relates to the previous ticket.
You see, I view a ticket as a work order. A call to the Service Desk will not necessarily create a ticket, but will always be recorded to show it came in.
I'm starting to follow man. You do not call all records a ticket, only the ones that need follow up. Now I get it... _________________ BR,
Fabien Papleux
Accenture
Technology Consulting | Service Excellence
Red Badge Certified
My philosophy is that a call which does not require investigation/diagnosis should not result in the creation of a ticket. In this category I place calls to the service desk to report an additional user report of an incident that is being worked on. I will create a record of the call and tie it to the original incident for statistical and follow up purposes, but not a new ticket. I will give the user making the duplicate report the _original_ ticket ID, so that when all those people call back for that same incident, they will all get the same resolution.
I base this on my belief that creating tickets for dupllicate reports of incidents only increases the chances of winding up with orphan tickets on the database.
Now, here's the catch -- not all service desk/incident/problem tools support this philosophy. If you HAVE to create the ticket for a duplicate report of an incident in order to track it and provide closure (even if just a call to inform of resolution), then I suggest that you place specific emphasis on the procedures for handling this situation, as well as procedures for verification and handling of possible orphan or "lost" tickets, to make sure the tickets are handled and closed properly.
Juan,
If I understand you correctly, you are suggesting that if 20 different users call the SD about Application X being unavailable, instead of creating 20 different tickets ('work orders'), you would rather create just 1 ticket and somehow record that it has been reported by 20 different users (e.g. by linking the incident ticket to call records).
I understand the reason why you prefer to do this, but I see one potential problem there: how does the SD know that these 20 calls related to the same incident? Although the symptoms they experienced (Application X being unavailable to them) were the same, the reason for these symptoms may have been different. For example, 12 of the users couldn't use the application because Router Y, which serves their location, was down, whereas the other 8 users couldn't use the application because their Router Z was down. So actually, there were 2 different incidents, for which I would like to see 2 different tickets. How would you address this potential problem in your approach?
It's important, however, to understand why that should be done, determine if there is a business justification to do it that way, and if so, document the requirement, communicate it and get it done.
I wholeheartedly agree with this. This is indeed the key to every choice made in any ITIL implementation.
I also follow your explanation of how you would go about having just 1 incident ticket in the situation I had presented. Besides the theoretical aspect and the business justification, there is - as you already pointed out in a previous post - the implementation aspect: what does your tool support and till what extend are you willing and able to customize it.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
