How to manage change and expectations with customers

Question

My team is implementing the software of our company with new users. Recently, I've implemented our software with a bunch of new users who were working with a different software from another company. They are complaining loudly about our software, saying that they were used to the old software and saying that our software is implicitly bad.

They are calling us on an almost daily basis, taking a lot of our time and energy in support and at the end of almost each call, we have to listen to their rants.

One of the solutions is to add some functionality to make our software like the old software they worked with.

However, thinking about it, if my company does that for every customer we will be spending a lot of time and resources, pleasing customers who are treating us badly.

I'm hearing their complaints but I don't know how to bridge the gap between what they want, e.g going back to the old ways, and what we can do.

Are there other ways to satisfy them, in terms of customer care and change management? Should I let them "rant" even knowing it is bad customer care? Last but not least, how should I manage their expectations in respect of Change.

Please find my update as requested in comments

Who is responsible, at the customer's company, for managing the change of software with the users?

Usually one senior person who is, most of the time, not familiar with software implementation , he/she is more a senior figure who rose through the ranks.

Who is responsible, at the customer, for accepting the functionality of the new software despite the fact it is different to what they were using before?

Usually that same senior person with the IT manager of another town hall. Both drove the change. From my perspective and that specific customer, it was poorly sold internally and that IT manager who is part of another town hall , is part of the IT department of the region and should have not a say but as he was part of that region, he is a god-like figure. The final users were barely trained for cost reasons and not ready for all the changes.

For the sales and acceptance process, the process goes as following:

Client sets a RFT. We create a word document, detailling what our software can do. Once done and if we are selected, we go for a public audition with the competitors where we show our prototype. If it goes well, we won the bid. Starts the implementation phase.

Size of the client?

It depends. It can go with 2 or 3 people for small town up to hundred of people for bigger town. As we try to make more business, we are going for bigger market... My company is a small one but we are gaining momentum. Therefore bigger markets means change for us , too.

Answer 1

What you are asking has nothing to do with the workplace, but it has everything to do with running a profitable business. But you can help a bit.

Find out who in your company has the responsibility for what your software does, has the power to tell your team what changes to make, and the responsibility for the cost. I would very much hope that that person follows the old rule which says "The customer is always right - as long as the customer pays".

Find out who in their company is the contact who would discuss requests to make changes. That one is the person who the one responsible in your company would talk to and nobody else. Unless you have a contract that says you have to listen to the complaints and rants of every single end user (in which case you are FUBAR), tell those complainers firmly but politely that you are not their agony aunt, and their complaints should be directed at the contact in their company.

Making changes because an end user complains to you, without the person in charge telling you to make that charge, is madness. You are not appeasing them, you are encouraging their behaviour.

"Answers are no ones. For future customers, we have internal peoples who will be dealing with the change process. But what can we do for existing customers...? Should we ask the customer to name one?"

Bloody hell. You put yourself into a massive hole there. Should we ask the customer to name one? You call the customer and tell them that what is happening is unacceptable, that you will not take complaints from end users, that they need to appoint one person to handle this and won't talk to anyone but that person. And then you better check what your contracts say, because I can see this situation becoming very, very expensive if you don't stop it.

Answer 2

This might not be the correct answer as I've never owned a business, but I have worked for them!

It seems to me that you sold a product to your customer - they knew (or should have known) in advance what they were buying... (Have they paid yet? ;) )

If they need changes to the new software to make it more like the old software, then that is additional work for you and - unless you agreed to do it as part of the sale - you should charge extra for it!

This is what contracts & specifications are for! Now you may want to just make the changes for free as a gesture of good-will and to maintain a happy relationship with your customer (maybe they are planning future purchases from you), but that's up to you really, you're not obliged to.

If I buy a car and it doesn't have a CD player, I can't really go back to the seller and complain that because my old car had a CD player, he should provide one to me too...

Answer 3

The most obvious answer is that you shouldn't have created "bad" software to begin with. I've run into more than my fair share of that and it is far more frustrating to your customers than to you as the customer tends to not have a clue what is going on "under the hood" and they have no ability to figure it out since they don't have the source code. Just keep that in mind when getting annoyed with your customer.

But now that you are "stuck" with each other, your best bet is to find a way so the customer can easily submit problem reports. Calling on the phone is in nobody's best interest unless you can actually help them in real-time. Which is probably doubtful.

Frequently, just having the ability to submit a problem report quells the user's frustration. Then it is just a matter of responding within reasonable time frames. e.g. We plan on fixing this by xyz date. We aren't going to fix this. Did you try abc? yadda...yadda...

The other thing you can do is make sure you have decent documentation. I am currently working with a company that only reports error codes. Their documents have a large number of error codes listed. Guess what....none of the error codes I run into seem to ever be listed in that documentation. Also, 95% of the error codes in the documentation don't tell you why you might be getting a particular error code. So my only option is to call or email. I usually email first, if they don't get back to me soon then I'll call. Being a pain in the .... customer frequently is the only way to get any action to take place.

Another option is to setup a training session or multiple sessions. This can go a long way in changing the mindset of your customer to start thinking like you want them to think instead of their previous products' way of thinking.

Face to face training would be preferable. It seems that once people have actually met each other in real-life they tend to be nicer to each other.