Are We Creating Problems By Design?

Mark Graban over at Lean Blog had a post this past Sunday that was an "Ah Ha" moment for me.  His post, "That's What We're Here For" struck a chord with me.  He relates how he when he registered for access to a web site he was given an Owner Name, Owner Number, Conference Code and Leader PIN.   However, when he tried to login it required an Owner Name and  a "Password" instead.  I won't relate the whole story but it involved needing a User Name which was not the same thing as the Owner Name and it gets worse from there.  No doubt you can see the problem this can cause.  Graban called Tech Support which was able to get him going.  He then relates:

I said to the tech support rep, "You know, the website is very confusing. I'm good with computers and I couldn't figure it out because things are labeled wrong on screen and it seems every new user has to make a tech support call, which costs us all money."

The tech support rep was sort of irritated and said, "Well sir, that's what we're here for."

A situation that could have been easily avoided with consistent wording and clear instructions.  Yet this is not all that uncommon.

Often we deploy systems with out visualizing how they will actually be used.  We don't see things from the user's perspective.  Maybe it is because we know the system too well to see how it might be confusing to others that don't have the same intimate knowledge that we have.  Some tips to avoid this:

1. Review your process and instructions carefully to see if you are clear and consistent.

2. Have someone who is not familiar with the system try to use it. This can be a good indication of how it will really be perceived by the user community.

Graban noted that other users probably had the same problem he had but Tech Support didn't seem to be too interested in solving the root cause.  They were more interested in only helping users as they individually encountered the problem.  Graban assumed that this was done out of a desire to ensure their job security.  He thought Tech Support didn't want to do anything that might result in fewer Tech Support calls since it could endanger their jobs.

I don't agree with Graban's assumption.  All the Tech Support people that I've ever met at many different companies have all been very dedicated and truly interested in helping their callers.  I have yet to see any Tech Support people that wanted to perpetuate the need for calls just to protect their jobs.  If there was ever reluctance on the part of the Tech Support folks to get a problem resolved I believe that it was due to a sense of futility.

Early on they've no doubt tried to get a situation, such as the one Graban encountered, truly fixed only to be stymied by lack of resources, prioritization processes and a cumbersome bureaucracy.  After trying that a few times they learned that it was futile to try to fix the problem so they do the best they can to repeatedly help users as the problem occurs again and again.

This brings me to the third tip:

3. "Mine" your Tech Support's experience for where the recurring user problems are.  Then allocate some resources to solve these what in many cases will be simple fix issues.

There are lots of ways to get at this information.  You can use six-sigma tools such as a Pareto chart to analyze the call records to see where the most problems are.  For a real quick start you can simply ask the Tech Support folks.  I suspect they can rattle off 3 or 4 without a moments hesitation.  This informal method may not get you all of the top problem areas but I think you'll find that they can identify most of the top problems.  The other advantage is that it can get you some quick successes while you are working on a more detailed data mining.

Once you've identified which problems you want to work on allocate some resources to work on this.  Taking care of small irritating problems can go along way towards improving customer perceptions and also help energize Tech Support by removing a source of frustration.  Who knows instead of solving the same problem over and over again they might get to work on some real problem issues.

What are your thoughts?

If this topic was of interest, you might also like these:

1. Director of First Impressions
2. 'Sup Chumps and Why IT Sucks
3. Why It's Time to Lose the Snide IT Attitude
4. Or the posts in the "Customer Service" category

Comments

[Mark Graban]

You're right, I should have given more credit to individual tech support workers. I can certainly understand how individuals would try and then get "beaten down" by management. It's more likely the tech support organization (management) that is trying to protect their fiefdom than individual workers.

[Mike]

Mark,

Thanks for the comment. Your perception is understandable since as the customer you only get to see part of the situation. It does highlight "unintended consequences" from what we as an organization do for the sake of efficiency or not do because it does not seem important. We have to be aware how our decisions impact both our customers and those the deal with our customers.

Mike