Following on from yesterday and my revelation...
My colleagues needed to SEE the backlog. A long list or number on a report just doesn't cut it. I needed something tangible; something to shock; something that could inspire change... and ooh, something that might be motivating in and of itself.
Enter: sweets. Hundreds of them!
The 3-step process I came up with works like this:
1. Allocate a sweetie jar for each work queue with each sweet in the jar representing someone who is waiting on us to complete their incident/service request.
2. When someone resolves a call, they get to take a sweet from the correct queue jar and either eat it, or put it into the shared 'Eat Me! (available sweets) jar.
3. After work each Friday I take on the role of 'sweetie monitor' and top up each jar with the new calls for the week and check the count of each jar to ensure people are taking their sweets/not taking too many!
The following day I sounded out the IT team leaders and was pleasantly surprised to find that neither of them laughed at me. They actually leaned back and said, "That could work..." So, with the authorisation to go ahead I went shopping!
I made sure that I purchased a wide range of sweets with wrappers so they could withstand the rummaging, as well as checking best before dates because some of our calls have been outstanding for a rather long time.
Finding the right style of sweetie jar took a little effort but I found some and had to wait for a week whilst they ordered more to make up the numbers I needed.
With the jars and sweetie stock at the ready, I had to figure out how to present the idea to the team in such a way that they'd support it instead of dismissing it as 'one of her crazy schemes'. I'll save this part for Friday's entry. See you then.
Tuesday, 10 October 2006
Subscribe to:
Post Comments (Atom)
Posts
5 comments:
Hi Dan,
Thanks for stopping by, I thought I recognised the name :)
Strangely enough, I had the very thought about how to differentiate the reward between calls resolved within the SLA compared to those that are just clearing the backlog yesterday afternoon when listening to the banter I heard someone saying that they deserved another sweet because they closed their call within time whereas another person didn't!
The possibilities I've come up with so far are:
- Maintain a separate stock as a bonus if the call is closed within time.
- People get a larger sweet than normal(lollipop, parma violets etc.)
I think from a logistical point of view it may be better to separate out the reward for calls resolved within time and high customer satisfaction with something on a monthly basis to coincide with reporting. I haven't gone further with my thinking on that just yet :)
If you've any further suggestions I'd love to hear them.
See you over on Manager Tools!
The ITIL Imp
As helpdesk manager, I would Have the evaluation of the helpdesk agents based on this principal (I can tell you sweets won't do the trick over here in belgium).
Have their yearly bonus (or other pay system)based on their personal statistics (ticket resolved within SLA time vs not resolved within SLA time vs total tickets).
Be carefull giving rewards even if resolved after SLA time. An agent might prefer not to solve some incidents in due time (knowing he still get's a small bonus anyway)giving him a less tight schedule and more time for himself (web surfing, coffee break, etc.). You need to go for the "within SLA time or nothing" in order to keep the preasure on. As manager, it's you role to establish if you have enough agents to fill in the requirements. On the other hand, You don't want to discorage the agents knowing there are too many incidents to treat -> agents will never be able to satisfy all ticket in due time.
Your job is to make sure your agents can treat a great deal of incidents in due time. On calm days, you need 100% in due time, on difficult days, 70-80% can be acceptable. This is why the total amount of ticket also needs to come into account. It's also your job to keep the total amount of incident as low as possible via a developped ITIL approach to the service support.
A proposition: Use a "+" and "-" system for evaluations:
ex:
+3 quickly resolved
+2
+1
0 In due time
-1
-2
-3 well over resolution time.
This total is then multiplied by a factor depending on number of incidents reported:
Average day : (nb of incidents depends on your workload capacity)
all are multiplied by a factor 1.
low day:
"+" are mutiplied by 1
"-" are multiplied by >1
High day:
"+" are mutiplied by >1
"-" are multiplied by <1
You could also bring in another factor depending if the incident is to be resolved by the helpdesk or by another level of support. Helpdesk are responsible for follow up of open incidents.If transferred to an other level of support, the "+" or "-" impact will be lower because final resolution is not in his hands any more (but he can influence it by sending reminders of finding someone else for the job).
Cymon (from Brussels in Belgium)
Hi Cymon,
Thanks very much for your post, I can see how your ideas would certainly work in an environment other than mine.
I should just clarify a couple of things:
1. Working in local government we cannot use financial bonuses as a motivator :(
2. I'm not the helpdesk manager and we don't currently have a post for a service delivery manager (although that is what I am aiming for!).
3. I don't actually manage anyone in my current role. I am part of a technical support team (2nd/3rd line support) that is struggling with the workload and just wanted to find a fun way to make things a bit better.
I completely agree that there needs to be more of an incentive for calls closed within time; I'm trying to come up with something more special than a sweet that doesn't cost the council money on a monthly basis for this one.
Thanks again for the tips; I'd be interested to hear what else you've found that works well.
For example, do you do anything in the way of quality monitoring with your helpdesk agents?
The ITIL Imp
Hi,
Do you share a knowledge base with the 1st line helpdesk. In other words, if a call is escalated to you, this generally means helpdesk cannot solve it. In this case, what action do you take once the incident is solved to avoid to many calls being escalated to second level. Do you inform the helpdesk on how to solve it the next time a similar incident pops up at the helpdesk (resolution procedure, quick training).
This can help increase first call resolution rates -> better resolution time -> better satisfaction of client and less incidents transferred to second/third level (giving you more time to spend on your ongoing projects).
Hi Cymon,
The knowledge base issue is a bit of a mixed back right now. The infrastructure across the sites is such that only helpdesk operators local to the site have administration rights to potentially resolve issues. It certainly isn't an ideal situation and funding is needed to address it in the medium-long term.
For now, they have the top fixes to deal with common issues for which they do not require administration rights.
One of my medium-term projects (once we officially start the ITIL route) is to introduce everyone to the Knowledge Centred Solutions process model as part of an upgrade to our current help desk system to encourage more information sharing amongst the technical staff.
Unfortunately those staff covering help desk are in the situation of often times having the skills to resolve an issue but not the access to the tools. Theoretically this could be relatively straight forward to address. However, trust me when I say politics gets in the way ;)
The ITIL Imp
Post a Comment