Slashdot Mirror
Dealing w/ Unsatisfied Customers?
MoOsEb0y wonders: "At the company I work at, we have set up a series of SLAs giving a list of things they expect our products to do, that we promise we will deliver. In my particular situation, I have a customer who claims that the product we delivered them was slow and unresponsive. However, when we tested it to try and determine what was wrong, we didn't find anything wrong with it. How do you deal with a customer who is bent on assuming that you are incompetent, and that he or she could never have unreasonable expectations?"
Some customers just aren't worth having. It's a tough choice to make sometimes, but every now and then you've got to drop a customer.
You Can't. You Just Can't. Let a higher-up manager deal with them. That's what they get paid for.
- You're not paranoid, they really are after you.
You can't always assume the customer is always right... sometimes they're just wrong and you just have to let them know. It's all you can do. :/
-uso.
What you hear in the ear, preach from the rooftop Matthew 10.27b
Due diligence is important though so make sure you actually do try to find their problems. If nothing's found, humor them and say you've looked into the problem. Try to get their system specs, environment settings, etc, etc, ad nauseum and they'll learn they better be able to provide a lot of detials next time they decide to report a complaint on a whim if that's the case.
why run from Vincenzo?
I've been in that situation, and it's not fun.
If you can't track down a cause for the problem, the best you can do is explain to them the limitations of the product and product development, etc. If they are saying the product is unresponsive when it's just being a little slow, then that's not going to work. If it really becomes a big problem, you may need to refer them to the engineering team.
Just hope the engineer doesn't say "I'm a people person, damnit!"
Ask them to give you a demonstration of the product and show you what's wrong with it, then work with them.
echo YOUR_OPINION >
'Tell them to fuck off'
Also, refer to:
http://www.somethingawful.com/index.php?a=3853
and
http://www.somethingawful.com/index.php?a=3885
If the customer is important enough then try to see the problems from their perspective; give them the benefit of the doubt. Assign a customer-oriented, technical person to be onsite to see the "problem" first-hand. See if it really is a problem (bug or implementation) or just an expectation problem. The absolute worst thing to do is dismiss it outright.
If it is too much trouble for your organization, give your customer the names of some competing product or another product that will fit the task and send them on their way.
Hey
I don't mean to flame, but I have been in the opposite position. I have had a laptop where it will fail something like Memtest, I will send it in and the technicians will say I am not a tech and that there is nothing wrong according to their certified tools. I have had hard drive failuers that techs could not detect and I have had broken keyboard where the one letter (q I believe) only worked if you pushed really hard on it and the technician has said it was normal.
Since all of that I have moved into a tech job. I have had computers come to me after they have brought them to other dealers and I have found things wrong. Though I am sure you are good at what you do I recommend you check everything. Sometimes the check list does not cover everything. I know that everytime I sent my laptop into Toshiba Tech with a broken DVD drive it was certainly never tested as it always came back broken until I gave up and replaced it myself.
Having said that I have had one occurence where I could not find something wrong. The customer was saying that the computer was to slow. In that instance I called them up with some timings I had made. E.g. Word takes 10 sec to start etc. Asked them if this was the problem. I would send it back to them and have them time it. I eventually found out that thought everything was suppose to be instantnious.
So after all that my advice, phone them up. Have them walk you over the phone what is wrong with it. Then you can tell them either you cannot reduplicate the issue, or that you don't support that.
It's possible that you're wrong, and the product really is performing poorly for them, and not because of a legitimate reason like "the server is slow because so many people are using it simultaneously."
I have been on both sides in situations like this where the service provider or vendor was wrong. I've made the mistake of jumping to conclusions when I couldn't replicate the problem, or when I thought the customer was being unreasonable. I've also had to deal with people who were clearly making the same mistake, and it cost them any future business from me.
My advice would be that if they're still convinced it's a problem, either go see it in person (if this is an expensive product), or offer them a full refund.
"...always new atoms but always doing the same dance, remembering what the dance was yesterday." -Richard Feynman
Only to idiots, are orders laws.
-- Henning von Tresckow
Perhaps too plain and simple an answer.
DT
Is this thing on? Hello?
I have had many issues where a customer's overzealous internal network security slowed EVERYTHING they did down. But they wouldn't talk about their apps, only ours.
Does the app run in an environment that doesn't have as much connection to anything they might have broken internally?
Do the guy's co-workers think it's slow as well, or is this person insane?
My mom says I'm cool.
I worked on a plugin that's being sold today. One of the things I pushed for early on is that we can offer refunds for people that cannot get it working, even if the fault's on their end instead of ours. As a result, we're pretty quick to say "If we cannot get this working, don't worry, we'll give you your money back." It has been my experience that most customers that hear this early on are happier to work with us troubleshooting the problem. It puts them into a position of feeling like we're truely trying to help them, plus it relieves them of the burden of trying to prove it's our fault. We've had a few hundred sales, and we've only issued a couple of refunds. To the best of my knowledge, we don't have any unhappy customers, and that includes the two we gave refunds to. (Heck, they may even come back when they have some time to put into troubleshooting.)
I don't know if you can offer a refund or not, but I thought I'd suggest it. I can tell you from personal experience that inability to get your money back is one of the biggest frustrations with support problems. If you can get the money element off the table, you may enjoy a better support experience.
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
(1) Their perception is completely based on their inability to properly understand how the system works... or worse, they don't want to know. If what they feel is stirred by their ignorance, you can't beat that until you demonstrate (with a LOT of patience) that it does work.
This technique is more valuable than most people consider, because when you work with the customer as directly as possible (or explain as simply as you can what the readouts of the Task Manager Processes window actually represents), it actually helps to create the relationship that businesses really want with service providers.
(2) Another thing guiding their perception is spawned by the possibility that other systems may interfere with your systems. Your benchmarks and your test environment are not the same as theirs in production... what you see as a working, functioning model does not mean the outcome will be the same where they are.
Easiest example is like a network throughput test. You may see 100mbit full duplex, but they may work in a hubbed environment with a jabbering NIC somewhere on the network. Or a quiet network such as yours may not make multiple requests to the machine in question, but when they put it back online, it may be getting DoSsed out the yang.
(3) Last thing is to demonstrate the importance of your SLA, and what it does not cover. You must be firm about this, and explain that while your benchmarks indicate proper function, for a reasonable fee you can watch over their shoulder after it's reimplemented.
This becomes a cost/benefit exercise, but in one fell swoop, if you have the opportunity to visit his site, you might charge an hour's service wage to investigate on your own. Most often when I'm having to look at the impossible possibility, I have to open my mind as wide as possible, and consider as many variables as I reasonably can.
Keep your perspective as wide as possible. People don't always intend to insist things are your fault, but you better be aware of the fact that this customer will not be the first to bitch. If you succeed at solving the problem, you have both satisfied the customer, and demonstrated your ability to agreeably end hostile customer problems.
Some customers are unskilled and unaware of it (PDF link, 254kB). There is nothing you can do. In these people the level of incompetence is high enough that they cannot recognize their own inability. The only thing you can do is stay away from them. Don't explain, don't try to make it right. You cannot. Limit your losses and get rid of them. If nothing else helps, take the device back and give them a full refound.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Some dumb and sort-of-unrelated observations: It isn't how it looks to you, it is how it feels to him. I was walking out of the courthouse with a client after the judge ruled against us. My client told me not to worry about it. He said I had clearly presented his case. He knew there was a chance of losing, and he had lost the gamble. He thought he had received justice because he had his side clearly and eloquently presented, and he felt the judge had ruled against him on one of the marginal points. Southwest Airlines employees like to re-tell the story of the lady that wrote numerous complaint letters, objecting to many of Southwest's unique policies. The staff finally kicked one of her letters up to CEO Herb Kelleher. It took Kelleher sixty seconds to compose his response: Dear Mrs. Crabapple: We will miss you. Love, Herb. It isn't how it looks to him, it is how it looks to everyone else. That one sale will neither make nor break your business. If the rest of the general public is convinced that you treated him fairly and respectfully, listened to his problems, and made a serious effort to find and eliminate any possible problems, then you are ahead of the game. With those kinds of folks, I find it best to go a little overboard. When they complain to friends and neighbors that you didn't do what they wanted, they will be quizzed about what you did do. When the complainers describe the above-and-beyond things you did to fix their problem, first, the audience will disbelieve the complainer, and second, it might just generate some business. It often worked that way for me.
All is paradox. Retired lawyer, so this is just one more layman's opinion.
I get this all the time. I've been troubleshooting systems since the mid-60's, and now I get a lot of calls to fix systems that other techs and engineers failed to fix. One thing I've learned over all those years, is that 90% of problems on most projects (including my own) are due to inadequate design and specifications in the beginning.
A problem is a discrepancy between the way things are and the way you want and expect them to be. All problems have a specific description, and elements of timing, location and scope. In order to resolve a customer's problem you must have agreement UP FRONT about what the resolved problem looks like in description, timing, location and scope. Without that agreement about "how you know when the problem is solved" you will just keep tracking unspecified problems. Precision is ultimately important.
Now, if one of my projects fails to perform within the environment, time and extent that I promised, I fix it. Occasionally the customer has an additional requirement (change orders, anyone?). If I can profitably meet the customer's requirements, I will. Some projects are not worth fixing. In less than one percent of my projects have I had to give a refund or a discount, but I'm willing to do so if that will get some projects out of my hair. As has already been said, some customers are not worth having. I usually find this out when I try to get proper agreement on the specs and prices.
Occasionally I find there are conditions outside my control that keep the project from performing like the customer expects. I will work with just about anyone to help alleviate these problems, but if it works correctly in my test environment, and if the test environment is spec'd at the design phase, and if the customer agreed to the test environment, then it's not my problem. (The last problem I had like that, about 4 years ago, the customer changed telephone systems just before I installed the project, and the new system had some incompatible idiosyncracies. The customer paid extra for me to resolve the problem.)
If you are not trained in a formal problem resolution process, I recommend starting with "The New Rational Manager" by Kepner and Tregoe. Good luck
"The mind works quicker than you think!"