Discussion on:

Satisfying IT customers may be a bad idea

Wow, finally: someone who understands how I feel (I can move not only the requested mountain, but the whole range, and the user can hardly be bothered to utter a "thanks" in passing)! Not only that but he offers a new perspective which might actually help me deal with my frustration! Thank you, Paul Glen!

Customer Satisfaction is a key performance indicator where I work, however seeing as most of the time they don't bother to feedback, our managers have defined no response as good. Nice straight line on the graph.

I think it is interesting since so many companies, especially mine have gotten the art of the customer satisfaction numbers so high.

First, If the complaint don't fit the question that is asked, then it is discarded or changed through process to a satisfied grade. An example of this is : "Was the problem fixed in a timely manner?" the answer is "The technician took longer than I thought needed to be taken." In this case since it was a complaint rather than answering the question, it becomes a satisfied rather than a unsat.

Second, if the surveys come through incomplete, then they are either thrown out or the incompleted sections are marked as sats.

Last, if they are not committed to a call, then they are throw out. No call number, then it is not something related to anything dealing with the problem.

So no matter what you want to measure anything against, utilization (Made up number from number of calls closed versus the hours worked = Poor Time Tracking) which is another bag of worms all together, you are never going to get the number that is considered the correct answer in an executives eye.

If you are purely measuring customer satisfaction, then I urge you to start posting positions on all of the job websites that you can get because your gonna have a fairly large amount of turnover.

If we can get things in proper perspective, we can certainly define the terms. Who is on what side of the fence so to speak. I thought you defined the terms quite nicely as it is not a customer policy it is a continued client relationship whereby we resolve issues far more critical and pertinenty to their satisfaction with systems issues. We are not selling them some object, we are however;managing their objects/systems,reviewing their architectural needs, troubleshooting hdware/software conflicts, upgrading, maintaining,securing their networks, data and company objectives. A huge difference. Conversely, we still have to provide a service
mentality worthy of their business. Great article.

I think Paul's article would have been good a few years ago, but IT is evolving more into a commodity product than a client/provider relationship. With the deployment of hardware and software systems that are easier for users to maintain for themselves, IT is being asked more and more often to be accountable for the overhead they introduce into the cost of doing business. IT clients are evolving into "customers" who want to know that they're getting good value for their money. Setting realistic cusotmer expectations and then meeting them or exceeding them will become increasingly important over the next few years.

Wow, finally: someone who understands how I feel (I can move not only the requested mountain, but the whole range, and the user can hardly be bothered to utter a "thanks" in passing)! Not only that but he offers a new perspective which might actually help me deal with my frustration! Thank you, Paul Glen!

This article got off to a weak start and went downhill from there. There were two good points made in the entire piece. That was when the author pointed out that system support personnel cannot mistake being a sychophant with being customer oriented. I've always expressed that idea as being friendly but not obsequious. The only other point made in the article was to you don't just do whatever any individual wants you to do. You do what is in the best interest of the customer/client. The problem is that the author chose to express this point by making a false disctinction in the meaning of the words "customer" and "client". If you don't believe that the distinction is false then look the words up. They each have several definitions and you can mix and match those definitions to either support or refute the point that the author is trying to make in the article. So the author made these two points:
- Don't be a sycophant.
- Act responsibly when addressing customer/client requests.

That's good as far as it goes but it clearly didn't take me two pages to express those ideas.

The real weakness of the article is that it is mostly limited to making vague assertions. The author talks around the subject without getting to the meat of the subject. How could the author have done this? The author should have taken each of the two valid points and devoted a paragraph to explaining how to implement each of them. That doesn't mean simply stating a case study or two for each point. It means explaining the philosophy behind each point. I could do that here but I'm not being paid by TR and I won't do the author's work for him.

I think that the author should take some time to learn his craft. Perhaps a college class or two on expository writing ( journalism ) would help. If nothing else he might learn the value of including the principle points of writing an article ( who, what, where, when, how ).

Otherwise it was a great article.

OK, let's talk definitions first. Yes, you can read the dictionary to say that "client" and "customer" are interchangeable. I think the author's point was not about the literal defintions, but about how some people interpret the words -- the mental image they conjure up. And I agree that the word "customer" probably tends to summon up the image of someone involved in a short-term, one-shot transaction, while the word "client" tends to suggest more of a long-term relationship. The distinction deals with the connotation, not the denotation, of the terms (the distinction is covered in most "college classes on expository writing" ).

There is also a good deal more here than the two points that "stress junkie" tried to boil the article down to. For example, I liked the author's distinction between the quality of the product and the quality of the customer's experience. It's not self-evident that "act responsibly" means paying more attention to the client's involvement in the development process than to how clean and tight the code is. (In fact, I know many people in IT who would argue just the opposite.)

I do agree with "stress junkie" that more concrete examples would be helpful, and I hope the author will provide some in a follow-up article.

I do wish the article had included the point that sometimes the customer / client is mistaken or even -wrong-. In a corporate setting, there are always two clients. One is the user requesting service, and the other is the company itself. Sometimes a person will request something that may be good for that individual but not for the organization. The request may violate company policy, conflict with existing or planned technology deployments, or be expressed in terms of methods, not goals.

Part of the "quality" can still be suckup mode. It is not just the corporate setting individuals have the same issue. We have 2 kinds of client/customers; individual walk ins, and long term clients. Taking the 'bubblegum' interface off of the wxp machines that come in without asking is a wayu to speed up the indiviual repair, but can upset the customer greatly. while asking about the interface give the customer respect. We alway tweaked the performance properties and set up task manager to start running, now we explain why. Choice when possible is a good thing.
The problem is when is it possible. I remove all rebate 180 type programs when a machine comes in for 'running slow' I proactivly ID these programs as problem. when returning the machine. If it comes back 3 moths later with the same program because the customer likes it, I take them off again, because that is how to fix the issue.

One should not confuse a Company slogan with a Company objective.

Slogans are marketing tools which are designed to associate a particular phrase, saying or logo with a particular Company, and thus give some prominence to that Company. They are, by definition ?external? influences.

Objectives are ?internal? influences designed to help a Company achieve particular goals.

Customer Satisfaction is a measurement of how well a Company is performing against perfection. The premise is that the higher the CS rating the happier the Customer is and, consequently an environment for additional sales or services is created.

All Companies who survey their customers should be able to demonstrate a relationship between sales/revenue and customer satisfaction. If they cannot then the mechanism and measurement values used are wrong.

I disagree completely with Paul Glen in his attempt to create some distinction between the words ?customer? and ?client?. In a professional world both are synonymous. One could add a few others, like: ?patient?, because that is what I am to my GP. I am, nevertheless, someone in need of his/her services.

Perhaps if Paul could just give some license to the phrase ?Customer Satisfaction? rather than taking a pedantic and jaundices view he may agree that it is not necessary to have different titles for what is the same exercise. ?Client Satisfaction? or ?Patient Satisfaction? surveys would suit his point to some degree but I suggest that it is not the title that is important ? just the content. Given that the customer (client or patient) is presented with appropriate questions and understands the purpose of exercise then the result ought to be valid.

I also disagree with Paul?s concept of a client ? being rather ignorant and unable to judge quality of service.

I would never provide support to anyone who was incapable of defining exactly what they required of me or my staff. If they understand what they want then they should be capable of knowing whether or not they are getting it.

Never, in my forty years experience, have I known of a client, customer or partner who was unable to express an opinion on my labours ? good and bad, and often unsolicited!

Clearly there are clear differences of opinion on this one and, I guess, it depends on where you are in the chain.

Differences apart ? one thing is certain: if you don?t know your client or customer, and his business, you will never be able to set Customer Satisfaction parameters that will be meaningful.

Customer Satisfaction is not about the quality of code, how many midnight hours were spent on a task, how much blood was spilt in the process or any other such personal pains that were experienced providing a service. It?s about how the customer (client) perceived your work and how well you met his/her objectives. Forget the personal gratification needs. Get the new contract; get good write ups about attitude, performance, meeting targets ? and whatever else the client views as value.

Every business person must have some measurement of his/her marketplace and their own performance in it. Customer Satisfaction is one such essential performance indicator.

I am afraid that I cannot get too excited about the exact definitions of customer versus client and I don't believe that most "users" care what term is used by the IT Department to refer to them.

I do agree to a large degree with Paul that user satisfaction, as one measure of the success of an IT Department, is based on the experience rather than the technical realities. To give an example, an organisation I know took nearly 2 days to recover from a virus outbreak while managing to maintain high user satisfaction because of extensive communications from IT management. A few months later, the same organisation received bad user reaction to another severe outage (not virus this time, but same impact) although they fixed it in 2 hours because they had forgotten to adequately communicate.

The exact mechanism you use to deliver a good user experience will differ with the type of relationship you have (transitory or long-term), the nature of the service you are providing and, not surprisingly, the level of value-add the user perceives you are giving.

Paul's positioning of the client interaction may have been a bit simplistic, but it gets across the point that being a hard-working whiz at your job does not equate to satisfying those that you serve. Each IT Department needs to understand their users, developing a service support approach that addresses the issues while leaving the user satisfied.

The use of Customer versus Client terminology can be useful in one way. That is to distinguish between those that you interact with, sometimes called end-users, from those who pay for the service. In this context it can be useful to refer to end-users as "clients" and the business functional owners as the "customers". The allocation of terms is somewhat arbitrary and is not based on the logic used by Paul (even if it does appear to coincide).

The key point is that the IT Department should have satisfaction ratings for both "clients" and "customers", because they represent two very different facets of the IT Department's business. The former indicates how smoothly the IT Department delivers its services while the latter indicates the value of the service to the business. While not totally independent of each other, the metrics used to measure satisfaction will be different as will the core processes responsible for driving satisfaction.

To use my earlier example; The Service Desk and the Incident Management process were core to "client" satisfaction while Problem Management supported by Configuration and Change Management address the "customer" satisfaction objective of service availability.

While Paul's article provides another angle on the "perception versus reality" debate, I would encourage IT Departments to also assess the satisfaction of their Dollar-paying customers; the business owners.