Recently we were invited to speak at the itSMF (IT Service Management Forum) about our approach to Service Management. TechTime's very own Daniel Hofmann and Ed Letifov presented "How would you like your Service Desk: Rare, medium/rare or overcooked?"
What did we talk about?
The aim of the presentation was to share the problems we are facing, alongside everyone else, as in 'we're suffering from the same issues'.
What we've seen?
Over the years of our collective experience we were able to categorise service desks into 3 different types. In loose terms we call them 'rare', 'medium/rare' and 'overcooked'.
'Rare' being service desks that rely entirely, or almost entirely, on the human interaction, very limited scalability and re-usability of interactions. In other words, a lot of one on one interaction that can't be reused.
At the other end of the spectrum we talked about a service desk set up which is 'overcooked'. The term we used was 'the dawn of the machines', workflows with a myriad of sub-tasks spawned depending on what choices a customer makes in the front end form. Ultimately the dawn of the machines means that service desk agents often feel that they are no longer in control and that they are also not quite sure what is happening within 'the system'.
In the middle then is the 'medium/rare' service desk. Highly scalable, answers to customers are reusable. Machines are doing the donkey work, humans are adding the 'heart', i.e. once you have exhausted the machines human service desk agents will step in and help with the problem. A mature model of self-help before another person has to step in.
We did, however, point out that service desks need to be matched to the business they are in. If your business is a service business built around great one on one customer service then a automated service desk might not work for you.
Our conclusions
After setting the scene with what we have seen so far we in our time of putting service desks into place we drew several conclusions. The first set of conclusions was that service desks fail for two reasons and two reasons only: Either the actual load is too high or the complexity of the questions coming in is too high for your service desk agents.
If the load is too high your service desk agents won't be able to cope. No surprises there. But equally having 5 channels to access your service desk and people who will then potentially submit through these 5 channels means that the number of actual tickets is, potentially, the number of tickets you have divided by 5. One ticket for the same problem send in through 5 different channels. This means you will immediately face a new problem, which is that a large amount of you time is spent trying to close tickets that have already been dealt with in other tickets.
If the complexity is too high your service agents won't be able to answer the question/request in the ticket easily. The answer here is, as you've expected, training for your agents, a knowledge base and a clear understanding among your customers what it is that you actually do and what they can realistically expect you to do, in short a service catalogue.
Our learnings were, consequently, that:
- channel management is important. All channels need to lead to the service desk, but also that you need to reduce channels if your company environment is such that people will submit the same ticket through 5 different channels 'just to make sure'
- simplification of your front end portal is key. Make sure there is no way your customers can mistake what they have to do and which service they need to select.
- self-help is where the true power of your knowledge base comes into full force. Can your customers help themselves and you can reward them for doing so, i.e. they can fix the problem easily themselves and feel good about it or do they need to sit in a queue and get their problem fixed for them later?
- No ticket no service was our last learning. As soon as people can circumnavigate the system they will. It's so much easier to use connections to get things done than follow a process. Sigh.
What we are doing to fix this
There are four things we are doing to fix this:
- EasySSO: By removing the need to log in we are removing a barrier to adoption. The last thing anybody needs is more ticket for lost passwords.
- Real-time graphics: Showing a service desk team lead where everything there is to know about her/his service desk is a powerful tool and allows for a clear identification what is working and what isn't.
- Self-classification: We have this problem ourselves were a human needs to step in and sort our service desk tickets coming in via the support email. The self-classification product we are working on will enable us to have a set of parameters which will enable the system to classify emails for us. This will be a great help and will allow us to focus on resolving the tickets rather than classifying them.
- Complex root cause analysis: this tool is based on the mathematical concept of decision tree learning, a concept used to generate evolving virus protection databases. Once the full power of this concept is used the tool will be able to assist in the finding of the root cause for the failure of a service desk or the improvement opportunities.
Feedback
The feedback was good, if a little hesitant. People were able to relate to the examples given and agreed with our findings.
The same presentation will be delivered in the upcoming Wellington AUG meetup on the Tuesday 30th August to an enthusiastic audience which we are hoping to attain more feedback from to fuel our ideas to fix it. Along side this presentation, Irina Mosina from TechTime will be discussing new Atlassian Official training courses which are to be rolled out, and new certification processes and levels with specialised names. All this information was passed on during the Atlassian Asia Experts Camp, recently held in Yokohama, Japan.
We look forward to seeing you all on Tuesday 30th August at BizDojo for the Wellington AUG meetup. Drinks, nibbles, pizza and socialising is also high on the agenda. - See you there!