I just listened to the Gamification of the Service Desk webinar presented by Kim Liston, Michael Slabodnick and Tim Deniston from Omnicare.
It's a story that I followed on Twitter through Michael and I was fortunate to grab some of his time on the phone a day or so before the conference to get a demo of the system that he built.
Omnicare have done a fantastic job with their solution and I think it shows that they really thought about the concept and how it would translate to business objectives and metrics - rather than simply building a game.
Being able to show hard metrics on customer service as a result of motivating engineers through gamification is a really compelling argument. I've seen discussions on various forums where people are sceptical about the benefits. I think it's a natural reaction to classify gamification alongside other social activities - Facebook, YouTube and Twitter - which are traditionally productivity killers.
Kim, Michael and Tim have given us a glimpse of proof that social is not just something that users do when they're not working at work.
It's an amazing piece of innovation and I'm a big fan of their approach and implementation. Also good timing for Omnicare to showcase their work in the week that Gartner released some information about Social IT and peer-to-peer support. It's a short article copied in full below
Organisations that incorporate peer-to-peer community support could reduce costs to serve by 50 per cent, but will damage relationships with users if they blunder the integration.
Research by Gartner has found that support calls handled by the community cost less than five per cent of a service desk agent. Although estimated savings start at 10 per cent of overall service costs, teams providing technical support stand to make the biggest gains, with Gartner predicting that B2B software, telecoms and consumer electronics providers could half costs.
Gartner warns that incorporating social support is more difficult than simply offering a community forum. Satisfaction can be seriously damaged when alternative channels are incorporated and customers are forced to use the option. The balance between savings while maintaining satisfaction only works if the customer is directed to use a channel appropriate to their problem.
I had some thoughts after meeting with Michael about their approach to gamification
Badges or Coins?
Engineers at Omnicare can earn badges from the system by performing routine tasks but I was worried about the longevity of the system. You would need a system that is easy enough to start earning rewards - no point working away for a month in order to earn your first badge - but also has the scope to keep people engaged in the second or third year of playing.
How would you keep engineers that have earned all of their badges occupied? Probably by creating more badges for them to earn but I'm not sure of the scalability of that system.
If a new engineer joins the team she would be looking at a huge number of available badges, where more senior staff have dozens that are already awarded.
How about a coin system where you define a naming and currency system for awards.
For example rather than a badge for closing a Priority 1 Incident under the SLA you would be awarded a "Priority 1 Knock em down" coin worth 5 credits.
Reducing your average Incident age by a day earns you a "Backlog killer" coin with 3 credits.
By providing two dimensions to an award (the name and a number of points) you provide both the relevance of the award linked to the activity and a currency value.
After a while players would bank a number of credits which could be redeemed in a number of different ways. I would be very careful about linking gamification to salary or bonus for the following reason....
.... but that isn't to say that players shouldn't be able to trade credits they have earned for beer, pizza or nachos. Why not?
Of course with a currency system it is possible to lose points. For every P1 incident that goes above SLA you might be "fined" 5 credits 🙂
Gamification cannot just be a "thin layer"
The work done at Omnicare is terrific, but I am most excited about what happens next.
Gamification cannot just be a "thin layer" of functionality that just interacts with Live Feed. As Chris Dancy will tell you reputation is everything and we are really talking about an engine to rank individuals by experience and capability here.
An engineers reputation should be used throughout the system. Perhaps only visible to other players but when you look at a long list of work notes and comments on an Incident we should be able to derive the skill and experience of the user in that context.
If I'm looking to assign a Knowledge document to be reviewed on a particular technical subject I'd like to make sure the engineer I involve has a strong reputation in that area.
Make your team be successful
Gamification is really about personal progression through the system. Some of the negative comments I've seen about the concept worry about users "playing the system" - Surely that's the point, but I know what they mean. Users advancing through the game by artificially closing Incidents to earn points.
I think there is a great use of gamification that I haven't seen yet - defining short term team objectives to give focus on a particular outcome.
For example you may have a support team with a large backlog of Incidents. In gamification you should be able to define using a database query or filter an outcome that you want to achieve by the end of the month. The backlog for the team must be under 200 incidents. Or we need to increase our number of Problems with Workarounds to above 75%.
By providing the team with a dashboard, a clear set of objectives, a reward and their current progress I think this would be a great way to help a team meet business objectives.
Last year whilst still entrenched in corporate Infrastructure and Operations at a large organisation I wrote "7 habits of a successful Infrastructure team". Number one was:
1. Practice being successful.
IT staff like to be successful, and the organisations they support like them to be successful too. It is amazing then how often we spend time practicing to fail. Everything we do is a new opportunity to succeed.
For example, an Infrastructure team has a number of low-level tasks to complete. Let's use a rollout of service packs to 10 servers. An IT leader that is used to practicing success will turn this into an objective. That leader will set a completion date, set checkpoints to measure progress and the team will celebrate in their success.
An IT leader that doesn't practice success will let the task proceed at it's natural pace - often very slowly - and will only run a checkpoint at a point where failure has already occurred. Practice being successful.
In summary
I am genuinely inspired and excited about Omnicares progress - inspired because a customer had the energy, vision and development skill on our platform to do something so cool. Excited because I think having a measurable case study at one large customer will help other organisations see the benefit of gaming in IT Service Management.
Photo credit
1 Comment
