Serio Blog

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.

If the last few posts have convinced you to give Problem Management a try – I’m glad. If not, I reserve my right to nag in future posts.

So how do you get started with your own Problem Management function, and what do you need?

Aside from a basic process, ideally you will have a CMDB (Configuration Management Data Base). I’ve posted about the CMDB here and here. I say ideally, because you can still derive benefits from Problem Management even if you don’t have one yet.

Here’s how you can get started:

  1. Nominate a Problem Manager – this is your most important step. This can be a member of your existing team. It is, of course, a way to add a bit of ‘career progression’ for a member of your staff. More about this here. Make sure that your Problem Manager is 'empowered' - he or she should certainly own the Problem Management process.
  2. Make sure that your Problem Manager is aware of what a Problem is. Ideally, he/she will have been on an ITIL Foundation Course. Failing that, they should at least have a copy of the ITIL Service Delivery and Service Support books. We also have resources here, such as our Introduction to ITIL and Problem Management white papers.
  3. Make sure that they know how to use the software tool. If you are a Serio user, logging a Problem is just as easy as logging an Incident. However, make sure that they know:
  • How to raise a Problem directly from an Incident (see the Help topic ‘Raising a Problem from an Incident in SerioClient’)
  • How to link an Incident to a Problem (the easiest way is simple copy/paste)
  • How to use the 'link count' of linked Incidents in the management process
  1. Make sure that you are entering Cause Categories when you resolve an Incident. Nominate a Cause Category for ‘Unknown’ (or 'Potential Problem') so that your Problem Manager can check for these. Ensure that your Incident Management staff are also aware of what Problems are, and have a mechanism for suggesting/flagging them to the Problem Manager (before you can manage and resolve Problems, you have to identify them).
  2. Depending on the size of your organisation, you may need a Problem Management team. Before you cry 'I've got no budget' consider that the Problem Management team is usually drawn from existing members of staff - that is, we simply add to their service management responsibilities.


Wednesday, 16 Aug 2006

One of the frequent objections I hear about Problem Management is this: our Service Desk does not have the time.

I totally sympathise with this, having acted as both Helpdesk and Service Desk manager in my time. When you are under pressure it's easy to push something like this out to a permanent 'next week'.

The point is though that Problem Management is something that can help to reduce the number of Incidents you are dealing with - helping to take the pressure off... and the payback period can often be quite short. Serio supports Problem Management, helping you by keeping the Problems you log quite separate from Incidents.

If that doesn't convince you - try this: allocate a fixed number of hours each week to Problem Management by a member of your team (who you'll nominate as your Problem Manager). Do this for a couple of months, and at the end of that time see if you've got anything worthwhile from your investment.

I'll follow this post at the end of the week some suggestions as to how you can get started with Problem Management.

Tuesday, 15 Aug 2006

Just a quick post following on from George's post about linking Incidents and Problems. There are quite a few ways that you can do this in the Serio tool, but by far and way the quickest way of linking is simply to use cut and paste.

  1. In the selected Incidents list, click on the Incident you want to link.
  2. Go to the Problem list, select the Problem you want to link to and click Paste. That's it - the two are now linked.

I thought I'd post this week about Problem Management, and pose the question: Do you have a Problem Management function? (And if not, why not?).

I'll start by giving a definition of what a Problem is: It's simply something that affects IT services where we do not understand the cause. An example I always give is this: suppose that your main database server fails (let's say with the Blue Screen of Death). You raise an Incident, reboot the server, and resolve the Incident once normal service is restored. You don't know why the server failed.

Is that the end of the matter for your Helpdesk/Service Desk? Do you have any mechanism for investigating the fault - or do you wait until it happens again?

It's Problem Management that fills that gap, and provides a separate framework to understand and resolve these kinds of issues.

I'll post more about Problem Management later in the week.