Saturday, 11 February 2012

Service Desk 2.0

OK, this is important, now listen very carefully chaps  I'll say this only hold on, no, I'm going to spend most of 2012 yelling this from the rooftops.

2012 is the Year of Service Desk 2.0

You first heard me talk about it in my predictions for 2012 , and like #Back2ITSM it is already gaining momentum despite being a Work In Progress. Aale and I have already presented a very sketchy outline of the concept in a recent Bright Talk seminar, and work is well underway on a joint white paper in conjunction with Aale's continuing exploration of why we need to Unlearn ITIL*,

Let me sum up SD 2.0 for you as it stands.

First of all we aren't talking about a product or a methodology, although I can see how both those elements could be developed. SD 2.0 is about an approach, and it is an approach based on the realization that a lot  of conventional thinking around the Service Desk** is in danger of becoming obsolete before the year is out. You know as I wrote that I could picture Rob England reaching for his bottle of green ink to say that we are just scare-mongering to earn consultancy dollars.

Whether we like it or not both customers and users (and as I wrote that I could imagine Aale reaching for the green ink as well, because he thinks that is part of ITIL speak we should unlearn) are having their personal experience of IT transformed. The use of mobile devices has exploded and people are bringing them into the workplace. They are also beginning to experience, accept and except*** new support models, of which the Apple Genius Bar stands out.

SD 2.0

  • Users will be accessing and using services on non standard BYOD devices in the workplace on the road and at home, and some of those services will themselves not be provided by the IT dept.
  • Users will combine different services in real-time to support business processes, in the way they built email into critical business activities without telling IT they were doing it.
  • Users will use self-service /Google/SocMed facilitated peer support before coming to the SD - filtering out all the simple,typical first time fix interactions. Aale and I like the term interaction which we've borrowed from the SDI
  • When they speak to the SD the users will by default know more about their issue than the agent who is desperately Googling to catch up with them
  • Since the interactions are non-standard the simple ITIL process models will be hard to apply and harder still to measure meaningful - we need to de-construct them and reassemble them in more useful ways. Charlie Betz has been contributing to that discussion with some "must read" papers.
  • When users interact with the SD they will expect that Apple Genius Bar experience, not a dumb (in the nicest sense) agent.


In the beginning there was the Help Desk. Then ITIL got hold of it and we saw the wholesale renaming of Help Desks as Service Desks. This was done with the best of intentions, but I don't believe the expected value was delivered to the business. It was bad timing that in the UK this shift in thinking coincided with the move to the wholesale out sourcing of service desks off shore.

A well thought out SD 2.0 strategy**** would include:
  • Accepting the reality that this is happening
  • Blending on shore and offshore support so self service interactions are fielded by an industrialized service desk back office
  • Making the service desk genuinely accessible to users - no more "Service Desk - No Visitors" signs on doors
  • Integrating innovative channels for both support and knowledge management
  • Revising the entire metrics framework to build a newly balanced scorecard
  • Enabling and empowering service desk teams and removing micro-management***** 

A Beautiful Dream

Perhaps Rob is right, perhaps this is all wishful thinking. But why not think it - and if you think it, why not make it happen?

Please, please let me know your thoughts.

"Transform or you will be transformed!"


Judging by some of the comments and the blog Rob posted in response to this one I need to make some points much clearer to avoid either confusion or willful misrepresentation. I don't want to edit the original text because I stand by the integrity of what I said. So I'm afraid you are stuck with a shed load of footnotes. I've put them in small type though, so they will be easier to ignore for those who want to. Also so that hopefully the footnotes will appear shorter than the article. 

* "Unlearn ITIL" is the tag Aale is using. My own view is that we need to unlearn certain elements of ITIL, but  perhaps more importantly we need to unlearn bad habits that we all develop when thinking about and with ITIL. For instance we can get too hung up on the flowcharts in ITIL being holy writ. We gloss over that ITIL seems confused over what is a process, a function and a capability, and that the "common vocabulary"  breaks down when you try and use it across a complex supply chain. In this specific context my main beef is that "incident" "event" "request" "change" and "problem" as defined in ITIL don't explain what exactly the service desk should be doing, and how that links to what is happening in the world of the user. I'm not saying they are wrong, I'm saying they represnt a partial, slightly artificial and inadvertently inside-out view of the world.

** It is inevitable that this article will be seen in the light of a larger debate about ITIL and ITSM, but my prime focus here is the Service Desk. There is a certain snobbishness in the ITSM world about the Service Desk, as if they are not members of the club.

*** This is something a lot of people seem to be missing. This is not like previous IT led attempts to get users to use the technology. This time it is the business who are keen to explore new ways of working. After all nobody likes hanging on the phone for half an hour just to get  their password reset. Disintermediation has become a fact of life, just ask your high street insurance broker...ah, you probably can't because they lost their job four years ago.

**** It seems eminently sensible to me that with the prospect of these changes on the horizon a professional IT department would be looking at the potential implications. Most of the suggestions I make here hold good whether the so called "revolution" takes place or not. I am left uneasy by the comment from more than one pundit that the service desk will "just evolve" to meet these challenges. The last twenty years of trying to get a reasonable standard of ITSM into many organizations should have taught us that it isn't going to work like that. What is true is that some service desks will end up extinct. 

****** The three most ardent critics of this article are people who I have a lot of respect for. It saddens me, then, when one says "I notice all the people who say xxxxx  are all IT technical people" and another "Sometimes I think we're surrounding by highly dangerous ITSM Consultants armed with a few certificates which are no substitute for using your brain"  Now let me be perfectly clear that there are areas of the ITSM  world where I totally agree th. However I'm far from convinced that it is highly relevant or helpful to this particular debate******. Those being vocal on both sides of the argument all have many years practical experience of ITSM and all have a reputation for promoting the cultural aspects of ITSM. I ended the article with a quote from Rob Stroud for a reason. 

******* I'm British. I'm being polite. What I actually think is unprintable and I've broken the * key on this computer from over use.


  1. I agree that there needs to be a change and awakening, although from a Service Desk perspective I think this is more an evolution than revolution. The revolution needs to happen across IT organisations - Service Desks have adapted and coped with change over the last 25 years and continue to do so. That is reflected in the development of things like the SDI (world class) standards. From the 'unlearn ITIL' view, the ITIL world has to me still patronised and taken the SD for granted and seen it as a low value role - so I think that the Service Desk is constantly evolving and is some ways just needs to be taken a bit more seriously across the industry..

    1. Agree with pretty much all of your points and also hope that Service Desk evolves into the more respected role it deserves.

  2. Barclay, The last year has reinforced what I've long thought. First the ITSM/ITIL world is still divided between SD and everybody else, and second that just as the SD was beginning to begin to get taken seriously as a potentially value adding function it derailed by the fad for outsourcing and automation. Now both outsourcing of the desk and automation are approaches I will argue for at length, but if applied without thought they negate value.

    So to that extent I agree with you. Really thsi sia bout catching up with where we should be by now, and of course we know there are SDs out there that recognize this. However I also believe there is a requirement for a large element of transformational activity as well. The more I think about this the more I think it becomes evident when you think about how you should measure the SD of the future

  3. "Unlearn ITIL"? Give me a break!

    The Service Desk isn't ITIL. And ITIL isn't just about the Service Desk. Barclay is spot on when he says that the Service Desk needs to evolve. I think if anything he's being overly subtle. Never mind "evolve", the Service Desk may well disappear as we know it, but the units of work (Incidents, Problems, etc) will still need to be understood and dealt with.

    Clearly the end user is going to be doing even more personal support (especially SYOD because of BYOD). But personal support has always been around, just now you don't need to be a nerd or expert to solve your own issues, just have a browser with a Google bookmark.


    1. "Unlearn ITIL" is a bit of a teaser, a wake up shout and it seems to work, it's getting discussions going.

      The Service Desk is an important element of IT Service and ITIL and I do not think that a service organization will survive if it does not have some sort of customer interface. What I do think will change, is the units of work.

      The word "incident" has at least two different ITIL meanings. One is the old "anything unusual that may affect service" and the new "any failure". There is an ongoing LinkedIn discussion of the ITIL nature of password reset with 247 comments. The ITIL term "problem" is as problematic.

      I have commented on Pink doing a survey where you ask about the number of incidents without defining what you mean by the word, not a good practice.

      Here is a few things we should unlearn:
      SPOC: The service desk is not a SPOC. When ITIL was written, people used land line phones and getting the callers number was difficult. The telephone system was easy to control. Cell phones have broken that control and social media makes it so much easier to find alternative support.

      Incident: Customers have problems with the service and the service has failures. Calling both as an incident is not a best practice.

      Service request: Customers may find the service difficult to use or they may want to order more of it. Calling both a service request is not best practice.

      Our analogue for the necessary change is from a greasy garage to an Applestore. The forces that killed the roadside garages are the same which are changing IT today. I don't think you get that by evolution. Some years ago every service station here had a garage then they changed or were closed.

      OK, this is not all of ITIL. The major thing we need to unlearn about ITIL is the concept that IT is the in the center of the life cycle. I will be talking in an itSMF USA webinar with Mark Smalley,Robina Chatham and Paul Wilkinson about IT outside IT. There I will discuss about how IT and business see things differently. IT thinks it is in control but the business sees it just as one player.

  4. David,

    There is a well known phenomena in the aviation industry where a pilot in a crisis reverts to his original training, not to the correct action for the situation they are in. As a result a lot of aircraft have crashed.

    We have all met people during our many years of involvement with ITIL who fall into the trap of thinking "This is what you do because ITIL says so" Sometimes they do it explicitly, sometimes it is implicit.It happens at an individual level, I've seen it happen at an organisational level, and to some extent it probably happens at an industry level. Ken Gonzalez pointed out, in a different context, that people often think they are doing something because "ITIL says so" when in fact it doesn't.

    Most of the time that isn't such a bad thing. After all doing what ITIL says is almost always a lot better than not doing what ITIL says. Where it can breakdown is in times of crisis or times of transformation. I'm certainly aware that in the work I am doing with designing large multi-sourcing /service integration solutions it is clear that ITIL, in its current state, can only take us so far.

    Aale's position is perhaps a little more extreme than mine. Mine is that we need at times to unbundle the boundaries ITIL draws around processes and rebuild them to suit certain situations.

    However I think the issue around ITIL isn't at the heart of what I'm trying to say in this post, rather it is your second point. And do please tell me if I'm misinterpreting it, I know how annoying that can be.

    I couldn't agree more with you if you are saying that the service desk will either evolve or face extinction. I prefer to dwell on the positives than the negatives though. What I wouldn't agree with though is someone saying that we can all sit back and relax and it will happen naturally.

  5. Jim:

    Talking about evolution and improvement of how we manage infrastructure & services is all good, and I'll be there with my two cents.

    What doesn't help is when we have both sets of extremists promoting confusion.

    1. The ITIL Rednecks who think everything we do has to be according to ITIL (see my recent blog entry: )


    2. The Non-ITIL Rednecks who think everything in ITIL is dangerous at worst or useless at best.

    One of my favourite phrases (I learned from an old buddy - Ken WIlson, now at CA I believe) is - "a little knowledge is a dangerous thing". Sometimes I think we're surrounding by highly dangerous ITSM Consultants armed with a few certificates which are no substitute for using your brain. (The last ITIL certificate I got was in 1996 - but my brain is up to date and still in good working order!)

    Please don't take anything I've written above as a shot at anyone in particular, I know everyone wants to do a good job and be helpful. But phrases like "unlearn ITIL" are not helpful in my view. And if anyone really believe that unlearning ITIL is necessary, then ..... well, I don't want to go there!

    OK, enough of the rant. Getting back to the subject at hand - Service Desk - I really believe we need to see some quality SD leadership to help this function maintain any relevance in the future. I think a focus on Knowledge Management may well be more worthwhile than the Incident Management activities we've been used to so far. But changing the activities that currently support Incident Management doesn't mean no Incident Management. As long as we're imperfect, knowledge of Incidents and how to deal with them is always going to be a good idea. So there is a future for Incident Management of one kind or another; but the Service Desk as we know it? Hmmmm.

  6. I do agree that some offshore, low cost, service desks don't add a lot of value, but I am not as convinced as you that most users in most organizations have the capability to investigate and resolve their own incidents.

    Clearly the service desk needs to evolve. Anyone who has studied ITIL should know that everything a service provider does should focus on how it creates value for the customer, and this includes how they manage incidents and service requests. I expect to see a gradual migration towards a better implementation, rather than a complete upheaval and replacement.

    1. Stuart,

      Off shore low cost service desks are an important component of my vision of the future. Where they work well is where the value they can bring is well understood. That value might not be the same as an on shore team, but that doesn't mean it isn't the right value in a particular case.

      If any one discussion kicked of all of my thinking in this area it was one with Pat Bolger about the speed and extent to which the highly successful introduction of self service had impacted a customer. In that case the benefits were all positive but I could imagine a very different management reaction in some organisations. If that pattern is repeated then it might be some service desks have less time than we realize in which to respond.

  7. Good discussion,and I think everyone is a lot closer to agreement than it might appear. The role of the service desk is changing, but in some ways I think it's closer to what ITIL intended. There was good reason to separate Incident Management and the Service Desk function. It's the practitioners over the years that morphed the two into meaning essentially the same thing.

    (Similar to the way we've allowed ITIL to morph into equating with IT Operations Management. They are clearly not the same thing, but we've allowed it to be taken that way. I suppose it's the fault of lazy managers who are looking for One Model to Rule Them All; but I'd rather blame the consultants)

    We've allowed/forced the service desk function to be equated with incident management processes. That allowed us to set low expectations, leading to lower pay and status expectations, for the service desk staff. So what I hear both James and David suggesting is to put incident management processes into their proper place, which is that of one of the many tools in the service desk staff toolbox. There's knowledge management, problem management, empathy, and yes, vulnerability. I suggest reading Patrick Lencioni's "Getting Naked" for an excellent primer on the importance of a service provider exhibiting vulnerability.

    I really like when I'm reading guys. Keep up the good work!

    1. Dan,

      I'm glad you are enjoying the debate. Of course it isn't surprising our positions aren't as far apart when you dig deeper, after all we have broadly similar backgrounds and the same passion for ITSM.

      I quite agree that my vision for SD2.0 is closer to what we originally wanted the SD to be in the early days of ITIL. I see it more as going back to where we were in 1996 and starting over again.

      I would extend your point about confusing SD and incident management - oh how that takes me back to my days as a V1 trainer - to say, and I think this is Aaale's point, that we are artificially and un-usefully categorizing the work of the SD. Actually any attempt will be artificial, the focus should be on the usefulness.

      I like the SDI approach of talking about interactions, and I'm also keen to learn more from the Service Design (in the non ITIL sense) community.

    2. "... the focus should be on the usefulness."


      I have to admit very little knowledge of the SDI approach. But I'm an American, so I should naturally be excused from such things. :-) Actually, I'd love some guidance as to where to start in learning about it.

      A thought just came to me, and I may be about 10 years late to this realization: Did ITIL start getting thoroughly mucked up when we Americans started embracing it (and thereby changing it to be more superficially US business friendly)?

    3. Dan,

      I'm only just coming to grips with the SDI approach myself, though since I've just been co-opted on to their World Class Service Desk standards Advisory Board I'm getting up to speed quickly. If you going to Pink12 Tessa from SDI will be there.

      No, I don't think ITIL got mucked up specifically because of the Americans, but I do think the shift in examination style from essays to multiple choice has hobbled a lot of people's thinking.

  8. Once upon a time I would have agreed with your polarization, but perhaps it is a little simplistic for today. There are other ways of splitting up the community that work equally well. As an example the last six months have reminded me that the marriage between those who are passionate about the Service Desk and those passionate about ITIL is not as solid as it might appear.

    The debate around the need for transformational ITSM (just a label I'm using here) isn't one between the experts and "ITSM Consultants armed with a few certificates" It is disingenuous to appear to suggest it might be. It is a debate, a totally legitimate debate, going on within the community of experts. None of us can see clearly into the future, but I believe as thought leaders in the ITSM space it is only right and proper that we should explore the boundaries.

    No one is saying chuck ITIL on the bonfire, what they are saying is lets examine whether the structure and language and process diagrams within ITIL can be improved, and let us not be precious about looking to other sources if they are more useful for a specific task, be it COBIT, USMBOK , lean or whatever.

    I'm still chuckling at Ivor MacFarlane's recent description of ITIL as "Generally accepted suggestions"

    To be honest I really don't want a single sentence in my original article about an unpublished paper from Aale to detract from the overall thrust of it as a call to action for the Service Desk. At the same time I don't want the debate to disappear from view. The most obvious way forward would seem to be for Aale to summarize his position, either here or on his own blog, and take it forward from there.

  9. But - You have the wrong name for all this - a Service Desk is a style of support, as is a Help Desk. Both have their role in responding to individual scenarios.

    First - understand what the customer is trying to do and how you help them succeed in doing that. In doing that, appreciate the style of support they will need and realize their are four major buckets here: break/fix, hold hand, service recover, and help yourself.

    There are three general service models: generic, specialized and personalized. I write to these in the USMBOK and will do a better job of blogging from March onwards. In fact I am speaking on the service recover (saving customers not recovering applications) at HDI in April in Orlando.

    It must be 15 years ago I coined the term X-Desk to stop folks from being drawn into a "Service Desk is better than Help Desk" discussion as promoted by ITIL.

    Whats better is what helps your customers. I'm a fan of Apple's Genius bar and the whole support regime that encourages their customers to take an active role in the support "experience".

    Google 'service recovery paradox' and you'll get what I mean here. Helpdesk, servicedesk, they are all inside-out thinking and we need to stop focusing on better names to call things and start to think and act in our customer's interests first - what level and type of service support (not just break fix) do they need to be successful?

  10. Ian,

    An interesting point. To crossover to my Service Integration work one of the issues I have is explaining to people how it does, and doesn't, create a need for new processes and how they map on to new and existing functions. In particular I make the point that you have to look at the TOM across the supply chain. I'm sure Aale and I touched on this in some of our early discussions but the wholes system model has to be part of the SD2.0 philosophy. We can't, as many in our industry seem to want to do, ignore what the customer and user community are going to do, and neither can we control it.

    I was never a fan of the headlong and largely cosmetic rush to rename help desks service desks. Do I think we should abandon the name in this context? I'm not sure, but I think we need a better language for talking about the underlying "things" that are going on than incidents, problems, requests and events, and a wider term for the scope of the subject - I quite like "support experience"

    Hopefully you don't need me to to repeat that I'm fully behind the shift to an outside-in approach.

  11. I hope you all have seen Robert Stroud's blog.

    It is just one of the comments that I have seen lately saying basically the same thing. IT Service Management must change because the world has already changed.

    Service Desk is a logical place for the change to begin as it is in direct contact with the customers, the rest of IT can hide behind. I think James and I agree completely on the SD2 part, we both see the same forces at work.

    Is this the end of ITIL? Maybe, maybe not. It is quite possible that ITIL will survive and there will be IT organizations that prosper with the ITIL model but there will be also successful IT organizations that have left ITIL behind them. I think those are the ones that are creating the new best practices that we should be teaching. It is also quite possible that the next version of ITIL will reflect these changes.

  12. Meh. I Just can't get excited about this stuff. Sure things change, but I'm just not seeing revolution, a new era. I'm struggling for an analogy: how's this? The automobile changed the world, automatic gearboxes didn't.

    the internet already changed the world. I don't see it changing service desks any more than it already has.

    the truly profound impact of the internet on service desks has been and gone:
    - the ability to easily give logons to third party suppliers to update tickets
    - end user self service
    - mobile access for field support techs

    As for multiple suppliers, we've already had telcos, PC vendors, and all sorts of app salesmen (not least of all SAP) creeping around IT to go direct to the business for years.

    i agree with everything you say except the significance of it.

    1. Rob,

      I suspect the significance depends on where you sit.

      Will it have much impact on the comfortable world of service management experts sat in a bar in the Bellagio next week? Probably not, whether it happens or not. Could it be significant for a company like TCS, where the provision of industrialized service desks, whilst not our core business, employs a very substantial number of people and services customers who want to see transformational approaches to service delivery over the life of typical contract? Yes I think it could be significant, though my life would probably be a lot easier if I'm completely wrong and we can all carry on as before.

      Could it be significant for those currently employed on Service Desks where self service is already beginning to be introduced? Faced with a choice between role enrichment, role impoverishment or unemployment I guess it might be quite significant for them.

  13. Just one little wrench in the works: Contacts to service desks are going up, not down.

  14. Roy,

    Does that hold good where there has been a major shift to self service and what type of calls are going up? Are there more "Why can't I have an iPad" requests than this time last year?

    There is certainly an argument that once the log jam of simple interactions are moved to self service that it will unleash a pent up demand.

  15. First let me say I dont believe that anyone here is a half-educated ITIL invoice-monkey consultant. However, perhaps it is valid that endless reinvention of terminology, that refers to very old things, does not help the perceptions of the consulting profession in the eyes of our customers?

    As an example, I believe that nearly 2,000 years ago the fundamental principle of outside-in thinking was very succinctly expressed as (what we usually call) the Golden Rule. Yet I would be utterly unsurprised to learn that someone had trade-marked the term "Outside-In Thinking" and are trying to sell it as their unique intellectual property.

    No, that kind of thing doesn't help.

    I also believe that imposing the ITIL terminology on a business, from the IT unit outward, is a huge error in both tactics and understanding. Since ITIL has a major imperative to think across the whole service delivery landscape, and to consider all the necessary components thereof, it seems at best contradictory.

    I would also note that "disintermediation" is not only about removing business intermediaries in the supply chain. It is also removing human intermediaries between customrs and IT systems, and between IT systems and supply chain. SO the fulfilment process operates not only in real-time but in real-time view of the customer.

    So (A) it had better be good, and (B) you had better have a damned good remedial service in operation, irrespective of what label you stick on it.

    What I tell my customers is that it is inevitable that things WILL go wrong, even in the best organisations. Perfection is not on the menu, so dont try to order it. What matters is what happens AFTER things go wrong? Who is there to help? Do they actually help? Do they know what they're doing? Are they honest? Respectful? Attentive? etc ...

    THESE questions **matter**.

    Does what you call this service matter anywhere near as much?

  16. I'm afraid that customers love old ideas being dressed up as something new. USMBOK though, and its focus on Outside In is an attempt to bring existing business service management thinking into IT rather than the other way around.

    Personally I'm still not sure that ITIL has the 'right' to impose thinking on other parts of IT, never mind the business. Then little that I do these days gets its mandate from ITIL.

    I like the concepts doing the rounds about anti-fragility. Too many IT attempts to design interactions between the business and IT are based around either the model that everything will work according to plan, or that everything is subordinate to the worst case case scenario. Instead we need models that accept things go wrong but deal with exceptions without drama.

  17. Thank you, folks. This conversation was great. I'm a new L1 Service Desk worker at an offshore (Canadian) site and have been balking at $125-$175 textbooks. I'm approaching this conversation from a background in non-profit management, environmental awareness and hospitality career experience, and academic undergrad work in Canada-EU subsidiarity and business governance before that. Thanks as much for a collegial (if two year old) discussion on something very 'new' to me: ITIL/ISO20000, COBIT, Lean IT, USMBOK, and the politics of certifications. Happy holidays from a newbie at a 24/7 remote IT Service Desk.

  18. A very informative article discussing service desks. The information are truly helpful. Thanks for posting.

  19. Thanks for sharing this post about service desk. It is very informative. Cheers!

  20. Nice post.
    Your information are valuable.
    Thanks for sharing.
    Help desk services