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: CNWF
New Today: 136
New Yesterday: 176
Overall: 131381

People Online:
Visitors: 52
Members: 6
Total: 58 .

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 - How many tickets per issue? What if they are the same?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

How many tickets per issue? What if they are the same?

 
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk
View previous topic :: View next topic  
Author Message
Chompers
Newbie
Newbie


Joined: Dec 14, 2009
Posts: 4

PostPosted: Tue Dec 15, 2009 3:16 am    Post subject: How many tickets per issue? What if they are the same? Reply with quote

How do you handle when a client has multiple issues to report that are the same issue?

What I mean by this, for example, if the user has 2 blackberries, both requiring new batteries, is that one ticket or two?

Typically our process is for distinct issues, each it's own ticket because each may need to be escalated to seperate teams.

However when it comes to examples as posted above, we often have users calling in to report 15-30 of those, should we log 15-30 tickets? Or just record each device affected in the same ticket?

No SLA's are affected by this, because we don't really have any.
Back to top
View user's profile
Timo
Senior Itiler


Joined: Oct 26, 2007
Posts: 295
Location: Calgary, Canada

PostPosted: Tue Dec 15, 2009 3:47 am    Post subject: Reply with quote

Since you don't have SLA's do you do any sort of reporting on the work performed? What I mean is that if it doesn't matter to anybody whether you have replaced 1 Blackberry battery in a given month or 30 batteries then it really doesn't matter whether you create one ticket or multiple. If that's the case I would go with whatever makes more sense from resource utilization perspective.

Basically, it is what you need to know about what you do that would drive how you'd do it.

In your specific example, because one action can address two issues I'd just create one ticket, provided you don't perform CI based reporting.
Back to top
View user's profile
Chompers
Newbie
Newbie


Joined: Dec 14, 2009
Posts: 4

PostPosted: Tue Dec 15, 2009 3:53 am    Post subject: Reply with quote

No reporting is done, however we have the ablility to link to the specific Blackberry in question, i.e. we can link all 30 blackberries to the same ticket.

However the reason I ask is the team that deals with them, seems to want to manage 30 tickets, which seems like alot of wasted effort.
Back to top
View user's profile
Timo
Senior Itiler


Joined: Oct 26, 2007
Posts: 295
Location: Calgary, Canada

PostPosted: Tue Dec 15, 2009 4:05 am    Post subject: Reply with quote

Well, unless there is a specific (justifiable) reason why they want to manage 30 distinct tickets, I don't see a point. ITIL wouldn't tell you one way or the other, mind you. It's just whether there is a reason for doing something. I have worked in the organization where everybody was tripping about collecting as much information as possible and logging millions of tickets, but then what? Nobody would every anything with that info (analysis, trends, CIS, etc), so what's the point?

I am sorry if I am not giving you the answer that you want, but IMHO this is how I'd look at it. I don't think there is a right or wrong answer, just the "depends" one.
Back to top
View user's profile
Chompers
Newbie
Newbie


Joined: Dec 14, 2009
Posts: 4

PostPosted: Tue Dec 15, 2009 4:36 am    Post subject: Reply with quote

Timo wrote:
I have worked in the organization where everybody was tripping about collecting as much information as possible and logging millions of tickets, but then what? Nobody would every anything with that info (analysis, trends, CIS, etc), so what's the point?


Exactly! No this is perfect, thanks for the input!
Back to top
View user's profile
GDVS
Newbie
Newbie


Joined: Dec 15, 2009
Posts: 1

PostPosted: Tue Dec 15, 2009 6:36 pm    Post subject: Reply with quote

Timo wrote:
I have worked in the organization where everybody was tripping about collecting as much information as possible and logging millions of tickets, but then what? Nobody would every anything with that info (analysis, trends, CIS, etc), so what's the point?

If your current management don't use the data to report then it doesn't hurt to collect it anyway, one day you may get someone who does.
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Tue Dec 15, 2009 7:56 pm    Post subject: Reply with quote

Chompers,

I'm tempted to ask if no one ever reports anything then why bother to do anything?

More seriously, your question is a practical one, but it does not have a generic answer.

One ticket for thirty battery changes is just as good as thirty tickets. And the difference may not be burdensome if you can go some way to cloning the ticket generation.

What can make the difference is:

- Whether there is more likely to be a human error, for example missing out one of the items, if they are just a list on one ticket or if they are on separate tickets.
- Whether it is easier (if desirable) to distribute the task among staff if they are on separate tickets.
- Whether they can all be done at the same time or the user needs the task to be phased.
- Whether they are all in the same location or not.
- Whether you have the resources to do them all at once or not.
- Whether dialogue with the requester will be better facilitated one way or the other (this is to do with how customers/users like to manage the interface).
- What you/IT Service Management see as being useful in the future when you have applied basic controls to your management system (this of course should be a far higher priority than your worry over ticket numbers!).
- Whether you treat these as incidents or service requests (except that if there is no reporting going on then this is almost certainly moot)

There will be other factors, but that should give you a picture. As you can see some of these could be used to apply a general rule while others would best be decided on a case by case basis. The logical conclusion is that you should generate some guidance based on the more strategic factors and then have staff make the decision on a case by case basis within that guidance.

However if you do not begin to report on these things you will be wasting your time because you will never be able to review how effective and appropriate your guidance is.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Back to top
View user's profile Send e-mail
smehdi
Newbie
Newbie


Joined: Dec 09, 2009
Posts: 16

PostPosted: Tue Dec 15, 2009 11:26 pm    Post subject: Reply with quote

Hi All,

If today we dont have a reporting mechanism in place , we might need it tomorrow. What if in future we want to know how many Incidents received by the SD regarding replacement of battery.I am sure we won't open individual Incidents and count the no. of people requested for it.

Secondly , it will also impact call to ticket raio.

Thirdly, the support team whom we are assigning the Incident , would not be very comfortable in handling multiple request attached to just one ticket.

The most important point , if one person is calling on behalf of many people , then its ok to raise one Incident, what if different people are calling for the same issue , I would not take it as an Incident but would send it to Problem management team to investigate why suddenly we are getting so many Incidents for battery replacement.
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Tue Dec 15, 2009 11:57 pm    Post subject: Reply with quote

smehdi wrote:
If today we dont have a reporting mechanism in place , we might need it tomorrow. What if in future we want to know how many Incidents received by the SD regarding replacement of battery.I am sure we won't open individual Incidents and count the no. of people requested for it.

In the future you might want to know whether it was raining that day. How do you know what information to hold for unplanned, unthought of future use?

While you have no use for it, data is clutter. The only answer is to decide how to use it first.

smehdi wrote:
Secondly , it will also impact call to ticket raio.

This ratio is not very important if it is not reported on. I'm not sure it is very important if it is reported on. What can you use it for?

smehdi wrote:
Thirdly, the support team whom we are assigning the Incident , would not be very comfortable in handling multiple request attached to just one ticket.

They can still do them one after the other. They might be uncomfortable with twenty requests to do the same thing for twenty people in one location, recording twenty visits that were in fact one visit.

smehdi wrote:
The most important point , if one person is calling on behalf of many people , then its ok to raise one Incident, what if different people are calling for the same issue , I would not take it as an Incident but would send it to Problem management team to investigate why suddenly we are getting so many Incidents for battery replacement.

You can't abandon an incident just because too many people are reporting it. It still needs fixed. In fact you could argue that the fix has to be quicker because it affects so many people. You can look at why it happened later.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Back to top
View user's profile Send e-mail
smehdi
Newbie
Newbie


Joined: Dec 09, 2009
Posts: 16

PostPosted: Wed Dec 16, 2009 5:24 am    Post subject: Reply with quote

Hi Diarmid,

If the company does not have any set SLAs and reporting mechanism and no plans to implement this in near future then what you said is perfectly correct.

Else , what I believe is" The most critical step in the workforce management process is the : data collection and analysis. The best predictor of future call workload is past data, so gathering the right data is critical to the workforce management process."

Another important aspect is CI. If all the employees in a company are using the same model of Blackberry then we can end up raising one Incident for all the users. What if the company is upgrading the models as per the recent promotions or requirements.

Please clarify my doubt , can we still raise all the request in the same Incident for different models.
Back to top
View user's profile
viv121
Senior Itiler


Joined: Dec 15, 2007
Posts: 112

PostPosted: Wed Dec 16, 2009 5:29 am    Post subject: How many tickets per issue? What if they are the same? Reply with quote

Chompers,

Have you actually come across this situation or you are just thinking about if it rains tomorrow kind of situations? You mentioned you don't have SLAs which makes me wonder if you have a CMDB. So, if you are changing one battery of one blackberry, you are probably not updating the CMDB with the information of the ticket. If you have an IT Asset management ( ITAM)discipline, you will probably need to put an incident number or a service request number against every battery change on the blackberry. Moreover, there is no harm is 20 requests come at one time. If you are talking about twenty blackberries need battery replacement due to a fault (read Incident), then probably the fault has gone through the problem management cycle and the root cause has been identified as the battery replacement for all twenty replacement. So, you can have one incident, twenty incidents, one service requests, twenty service requests or a problem. All this when it rains!!
Back to top
View user's profile Send e-mail
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Wed Dec 16, 2009 8:35 am    Post subject: Reply with quote

smehdi wrote:
Please clarify my doubt , can we still raise all the request in the same Incident for different models.


I cannot clarify any further. Unless I visit your site and examine your processes etc. The answer lies in my earlier post (the one with all the "whether"s in it). You make up your mind on the basis of how you weight these factors (and any others that are specifically relevant to your services). It is wholly a practical matter, not in the least theoretical.

Without taking into account what is best for you, you can do anything you want, just like Viv said.

Good practice is to decide along rational lines what will work best for you. Neither books nor fora can help you beyond the principles involved.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Back to top
View user's profile Send e-mail
Chompers
Newbie
Newbie


Joined: Dec 14, 2009
Posts: 4

PostPosted: Wed Dec 16, 2009 8:49 am    Post subject: Reply with quote

Yes we've come across it, just one of those things where one team wants it one way (single ticket) and the other wants 20 tickets.

As for not having SLAs that is true, however we have undocumented targets that we strive for, but nothing is formally written down.

Much appreciated commentary, I think we'll end up going with the 20 tickets, mainly for the reason stated above, even though we don't report on it now, we may want to in the future. Gives us an idea of the volume etc.

We were able to put in place a "copy ticket" function in our tool to speed the process up.
Back to top
View user's profile
vz-r_Dave
Newbie
Newbie


Joined: Oct 28, 2009
Posts: 15

PostPosted: Wed Dec 16, 2009 4:02 pm    Post subject: Reply with quote

Chompers are you using the Problem Management process? Going by what I have read it seems that you are not at the moment?

Dave
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
Page 1 of 1

 
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.