The company i work for has a customer that we provide several software solutions for. They run various events and we provide them with an admin system for them to run their events and a windows application for them to keep track of things as they happen at their events.

While working with them I have noticed that they have are extremely hostile. Examples of this are:

  • Placing blame without attempting to identify a root cause of software failure unique to thier environment, and
  • Approving incomplete and inaccurate requirements that later cause system failures.

The focus of the criticism from the above issues appears to be directed to me, which includes many senior managers. My boss is being supportive but there are others in the company who are more focused on the customer's negative experiences.

What are some strategies to handle negative criticism based on inaccurate information? My immediate desire is to return thier aggression in-kind, but would appreciate it if someone could suggest a more constructive strategy.

  • If they had written you a polite email explaining that they had trouble but again you couldn't reproduce it, what is your commitment to the customer? Are you committed to help the customer in this situation or not? – Brandin Aug 9 '14 at 10:32
  • Make a list of everything needed to make your software work (network connectivity, database connectivity, JVM or .Net versions) and make a program that checks all of these, and provides a meaningful messange "I cannot reach port X of machine Y", ".Net version should be at least 4", etc. – SJuan76 Aug 9 '14 at 22:14

Be Zen about it and send them an email stating that after x developer- hours and y tester-hours of trying, you as a group were unable to reproduce the problem. Note that this complaint is the first incident of this type that the group has been notified, after the customer's software has been deployed and in production for six months. cc: your management and the same people that the customer cc'ed. If you are not customer facing, have your manager send the email.

The ball is in their court, and the burden of proof is on them. Your story reminds me of a particularly ignorant sys admin who called our tech support, stating that our load balancing software was no longer working on one of his machines. The field engineer we dispatched established that the sys admin had moved the machine to a different location within the office, without taking note that the new machine was now on a different IP subnet and without paying attention to the fact that the machine had been assigned a static IP.

Until new info surfaces, my best guess is that your customer did something stupid on that day. My second best guess is that there was a network glitch that day. Third possibility is that some of the data your software was processing was corrupt.

Keep in mind before you go to war that the world's idiots have us significantly outnumbered, and that they'll outlive you and me - While idiots may aggravate us from time to time, they have to live with their idiocy 7x24. For them, that's what hell looks like :) There is not much that you can do to them that's worse than what they're doing to themselves and to each other.

@jcm comments that " may come off to the customer as "It works on my machine" which is never acceptable to customers or bosses. It might be helpful to put in the email a request for details from the customer to help you reproduce the problem. That way, you're seen as cooperative while demonstrating that the problem isn't on your end."

That's NOT a good suggestion! I am presuming that the OP had the good sense to ask for these details beforehand from the customer when they tried to reproduce the problem. It makes no sense at all to try to reproduce ANY problem without data - This is so fundamental as due diligence that your suggestion would come off to me as somewhere between not funny and extremely frustrating if I were the target of that suggestion.

I couldn't care less about being viewed as cooperative. The only thing I care about is reproducing the problem. I am not into perception engineering.

As I had said, the OP's team, despite their efforts, were unable to reproduce the problem, and the ball is in the customer's court. Especially when "It works on my machine", it works on every other customer's machine, it has worked on the customer's for the past six months and the only time it didn't work was that ONE instance.

Come to me with such a story that my software failed, and if not only I but my entire team can't reproduce the problem with the data that you gave me, I'll shrug off your story. If either you or my bosses were not happy with our efforts and you know something that we don't and you feel that you can do our jobs better than we can, you are all more than welcome to reproduce the problem by yourselves and show us up.

Clarification from OP: "We are responsible for the software working but it runs on IT infrastructure they are responsible for setting up and maintaining at every event. They literally have no one who is qualified to do this. They had one qualified network engineer that they made redundant because he used to sit around not doing anything because they never had any network problems ..."

They could have had the qualified network engineer set up for every event. They did not come exactly ahead when things did not go according to plan at that last presentation.

|improve this answer|||||
  • 3
    This may come off to the customer as "It works on my machine" which is never acceptable to customers or bosses. It might be helpful to put in the email a request for details from the customer to help you reproduce the problem. That way, you're seen as cooperative while demonstrating that the problem isn't on your end. – jcm Aug 9 '14 at 4:38
  • 1
    I don't make assumptions. The OP didn't put it in the question thus my comment. Also, there is no need to be offended when someone comes to you with a suggestion, no matter how fundamental it may seem. The goal is problem resolution, not ego preservation. – jcm Aug 9 '14 at 13:50
  • 1
    We're just different then. I feel life's too short to take offense at such things. – jcm Aug 9 '14 at 13:59
  • 1
    @Dunk I am a systems engineer. I also used to do systems programming in grad school. You and others are wasting my time arguing stuff you know nothing about. – Vietnhi Phuvan Aug 12 '14 at 14:39
  • 1
    I'm not saying the OP's software is responsible for the loss of an Internet connection. All I'm saying is if that is in fact the case, the software can very easily "indicate" that is the problem. Tell the client to fix their connection. It's very simple. – user8365 Aug 15 '14 at 1:48

my immediate desire is to be just as aggressive and belligerent back and point out the many failings in their organisation that lead to these sort of issues

You need to suppress this immediate desire - no good can come of it.

Have you spoken to your boss about how to handle these sorts of customer issues?

In general, "the customer is always right" (even when they aren't). Being defensive is unlikely to help things at all - try to be helpful instead. Put yourself in their shoes and imagine how it would feel to have the software you depend on to help with your event just fail completely. Remember that without happy customers, you don't have a job.

Also remember that unless you own the company, you don't get to decide which customers can be discarded/dismissed.

Try to brainstorm additional ways to debug their system. Perhaps once you solve their issues, you'll be able to show them that the problems had nothing to do with the software you wrote. If that happens, you'll have converted them from a negative, blaming client to a grateful, happy customer. That can pay off big time.

Work with your boss to determine what to do next. Strategize ways to avoid or be able to quickly diagnose this problem so that it doesn't happen to another valuable customer. Ask you boss how you should react if a similar situation occurs in the future. You could rise above their negativity and be the hero here.

|improve this answer|||||
  • the customer is always right :if you're a techie and customer is not tech savvy, IMO that rule is not apropos. Depending on the contract, it can get you into big trouble: Try to brainstorm...debug their system :OP says they cannot reproduce problem and system was working a long time. 99.9% of time it means something in client's environment caused the failure. Who pays for fixing their system? Free? You open yourself to being taken advantage of. Charge? The client gets angry. Better to just explain it's not your problem and maybe lose a client. Fact is, you don't need such a client... – Vector Aug 10 '14 at 5:55
  • @Vector:The OP said "the sw they provided for the customer". Which implies that it is custom for the customer. In which case, it doesn't matter if the customer is tech-savvy or not, I'm inclined to side with the customer if they are using the sw in its intended environment. If the customer isn't tech savvy the sw should be built to accomodate for that. Somehow, I don't believe that this is a 1-time event and the sw really hasn't been "without problems for 6 months" which is why the customer might be a bit testy.If it is a completely different type of environment then that's another matter. – Dunk Aug 11 '14 at 15:39

Other than upsetting you, so far, nobody has punished you; it could be worse. The customer paid for the software to work and it doesn't, what do you expect them to do? If the programmer throws-up his hands and can't solve the problem, they will go over his head. There's is nothing they can change to fix the problem. Other breakdowns in communication on their part on other projects is irrelevant. They're paying your salary.

Based on what you have posted, there is something wrong with this particular customer's installation. You can blame it on Windows or the Internet Gods, but you need to fix it regardless.

  • Remote to their system and watch it fail on their side.
  • Increase the logging and error trapping on the app, so you can get more information.
  • Get on a plane and go to their site directly and fix it.

It has nothing to do with blame. You're the only one who can help them. Suggest everything to the Seniors in charge and see how far they will let you go to solve this specific problem.

EDIT: If this client is taking up a disproportionate amount of support time compared to other customers, Senior management needs these data. Regardless of their technical expertise, they're not going to want to throw more money at this client if they are not paying enough in return. If they have not technical, business or accounting skills, they're a lost cause.

|improve this answer|||||
  • there is something wrong with this particular customer's installation. [...] but you need to fix it regardless. In general, no. You provide a software that works with a defined setup, and not in every setup a client may have. Why if said company is using, say, Token Ring? Are you supposed to upgrade them to Ethernet? That said, documenting and defensively checking the environment is needed (if you need to access port X of machine Y, document that you need that and provide -by the SW itself or a separate diag tool- a message saying "I cannot reach port X of Y", instead of just doing nothing). – SJuan76 Aug 9 '14 at 21:57
  • 1
    @SJuan76 - Agreed if we're talking about off the shelf software, but the OP indicated "projects" which you can assume some customization. In the case of token-ring, the app would never have worked and thrown some type of error indicating there was no ethernet connection. Anyone can simulate that in testing by disconnecting your network cable or turning off you wifi. – user8365 Aug 10 '14 at 2:38
  • @Slaun76 - The OP admitted he customised the software. The role of a developer is not to provide a piece of software that works at the point they delivered it and then wash their hands of the process. Where else would you imagine the initial investigation would lead to other than the developer who customised the process? – Venture2099 Aug 14 '14 at 13:24
  1. Take a deep breath before reading any of their emails or answering the phone. There is absolutely nothing to be gained by getting into an arguing match.

  2. Log everything. Every request, every call, every email and every system action. When they call asking why things don't work the way they want, politely bring up the requirement from a few months prior demanding it work the way it does. Then politely ask them how they really want it to work. If they waffle more than 2 times on a particular item, start increasing the cost for the change.
    I had one client change their mind on a particular feature every three months. Every time they made the request, I brought up that they had changed it before. Finally I started escalating the cost of the change and it reached a point that their upper management stepped in, they made one last decision and those requests stopped.

  3. If some data goes missing and they are raging about it, give them a screen shot of the log showing who did it and when. This is at the heart of logging all system actions. If you can't tell them who, when and what then your application will always be at fault.

  4. Make damn sure that your application works. Test it every way you can and fix it quickly. Know how it can fail and make sure that's documented. The app should also be pretty verbal with the user about exactly what isn't working right; and must have a rock solid logging system. Not being able to transfer data across the network should be an easy one to identify the root cause. If you can't, then as a 3rd party who was never seen your app, my first thought is that you are doing it wrong.

  5. Schedule regular calls with them. In our case, if we haven't heard from a client in 30 days then the account rep calls them. We have a pretty good feel for which clients need more communication and which need less. Ones like this need more. You might even need to be weekly until they start feeling comfortable.

|improve this answer|||||

Not the answer you're looking for? Browse other questions tagged or ask your own question.