• 07:00:00 am on August 5, 2008 | 6
    Tags: , , ,

    Not My Job

    One very interesting thing about we few and proud in the customer service and support industry is that we all lead a double life.  Not only are we analysts or directors or designers or engineers or marketers of customer service software solutions; we are also customers, the beneficiaries (or victims as the case may be) of our own efforts to improve customer service.  As such we have an almost limitless supply of experience and anecdotes, based on being a customer, to draw from for inspiration and insight.

    Just yesterday, I was attempting to fill my car with gasoline at a self-service pump.  No matter what I did with the nozzle and its associated pump mechanism the pump refused to dispense fuel.  Instead, the display just kept flashing the message, “Lift Pump Handle to begin Pumping Gas”.  After several attempts to convince the machine that I had already lifted the indicated pump handle it decided that I wasn’t really serious about my intention to get gas and cancelled my transaction.  Time to escalate (using the terminology of our industry) and get assistance from the kind and eager attendant inside.  Noting the number stenciled on the side of the obstinate device, I set off on my quest for help.

    Now I wish I had video of what occurred next because at least as much, if not more, was communicated in facial expression and tone of voice but the brief conversation went something like this:

    attendant: “Yes? May I help you?”

    me: “I just wanted to let you know that pump #9 isn’t working; it seems to be broken.”

    attendant: (rolling eyes and sighing as if explaining something completely obvious) “You could move to a different pump.”

    me: “Well, yes, of course I’ll do that. But I thought you might like to know that it’s broken.”

    attendant:  (Doesn’t say anything but stares back at me, blinking, with a look of bewilderment that clearly says that she thinks this is probably the stupidest thing she’s heard all week.)

    me: “Maybe you could call someone to fix it. Or at least put a sign up so no one else wastes their time on it.”

    attendant:  (Now a look of concern like maybe she should call someone – like 911)  “Ooookay.” (She had decided to humor me and hope I went away.)

    I went away, filled my car at a working pump and left, pondering on what the world was coming to.

    How could the concept of taking some action seem so totally alien to this attendant?  Later I started thinking about the similarities this scenario had to other experiences I’ve had and heard about in other customer service situations.  How much additional aggravation – and cost – could be avoided if agents had the ability and the direction to post a notice when they discover something isn’t working?  The concept is at the core of Knowledge Centered Support’s (KCS) “flag it or fix it” doctrine.  Most agents want to be as helpful as possible or they wouldn’t have sought a job in customer service in the first place.  But too often they’re working under pressure to just get to the next call.  They may have even been trained that it’s someone else’s job to fix unanticipated issues and that they are only to handle items for which they have scripts ready made.  Call guides and scripts have their place but the bottom line is that customer service organizations won’t consistently see customer satisfaction rise and costs of repeatedly fielding the same issues go down until that most basic of KCS methodologies is adopted and agents can take a few seconds to alert their peers when they run into something new and, ideally, what they tried to resolve it.

    Advertisements
     

Comments

  • Lars Gustavsson 12:20 am on August 6, 2008 | # | Reply

    Hi.
    We have been using KCS for years, and “Flag it or Fix it” is VERY hard to achieve for us. We have been pushing hard for it, and when doing random reviews we see that it happens approx 10% of the time.

    Our Engineers are somewhat ok with adding new facts – such as saying that a solution is applicable also for release XYZ, but it’s like pulling teeth when it comes to adding newly found information or highlighting that contents is incorrect or incomplete. Many engineers are offended when they get these kind of comments – even when they are very constructively written.

    Anyone that has any good experience on how to turn that around?

  • Esteban Kolsky 11:33 am on August 6, 2008 | # | Reply

    Lars,

    Ah, yes… the perpetual question of putting the needs of the organization ahead of our own feelings. Or, in other words, how to make the key element in the KM chain, the users, become more aware of the needs of the content over their own needs.

    It has been my experience that this type of cultural change, which is what this is, required very specific and detailed steps to be taken from the very early steps of deploying KM.

    The importance of having a complete and accurate knowledgebase, and the value to the user – not just the end-user but also the corporate users – needs to be a critical part of deploying the system. If corporate users can see how a complete and accurate entry reduces their frustrations, increases their ability to help customers and in turn increases the satisfaction and loyalty of those customers they do tend to take it more seriously and be more invested in the process.

    Alas, this takes time and effort to change those perceptions. Elements from change management (find the critical change agents you can enlist to assist you with those changes, repetitively ensure that all stakeholders see the benefits and value of those changes, document and benchmark critical metrics to all stakeholders and participants, etc.) can certainly assist you in reaching your goals.

    Feel free to reach out to me for more details, or more discussion on this. You can find me easily via email at ekolsky at evergance (sorry, trying to prevent spam)

  • Keith Holt 3:03 pm on August 6, 2008 | # | Reply

    Lars,

    Thank you for your comments. You do have an interesting variation on the contribution challenge.
    By far the issue I’ve seen more often is a reluctance to contribute. At the risk of over simplifying human behavior, this is often attributed to a fear of being made obsolete by the knowledgebase. “Once they have everything I know, They won’t need me anymore.” Interestingly, this fear stems from individuals underestimating their own value to the organization. If their knowledge was static the fear might be well-founded. But people continually learn new things. The normal, healthy individual in a support position is continually applying their cognitive skills to the situations they encounter and coming up with new insights and creative solutions. Therefore the best approach to encouraging contribution is to get your people to understand that they are valued – and rewarded – not for what they know but for what they contribute. What they know can run out but, as long as they’re still learning, their contribution is potentially limitless.
    Now to address your variation on this theme: You write that many of your engineers are offended when their contributions are corrected or improved. Might it be that this indicates a high degree of personal pride and sense of ownership on the part of these engineers? If so that is basically a desirable trait. Perhaps (and I hasten to say that this likely needs much more analysis but this is the beginning of a working theory) it would be possible to adjust this sense of ownership to a community instead of an individual focus – “We contributed this solution,” and “We are proud of the quality of our contributions.”
    There’s no ‘magic pill’ to make that change but it reminds me of something I learned watching the movie 300 just last night. In it the Spartan commander is explaining to a character who could not use a shield properly how their phalanx maneuver worked. Fighting shoulder to shoulder, each warrior’s shield held in the left hand protected the right flank of the next warrior in line. What seems applicable here is that this was not done because of any weakness on the part of that fellow warrior but rather it freed his right arm to wield a weapon in attack. The engineer/contributors should be led to a point where they understand that having a contribution corrected isn’t a sign of weakness but rather it is just a mechanism of mutual support – both received and given – that will allow them all to most effectively attack problems for their customers.

  • Susan Abbott 2:18 pm on August 15, 2008 | # | Reply

    You know, a similar thing happened to me earlier this week…
    If we can’t change the front end with people, maybe we at least need to put a device in the unit that knows when it isn’t working and sends a signal to a central repair facility, and simultaneously changes the electronic messaging to say “I’m sorry, this pump isn’t working, please use another pump”.
    A little smart technology could help, even if the people can’t.

  • Lars Gustavsson 6:32 am on August 18, 2008 | # | Reply

    Hi Susan.
    We incidently created what you spoke of in our KPI’s. It didn’t work out too great.
    Read,laugh and learn:

    We had order from management to create a KPI around our Knowledge management that “showed the real value” (=$$$) for the customer support. We decided to track the difference between the time it took to solve a problem the first time (the originating ticket), and the tickets that reused the same piece of knowledge.
    Correctly used it would have achieved what Susan talks about (flagged situations where the reuse of a solution do not achieve time savings).
    Results were tallied up so the owning organisation of a solutionobject received half the gain/loss per individual reuse, and the reusing organisation received the other half.
    But we decided not to disclose the individual ticket and solution ID’s as we feared that it would lead to people sub-optimizing on the numbers instead of driving improvements.
    Instead we only showed a total result per country unit.

    We were wrong. Many support teams spent conciderable time to generate & maintain lists of what solutions were “Safe” to reuse, as it gave them good numbers.
    Others created brand new solutions rather than “flag it or fix it”. We got to a situation where many organsiations showed great KPI numbers, and still did not provide or got any business benefits from KCS, and the knowledge quality in our database suffered.

    It was a great learning experience about what KPI’s can do to behaviours.
    We have a very different KPI on KCS now.

  • Jack 11:01 pm on August 19, 2008 | # | Reply

    very good blog


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: