Will it be correct to say that ITIL does not think it is good practice if a SLA stops calculating when a incident is put in a e.g. a status of pending customer?

We have a scenario where a incident could be in progress, but then a agent are in need of more information and can not get hold of the customer , so he put it in a status of pending customer. Sometime the customer takes a while to respond and in the meantime the SLA breached. Our agents are now saying that the SLA should stop calculating if the incidnet is put in a customer feedback status and only start again when the status is back in progress and stop again when status is resolved.

I feel however that this could be a easy way of manipulating the system ? But it seems like I am the only one thinking this way ?

Incident resolution is not complete until the service has been restored and the users are able to use it again. stopping the incident clock, stops you measuring that aspect and it is the most important.

If you have the kind of SLA that imposes a requirement for resolution of individual incidents within a given time, then you will get breaches of many sorts. Such an SLA is a hostage to fortune and not a particularly good way of measuring quality of service.

I suggest you search some old threads for considerable discussion on this issue.

To address your specific case. The reason for the delay was the inability to proceed without information that was temporarily unavailable. This will happen from time to time. But when it does there is a case for analysing why it was a problem (very small p, although I am now slipping into a Problem Management mode of thinking). Perhaps steps could be taken to not need to rely on the user for that type of information; perhaps the information could be gathered at an earlier stage when the user is available.

But it goes further because the primary concern is the unavailability of service for an extended period. This is a primary concern to the customer and it can be established in the SLA (which is a two way document) that there is a requirement in certain circumstances for users to be available for dialogue during the process of incident resolution.

Obviously it is not the "fault" of the technician if the user is unavailable, and at the same time it may be moot that this incident took longer to resolve in this case (e.g. if that user is the only user of that service and is clearly not waiting desperately for its return).

In the circumstances of your over-detailed SLA which is measuring the wrong thing, you would classify the incident resolution as a breach and the reason being the unavailability of the user. That is another problem with your incident-specific SLA: you need to have ways of handling all sorts of cases where the fact that the time was exceeded is not a black mark. and that is very difficult to do, because it encourages all sorts of special pleading, foments distrust and clouds the issue of whether your service is good or not._________________"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

I have to say that, in my experience, it is considered the norm for the amount of time that the user was unavailable (and therefore the incident could not progress) to be removed from the calculation.

This has been implemented in the last 3 organisations I have worked during the Incident Management implementation.

Where it is a larger system fault, that incorporates multiple users and stakeholders, it is unlikely that a single user can be the source of a delay.

I have seen abuse when this is the case...e.g. Single User X logs a system unavailable incident for his/her department. Technician can't get hold of the requester and suspends the SLA on the strength of needing more information from the user. Clearly, this is an unacceptable use of pausing the clocks.

I have recently implemented this where I am today and will continue to do so (unless the organisation doesn't want it)

For me, the key is going to be the SLA Breach reviews that you put in place (if any). If you are prepared to take users and departments to task for failing *their* commitment during their own incident resolution...it is perfectly acceptable to deal with this then.

Just my thoughts_________________No I will not *convert* that Incident you have been diagnosing for a week into a Change

what you are doing is wholly IT-centric and appears to pay no regard to service whatever.

At the very least you are dissociating your information on incident resolution times from reality.

You run high risks of alienating your customers.

Does your customer know this is happening?
Is this defined in your SLAs?

What process do you put in place for defining sufficiency in the attempts to contact the user?
What do you have in place for sufficiently looking for other sources of the required information?
What processes have you in place for alternative paths of investigation?
In short, how do ensure that your staff don't mess with the system?

Do you design specifically to reduce the need for user interaction in any class of incident for which that is possible?
Do you measure the frequency and duration of the clocked off time?
Do you measure its impact on business?
Do you keep a pro-active [Problem Management] eye on this?
Do you investigate, with the customer, why it happened (or keeps happening)?

What steps do you take to ensure the soonest possible time to achieve communication? - Are these steps agreed with your customer?

It is not an issue of customers breaching their SLA obligations. It is an issue of circumstances. SLAs should only become a battleground when all else fails. You have an obligation, along with your customer to develop the best system possible and starting out with faulty premises is not the way. Time lost waiting for return communication (and also, as some people do, waiting for third party response or delivery) needs to be measured in order to look for ways to improve it. you don't switch off the clock, you switch the classification under which the time is being recorded.

It is a wholly different matter when measuring the technician's time spent because this is not elapsed time._________________"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

what you are doing is wholly IT-centric and appears to pay no regard to service whatever.

At the very least you are dissociating your information on incident resolution times from reality.

You run high risks of alienating your customers.

Does your customer know this is happening?
Is this defined in your SLAs?

I don't believe that this approach pays no regard to service, I firmly believes that this approach focuses on the service as a whole, rather than ignoring the customers responsibility to the delivery of service

Customers have a role to play in Incident Management as does everyone else and this is made clear to them. We do have a number of customers that don't want this, and any breaches are dealt with in Service Reviews, especially where breach penalties are being imposed.

Yes, this is clearly defined in the SLAs.

Diarmid wrote:

What process do you put in place for defining sufficiency in the attempts to contact the user?

The Incident Management Process (supported by work instruction) clearly defines the expectations of "reasonable attempts to contact". In our case (and defined largely by SLA timers) we generally refer to telephone contact, 5 attempts followed by an email.

Diarmid wrote:

What do you have in place for sufficiently looking for other sources of the required information?

What processes have you in place for alternative paths of investigation?
In short, how do ensure that your staff don't mess with the system?

We define that colleagues of the requester are engaged (and indeed actively sought where we don't already have the information).

This kind of thing is always open to abuse, but we have Service Reviews with our customers regularly and most of them keep their own track of our company performance. Additionally, I regularly report on, and review, "pending customer" incidents and re-enforce the process with internal resources using it incorrectly.

Diarmid wrote:

Do you design specifically to reduce the need for user interaction in any class of incident for which that is possible?

In fairness, the support that we provide to our customers where I am now (all of which are external companies) means that we have minimal user interaction and normally have comprehensive documentation and access to limit this.

Diarmid wrote:

Do you measure the frequency and duration of the clocked off time?

Yes, as mentioned above

Diarmid wrote:

Do you measure its impact on business?

This is harder to do. I should qualify that Major Incidents cannot be paused for any reason

Diarmid wrote:

Do you keep a pro-active [Problem Management] eye on this?

I have never felt the need to involve Problem Management for an SLM matter..a customer not responding to our requests for additional information or attempts to resolve don't fall under the scope of Problem Management to me. Although, I do pro-actively monitor the usage and feedback through Continual Improvement etc.

Diarmid wrote:

Do you investigate, with the customer, why it happened (or keeps happening)?

Absolutely, during service reviews. We try to agree corrective actions and limit future delays. For example, we now always ask for an alternative contact when logging incidents as the result of continual delays with a particular customer.

Diarmid wrote:

What steps do you take to ensure the soonest possible time to achieve communication? - Are these steps agreed with your customer?

We have OLAs setup that measure responding to the customer within set time frames (based on overall SLA). Customers are aware of this and the preferred method of communication agreed.

Diarmid wrote:

It is not an issue of customers breaching their SLA obligations. It is an issue of circumstances. SLAs should only become a battleground when all else fails. You have an obligation, along with your customer to develop the best system possible and starting out with faulty premises is not the way. Time lost waiting for return communication (and also, as some people do, waiting for third party response or delivery) needs to be measured in order to look for ways to improve it. you don't switch off the clock, you switch the classification under which the time is being recorded.

I do agree with you here in the main (incidentally, if we are engaging a 3rd party to assist with a customer resolution, we never pause the clocks). Although I have to say that this has never become a "Battleground" with any customers in any of the organisations where I have delivered this particular method. We always look, along with the customer, at ways to improve and remove delays...we just communicate with our customers and have them agree their responsibilities (providing information and their own availability). The key for us is regimenting when we do it and when we undo it. With our Incident Management staff suitably trained, abuse is rare and easily caught...especially when coupled with customer service reviews.

Diarmid wrote:

It is a wholly different matter when measuring the technician's time spent because this is not elapsed time.

I couldn't agree more._________________No I will not *convert* that Incident you have been diagnosing for a week into a Change