Serio Blog

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.

Friday, 11 Aug 2006

One thing I ought to add to my post below is that different web development environments are supported fine - .ASP and .NET as examples.

The new functionality includes full cookie and session management (including the big viewstate cookie).

With a new Command Center release due very soon, I thought I'd post on one of the new features which interest me most.

The Command Center now has revised HTTP web monitoring functionality. This is more than just pulling off web server statistics though.

Instead, you can now login to web applications, test the pages of the web application, and then log off again. In doing so, you can test for page not found errors, time out errors and so on.

It's a way for Service Desk and Helpdesk staff to probe web applications pro-actively, by performing actions that users perform, and measuring the user experience. Logging the results to disk is easy, an can include things such as

  • Time taken to log in
  • Time taken to return pages from the post operation
  • Is the content of the pages as expected?

You can perform test operations as often as you want - 15 seconds, 30 seconds, 5 minutes - it's up to you. The statistics produced can be very useful in Capacity and Availability Management!

Pages