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: ZOConnor
New Today: 45
New Yesterday: 69
Overall: 144601

People Online:
Visitors: 61
Members: 5
Total: 66 .

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 - Stopping The SLA Clock - Your Thoughts Please
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Stopping The SLA Clock - Your Thoughts Please

 
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion
View previous topic :: View next topic  
Author Message
Markrewsbury
Newbie
Newbie


Joined: Sep 20, 2005
Posts: 1

PostPosted: Tue Sep 20, 2005 7:48 pm    Post subject: Stopping The SLA Clock - Your Thoughts Please Reply with quote

Dear All - I would really appreciate your thoughts and comments regarding the following topic:
Whether an incidents SLA should be stopped if you are awaiting customer feedback?
I am divided on the issue, our Service Desk logs nearly 30,000 incidents a month and we are committed to complete 90% of these incidents within SLA (Driven By Urgency).
In order to prevent huge analyst backlogs, in your opinion is it appropriate to close an incident if following an analysts attempt to contact the customer they have not returned your call within 1 day to therefore simply send an e-mail detailing the actions you have taken, provide a reference number and contact details if they have any further questions?
Or
Do you believe that the incident should be placed in a status which essentially stops the SLA, and the call shouldnt be closed until comfirmation is recieved from the customer.

- The trouble I see with the second option is that the service desk is reliant on "all ready busy people" contacting the helpdesk to tell them that their issue has been fixed by the actions instructed by the support analyst. Understandingly the customers priority is get back up and running ASAP, not to remember to contact the service desk to inform them whether their issue is resolved.

- I also believe that if you have functionality within the Service Desk to put the SLA on hold, analysts may take advantage of this to "massage" their metrics eg FCR and SLA metrics. How do you combat that?

Your Thoughts Please

Regards
Mark
Back to top
View user's profile
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Wed Sep 21, 2005 12:21 am    Post subject: Reply with quote

I definitely agree that caution needs to used when applying status values to incidents like 'hold' and 'pending'.

There should be a standard sequence of states - generally if the status values jump around you can obscure information in reports that break down progress according to time in each state - useful more for assessing the process than the SLA target achievements.

Most configurations I know of do allow for automatic closing of incidents. But only from a state of 'resolved'. Usually it is more than one day. And anywhere up to two weeks is common.

The trick, I think is to ensure that the SLA compliance reports reflect the actual resolution activity and success rates.

Basically it is the TTR - Time to Repair (I prefer using the term Time to Resolution howerver).

The purpose of the call back is quality control - to ensure that there really is a resolution.

It is a perfectly reasonable assumption, that if you have a resolved incident that isn't actaully resolved from the end-user's point of view they will get back to you. Occassionally this won't be the case but there will not be a lot of those.

So ensure your SLAs are based on time to (actual) resolution not time to closure.

If a call back results in a resolved incident being re-opened then you can add all the elapsed time to the 'clock' and when resolution is achieved you will have an accurate TTR. And you won't have to use 'hold' or 'pending' between 'resolved' and 'closed'.

So to sum up,

If an end-user doesn't get back to you to confirm or deny a resolution, in +99% of those cases the marked resolution time will be the actual resolution time. And automatic closure won't affect that measurement.

When a user does request a re-opening updating the clock will mean that when the incident is finally resolved the TTR will reflect the actual resolution time also.

You can't get that with Time to Closure. And becasue it can never acurately reflect service delivery shouldn't be in your SLA.

WRT 'pending', a second field is advisable indicating the reason - end-user response, waiting on parts, etc. You may include a 'clock stopping' agreement for specific types of 'pending' in your SLAs - but others like waiting on parts refelct your service support capabilities and for them, generally, you let it tick.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
eisbergsk
Senior Itiler


Joined: Nov 01, 2004
Posts: 81
Location: Sask, Canada

PostPosted: Fri Sep 23, 2005 6:13 am    Post subject: suspending SLAs Reply with quote

I agree with rjp (and I worship his sage advice). Another reason that sometimes the client doesn't call back is because they are in a 'wait and see what happens if I do it again'-state.
It seems entirely appropriate to resolve & close an incident in the manner described in your original post.
What might appease any guilt is a customer-relationship role - someone who does after-the-fact callbacks for customer satisfaction surveys.
...just another off-the-wall suggestion Smile
Back to top
View user's profile Send e-mail
mcardinal
Senior Itiler


Joined: Oct 06, 2004
Posts: 77
Location: Bloomington, IL

PostPosted: Sat Oct 08, 2005 4:58 am    Post subject: Reply with quote

Markrewsbury,

Another item to consider is what it is you are trying to achieve by measuring the time. Two basic approaches derive from establishing SLAs

--> Internal Metrics (measuring how well your service desk is handling calls, following processes, etc.)
--> External Metrics (measuring how well you are meeting the needs of the customer as defined in the form of a service)

These are very different perspectives and require different types of measurement. IMHO you should first determine your focus (Internal, External, Both) and let that drive the solutions that rjp and eisbergsk have suggested.

MTTR can be a double-edged sword. You can use it for both Internal and External metrics, but it is derived for different reasons and used for different purposes. If the clock stops is really a matter of whether it matters to or your customers if it stops. If the customer does not care and you find no value in keeping it ticking then let it stop. If it is valuable to you to be accurate on the time then let it tick.

Hope this helps!

Michael
Back to top
View user's profile Send e-mail MSN Messenger
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion 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.