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 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
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 >
Better yet: try to actually look at their computer that is running so poorly. If they run it on laptops or in a horizontal enviroment, they could bring you their computer and replicate the error. Even if it runs on a desktop, if the problem is serious enough they could consider bringing it in. Try to get the exact enviroment in which the alleged error is occuring.
Information wants a fueled airplane waiting at the hangar and no one gets hurt.
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.
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.
(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.