Serio Blog

Monday, 11 Sep 2006

This post is another in my series about customer satisfaction surveys – you can read the last here (it has links to the others).

If you’ve started using surveys, you need to think about how you will access the data gathered and interpret the results.

Firstly, who should interpret the results? For me, this falls under the remit of the Service Level Manager, whose job it should be to identify unacceptable customer service. If you don’t have a Service Level Manager – why not?

Within the Serio tool, there are two main areas that can be used to access the gathered data:

From within SerioClient

You can access the data under Tools/Performance. Select the ‘Customer Satisfaction Survey Results’ graph – this shows trends for customer satisfaction, by plotting current month/previous month/previous three months. This simple mechanism makes it fairly easy to see if satisfaction is improving, neutral or declining over time.

From within SerioReports

There is an entire section devoted to this data – see ‘Customer Surveys’. SVY_1, SVY_2 and SVY_3 plot results from the surveys, and display data in a similar fashion to those displayed in SerioClient (you can amend the dates used for reporting though).

Service Level Managers should periodically (at least every two weeks) use SVY_4 and SVY_5. These show raw data, but crucially show any comments that have been entered by respondents – allowing a response from the Service Level Manager to be made where one is required (the respondents details are also shown).

An interesting report is SVY_6. This shows the mean average score for each question in Surveys responded to between two dates. Each response is assigned a score through SerioAdmin. By default, these range from 'Strongly agree' - score 5 - to strongly disagree - score -5. In addition to the mean average score for each question, the report shows the number of responses received for the question, and the standard deviation.

Friday, 08 Sep 2006

This post follows on from my ‘Customer Satisfaction – How do you measure up’ posts, which you can read about here and here.

This post is going to look at some questions you might use for a periodic survey, and discuss when such customer satisfaction surveys should be taken.

Let’s look at some sample questions, which are of course linked to what it is you are trying to discover.

For my example, I’m trying to find out something about attitudes to the Helpdesk/Service Desk, attitudes to downtime and availability, quality of the jobs we do, and to find out if the service we offer is improving or not. 

I stated in the earlier posts that you should ask the questions from a positive stance, so my questions would be:

  1. I am satisfied that the IT services I need to do my job are available when I need them.
  2. When the service desk reports a problem as resolved, it usually is resolved.
  3. The quality of IT service I obtained has improved over the past 3 months.
  4. Generally, I am satisfied with the IT service I obtain.

Of course there are other things that might be tested – for example, the quality of experience when callers contact the Service Desk. However, we do have the event-based surveys to tell us about poor experiences users might have here.

If I was using such a periodic survey, I’d perform the survey no more than once every three months. If I was embarking on a programme of IT service improvements (such as introducing IT Service Management with ITIL) then I’d consider such a survey to be essential before such changes were made. I would then re-survey after 3 months to see if there had been an improvement in customer perception.

One objection made frequently to me at the start of an ITSM programme is ‘I don’t want a survey right now as the results will be embarrassingly poor – I want to wait until we’ve made improvements’. I strongly disagree with this: users have their opinions regardless of whether you survey them or not. Taking a survey at the start may be painful, but is surely worthwhile.

I’ll post next week about interpreting the results from your surveys.

Otherwise, have a great (sunny!) weekend.

Thursday, 07 Sep 2006

We've added a new White Paper to the Serio website called 'Introduction to ITIL'. The paper is for those just getting started with IT Service Management, or those just curious about ITIL.

If you have any comments on this new White Paper let us know - there is a contact email address with the document.

Wednesday, 06 Sep 2006

This post follows on from my last post about customer satisfaction surveys. I hope to convince you that surveys are a worthwhile addition to your reporting repertoire.

There are (I think) two basic types of customer satisfaction survey:

  • Those you take after an ‘event’ such as resolving an Incident 
  • Those that are taken periodically

Both have a place in a properly organised Helpdesk/Service Desk, but how you use the results is subtly different.

A few do’s and don’ts:

Don’t: Ask too many questions. All you will do is reduce the response rate. Limit yourself to no more than 5 (5 is good because they can often fit on the screen at once – this will lift the response rate, and the survey form will seem smaller and less intimidating). 

Do: Keep your questions short. 

Do: Phrase your questions in the positive all the way through – you can see how it’s done from the samples below. Don’t ask people to ‘score’ you – it’s not objective. Instead, ask them how they feel about something.

Lets look at some of the questions you can ask for an event based survey (these are straight from the ‘default’ Serio survey for Incident resolution).

  1. My call was handled courteously and efficiently by the Helpdesk 
  2. I was contacted about my Issue in a timely manner after reporting it
  3. I am satisfied with the length of time it took to resolve my Issue
  4. I was kept informed about the progress being made on my Issue
  5. Overall, I am very satisfied with the way that this Issue was handled by the Helpdesk

Each of these can be answered as follows by selecting from a list

Strongly Agree/Agree/Neutral/Disagree/Strongly Disagree

For periodic surveys, it all depends on what you are trying to measure. My next post will look at what you can do with a periodic survey, ,and suggest some questions. I will then talk about how the results should be examined and interpreted.

Monday, 04 Sep 2006

Service Level Agreements (SLAs) are watched quite closely by those involved in IT Service Management (especially Service Level Managers) but, important as they are, it does not follow that good SLA performance leads to satisfied customers.

Definition: I’ll define customers carefully – all users of IT services within an organisation, rather just senior managers and budget holders.

In fact, I can think of a number of instances in my career where IT SLA performance has been ‘good’ but customer perception and satisfaction has been low or negative, often to the surprise of senior IT managers.

There can be all sorts of reasons for this, and I’m going to explore them in coming posts – almost all centre around the use of SLAs that are inappropriate in one or more ways (this is a big subject I wish to return to in future posts, so I’ll not go into it in too much detail here).

As an example, does your SLA reporting focus on SLA resolution times for Incidents, whilst having no element within your SLA for service availability? This means you might restore services to normal operation quickly (‘good’ SLA performance) but if there are too many of these Incidents your customers will be unhappy – it’s much better if ‘things just work’.

Having said all that, I started with the premise that on-target SLA performance will not necessarily lead to satisfied customers. So how do we measure customer satisfaction? The answer, of course, is directly – through surveys.

If you are a Serio user, the Serio tool can gather satisfaction data directly for you in a number of ways.

In future posts, I’ll look at the kinds of questions you can ask, and the types of surveys you can perform – and how this can be used to enhance our understanding of the performance of the IT Service Management function.

Friday, 01 Sep 2006

Next week should see the release of Serio 4.6. I’ve already posted about some of the new features of the Command Center here and here, so this post is going to be about some of the other more interesting features. There are over 40 changes, and amongst these is an Auto Responder.

The auto responder’s job is to suggest solutions to problems submitted by email to the Helpdesk. It does so immediately if it can find a solution, whilst still continuing to log the Incident, or place the eMail into the Inbox as it does at the moment.

For example, a Customer sends the following eMail to the Service Desk:

Subject: Can't print my document 

From: jo.hamilton@mhsxyz.com

Message: 

"Hi Support

I'm trying to print a Word document but am receiving an error message telling me there is a problem with my printer setup. 

Please could you help.

Regards

Jo"

The Auto Responder analyzes the eMail for key words and phrases you have defined. Based on these, it eMails the Customer a suggested solution (also defined by you), which may include attached documents. For instance, from the above eMail, the Auto Responder identifies the following key words:

can't 

print 

message 

word 

document

Based on these key words, Auto Responder identifies the following solution, which it eMails to the Customer.

Subject: Auto Responder: Problems printing to your normal printer 

Message: 

"NOTE: This email was generated automatically in response to an email you sent to the service desk. We hope you will find the advice it contains useful. However, please be assured that we will also contact you about your support Incident shortly.

When attempting to print a document from Microsoft Word, you may see the following error message (see attached document for screenshot):

"Microsoft Word 

Windows cannot print due to a problem with the current printer setup...."

The most likely cause of this problem is that your normal printer is currently unavailable. We will investigate why this is the case. However, in the meantime you can print using an alternative printer. 

To change to another printer:

1. Choose 'Start' > 'Settings' > 'Printers' from the Windows Menu. 

2. Double click 'Add Printer'. 

3. In the 'Add Printer Wizard', click 'Next>'. 

4. Select 'Network Printer'. Click 'Next'. 

5. Select 'Find a printer in the Directory' and click 'Next >'. 

6. In the Location field, enter your location and click 'Find Now'. 

7. Select a suitable printer from the list. 

8. When asked if you want to make this your default printer, select 'Yes', and click 'Next>'. 

9. Click Finish."

 

Thursday, 31 Aug 2006

Wednesday, 30 Aug 2006

I offered, in my last post, a very simple Incident Logging Script.

I’ll offer a critique now of this Script, pointing out here it can be improved or amended for use on your own Helpdesk/Service Desk. Remember though I think a Script of some sort should be part of your Incident handling procedures.

Style. I have used full sentences to make it more readable, but my preferred approach would be as follows, using a much more terse style:

Identify customer name

Confirm contact details – (make sure we have a phone number)

Confirm or obtain Configuration Item

… and so on.

Order. Remember that Serio’s Incident, Problem and Change logging screens offer significant flexibility in terms of customisation and how you capture information. For instance:

You can capture the Configuration Item first, and Serio will fill in the customer for you. This way, you could start the interaction with the customer with: ‘Good morning, do you have a Computer Tag name I can use’ – going on to confirm the customer details.

You can change the tab order. If you want a Script that confirms something like the Impact of the Incident early on, use SerioScribe to alter the tab order of elements on-screen.

Monday, 28 Aug 2006

This post follows on from: 

Incident Management - how good are you at taking calls?

Incident Management - how good are you at taking calls? (cont)

Incident Management - Call Logging Scripts

(and to be honest, I had no idea when I started with this subject that it would span over a week).

What I’m going to do now is post a sample Script as I promised at the end of my last post. The format I’ll approach is this: words to the customer are in bold, guidance to the Helpdesk/Service Desk Agent are in italics). The Script covers logging a new Incident (rather than a follow-up to an existing Incident).

What reading this sample, please remember my comments about training and role-play from earlier posts.

Hi this is the IT Service Desk, to whom am I speaking? (Locate the customer in our customer database)

Can I confirm that the contact telephone number for this call is… (Confirm and update as necessary). 

(CI Found by Serio) Can I confirm the Computer Tag Number as … (Serio will suggest a Configuration Item from its database. Confirm it is correct, or select the CI if it is not correct).

(CI Not Found by Serio) Do you have a Computer Tag Number there I can use? (If they do, locate it and select it for this call)

Now, how can I help? (Record as good a description as you can, and don’t be afraid to ask the customer to slow down or pause for you).

(If it’s not clear, ask) What affect is this having on you at the moment, is it stopping you from working? How many co-workers are affected (Record this as an Impact).

(Save the Incident) Your Reference number is …. One of our staff will contact you within the next … working hours.

There is a lot of different ways of approaching this. I’ll post later in the week with a critique and comment on this Script, showing how things could be done differently and what choices you yourself can make.

Friday, 25 Aug 2006

In this post, I’m going to talk about backup for your front line Service Desk/Helpdesk staff who log Incidents from customers. It follows on from my previous posts ‘Incident Management - how good are you at taking calls?’ and ‘Incident Management - how good are you at taking calls (cont)’ posted earlier in the week.

By backup, I’m not referring to filling in when staff are absent, or to escalation to other support lines. Instead, I’m talking about the documentation and guidance your staff need, particularly when they lack experience in your organisation.

What I am referring to are two things: a Call Handling Script (I’ll just call this the Script) and an Operations Manual. This post will be on the subject of the Script, I’ll leave the Operations Manual to a later posts.

So – do you have a Script? Many Helpdesk and Service desks don’t seem to. If you do – is it being used?

One of the common objections raised to having a Script is this: ‘I don’t want my staff to sound robotic’. This is quite right – robots are not desirable. However, having a properly prepared Script should not lead to that.

A Script should confirm the key items of data to be captured for each Incident logged. If used intelligently it will give consistency of experience to customers logging Incidents via the telephone, and improve the quality of data available in your software tool. If you have 2nd and 3rd line support teams, they might welcome a Script.

I’ll write some brief do’s and don’ts for call logging scripts, and in my next post I’ll write a sample Script.

Call Logging Script Do’s and Don’ts

Do – Assume your staff are trained to a reasonable level (see my earlier posts) and are proficient with the software tool you use.

Don’t – Attempt to micro-manage staff through the Script. Leave Helpdesk and Service Desk staff free to use their own words.

Do – Try to fit the Script on a single A4 page.

Do – Check it’s being used, by placing test calls or by periodic monitoring of calls.

Do – Explain to your staff why a Script is a Good Thing (consistency of customer experience, improved Incident quality)

Pages