Serio Blog

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 



"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.



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:






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 


"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)

Wednesday, 23 Aug 2006

This post follows on from my previous post about call handling.

In this post, I want to talk about training for the ‘front-line’ members of the Helpdesk or Service Desk, particularly when you are preparing new staff for handling incoming Incidents from customers.

Firstly, make sure that they can use your ITSM software tool. You don’t always have to call your software vendor – just make sure that you take a structured approach if you do this in-house.

ITSM Software tool training

Don’t : sit the new helpdesk member of staff next to an experienced employee and expect them to be trained.

Do: Create a list of things the new helpdesk staffer needs to be able to do during call logging. For instance, if you are a Serio user, I’d expect the following to be on the list:

  • Select the customer based on something other than Surname
  • Understand (and be able to explain) what fields like Issue Type and Problem Area are
  • How to access the spell checker
  • How to select an Item from the CMDB
  • How to over-ride any default Priorities you’ve set-up.
  • How to use Actions How to link documents
  • How to process new Incidents that might be placed in the Inbox.
  • How to use Serio Alerts.

Do: Prepare a series of workshops for the new employee.

Do: Prepare a series of workshops for the new employee.

Do: Provide a training system for the employee to use – don’t ask them to use the ‘live’ system. At Serio, we advise that you copy the live database to a test or training environment.

Do: Provide a separate training environment away from the main Helpdesk or Service Desk.

Call handling training

For me, this is the important bit. The first call handled by your new Helpdesk staff member should not be from a real customer. 

You should prepare a series of test calls and simulations and see how the new employee handles these. Make your test calls realistic, and increasing in complexity. Log the Incidents for each call first yourself.

Ask a peer to make the test calls – if managers make these, it can sometimes make people too nervous.

It will be pretty obvious is more work is needed, but you can consider the following in assessing results:

- How confident did your new employee sound?

- Did they control the call?

- Was everything captured that you expected to be captured?

- How do the Incidents logged compare to those you logged yourself? Explain any differences you find carefully and patiently.

In the post that started this thread I mentioned backup, and I think you need backup in the form of a Call Handling Script – something that outlines the information we expect to get on each Incident we log, and the order in which the information is obtained.

I’ll post more on this subject later.

Monday, 21 Aug 2006

Do you ever listen in to how your front line Helpdesk or Service Desk handle calls?

The reason I ask is that, if you’ve never ‘listened in’ you may be surprised at how the calls are handled. All too often it seems that front line staff are placed in situations where they are taking calls from customers, but they have little training, backup and monitoring – except for some assistance on how to use the software tool (often 5 minutes ‘sitting next to Nellie’).

Of course, people can and do ‘muddle through’ but I’d contend this is not an ideal state of affairs for customer focused Helpdesks and Service Desks.

What it leads to is a wholly inconsistent customer experience. There’s no set script, and a generally lower quality of inputs to the Incident Management process.

I mentioned three elements above – training, backup and monitoring.

Training – Running through different types of calls in a simulated environment, training on using the tool.

Backup – Call handling Scripts, documented Operations Manual.

Monitoring – Placing test calls, listening in on incoming call handling.

I’m going to expand on each of these over my next posts – we’ll look at what you can do to improve your own call handling.

Friday, 18 Aug 2006

ITIL doesn't stand still. Over at Verso Solutions they've posted about the ITIL Refresh Scope and Development Plan.