Stopping The SLA Clock - Your Thoughts Please

[Markrewsbury]

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

[rjp]

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.

[eisbergsk]

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

[mcardinal]

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