Serio IT Service Desk & Helpdesk Blog

Those of our Serio’s customers who have employed me as a consultant, or those whose accounts I handle, probably know I have a few (OK, many) hobby horses. One of them is Service Level Agreements (SLA), and in particular thinking about the SLA both widely and in terms of business need. Or put another way, there is rather more to it than setting target response and resolve times for each Incident that the Helpdesk/Service Desk handles.

In particular, it is important to consider Availability. What I mean is this:

• setting targets for the availability of key business systems
• trying to ensure that those targets are met
• reporting on what availability is actually met

At this point I should point out we have an Availability Management white paper that looks at a lot of the theory and background for you. If you are interested in the theory and more info generally on Availability Management check the white paper.

What I’m going to do in this and coming blogs is look at how Serio handles this and delivers Availability statistics.

So, you want accurate Availability statistics? First thing that you need to know is what systems or services you need statistics for (lets call them Key Services). It is often not easy to determine this, but I’ll assume you already have this information to hand. You will then need to have what the business requirement for Availability is for these Key Services, and there are a number of ways that you can express that. I’ve listed two examples below.

• Downtime in hours. You might say that the maximum acceptable downtime for a Key Service is ‘4 hours per month’.
• Uptime as a percentage. You might say that the target availability for a key service is 99% per month, meaning for your hours of operation the service is available 99% of the time. By the way, if that sounds good it still means around 2 hours actual loss of service per month on an 9:00 to 17:00 Mon-Fri SLA.

I’m going to continue this as a topic in coming posts.

• More on Availability Statistics
• Availability & Downtime Summary
• Availability Reporting Round-Up

Here’s a really nice but often unnoticed feature of SerioClient – speed logging (or logging an Incident in a few clicks). There are number of ways you can use this (for instance, repeat Incidents) but what I will write about is common Incidents. These are things such as password resets that you might have to perform 10 times a day.

Naturally you wish to log Incidents to record these, otherwise your reporting will be inaccurate. If you are logging Incidents such as this the usual way – by categorising and writing a description – you are going about it the long winded way.

Here’s how you would go about doing things the fast way.

1. The next time some one calls for a password reset, log the Incident correctly as you do at the moment. Categorise it, and put in a decent description. Save the Incident.

2. Look at the bottom of the screen. You see the link marked ‘Create Serio Alert’?. Click it. Give the Alert a name such as ‘Quick Password Reset’ then save it.

(You only have to do steps 1 and 2 once)

For the second (and all subsequent) password reset here is what you do.

3. Select the customer details as normal.

4. You’ll be taken onto the Incident Details screen. But look at the screen. See that there is a tab at the top marked ‘Serio Alerts’? Click this (or type Ctrl-2 shortcut).

5. You will be able to see an Alert called ‘Quick Password Reset’. Select it an click save.

6. Congratulations! You’ve just speed logged an Incident with a few clicks. It looks just like the Incident you created in step 1, but has a different customer.

Try it, it’s an easy way to log Incidents in a few clicks. Don’t forget to tell your colleagues what you’ve done, and how to use the Alert.

• Quick tip – Highlighting Rows in the Incident/Problem/Change lists
• Incident Logging Script – Follow-up
• Incident Logging – Sample Script

I’m going to return to the subject of the Configuration Management Data Base (CMDB) for this post, prompted by a customer that invited me to look at their CMDB.

ITIL makes a distinction between Asset Management and Configuration Management (the CMDB is what you get from an effective Configuration Management process). I’ll avoid quoting directly but it defines the two thus:

Asset Management: Accounting for IT assets for accounting or managerial purposes. This might include maintaining a list of items so that you know when warranties expire, or so you can perform some routine upgrade planning.

Configuration Management: Provide a logical model of all the Configuration Items within the organisation, showing how the combine and depend on each other to provide services to users.

In practice, this means that the two are quite different.

Asset Management is typified by lists of computers. These generally are not linked together to show much more than the machine and some peripherals attached (such as a monitor or printer). In an Asset Management system, it is sometimes hard to see server equipment amonst all the desktops, and you don’t see ‘virtual’ items such as web server instances or database server instances.

Configuration Management is typified by diagram rather than lists (though lists do exist of course). This is why Serio expresses the CMDB in graphical terms. The diagram shows a variety of items and shows how they link together and depend upon each other so that, for example, you can see the effects of shutting down a database server. The CMDB will typically have tangible and virtual items on it like I’ve mentioned above, and will show how items combine together to deliver customer services.

I’ll probably post more about this on Friday, but I’ll pose the question: how can you support an IT infrastructure that is not documented?

• Asset and Configuration Management Basics
• What is the Configuration Management Database (CMDB)?
• More on Configuration Items

If you are thinking of introducing Change Management to your Service Desk/Helpdesk, it is worth asking the question ‘are we ready’.

It is a good question to ask because Change Management requires a degree of process maturity, and presents those taking up Change Management with all sorts of technical, procedural and cultural issues to overcome.

Assess yourself honestly against the following statements – record if the statement is mainly true or mainly false. As in all things, there are no hard and fast rules – you may have a successful Change Management process implemented successfully with none of these things being true. These are just based on my own experiences and observations.

We have a mature and effective Incident Management process. It is written down in a concise and useable form.

We have a mature and effective Problem Management process.

We have an Incident Manager and Problem Manager.

We appreciate the importance of a Configuration Management Data Base (CMDB) in supporting effective Change Management. We are preparing to introduce one shortly after our Change Management process ‘goes live’.

We have a shared understanding of the problems we are trying to solve by introducing Change Management. For instance, there are not whole teams resisting the process, or who think that my organisation does not needs a Change Management process.

There is widespread support for the introduction of Change Management.

The IT function is quite ‘well organised’ within my company. For instance, there is a clear team structure and a clear understanding of responsibilities.

Our managers and team leaders are actively supporting the introduction of Change Management.

We have identified a person who we wish to act as our first Change Manager.

We have identified at least one person who will be our Configuration Manager and who will ‘own’ the CMDB.

We don’t have lots of different groups holding lots of important data in different places, such as access databases and spreadsheets. Our supporting data is easy to access and is within the ITSM tool.

We’ve picked one aspect of our IT services to be a pilot for Change Management. We want to learn from this experience before trying other aspects of the IT function with CM.

We understand that ITIL Change Management is not prescriptive in its approach (it does not tell us exactly what to do), though it gives us sound and sensible advice.

So how did you do?

More than 10 mainly true: You are probably OK to start thinking about your Change Management process – you are likely to succeed.

More than 6, but less than or equal to 10: You may not have sufficient process maturity or ‘buy-in’ from the rest of the organisation to succeed.

Less than 6: Hmmm. If you are still planning to go ahead, then I think you are brave. It might be that you don’t have much process maturity, and have insufficient buy-in. You may be working in a very informal and not customer-service focused environment.

Edit: Verso also have a related post on the subject of ‘the people factor‘.

• Change Control or Change Management?
• Introducing Change Management – Some Definitions
• Change Management – Defining the Process

In my last post (see below), I began looking at the question of what and how many Service Level Agreements (SLAs) you need with a recap of what an SLA is.

Today, I’ll introduce a real world example, which I will use in the next post to illustrate the sort of decisions involved in designing your own SLAs.

Example:
XYZABCD PLC provide services to the public seven days a week between the hours of 8am and 8pm. This operation is supported by an internal IT Service Desk.

There is no formal SLA between the Service Desk and the business, and the Service Delivery Manager is being pressed to provide one. Internally, however, the Service Desk do operate an informal SLA, and hope to put this on a formal basis.

Staff at the company can log support Incidents with Service Desk by telephone during working hours (8am-8pm Monday to Sunday) and by email or web outside these hours.

In fact, however, the engineers capable of resolving any faults are only at work between 8am and 5pm Monday to Friday. Outside those hours, the Service Desk staff manning the phones are able to resolve certain straightforward types of Incident, such as password resets, and can offer simple workarounds, but must wait until an engineer is in the office to deal with more complex problems.

Service Desk staff prioritise Incidents based on Impact. Non urgent requests or queries are given a low priority and may be dealt with within a couple of days. Faults that are causing inconvenience to user, but not preventing them working, are given a medium priority and must be dealt with the same day if possible. If the user cannot work, this is treated as a high priority and must be dealt with immediately.

Additionally, there are always a duty engineers who may be called in after 5pm when there is a critical fault affecting the company’s ability to provide service to the public (for example the failure a key network component). The Serio Command Center detects and raises alerts about such faults and sends text messages to the duty engineers. Should such an event occur the duty engineers must attend as quickly as possible, day or night. The Service Desk wants to ensure that key services are always available during opening hours.

• Deciding What SLAs You Need (Part 1)

Serio allows you to create multiple Service Level Agreements (SLAs). But how do you know what and how many SLAs you need, and is it a good idea to have multiple SLAs?

Over the next few posts I’ll be looking at these questions by considering a real world situation where an SLA must be designed, and the decisions taken in designing it .

I’ll start with a reminder of what a Service Level Agreement is, and what it is not.

A Service Level Agreement is an agreement with your customers describing the minimum levels of service they can expect from the Helpdesk/Service Desk. As such it may include such things as the times during which the service is available (e.g. 9-5.30 Monday to Friday, or 24/7), target response and resolve times for Incidents of different priorities, and levels of availability of IT services, such as email and key applications.

Key Concept: A Service Level Agreement should make levels of service predictable from a customer’s point of view.

For example, the Service Level Agreement may say things like: “A high priority Incident is an Incident that is preventing you from working, or seriously disrupting your work – for example, if your workstation or an important software application you use is not functioning. We aim to resolve 95% of such Incidents within 2 working hours.”

A Service Level Agreement is not meant as a direct measure of performance of Service Delivery staff and you should not design SLAs to measure Agent performance. (Of course, Helpdesk/Service Desk performance must be measured against the SLA, but the SLA’s main function is enable customers to predict the level of service they will receive, and the latter must the principal consideration in designing your SLA.)

In the next post I’ll introduce a real world situation requiring an SLA to be designed, and in subsequent posts at the decisions involved designing the SLA.

• Deciding What SLAs You Need (Part 2)
• Supplier Management – SLAs and Stopping the Clock

If you took the Helpdesk/Service Desk Metrics Health Check and made a note of your score, here is my take on the scoring bands.

40 or more

Super Hero. Take a bow. You work on a wide breadth of data, and are on top of your management reporting. You probably have days where things go wrong, but on the whole you provide a very professional and effective service to your customers.

39 to 24

Prize fighter. Very good performance, but with room for improvement. You need to expand the range of data that you use somewhat. However, your reporting is still probably above average. Try setting yourself some management objectives (such as improving first-time fix rate) and then seek out the data you need to help you deliver and monitor this.

23 to 8

Mr Average. You use some data, but there is a lot of room for improvement here – you simply are not using as much information as you could be. See the white paper on our website called Service Desk Metrics, and then prepare a project plan for yourself. Using more data will help point out where service improvements are needed and can be most cost-effectively made.

7 or less

Grapecrusher. You have barely got started with IT Service Management, and are either not reporting at all, or run very few reports. Right now you have no data as such to make decisions with. See the white paper on our website called Service Desk Metrics, and then prepare a project plan for yourself – do this as a matter of urgency!

• Making a Start with ITSM Reporting
• Interpreting your IT Service Management Data & Reporting

One of the things I help customers with a lot is reporting. In essence, helping people choose what ITSM statistics to examine, and then helping them interpret the data and use it to make management decisions with – something that sounds rather easier than it is for those getting started with ITSM.

I’ve prepared a somewhat light-hearted survey for you to take below to assess the quality of your own reporting. Simply read the statement and then make a note of the score for the best response available for you.

‘I run reports and then frame a text summary of the data available which explains my own conclusions and future actions’

I just print them and send them direct to customers (score 1)
I sometime do this (score 2)
There are reports? (score 0)
Yes, I do this every week or month (score 5)

‘My reports focus mainly on Incidents logged and resolved, broken down in different ways’

Yes that is true (score 2)
I use this data and quite a few other streams as well (score 5)
I don’t report on Incidents logged at all (Score 0)

‘I report on the number of first-time fixes made by my Helpdesk/Service Desk’

Yes (score 6)
What is a first-time fix? (Score 0)

‘I report on responsiveness – how soon we contact customers after reporting a fault’

Yes (Score 5)
I just report on resolution performance with respect to my SLA (Score 2)
I ignore SLA data, my customers don’t care about that (Score 0)

‘My reporting uses Causes for Incidents that we resolve.’

No, I’ve never got round to defining any Cause data (score 0)
Yes I run reports using Cause data (score 4)
Yes, I run reports using Cause data & I use this data to reduce Incidents (score 5)
Causes are for wimps – I have a Proactive Problem Management framework in place (score 6)

‘I run reports that produce statistics for both Team and Agent performance. I use this info to see how Incidents move through to resolution.’

No my customers are not interested in this (score 0)
Sometimes, when I think I have a problem (score 2)
Yes always (score 5)

‘My statistics include telephone stats such as call abandonment and number of rings before pickup’

Yes (score 5)
If we pick up the phone too quickly customers phone too often (score -1)
No I never thought about this & don’t report on it (score 0)

‘My reports include a section on Major Incidents where I report what Major Incidents occurred, and what we have learned from them’

We are too busy fixing the Major Incident to record it and report it (score 0)
If I report on Major Incidents we will look bad (score 0)
Yes always (score 5)

I’ll write on what you can conclude from your scores in my next post. In the meantime, add up your score.

Edit by admin: You can rate your scores here. We also have a white paper entitled ‘Service Desk/Helpdesk Metrics – Getting Started’ you can read here.

• More Simple Helpdesk/Service Desk Metrics and Reports
• Does Your Helpdesk/Service Desk Phone Just Ring Out?
• Measuring the Performance of Helpdesk/Service Desk Teams and Agents

Ever wished you could highlight High Priority Incidents red? Or Hardware faults blue? Here’s how you do it.

1. Go to your list of Incidents, Problems or Changes.

[ Figure 1 - Incident List ]
2. Alt-Click the data item you wish to highlight by. In this example, I want to highlight by Priority, so I Alt-Click Priority.This will bring up the row highlighter dialog.

[ Figure 2 - Data Highlighter ]
Use the highlighter to specify your colours and styles. I will choose a red background.

3. When you click ‘OK’ this is what you see.

[ Figure 3 - Highlighted High Priority Incidents (in red) ]

4. You can set multiple highlighting options – Serio evalutates them in the order you leave them in the list.

5. Lots of screens in Serio can be customised like this – just try Alt-Click.

• Quick Tip – Speed Logging

This will (hopefully) wrap-up my previous Callback posts.

Recall that I have covered how you can use display columns in Serio to view if a Callback is outstanding on an Incident? One thing that I should have added is that you can also query for Incidents with Callbacks that are due, and you can use the SLA Performance Dashboard (2nd dial) as well.

Placing Callbacks

Serio Agents: When you take this Action you’ll see your Callback Calendar (below). Simply use this to book your upcoming Callbacks by clicking a square.

[ Figure 1 - Callback Calendar ]

Setting the system so that you can Book Callbacks, and then Flag the Callback as Taken

Experienced Serio users will probably guess that it is all done through Actions – and you’d be right.

Serio Administrators: At the very least if you want to start using Callbacks you need an Action called ‘Book Callback’ and one called ‘Callback Taken’. When you set-up the Actions, look at the possible Action Extensions available: amongst the options you’ll see

• Book Callback
• Flag Callback as Taken

Use these as appropriate for the two Actions you are creating.

Setting the system so that eMails can be counted as Callbacks

Serio Administrators: It’s very easy. Simply edit your ‘Send eMail’ Action so that it has the ‘Flag Callback as Taken’ Extension. It’s probably best to make this conditional – use the ‘Ask the Agent’ option, and use this question: ‘There’s a Callback outstanding – do you want to flag this Callback as being made by this email?’.

Getting Callback Notifications

As the time to make a Callback approaches, and the Callback has not been made, Serio will automatically send a reminder to the Agent currently assigned to the Incident. You can also configure the Serio Escalation Engine to send you emails, text messages and Serio Messages as a time of your choosing before the Callback is due.

• More on making sure we call back
• Making use of Agent Status