If you meant how much time is applied to resolving incidents, then it is better if that is the time it takes to resolve them rather than some SLA figure which should only be about priorities and averages and general commitments about down-time.

Diarmid, your clarification makes sense. Actually, it is difficult for us to define such SLA to estimate the time to fix the problem so that I never seen such SLA is defined. In reality, we're focus on the priorities and down time etc SLAs...thanks for pointing that out.

sorry to bring this old thread back up, didnt feel the need to create a new one.

I understand the concept of Service Desk taking ownership until closure but isn't it the 2nd level teams responsibility to contact the client if there is a fix or if they want to try a fix which has a list of steps then shouldn't they contact the client and walk them through it? It appears to be not the case where I currently work. Calls get passed back to SD asking to we ring the client to try whatever had been suggested as fix and the call then gets flicked back to the 2nd level team again if the workaround/fix fails. This I feel is very un-necessary specially a time waster when the 2nd level teams queue is fairly large and they process it in the order it comes in.

I've not explained the workflow process is currently followed at my work but can do if required. But in short, we log & fix the ones we can and we escalate it to the 2nd level hoping they can fix by contacting the client directly. In most cases, the call returns to our queue which is managed by our TL who then assigns to call back to the SD officer who logged the call to follow the instructions given by the 2nd level team. Really, this ping pong game is a time waster and causes unnecessary delays.

I understand there is a closure/verification step in ITIL which asks the SD to contact the client to verify solution before closure. Does this indicate it is our role to do what the 2nd level team tells us to do...

The SD should be used as the funnel from the tech to the user as well as from the incident creation to closure

here is a good reason to do this

If the user has the tech's phone number email, then as most people do,
that user will bypass the Service Desk and call the tech

Eventually, that user will share the tech;s number with his whole inner circle, and the tech being a good natured type will not push back and a lot of work - incidents, changes etc - gets done off the books so to speak

also, if the tech emails the user with his own email address, the user will bypass the SD as well and merely email the techie and if the techie is on holiday.. bitch moan and whine that his ticket /issue is not dealt with and the SD can say ....what ticket ? what issue ? we dont have one

So to ensure that the IT Department provides a quality of service expected the SD should be the only point of contact or the team that the comms is filtered_________________John Hardesty
ITSM Manager's Certificate (Red Badge)

So communication issues and fear of bypassing the SD are the only reasons? I agree to that but there are ways to get around it. For ex, our logging system allows to email by masking the from so it appears the ServiceDesk is emailing and any replies to that email will be recorded in the action log. And if you have to phone them, say you are part of the IT section ringing to fix the issue and any follow up will have to come through the Service Desk backing up with reasons. Our phone system hides the number too!

Flicking the call back to us and then waiting for the team leader to pass it back again just delays everything if you ask me. After all, the goal for everyone should be quicker resolution leading to higher customer satisfaction. I understand there is a SLA in place which covers it but wouldn't it make sense to avoid any further breaches by taking the quickest route for resolution? And please dont say the 2nd level team has no patience or speak in the language of the client because these days communication skills at all levels is very important. I guess its also depends on the Organization Culture.

ITIL Best practice states that the ultimate owner ship of the incident belongs to the Service Desk no matter whom is working the ticket

Gnome

Who manages the incident ticket system ?
Who provides reporting to management ?

How you handle the ticket is up to your own process, policy and the tool.

I am NOT saying that the ticket must flip flop back and forth between the SD and the Incident resolution team. I am saying that the customer / user should only have to deal with a single entity / phone number / email in order to find uot the status of their ticket. The purpose of the SD is fulfill that and keep track of the tickets in the system.

The Incident resolution team should deal with resolving the incident and not having to provide updates to customers every # minutes from many users asking .. is my done yet ...is my done yet

The SD should be the group that prioritze and assesses the urgency of a ticket - not the customer, not the user, not the resolution team

If you dont want to use ITIL Best Practice or ISO20000 in the Incident Management process... that is up to you and your company. If so, why are you even here ? We discuss ITIL BP not try to justiy why ITIL BP should be used.

If your company uses its Incident tool as a replacement for the Service Desk, that is fine by me. I dont care. But, I would not consider your company following ITIL Best Practice, ISO20000 Standards or even CoBIT and Sarbanes Oxley compliance in doing so

But that's my opinion and as well know opinions are like .... every one has one_________________John Hardesty
ITSM Manager's Certificate (Red Badge)

I couldn't agree more ukviking but not sure if you understand my initial query. I'm not saying we wont be the single point of contact, I'm not saying we don't communicate with the client once the call has been escalated. The client still rings the Service Desk to check the status on the call and we give the necessary info. We still take the ownership and don't mind verifying the solution once it has been resolved by the escalation group. But, I'm trying to gauge the mentality of our escalation groups. If they are willing to trial a workaround, why can't quickly do it on their own. Why does it have to come to us and we do whatever has been said and then it gets flicked back to only get the call back wanting us to try a whole lot of other things. This just adds a lot of frustration and delays at clients end. And at times some of my team members feel they are being treated like receptionist leading to lack of trust and broken down communication with the escalation group.

The reason for me being here is to find out if others have experienced similar situations and how it is being dealt if a standard like ITIL is employed within the organization.

Also do we agree that ServiceDesk is not the only team which needs to understand the Incident Management process? Escalation groups require training in ITIL too?

Quote:

'The SD should be the group that prioritze and assesses the urgency of a ticket - not the customer, not the user, not the resolution team

Sorry. I misread (obviously) your point. I read the whole OLD thread and interpretted your wrongly

If the incident is with the Incident Resolution team, they are in control of the incident, ticket and actions and the resolution.

If the incident is unqiue and they have to try something, the guage I would use whether to involve the SD and its mgmt food chain is

if the service is dead already and the IR team is trying to bring it live. JFDI Just F do it. They need to get the service up. They dont really need to talk to the customer/SD etc.. just get the work done. update the ticket and get that service up. Changes that are needed should be done by emergency process

If the service is impaired and the work around will make it worse temporarily, then the SD / customer shuold be informed and the customer may have to agree or not. How this is done is dependent on the relationship with the customer point of contact. If you have a poc who is techie oriented, then the IR team can chat with about the issue, agree and then the ticket gets updated
if the poc is not a techie, then the SD should be involved (cofnerence call/ email) to explain the issue / need for decision

Under Standard Temperature and Pressure (STP), the Service Desk (Incident management) folks have access to open a new Incident in the ITSM tools which an organization adopts. This is other than the automation incident generated by NMC, SMC etc. While, the permission to resolve remains with any support team, the permission to 'close' or demise an incident rests with the Service Desk. ITIL says so. I have not mentioned anything which is not discussed already in this particular thread so far. There is also a post on the KPIs where in one of the KPIs is the percentage reduction in the users bypassing the service desk is one of the KPIs. It may or may not be ITIL but its got something to do with the culture which promotes dedicated support team and encourage people to fall in 'queue' to get support. For the second line teams, masking the identity while sending a mail to the user is something which is in practice but the masked email has the contact details of the Helpdesk in case there is any further issue that the user wants to report with respect to the same issue._________________regards,

Vivek
"the only statistics you can trust are those you falsified yourself"
Winston Churchill

I think we should differentiate the processor and the owner of the incident for your situation. SD should always be the owner of the incident whether it was escalated to 2nd/3rd level or it could be solved by SD. As the owner of the incident and single point of contact, we could always update the customer with the incident status. But the processor of the incident would be 2nd/3rd level whose respoinsibilty is to provide the solution to the customer (including contact the customer with trail solution or seek more informations).