Customer is “deeply disappointed” in our software because of one bug. How to reply? [duplicate]

Question

This question already has answers here:

How do you respond to: “Ever since the update…” questions from clients? [closed] (7 answers)

Getting users to write decent and useful bug reports (6 answers)

Closed 6 years ago.

We have been building custom software for one of our customer for a few years now. Everything is going well so far.

However the customer always has an attitude that when they find a bug in the software, then they are getting really pathetic and complain that they are now really disappointed with the quality of the software: Because if they found this one bug then there surely must be other bugs, so they assume that the quality of the software is getting worse. It's almost like a proof by induction: If there is one then there must be many.

To me, there can always be bugs (the software is part of their CRM solution, so nothing like software used to run airplanes, nuclear reactors, etc.) Obviously, we have various means of testing, but we (or the customers) are not testing everything, so bugs can slip through. Which is OK in my opinion.

But how would you react to such a pathetic and emotional response? I am always totally speechless when they start this way.

Answer 1

It sounds like for the most part, you have a good relationship with this customer. ("Everything is going well so far.") Presumably you want to keep that relationship.

But it sounds like this scenario has occurred more than once. Perhaps you have somehow (unintentionally, perhaps) let the customer believe that you aren't bothered by these occasional bugs as much as they are. If so, the customer may feel they should increase their own expressed level of concern over the problem in order to get more attention from you.

In such cases, the more you appear to brush off the problem, the more they will complain.

Outside of (possibly) some very expensive development processes, it is perhaps inevitable that a bug will sometimes be found after release. But it never needs to be acceptable (or "OK") for bugs to slip through. You can reconcile these two beliefs by making it clear that you don't want to deliver buggy software and that you take the discovery of even one bug as something to be addressed. The next step is to figure out how to address it.

If you make the customer understand that you are on top of the situation and doing everything within reason to fix the problem, they may complain less. If they somehow inform you of the existence of the bug (such as in an email saying, "Hey, is this supposed to happen?") before the meeting where they tell you how disappointed they are, you might even be able pre-emptively to make them understand (even before the meeting) how seriously you take this situation and in that way possibly deflect some of the criticism.

Answer 2

1. Agree wholeheartedly with the customer that repeated bugs are a problem

2. Have the customer agree that more work should be done to prevent these bugs

3. Have the customer agree that more qa and more testing is appropriate

4. Have the customer agree that this will initially seem to slow things down a bit and cost more

5. Do more qa and write more tests during development.

6. Invoice accordingly

Answer 3

Same as you would to any other customer: "I'm very sorry that you had problems. What can we do to help?"

Now, you're likely not going to be able to do everything they ask, and certainly not for as free as they would like it to be. That's a matter of negotiation. But your first communication is apologies followed up by positive, constructive overtures.

Answer 4

It sounds like you haven't been up-front about the nature of your work with the client from the beginning. I'm not sure from your question that you and your client understand that All software is buggy.

And I do mean all. Even your HelloWorld app is "buggy" if it's expected it to ... I dunno ...

• Automatically translate based on locale settings
• Say "hello world" out loud for hearing impaired users
• Run on a toaster
• Other unreasonable things

Or even if it's expected to do something kinda reasonable that wasn't initially expected:

• Display "Hello World" visibly even when STDOUT is redirected to /dev/null

Bugs are often just features as seen from another perspective. If there are delusions about this on either end, clear that up.

BUT FIRST, it's wise to apologize if any of the following are true:

• The bug is severe
• The bug is a result of some carelessness on your end
• If the client wasn't fully educated on your process, the nature of software, or the nature of bugs
• The client is very upset (even if it's not your fault)

What you do from there depends on your contract and desire to keep the client. If you bill by the hour, it's between you and the client as to whether it's billable time. That may require some investigation on your part before you can determine whether the issue was related to recent billable work. If it's a fixed price for completion of X, you should probably fix it for free. But, nothing is not beyond the realm of negotiation -- even if your in a contract.

Basically, have a conversation with the client and come to an agreement. Speak like humans. Ensure that you're giving the client's needs and expectations explicit consideration. Ensure, in as polite of a tone as possible, that the client also understands your needs in the relationship (to make a living) if profitability on the project is becoming questionable.

And if this is a common occurrence:

• Educate the client and agree on bug-fix and change-request procedures (and billing).
• Update your development and QA process.
• Update your attitude.

Your job is primarily to know what you're doing and deliver high quality work. If you don't have processes in place to ensure the client is getting a stable product, you need to fix that -- immediately. Secondly, but equally importantly, it's your job to politely educate the client when misunderstandings about the work, the product, or the process arise.

Imagine taking your car into the mechanic to replace a battery. Shortly after the replacement, you hear "funny noises" when you turn a corner. When you return with your car, your mechanic will (should) politely investigate the issue, explain the situation, and bill based on whether the newfound noise was related to the battery install.

He probably won't go to his buddies say, "I have a pathetic client", unless you've been truly unruly -- in which case, a good mechanic might offer a refund and recommend another mechanic.

Answer 5

The immediate answer to your question is to remain professional, but you have to back it up with action. Specifically, addressing the customer's concerns in a way that objective and fair.

It is important to have open lines of communication and an easy way to report and track bugs. Typically this goes through the project manager or development lead, sometimes the customer has direct access to the tracking system (e.g. Jira).

If the customer feels reassured that they can report bugs and they actually get fixed, this goes a long way toward improving their attitude toward both the software itself as well as the processes used to build it.

The important thing is to have a clearly-defined process the entire team follows when reporting bugs, scheduling them to be fixed, and validating they are fixed. Depending on the type of bug this may involve writing more test cases, or manually testing. There should be a clear regression strategy as well in case a bug for which a test does not exist (e.g. spelling error) is broken again later on. Be sure to work with the customer to identify the high risk areas to get the greatest return on investment from your QA.

Answer 6

Something that may help is to point out that software development is similar to a production environment. Even the most stringent of environments, such as nuclear reactors, understand that the unknown must be bounded statistically. Their bounds are just tighter than ours.

Explain to your customers that you can bring bugs to an arbitrarily rare level, such as the elusive "6 sigma" that is so popular now days. However, development of large applications at this grade is exceedingly expensive. If they truly value a low bug rate, they are free to pay the cost for it.

Another approach you can take is to create more testable requirements. If they want you to reach a very high level of reliability in your software, the requirements you are given are going to have to be more and more specific. If I am given the requirement

Users should feel the interface is interactive

I cannot reach a high level of reliability. If I am given the requirement

When the user clicks on the interface, it should respond within 0.1 second 95% of the time. In 4.99% of the remaining cases, it should display a 'waiting' icon while it is processing

then I can seek a high level of reliability because I can develop a testing process to mitigate bugs.

As a follow on, I would like to suggest an alternative to seek. Your customer is acting like a customer. If you are given the opportunity, try to work with them to turn them into a partner. The customer/provider relationship is not as stable as the partner/partner relationship. The latter can actually deal with bugs better.

I list this as a follow on because it doesn't really address your question, but I find it is something important to think about when dealing with longer term customers.

Answer 7

You are really asking on the wrong website. As a programmer, you don't reply to this at all. Your manager, or better your product manager, or maybe your sales people, they are the ones to reply to the customer.

Now if your manager, or product manager, or sales people, come to you and ask why they have so many complaints about bugs in the software, then the bad answer is "must be because I'm a pathetic developer". The good answer would be "do you remember how we told you that one week testing isn't enough? And how we told you that we shouldn't make these big changes just before the release? And how we told you that we have to spend some serious time improving quality instead of adding more features? "

Answer 8

Address the bug, of course, but there are a couple of factors to consider. Remember that at the end of the day it's a business relationship: a value-for-value proposition.

1) Is the overall relationship a good one? Are they using the software? Do they want to continue the business relationship? You might not be able to fix their hurt feelings, but you can certainly focus on positive, forward-looking results.

2) Sometimes people express themselves in funny ways. They talk about the end of the world, but that's just how they talk. (My little girl does that.)

3) They may be apprehensive about addressing the issue. People like the happy path. So their feelings of disappointment may be as much from having to talk about it as having the problem.

4) It might be a negotiating tactic, as in "We'd like you to do more work for us, but we need a discount because of that TERRIBLE BUG IN THE LAST VERSION." OK sure.

5) There may be a legitimate cost concern, as in, how to pay for the time to correct the issue.

I've found in dealing with external and internal customers, if I focus on results, and address any problems diligently, the interaction gets smoother as trust improves. Fix the problem, and take the long view. As you establish the basis of your relationship, you want to focus on the forward-looking stuff.

If nothing else, it's a great example of customer interaction to learn from.