Serio Blog

Friday, 13 Oct 2006

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.

Thursday, 12 Oct 2006

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!

Monday, 09 Oct 2006

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.

Friday, 06 Oct 2006

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.

Serio Incident List

    ​Figure 1 - Incident List

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

Data Highlighter

Use the highlighter to specify your colours and styles. I will choose a red background.




Figure 2 - Data Highlighter


  1. When you click 'OK' this is what you see. 

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


  1. You can set multiple highlighting options - Serio evalutates them in the order you leave them in the list.
  2. Lots of screens in Serio can be customised like this - just try Alt-Click.

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.Callback Calendar

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.

Wednesday, 04 Oct 2006

This is a follow-on from my last post ‘I’ll call you…later

The problem I’m addressing is making sure that we call our customers back when they are expecting it, which means

  • After they have reported an Incident to us (Serio calls this the Primary Callback)
  • Calling back when we say we will, or when the customer asks (Serio calls these Secondary Callbacks)

I’m often asked if emails count as Callbacks. The answer is Yes, provided they are written by a human and are not ‘automated’.

I mentioned in Mondays post that the Helpdesk/Service Desk needs to get some help from the ITSM tool, so what follows aims to give you an overview of Callbacks within Serio. Most of what follows applies to Incidents, but it’s just as easy to apply to Problems and Changes.

Seeing what Callbacks are booked, and whether-or-not they are overdue

You do this through choosing the right columns when viewing Incidents in your ‘Selected Incidents’ list (you knew you could change the columns you see, right?). Specifically, you need to add these columns:

  • Callback Outstanding (Any)
  • Callback Reason
  • Callback Due Date/Time

Serio Query - Selecting the right columns

Figure 1 - Setup picture

​[Callback Outstanding (Any) is an interesting one, it shows blue for Callbacks we’ve booked, and red for Callbacks that are late.

When you use these columns, here is what they look like Serio query result


In figure 2, Incident 2081 has an overdue (late) Callback shown by the red tick. Incident 2096 has a Callback booked for 10th October which is not due yet. The other Incidents have no Callbacks set.








Figure 2 - How the columns show when used

I’ll post on Friday how you can actually set and manage your own Callbacks. If you are impatient, look for the following book in the Serio HowTo guide (Administrator How-To/Managing Issues/Callback) – this tells you in some depth what you need to do.

Monday, 02 Oct 2006

‘I’ll call you tomorrow to let you know how we are getting on’.

It’s easily said to a customer reporting a problem, and if the number of Incidents that you staff are dealing with is small (and the environment no overly hectic) it’s not so difficult to do.

However… once the number of Incidents active for each member of the Service Desk/Helpdesk rises (say above 20), the likelihood of that callback being made starts to dip alarmingly. If Incidents are being re-assigned to specialist teams in the meantime, the likelihood drops to ‘not very likely at all’.

Let’s ask ourselves this: does it matter? After all, our Service Level Agreement (SLA) measures the timeliness of the initial response. However, that is just the initial response – what about Incidents that take longer to resolve? My experience is simple: regular communication with customers is vital, and too important to be left to chance.

I’ve posted before that good SLA metrics don’t necessarily mean happy customers, and I think this is another instance. For the most part customers remember if you’ve promised to give a callback and will look forward to the call. If it does not arrive, you’ve tarnished your Helpdesk/Service Desk’s reputation, with many customer’s drawing a conclusion that you’ve ‘forgotten’ about their Incident and are not working on it which is often not the case.

So, what do we do? This is an area where you have to rely on your ITSM tool to help you, and my next post will cover this for Serio users.

If you are a Service Delivery or Service Level Manager you should consider what statistics you have available for monitoring callback performance. If you have none, I would suggest this is something you need to address as a matter of urgency.

On the Verso blog there are a couple of new blog articles by Kirstie Magowan that may be of interest. The first is Making use of your CMDB and the second is Keeping your CMDB data current.

Friday, 29 Sep 2006

I said in my last post ‘Supplier Management – Roundup and Finish’ that the blog would move away from the Supplier Management topic for the time being. However, I am prompted to return to it today due to a conversation I had with a long-time customer yesterday, who is starting out with Supplier Management and has been following the blog.

The question was this: They have set their system up so that, when an assignment is made to a supplier, the internal Service Level Agreement (SLA) is ‘clock stopped’ until the supplier resolution occurs – is this right?

Our customer had some doubts about this, but had set the system up this way because ‘if the Incident is being assigned externally we (the helpdesk) can’t resolve it so it isn’t fair for it to drag down our statistics’.

My experience is that this is quite a common procedure, but I don’t think it is the right approach to take.

My reasoning lies in What an SLA is, and What an SLA is for – but I’ll start by saying what an SLA is not:

An SLA is not there (or should not be used) to remind you when you have to do things by.

An SLA is the minimum level (or acceptable level) of service required by the business, and it many cases is targeted towards Incident resolution and restoration of services after a fault. If this does not help, consider things from the customer’s point of view.

Imagine you have a customer Carole that deals with your organisation’s customers – the customers who pay invoices and keep your company in business. If Carole has an IT problem that stops her doing her job effectively, what matters is the time that it takes the Helpdesk/Service Desk to resolve her problem. She is unlikely to be interested in the fact that you may or may not have had to use a 3rd party supplier – she has customers to deal with.

This is where the SLA comes in. It’s trying to ensure that there is a reasonable and agreed understanding of when Carole’s problem will be resolved. If you choose to use 3-rd party suppliers then that needs to be factored into the design of the SLA that you have – something that this blog may return to later.

Wednesday, 27 Sep 2006

Whilst George is away, I will finish his series of posts on Supplier Management. As indicated in the previous blog entry, this post is going to be about getting started.

I’ll recap on George’s previous posts first, which have covered:

So how do you get started in Serio?

I will outline the major steps here, but for the definitive guide you should see the topic ‘Supplier Management Roadmap’ in the HowTo guide, part of the Serio documentation distributed with the product.

  1. Determine the data you need to effectively monitor supplier performance. Examine the contract or agreement you have, obtain any service levels that the supplier is meant to meet, and consider the data you need from your ITSM tool.
  2. Determine how Incidents will be passed to the supplier. Here you are looking at the key Supplier Management steps, and how they relate to a given supplier. If it helps, draw a map or a flowchart. You are deciding things like ‘do I assign using email or telephone’, ‘what information needs to be contained within assignment emails to the supplier’, ‘when do I get the supplier reference number’ and so on.
  3. Update your Incident Management process accordingly. Ensure that the responsibilities for supplier-assigned Incidents is clearly defined, and that a procedure or guidance exists for handling overdue or problematic Incidents that have been assigned externally. Make sure clear guidance is given to Service Desk/Helpdesk staff.
  4. Now you need to use Serio to start to set some of this up.
  • Start by entering your supplier details (name, address, telephone number and so on.).
  • Enter any new supplier Service Level Agreements (SLA) that you need, and associate them with the suppliers you’ve created.
  • Create Actions that will perform the various assignments, acknowledgements and resolutions you identified in step 2.
  • Make these Actions available to your front line staff.
  • Create Issue Queries for your staff (do this centrally, don’t expect your Helpdesk/Service Desk staff to create them themselves). These Queries should retrieve Incidents that are assigned to suppliers, assigned to a particular supplier and so on.
  • Create Issue Displays (again, do this centrally) that allow those involved with Supplier Management to see key supplier data. Issue Displays control the columns that you see in the Issue Monitor.
  1. At intervals, run management reports from SerioReports to examine supplier performance, drawing the attention of your suppliers to unacceptable performance as required.