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?"

Comments

The Bottom Line.

[violent.ed]

You Can't. You Just Can't. Let a higher-up manager deal with them. That's what they get paid for.

Humor them

[kingkade]

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.

Re:Humor them

[sumdumass]

I couldn't agree more. I had a hard case were a customer purchased a new computer and because of not only certain software he installed but because of the way he was using the damn thing caused a memory leak and after hours of work, it just froze up losing every thing he did for the last hour or so.

As it turned out, he installed Microsoft office 2000 (from an internet download site) on a windows 98 computer and only updated to service pack one or so. He then installed some sermon writing program and wrote his sunday sermons on office so he could place an outline in powerpoint and project it durring the church service. There was some obscure problem wich was fixed in later service packs (sp2 i think, been a while) that caused a memory leak when copy and pasting from hyperlinked documents. It wasn't untill I observed the crash and the way the computer was being used before I could pinpoint the problem. I guess service pack two or later checked for authenticity of the microsft office product and he was afraid it would cause problems with him having it installed on two different computers and not owning a legit copy.

It was one month, four complete wipe and reloads plus replacing almost every component before the problem got to me. After two weeks of not being able to reproduce the problem I decided to have him show it too me (and showed him how to operate the autosave feature). The problem didn't become clear until I noticed the only difference (outside the parts) between his old computer and new was the office service packs. Sure enough I found a reference to a fix for something resembling the problem in the SP2 release notes.

  He had bad mouthed us, verbaly abused the counter girls and techs, made claims that we sold junk computers, trash talked us at his church and finaly threatend to file a lawsuite against us. It was good to explain to him the problem was because he installed pirated software and wouldn't apply the patches because he was afraid of getting caught. I found records were we installed the Office service packs on his old computer when it was serviced previously wich is why it didn't act the same. Needless to say, after I explained the office issue and the problem couldn't be recreated after the service pack update, he still tried to claim he was right and still maintained if it was a good computer, it wouldn't have had the problem. We then filed a slander and liebel suite against him. As part of the judgment, he had to mention in a newspaper add that he was wrong, uninformed to the workings of a computer and was the cause of the problems he was complaining about. He was also barred from entering our premises again.

That shop is out of business now, the owner died in a jet ski accident while drinking too much and his family had to liquidate to pay the damages. IT probably wouldn't have lasted too much longer because of all the preacher said at the church and stuff ruined any positive word of mouth advertising and made a quite a few other clients go elswere. In hind site, we should have just refunded his money and told him to go somewere else. But after we were commited, we had to solve the issue one way or another.

Use my patented method

[Anonymous Coward]

'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

Re:Drop them

[Reality Master 101]

I agree with you 100%. I've had to drop a few customers like that in my time.

Heh, I'm reminded of a story that took place in the early 90s, when I was involved with a medical system start-up. Now, these systems were pretty pricey, and I was doing some technical pre-sales support out at this hospital site. Now, the tech guy there was a real arrogant a-hole. I had been taking a lot for a number of days.

So we set up a demo system for him. Normally, our system used either X-terminals or Windows running eXceed (X-terminal emulation software). But this guy was a TOTAL IBM-a-holic. He worshiped at the alter of OS/2, and insisted we use OS/2 with IBM's X-terminal software. All right, we said, X is X, right?

Wrong, unfortunately. IBM's X server sucked big time and had a lot of problems. So the guy is giving me these fishy looks in a big meeting with some of his other guys. I say something about the limitations of what I can fix when the X server has bugs, and then he crosses his arms, and says,

"Well, whose problem *is* that?" (expecting me to roll over and admit the customer is always right, and promise to do what I can to fix it).

But I'd had enough. My response, "Well, it's YOUR problem, since you specced OS/2."

Dead silence. The guy's jaw dropped open, like no one had ever dared to speak to him like that. He huffed and puffed and blustered, and we moved onto a different subject. Later on, one of his guys took me aside and said, "I can't believe you said that to him."

I responded that I didn't care. If it runs like crap in that hospital, then we're better off not selling it to them and poisoning the whole area. I think I even said that they didn't deserve to own the software, heh. :D

Funny enough, the big boss and I got along much better after that. I think I earned his respect. He still insisted on OS/2, but he stopped blaming us.

Refund

[MobileTatsu-NJG]

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.

Re:Drop them

[techno-vampire]

I worked for an ISP for a number of years, doing tech support. Of course we had our share of customers who'd complain about every tech they spoke with and expected the impossible. No matter how good their connection was it wasn't fast enough or clear enough. Every little hickup on their side was blamed on us. When we identified a customer as impossible to satisfy, we'd regretfully send them this letter:

Dear customer:

We have been examining the history of your account with us and seen a large number of problems, issues and complaints. Apparantly, we are unable to provide you with a level of service you find acceptable. Therefore, we are going to maintain your account for 30 days to let you find another providor then terminate the service. We wish you the best of luck with your new service and hope you find them more acceptable.

This was a win-win situation. We got rid of the troublemaker, somebody else had to deal with them and the troublemaker couldn't even complain that we'd not given them a chance because we'd started out by accepting responsibility. (Note, however, that we never admitted that the customer's expectations were reasonable.)

Process correctly

[meburke]

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