Serio IT Service Desk & Helpdesk Blog

If you are a Serio user, at some point you are almost certainly going to want to exchange emails with another support system. There are generally two cases that we see being met:

- You have a supplier you wish to exchange information with via email as part of Supplier Management.
- You are a company that deals with external customers, and one or more of your customers has their own support system.

By exchanging emails, I mean that when you send them an email from Serio it is added to the correct ticket and processed efficiently, and likewise when the supplier or customer sends you an email from their system that Serio picks it up and places it with the right ticket.

Things like this usually work seamlessly, and I’ll explain how they work. Most support services use something called a Reply Reference (in Serio’s case), or a ticket id, or an email reference code. It’s something that

• uniquely identifies the originating ticket
• is unlikely to come-up in normal email exchanges by accident

The main thing to understand is that there is short text string that can be used to identify the best ticket to add the email to.

If you are just using Serio, all you need to worry about is that the Reply Reference is quoted, which normally means putting it in all outgoing emails, so that when customers or suppliers reply it is automatically quoted back, and the email is handled correctly.

When you start to deal with an external system, all of a sudden have 2 Reply References to consider; your own, which you are familiar with, and theirs – your supplier or customer. I’ll call this the 3rd Party Reference.

Here’s what you need to do to make this work.

Logging an Incident for a Customer who has their own support system

In this case, you might be acting as a support supplier or 2nd line support service.

- If the customer has telephoned you, ask them for the 3rd Party Reference (remember though, they’ll call it something different). Enter this value into the Customer Reference field.
- Change your eDocs to include the Customer Reference, if they don’t already. Make sure that at the very least it is included on the confirmation email, and on emails you send during the life of a ticket.

- If the Incident comes to you by email, make sure that your Customer has included their 3rd Party Reference.
- Just log the ticket as usual, and change your eDocs to quote the Incident description (but most of you will find it is already quoted). There is usually nothing else to do.

- In either case, ask your customer to quote your own Replay Reference on all subsequent emails they send.

Assigning an Incident to a Supplier

In this case, you are logging the ticket and assigning to a Supplier.

- Log the ticket as normal.
- Use Supplier Management to assign the ticket to the Supplier.
- Use Supplier Management Actions (Supplier Acknowledgment) to record the 3rd Party Reference from your Supplier.
- Make sure that you include this on all of your outgoing Supplier emails by amending your eDocs to include it.

• Serio eMails, an Overview including Variable Language and Sender Address
• Establishing a 24-Hour Helpdesk or Service Desk
• Service Desk/Helpdesk Metrics Health Check

This is a follow-up post to Estimating the Cost of Incidents. I wrote then that if you are going to make such an estimation, you need to look at costs to the business, and the costs of resolving the Incidents (i.e., the cost of the IT function). The previous post dealt with costs to the business, so this post will address something not often mentioned – the cost of the Incident Management and resolution service.

Factors to Consider

Throughput (t) – either the number of Incidents logged or resolved in a month. Take a typical or average figure.
Team composition – The people involved in Incident Management and Resolution.
Time Spent Estimate (p) – Each member of the team might have a percentage to indicate the amount of time they spend on Incident management activities. Some staff will be 100% devoted to this task, others not.
Capital Expenditure (c) – The Incident Management team will have a degree of capital expenditure associated with them – computers, desks, ITSM system and so on. This expenditure will generally depreciate, and you can use this annual depreciation in your calculations. You can usually obtain this information either internally from the Helpdesk/Service Desk itself if you have a functioning Asset Management function, or from your accounts team. Use an annual depreciation figure.
Average Salary (y) – The average salary of those involved in IT management will be needed. Don’t try estimating different worker levels, just use an average figure. If in doubt use your own salary as a guide. Use an annual figure.
Overheads – When employing any group of workers, you have to pay for a bunch of other stuff like office accommodation, training and so on. If you don’t know what figure to choose, make it 30% (this is the figure I’ve used) of your salary, as this is a generally accepted guide. Again, use an annual figure.

Blending all of the above into the mix brings us to a formula you can use as a cost-per-Incident-per-month (CPI) for delivering the Incident resolution service. I’ve broken the formula down into two parts to make it easier to read.

1. Staff Costs, pa

This is easiest if you use a spreadsheet. Make one row per Incident Management employee as follows. The numeric figure is (p) from above – percentage of time spent in Incident management and resolution.

Joe Bloggs b = (y / 100) * 90
John Smith b = (y /100) * 100
Paul Barnes b = (y / 100) *50
…
s = sum of all b. This represents annual staff costs attributable to the process.

2. Cost per Incident

This is the figure we’re after, a cost per Incident

CPI = ( s + (s * 30/100) + c) / (12 * t) )

Odd things thrown up by this formula

1. The cost per Incident will almost certainly go up if you have a quiet month with fewer Incidents, as most of your costs will be fixed or semi-fixed. This may be offset by a reduction in impact costs associated with Incidents, as mentioned out in the previous post. Whether or not you can measure that so directly is difficult to tell.

2. It may be that the cost of Incident impact is dwarfed by the cost of the Incident resolution service. However, no rational person would jump to the conclusion that it is cost effective to close or diminish the Incident management service – would they?

Technorati Tags: ITIL, Incident, Helpdesk

• Estimating the Cost of Incidents
• Change Management Scope and Cost Justification
• Supplier Management – Key Steps in the Process

I’m asked by a customer through our support service here at Serio:

How do you estimate how much all of our Incidents cost the business? Any pointers you can give? I’ve been asked this by our IT Director.

I’ll start by saying this is almost impossible to do retrospectively, and I’ll go on to explain why shortly.

It’s worth noting there will be two cost streams in any such calculation: the cost to the business of the Incident itself, and the cost of providing the service to resolve the Incident. Both of these might be very tricky to pin down, particularly the first one – which is the subject of this post.

I’d also counsel against providing ‘junk’ statistics just because someone asked for them.

Cost to the Business of the Incidents we Log

Let’s start with Major Incidents. Because Major Incidents usually

• happen infrequently
• have significant business impact
• and affect groups of users we can more easily identify

it is usually much easier to assess their business cost by assessing lost production hours, loss of profitability, damage to reputation and so on. For a full discussion about this, including formulae you can use, see our Availability White Paper.

Whilst the above can take care of a small handful of Major Incidents, what about the rest of your Incident workpool (which I’ll call Routine Incidents). Routine Incidents in my definition range from tickets affecting a desktop computer to a stuck mouse. How do you assess the financial cost of these to the business?

Retrospectively, I don’t think you can do that easily, if at all. The fact is that some Incidents will have no cost (someone wishing to upgrade to Firefox 3 or get their screen cleaned), some will have a cost, but a cost quite difficult to calculate because it is connected with intangibles such as lost business opportunity. Aside from going through each Incident individually, it’s hard for me to see any system that would deliver meaningful (as opposed to made-up-on-the-spot) statistics.

Going forward, there is something you might be able to do. In the same way that Cause Categories are applied to Incidents when they are closed, you might also apply a cost code which would be a way of approximating the actual cost of the ticket. The person responsible for setting the ticket as resolved could set this value, or it could be an off-line job for the Helpdesk/Service Desk. In either case it’s going to be a value judgement. I can think of about 3 ways of creating and using such a code in Serio.

For example, you might decide upon 5 cost codes

0 – No cost, zero
1 – £0-£5
2 – £5-£20
3 – £20-£50
4 – £50-£100
5 – £100-£200

…and then all you need to do is run a report aggregating these, choosing either the low or upper value from each cost code to come to an actual cost.

I’ll post about calculating the cost of the Incident Resolution process later in the week.

Technorati Tags: ITIL, Incident, Helpdesk

• Estimating the Cost of Incidents – The Incident Management Process
• Change Management Scope and Cost Justification
• Handling Major Incidents