How often do you give your customers feedback during a case?

An open discussion on issues related directly or primarily to the service or help desk.
Post Reply
User avatar
dicerman
Newbie
Newbie
Posts: 1
Joined: Sat Jan 16, 2010 7:00 pm

Sun Jan 17, 2010 5:32 pm

As a member of a servicedesk, I can see that our customers most likely only get feedback when a case gets closed. (And when they first report the case)

Is there any "best practices" on giving feedback to the customer during the case's lifetime?
When, where, how?

We want to give a better experience of the servicedesk, by giving better feedback more often, but how have you done it - which way works for you?

Do you have like reminders in your Servicedesk tools, so you won't forget to give feeback - FOR EXAMPLE - when the case might take a bit longer than first expected? Or any other situation.

The goal is to have the customer feeling he/she is getting good attention.
Quickcases like pw resets would not need a "halftime" notice, but maybe another case which is taking more than 15minutes or so.

So, are you guys giving more information during the cases or just when picking the call and when closing the case?


User avatar
Diarmid
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Mon Jan 18, 2010 5:44 am

"Best practice" would be to consider what information, at what intervals will be of value to the customers/users so that, for example they can restructure their immediate plans according to sound expectations or the lack of them; so that they can be warned of further delays or of imminent restoration.

There is a psychological element as well. People who have lost a service don't like being in the dark and they shouldn't need to be.

The opposite end of the spectrum is that they will not thank you for interrupting them every five minutes just to say "we're still working on it" and you don't want to be interrupting your service staff all the time while they are working hard on the resolution.

Sometimes it makes sense to agree a schedule of updating at the start of the incident to meet the specific needs of the situation and you can also make some commitments in your SLAs as to how and when you keep the users/customers informed during ongoing "situations".
"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
User avatar
JohnKing
Itiler
Itiler
Posts: 5
Joined: Sun Dec 28, 2008 7:00 pm
Location: Midlands UK

Mon Jan 18, 2010 6:23 am

We are currently running a pilot where Customer Feedback is based around the Urgency of a ticket.

The analyst having received the ticket would have X hours to contact the customer and explain they had received their ticket and the next steps. Then based on the SLA there is a follow up date. This is when the analyst will next make contact with the customer and provide and update on the progress. The follow up date can be moved on agreement with the customer.

When contact is made this is recorded in the ticket with a support action to show contact has been made.

The metrics are a little up in the air. It seems some of our sites can easily make the provisional target and some sites cant.
User avatar
mymickie
Newbie
Newbie
Posts: 3
Joined: Sun Feb 14, 2010 7:00 pm

Wed Mar 03, 2010 4:28 pm

Hi
We have 2 minutes to acknowledge electronic contact of Critical severity
5 minutes for Serious ... etc
In addition we have also update periods SLTs (internal) but that allow to define when the incident should be monitored by the incident owners not only to update the customer but also to escalate further if there is no progress. They are based on the recovery SLTs and Critical incidents to be recovered in 90 minutes have to be updated every 10/15 minutes while serious ones every 2 hours (SLT 6 hours to 48 hours depending the SLA)
The issue is that this is adding additional activities to the helpdesk that not only has to deal with incoming incidents (100 per day approx. for some teams) but also to update WIP ones
As our helpdesk is a 2nd level one, they do not like at all the clerical aspect of this - motivation may be an issue as they prefer to investigate as their resolution rate is 50%
User avatar
vz-r_Dave
Itiler
Itiler
Posts: 15
Joined: Tue Oct 27, 2009 8:00 pm

Wed Jun 09, 2010 2:07 am

Is it really a 2nd line helpdesk though? Of course this might be your official line but if it is the first point of contact then it really isn’t the case.

The guy's might have the technical ability but this doesn’t really change the fact that they are doing a first line role.

Perhaps I am wrong and you do have a first line desk but it doesn’t seem so.

If it is a case of the guy's on the desk realising that they are first line and that this so called admin/clerical work is part of their job then it should be pushed on them.

Perhaps this will de-motivate them further but there is no room for arrogance on a Helpdesk/Servicedesk.
User avatar
SubbuA
Senior Itiler
Senior Itiler
Posts: 33
Joined: Wed Jan 27, 2010 7:00 pm

Fri Jul 23, 2010 6:38 am

making servicedesk members call customer on a regular basis to feedback them on the progress of resulution is going to be costly and you may find that few time you call and few times you are stuck between work

It is suggestive to use automated emails that could be triggered from the ticket logging tool based on the progress of the incident - say once the ticket is logged, first email is sent which gives the ticket number, clarifies the SLA and also provides a contact number/email id for the customers to reach if the urgency seem to be any better than the SLA...

As and when the ticket progresses towards resolution - the worklog if practised to be formally written can shared automatically

if the ticket is on pending status for customer response then automated emails on regular intervals can be set to be triggered..

It all depends upon how well you customize this automation for your need and help suit your structure

But that works
Regards,
Subbu A
ITIL Certified and well experienced
Post Reply