a house-on-the-hill guide to categories and sla management. · most efficient system. ......

A House-on-the-Hill Guide to… of 25

A House-on-the-Hill Guide to Categories and SLA

Management. House-on-the-Hill Software December 2005 Version 1.0


Contents

Contents ..................................................................................................2 1. Introduction.......................................................................................3 2. Categories .........................................................................................4 3. What to use where. ............................................................................7 4. The Main Categories...........................................................................9

Types and Sub-Types ............................................................................9 The Status Category. ...........................................................................11 The Priority Category ...........................................................................15 SLAs Service Level Agreement. ............................................................17 Setting a Calendar for an SLA ...............................................................18

5. Making my Categories work. .............................................................20 6. Which Category to use......................................................................22 7. Where next......................................................................................25


1. Introduction SupportDesk has the flexibility to match the conditions of whatever Service Level Agreements (SLA’s) are needed, and to categorise calls by whatever terminology and coding that may be required. However… after dealing with many customers using SupportDesk in a variety of environments we have found that if done badly this can be an area that may lead to confusion and the creation of a complicated and unwieldy system. When done well one is rewarded with a help desk system that runs efficiently, and at the same time one finds that calls needing immediate attention are highlighted automatically with no extra effort other than the initial collection of the call details.

This paper aims to provide a guide to some of the thought processes and basic ground rules that the trainers and analysts at House-on-the-Hill try to follow when working with customers to set up Categories and SLA management. Whilst not being able to lay down an exact template into the way every SupportDesk should be configured there are some strong guidelines that will assist to build solid foundations for those embarking on the configuration process.


2. Categories Within SupportDesk calls are categorised in five ways. Type, Sub-Type, Status, Priority and SLA – Service Level Agreement. On the Categories and SLA Management screen (Figure 1) there are also tabs to maintain Actions and Activities, which are covered in another paper. There is also be a Tab showing Sales Stages which is only applicable if the CRM module is included.

Figure 1

The maintenance screens for each of these categories is very similar (Figure 2) and they all share many of the same settings and attributes. Where there are differences this paper will highlight these in the section on that particular Category. Each of the categories is defined through three tabs: “Detail” (Figure 2), “Workflow and Actions” (Figure 3), and Escalation” (Figure 4), all of which are shown below.


Figure 2

Figure 3


Figure 4

As can be seen there are numerous settings and options on each of the tabs, but one should not fall into the trap of having to set these when first creating the category codes, or even having to set most of them at all. Part of the success of SupportDesk can be put down to its flexibility, as represented by this choice of settings, but it is not mandatory to use all of them on every category and in most cases prudent use makes for the most efficient system.

In working with customers the consultants and trainers at House-on-the-Hill have found that the best approach to this area of the system is to actually create the framework of the categories first, using only limited settings that assist in the use of the Categories themselves.

The settings we will visit on this first pass are the actual Category codes themselves and a feature that SupportDesk calls Parenting.

A second pass through the category framework then makes use of settings that actually make the Categories work within SupportDesk to drive call response. This revisit of the category codes is covered in this paper under “Making my categories work”. A third pass of the Category codes looks at some of the other settings that add even more streamlining to SupportDesk and focus on Workflow, Actions and Escalation. This is covered in the section “Workflow, Actions and Escalation”.

To start with however we will focus on what each of the categories is ideally used for and some of the thought processes behind their use.


3. What to use where.

Before starting it is important that there is clarity of thought on how each of these categories is used; what they mean in the context of your calls; and equally important, what they don’t mean.

Whilst SupportDesk has the flexibility to actually rename these call categories through use of the Data Dictionary, for the purpose of this document the default names will be used.

When setting up Categories and SLA’s there are some key questions that one should keep returning to as sanity checks as to how the system is being configured.

1.Will it be confusing for people who are actually taking the calls?

A simple example of this is the scenario of 25 Types of call each with 10 Subtypes. Consider then the people actually taking the call and the level of understanding they require of these Types and Subtypes to be able to correctly categorise the call. The risk exists that this categorisation will quickly fall into disuse and it will become common practice to disregard the classification and focus on the call Subject. Once this happens then any breakdown of meaningful call statistics is lost and reporting becomes meaningless.

Similar problems exist with the Target times that SupportDesk calculates – as will be seen later these can be driven by the categories but it should be apparent which category and not a logic test to determine which category took precedent over which to derive the displayed times. 2. Will end users make sense of my categorisation if logging their own calls through the SupportDesk Web front end? SupportDesk already has design features that work towards simplifying what the Web users see when they log calls – such as flagging a call Type as Web Enabled or not, but the points raised in Q1 may still apply. There is also the argument that end users logging their own calls will have far less consideration for the validity of your SupportDesk data than you do, and as such every effort has to be made to control the data they provide that surrounds the actual Subject of the call.

3. Will the nature of my categorisation slow down the recording of the call? Similar to the issues in Question 1, in that the complexity of the call classification, unless clearly relevant in the context of its use, will


dramatically slow down the call taking process with the almost inevitable same outcome as described in Q1 and the subsequent loss of meaningful data.

4. Will my call categorisation give me the raw data I need for my reports?

Having the right categorisation of calls – which is at a level that can be adhered to (See Q1 and Q2), is the first step in giving you meaningful information from your SupportDesk system. It is only from this data that any detailed information about the calls can be gleaned and subsequently used for ‘Root cause analysis’ if appropriate. If all calls are categorised too generically then the only way we can understand anything about the nature of the call is through time-consuming review of the call subject. This is not a burden to be taken on lightly and certainly not when a level of planning can create a SupportDesk System that will maximise the potential to obtain meaningful and accurately categorised data.

5. Do I want to be the font of all knowledge on the categorisation and SLA settings on SupportDesk?

Unlike previous questions this one’s particularly subjective. If the answer is “Yes” then good luck. For those who may ponder this question and rightfully decide that they don’t then congratulations at making a good decision! If the categorisation of calls and automatic calculation of target times is overtly complex then there will undoubtedly be lack of update, ‘buy-in’ and ownership of the system throughout the work environment in which it is operating.

Conversely a system that has been configured with clarity, is efficient to use, and inherently builds a sound data repository that leads to meaningful reporting will be adopted without question and you will be surprised how many people claim to have been involved in its design and implementation.


4. The Main Categories.

Types and Sub-Types

Things you don’t want to hear! Q “What Type of call is it?”

A “A priority 1 type”

If we are going to go wrong it’s nice to have the opportunity to go wrong at the beginning and we have seen this happen with the use of “Type”. To understand what is meant by Type we often have to go through what is not meant and then by a process of elimination be left with a sensible unambiguous meaning.

Following that logic, what we don’t mean by Type is Priority, or Status. The Type of call should provide an immediate understanding of what the call is related to at a level neither too high nor too low. To have Type “Computer” in an IT Helpdesk will win you no friends, nor will having Type “HHSKEY.dll” or something that is particularly esoteric.

Unfortunately there is no definitive list that we can provide that will be a perfect fit for all businesses but through combinations of the Types and Sub-Types, which can be parented by Types ( i.e. – only be offered when that Type is selected) we have yet to find an environment that can’t be covered. Like all of the categories that have to be defined make sure that you concentrate on the calls that make up the bulk of your load rather than the exceptions that are hard to classify. If you manage to accurately encompass 80% of your calls into meaningful Types in the first attempt at setting this category you will have done well. The other 20% can initially be assigned a “Dump” Type which can gradually be eliminated as the categorisation of this 20% becomes clear.

Whilst considering Types and Sub-Types it is always a good exercise to consider the reports that you want to get from SupportDesk and how you want to see these split at a high level. The ideal balance is to come up with a range of Types / Sub-Types that are not so all encompassing that they include everything but at the same time are not so esoteric that the call takers are in doubt what Type of call it is and leave you with report data that is meaningless.

HotH Hint. When starting off it is far better to have too few Types and Sub-Types than too many. As the data and use of SupportDesk grows you will find that it becomes self-apparent what new Types or Sub-Types need to be added and a gradual introduction of new categories eases their adoption.


Parents of Type. Like all Categories Types can have a parent. This is a term that we will come across several times and depending on the situation it can have two slightly different meanings but the way it gets used is effectively the same.

In the case of Type we no longer use any parenting, but make use of Sub-Types instead. The reason the Parent option is still shown in versions as recent as SupportDesk Blue is that like all good software, SupportDesk is developed and improves – customers taking new versions as the Support Contract allows. For those customers who have been with House-on-the-Hill for some time certain features that are used in their configuration are retained. This is one example.

1.

Sub-Type. The Sub-Type category has already been referred to in the discussion on Types and should simply be considered as a way to break down your Types into more discrete groupings. Setting the parent of your Sub-Type to be one of the Type Categories will automatically filter the options for Sub-Type. An example here in an ITT environment could be: - Type – Printer Fault. Sub–Type(s) Epsom; HP, Lexmark, Olivetti..etc

Hoth Hint. Don’t use parenting on Types, simply make use of Sub-Types instead.

HotH Hint. Try and be consistent with your use of Types and Sub-Types in that Types either have Sub-Types or they don’t. Staff taking calls will get used to a way of working and will either expect to select a Sub-Type or not.


The Status Category.

Things you don’t want to hear! Q “What status is that call at?”

A “’Closed’ but the customer thinks its open and I have two people working on it”

When setting up the Statuses that you want to use in SupportDesk many of the same points raised in creating your Types are also relevant. Following a mantra of ‘start small and grow’ will pay dividends rather than embarking with multiple Statuses that may be both ambiguous and unnecessary. At House-on-the-Hill in the majority of cases we advise starting with the following:

Open should be the initial status for all calls. On hold used for calls on which you temporarily do not have the opportunity to progress – examples here may be that you are waiting for information from a customer, for delivery of parts etc. SupportDesk has the facility to ‘Stop the Clock’ whilst a call is at a status and this is a likely contender. The use of the stop the clock setting is discussed in the section – “Making my categories work”. Resolved an optional status that indicates work on the call is complete and which is usually introduced if declaration of a call being “Closed” is outside the remit of the Help Desk Team – i.e. the customer declares a call Closed rather than the Help Desk Team. Closed indicates that there is no further resource required on that call and no further actions will be taken. Re-opened a status used when, for whatever reasons, a call once thought closed later requires further work. Having this status removes the need to open a new call for the same problem.

At first glance one may feel inclined to introduce Statuses between Open and Resolved to indicate that a call is being worked on, or at least assigned. In principle there is no problem with this but one needs to be conscious of building a system that wherever possible protects its own integrity and is efficient to use. This is best explained in the HotH Hint below.


Status Milestones. When setting the Status Category – and this option only applies to the status category, one is given the option to indicate to SupportDesk if the Status you have defined corresponds to one of three absolute statuses that SupportDesk will recognise. These are called “Milestones” and fixed as: Responded to Status Resolved Status Closed Status.

The reason for this is to create a bridge between any numbers of statuses that can be invented by the customer and a set of empirical statuses that SupportDesk can recognise. This bridge is built by simply ticking the Milestone that corresponds to the status you have defined. It is quite acceptable that you may have more than one status that corresponds to a SupportDesk Milestone, SupportDesk will recognise this as long as they are ticked accordingly.

These milestones come into play in various places in SupportDesk, one being the Analysis Tab offered on each call.

HotH Hint. We advise that a user be created called “Unassigned” to which all newly opened calls are assigned by default. A quick scan of calls in the SupportDesk main window quickly shows those calls that are assigned to the user “Unassigned” and therefore need action. In most cases once calls are taken the next step is that the call is assigned to a person, or team, who is best placed to progress that call. These may be Call Allocators or another line of support within the prevailing structure. To do this the call needs to be opened within SupportDesk and a new assignee selected. We do not advise the introduction of another status to reflect this act for the simple reason that to change status it is another task, and one that may be forgotten and leave us with ambiguous data.


Which will determine the Metrics based on the Milestone settings of the your Statuses.

Parenting of Statuses.

As touched on with Types and Sub-Types, Parenting can be a powerful tool in streamlining the workings of SupportDesk, and making the maintenance of calls simpler. SupportDesk mandates that the Parent of a Status is another Status. What this does when used correctly is to limit the Status options available at any point in the lifetime time of a ‘call’ and as such guide the user as to what Statuses they may choose. One may think of it as sequencing. A simplistic example of this would be in an environment in which our five classic statuses have been adopted – ‘Open’, ‘On hold’, ‘Resolved’, ‘Closed’ and ‘Reopen’.

These statuses fall along the natural time line of a call – with the ‘Reopen’ status sitting at the end of the time line as an optional status allowing the call to be reintroduced back into the timeline.

It would be logical to say that a call must have been through the status of Closed before it can be assigned a status of ‘Reopen’. Parenting allows us to enforce this rule within SupportDesk by Parenting the ‘Reopen’ status with the ‘Closed’ status. By doing this the user will never see the Status of Reopen unless the call is at Status ‘Closed’.


Similarly the Status of Closed could be parented by Resolved – meaning that a call cannot jump statuses from Open to Closed without first having gone through the Resolved Status. This sequencing by parentage allows you to enforces a discipline into the operation of the SupportDesk and ensures a common work practice as to how the call progresses.


The Priority Category

Things you don’t want to hear!

Q. “Of all the calls that are Open how many are Top Priority” A “All of them – so we are doing the important ones first.”

In the absence of operating under a Service Level Agreement the Priority should be the single Category that indicates how imperative it is for the call to be resolved and like all categories discussed so far should be sparkling in its clarity. We should take as given that we are to have a Priority 1 – which is to be our top priority – try avoid topping this with a Priority 0 which can sometimes be interpreted as the very opposite of what you intended it to mean and can conveniently be taken as the call to look at after the next tea break. After Priority 1 the number of priorities created is based entirely on the number that your business will understand. If it is simply a case of

P1’s :those that have to be addressed immediately. P3’s :those that can wait until we have nothing more to do. and then P2’s anything that isn’t P1 or P3.

You will create a working system but be prepared for criticism from your users and calls getting promoted to Priority 1 merely as repository for Priority 2 calls that are not getting dealt with and which customers are chasing. Eventually you may end up with a SupportDesk in which the majority of calls are Priority 1 and you will then be forced to prioritise the P1’s so things will have come full circle. Try defining at least 4 Priorities and when specifying what constitutes a Priority 1 you should be thinking that these calls are very rare and will really be of the most critical importance. To determine what constitutes a Priority 1 consider two criteria to get started:- 1. How many people is it affecting. 2. Is it costing money. “Web Server Down” for a commercial web site would be a good example, or E–mail Server crashed. The fewer P1 calls that people see the more important they become in people’s minds. If you are making use of SupportDesk WebServer and letting users log their own calls then think very carefully before you give them opportunity to set their own Priority. The results of this are usually a profusion of over prioritized calls that will dilute the credibility and perception of SupportDesk data.


Parenting of Priorities.

Priorities may only be parented by SLAs – Service Level Agreements. If SLA’s are not required within your SupportDesk environment then do not introduce them.

HotH Hint. The SupportDesk main window offers sort functionality on any column. Make sure that the names of your Priorities are prefixed with numbers 1-Critical, 2-High, 3-Medium, 4-Low or letters, A-Critical, B-High etc so that this Sorting function can show you your calls in Priority order irrespective of the full name.


SLAs Service Level Agreement.

Things you don’t want to hear! Q. “Are you a fan of deadlines imposed by SLA’s?”

A.“Oh Yes, I just love that whooshing noise they make as they go past.”

Service Level Agreements, if in place, should indicate the level of service that is to be attained. It is unusual that one set of SLA’s will suffice to cover the entire operation of SupportDesk and because of the different levels that are required we recommend a combination of SLA’s and Priorities to provide this spread of conditions.

The Service Level agreements may be set internally as the prevailing working targets, or more usually in a Customer Service and Support (CSS) environment they will be set by third parties as a requisite of the support levels to be provided. It is in this latter environment that different customers may work to different SLA’s. In an ITSM (IT Service Management) environment it is more normal that different types of product are assigned different SLA’s. Mission critical servers will be assigned the highest SLA and thereafter hardware will be categorised based on its importance to the company.

To take a classic example let us assume three SLA’s of Gold, Silver and Bronze. These can be created in the SLA Tab of the Category and SLA Management screen. To discuss setting times on these SLA’s is to move away from out original intention of setting up our framework of categories first so at this point it will not be discussed. It will be covered fully in the next section “Making my categories work”.

HotH Hint. If you are not required to operate to SLAs then don’t introduce them to SupportDesk – use Priorities instead.


Setting a Calendar for an SLA

Of all the Categories available with SupportDesk the SLA Category is the only one which allows the association of working times that will override the default Office hours as set on the Company configuration tab. The Office Hours defines the normal working time in place in your work environment – normal settings may be 5 days – 9 – 5:30. SupportDesk will reference these times when calculating the target times for any call, e.g. a call taken at midday on Tuesday that should be closed in 8 hours will show an Action Date/Time of midday Wednesday (made up of 5 hours on the Tuesday (12 till 5pm) and 3 hours on Wednesday (9am – 12 midday).

Using the Calendar Tab on the SLA category (See below)

Support Desk allows an SLA to be defined that will operate outside of these hours and for calls categorised with this SLA calculation of target times will reference these working times and not the default Office Hours.

In the previous example of the call taken at midday on Tuesday – if categorised within SLA “24/7” which has been set to be 7 days per week and 24 hour per day – (indicated by the blank Start and Stop Times) then the Action Date/Time will show as being the same day and 8pm.


Parenting of SLA’s. SLA’s may only be parented by Type. We initially stated that our Types “should provide an immediate understanding of what the call is related to” and as such it is safe to assume that there are some fundamental differences between our “Type” of call – An example here may be Type “Printers” and Type “Servers”. It is also quite likely that this very difference in nature of our call Types leads to a different set of SLA’s. In general one does not need to react in the same way to a Printer problem as to a Server problem and as such the expectation of response is different.


5. Making my Categories work.

So far we have tried to provide an understanding of what the different categories are best used for and how, through parenting, we can simplify their selection and improve the chances of obtaining good data when the call is logged. If we did no more at this stage than simply apply a framework of Categories to our call we would still have SupportDesk configured such that our calls are clearly identified as to what Type and Sub-Type they are. We would know what priority the calls are and their status as they are progressed. We would also know if the calls were bounded by any SLA’s.

There is however another level of value that we can obtain from our Categories and SLA’s and from their interaction with SupportDesk. This comes by associating the times that are required from our SupportDesk operation to our categories.

SupportDesk has three key times against which all calls are monitored. These are: -

Respond within. This determines when a response must be made for calls with this category. Failure to achieve this target will be reported as a breach by SupportDesk SLA Monitor. If the auto-response e-mail facility within SupportDesk is used then this is largely redundant, as all logged calls will automatically generate an e-mail to the appropriate parties giving them details about the call number etc. When this configuration is employed the first response is immediate.

Warning after. The time period is used to calculate a warning date at the call dialogue or the reminder date for activities. A warning bell is displayed next to the call or activity when the warning date has been exceeded and is an indication that an action is imminently required.

Action/ Fix within. The specified time is used to calculate an action date at the call dialogue or the scheduled date for activities.

And can be set against every category or SLA. (Figure5)


Figure 5

Although days are shown in Figure 5 the time unit may be chosen from standard time units or derived times such as “End of Next Day” – which will apply the working calendar and calculate when this actually is.

The first application of these time settings comes into play when the call is first recorded. As the categories and SLA are chosen for that call, SupportDesk will refer to the settings and calculate the target times for that call (Figure 6). These are offered as default only and may be overridden if good reason exists.

Figure 6

In Figure 6 we see the various dates and times that have been calculated for this call. We can also see the Type, Sub-Type, Status, Priority and SLA. What is not obvious is which of these Categories – or SLA has been the driving force behind these times, and leads us to one of our top HotH Hints.

HotH Hint. It is advisable to only set action times on one band of categories, such as Priority; otherwise the calculation of action dates may become confusing or even un-workable.


Whilst one may say that the mechanics behind the derivation of times is irrelevant it makes for a more transparent system if the logic and drivers behind the calculations are known, and apparent to all users. This very much ties in with the questions that were raised at the beginning of the paper. – Will it be confusing for the call takers and do I want to be the font of all knowledge on SupportDesk?

Were times to be put on every category and SLA, SupportDesk will always work out what the correct advised target dates and times are for the call. This is done at the time the call is first logged – by taking the most aggressive of the times invoked by default categories, or by taking the last category selected for the call when a call is being maintained. If there are times on multiple categories then to work out where these have come from may be a time consuming job. A user would be required to check the dates and times set for each of the categories assigned to that call, and also take into consideration working calendars both for SupportDesk in general but also for SLA’s that may be defined with their own calendar. It is far easier to simply set these times on one band of categories only.

6. Which Category to use.

There are no absolute rules for this, only good working practices that we have seen applied successfully at many “House-on-the-Hill” implementations.

With SLA’s Our first recommendation applies to SupportDesk in a scenario where SLA’s are being applied, common in a CSS (Customer Service and Support) environment where the customers have been sold a level of support as defined by an SLA. Taking the framework of categories and SLA’s that we have already described it is simply now a case of building a matrix between the two. If we take our three levels of SLA, Gold, Silver, and Bronze, and then three levels of priority “1-High”, “2-Medium”, “3-Low” we can assign times against each permutation with results as shown below in Figure 7: -

HotH Hint. If you have the opportunity to set your target response times remember that there is more kudos in adjusting the times to be faster than slower at a later date! Only set targets than you think you can hit.


Figure 7

If the SLA’s are tied to customers then the next step in making this work efficiently is to tie the SLA to the customer. This will then automatically be assigned to the call once the customer has been chosen, and the selection of priority will force the time scales that are put on the call. In this way the decision about the SLA the customer is on is taken away from the call taker who can simply concentrate on the Priority of the call.

SLA’s within the ITSM Environment. Within the ITSM environment, the product to which the call is related usually drives the response that is required. Mission critical servers demand a more immediate response than most other products and as such an SLA can be associated to the product. The operating practice of SupportDesk is similar to that described for the CSS environment save that here the SLA is picked up once the product is selected and then drives the available priorities and associated time bands.

Without SLA’s

If SLA’s are not in place and have not been introduced into SupportDesk – our recommendation is to associate your times with your Priorities. This reinforces the association of the Priority of call with the “urgency” and again keeps the driver behind the target times very simple to track. When this is the case decide how many Priorities you want to operate within your environment. As already touched on there are dangers operating with too few as this can lead to a natural ‘up’ prioritisation of calls with a proliferation and therefore devaluing of Priority 1 calls.


Consideration also has to be given to such things as projected call volume, support staff numbers, working hours etc. Be realistic in setting the response times initially set target times that will be hit and leave the option to improve the response times rather than have to extend them.

Stopping the Clock.

As can be seen from the previous sections SupportDesk will calculate various target dates and times for any call that has a category associated which has key times set. We have also discussed how the times for a call will be calculated based on the set Office hours maintained in the Company Configuration, or the working times set on the SLA. SupportDesk however has another facility that works in conjunction with the calculation of these times and which was mentioned briefly under the section on The Status Category. This feature is found under the Workflow and Actions Tab on the Category maintenance screen ( See Figure 3) and is called “Stop the Clock.” In the section on the Status Category one of the recommended Statuses was “On hold”.

On hold used for calls on which you temporarily do not have the opportunity to progress – examples here may be that you are waiting for information from a customer, for delivery of parts etc. We recommended that this be used when the Help Desk Team do not have the opportunity to progress the call and as such it would not be appropriate that the time spent against that call should continue to be accrued. By ticking the Stop the clock option for this Status code SupportDesk will recognise that when a call is changed to this status it will effectively park this call until the Status changes again to one on which the Stop the clock option is not flagged.

As has been the theme through this paper we would not recommend that the Stop the clock flag be set on more that one Category stream and if possible the should be Status.


7. Where next.

This paper has touched on only certain elements of Categories and SLA’s but following it will give you a sound framework for the initial configuration of SupportDesk. To extend the functionality of SupportDesk even further we recommend that you read the paper “A House-on-the-Hill Guide to using Workflow & Actions, and Escalation” which covers how the remaining settings on the Categories can be set and what they can deliver. If you have any questions on the topics discussed in this document please contact us at House-on-the-Hill, or if there are other areas of SupportDesk you would like Guides for then let us know.

a house-on-the-hill guide to categories and sla management. · most efficient system. ......

Documents