Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: JSPL
New Today: 79
New Yesterday: 63
Overall: 139408

People Online:
Visitors: 60
Members: 0
Total: 60

Languages
Select Interface Language:


Major ITIL Portals
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

Related Resources
Service related resources
Service Level Agreement
Outsourcing

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
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Terminology - tickets and incidents
Goto page 1, 2  Next
 
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk
View previous topic :: View next topic  
Author Message
AndyR
Newbie
Newbie


Joined: Sep 19, 2006
Posts: 1

PostPosted: Tue Sep 19, 2006 7:18 pm    Post subject: Terminology - tickets and incidents Reply with quote

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?
Back to top
View user's profile
Fabien
Senior Itiler


Joined: Sep 27, 2005
Posts: 207

PostPosted: Tue Sep 19, 2006 10:42 pm    Post subject: Reply with quote

Well, it is not a problem that is raised, but an incident Very Happy

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

Twitter @itilgeek
Back to top
View user's profile Send e-mail Visit poster's website MSN Messenger
Fabien
Senior Itiler


Joined: Sep 27, 2005
Posts: 207

PostPosted: Wed Sep 20, 2006 10:00 pm    Post subject: Reply with quote

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

Twitter @itilgeek
Back to top
View user's profile Send e-mail Visit poster's website MSN Messenger
m_croon
Senior Itiler


Joined: Aug 11, 2006
Posts: 262
Location: Netherlands

PostPosted: Wed Sep 20, 2006 10:12 pm    Post subject: Reply with quote

So when you replace 'problem' by 'disruption', Andy's trainer would be right. Smile
Back to top
View user's profile Visit poster's website
Fabien
Senior Itiler


Joined: Sep 27, 2005
Posts: 207

PostPosted: Wed Sep 20, 2006 10:20 pm    Post subject: Reply with quote

mmh, that's a good trainer Laughing
_________________
BR,
Fabien Papleux

Accenture
Technology Consulting | Service Excellence
Red Badge Certified

Twitter @itilgeek
Back to top
View user's profile Send e-mail Visit poster's website MSN Messenger
Fabien
Senior Itiler


Joined: Sep 27, 2005
Posts: 207

PostPosted: Thu Sep 21, 2006 4:21 am    Post subject: Reply with quote

flybd5 wrote:
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

Twitter @itilgeek
Back to top
View user's profile Send e-mail Visit poster's website MSN Messenger
fighter
Senior Itiler


Joined: Mar 15, 2006
Posts: 68
Location: Thailand

PostPosted: Thu Sep 21, 2006 3:05 pm    Post subject: Reply with quote

Let it be a request or an incident, Isnt it a better way of working by recording all the external interactions to the SD from the customers?

i.e Create a ticket to record a request or an Incident.. Please clarify..

Vimzie
Back to top
View user's profile
jeffendy
Itiler


Joined: Aug 20, 2006
Posts: 25
Location: Indonesia

PostPosted: Thu Sep 21, 2006 3:46 pm    Post subject: Reply with quote

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.
Back to top
View user's profile
Fabien
Senior Itiler


Joined: Sep 27, 2005
Posts: 207

PostPosted: Thu Sep 21, 2006 11:35 pm    Post subject: Reply with quote

flybd5 wrote:
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

Twitter @itilgeek
Back to top
View user's profile Send e-mail Visit poster's website MSN Messenger
fighter
Senior Itiler


Joined: Mar 15, 2006
Posts: 68
Location: Thailand

PostPosted: Fri Sep 22, 2006 1:01 pm    Post subject: Reply with quote

Fabien & Juan,

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.

Hope this is what you both are meaning by.

Vimzie! Razz
Back to top
View user's profile
Fabien
Senior Itiler


Joined: Sep 27, 2005
Posts: 207

PostPosted: Fri Sep 22, 2006 1:18 pm    Post subject: Reply with quote

flybd5 wrote:
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

Twitter @itilgeek
Back to top
View user's profile Send e-mail Visit poster's website MSN Messenger
Marcel
Senior Itiler


Joined: Sep 21, 2006
Posts: 63
Location: USA

PostPosted: Sat Sep 23, 2006 3:29 am    Post subject: Reply with quote

flybd5 wrote:
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?
Back to top
View user's profile
Marcel
Senior Itiler


Joined: Sep 21, 2006
Posts: 63
Location: USA

PostPosted: Sat Sep 23, 2006 7:26 am    Post subject: Reply with quote

flybd5 wrote:
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.
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk All times are GMT + 10 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
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

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.