All businesses need to service their customers. Software testing tool vendors are no exception. The difference is that the customers in this (our) case, are testers – those whose profession is to improve software, and in the process, find bugs and issues. This can hurt sometimes :-)
However, as we have written in a few previous posts in the past (here and here for example), we try to turn this into an advantage rather than view it as a problem. Our customers and users are perfect for helping us make our products and our test management solutions better. Not only by finding bugs (and reporting them so professionally, ready for fixing…) but also by supplying a stream of new ideas, feature requests, and new development paths. We encourage it, give it the platform and train our support team to embrace it.
Support is not just answering questions
Our support process, and the team that makes it work, are something we’re proud of and has a great proven track record. We’ve had a few posts about our approach (going back to our first years with this post, and also this one, through the years until 10 years after).
Communication with users is not just handling questions and complaints. It’s about working together to create a better software solution, by fixing bugs reported, by guiding and assisting, to achieve the best implementation of solutions, and by engaging users to help us think of new ideas, future needs, and product design.
Actually, it is now a few years already, that most of the enhancements and progress of our test management tool, come from this line of communication. It isn’t always a direct feature request. It can be a question that makes us think, a bug that raises questions beyond simply fixing it. Even an approach to how to do something is a lead to re-visit that area and explore better ways of making it more intuitive and removing any need to ask for assistance.
For us the customer is always right is more the customer always teaches us.
What if the customer is all wrong?
Sometimes, however, things look different. A customer complains about a problem, and after a thorough investigation, we realize that the problem stems from their own misconduct. For example, a user gets really angry with data that went suddenly missing. We find out that one of the users in that organization, having the permissions (given by the account’s admin…) has deleted the data, or moved it to another location in the account. Sometimes, for various reasons, there’s no hard proof for this conclusion, that can be shared with the customer.
No one likes to be blamed for errors. Especially not when complaining and getting told in reply: “it’s your own fault”. We try hard not to go there, aiming to get things back to where they were, allowing the customer to move forward with what’s important – their work. This sometimes isn’t enough, depending on the direction it takes with each customer. Some will leave it at that, others will insist there’s a problem on our side.
What now? Simple. The customer may not always be right, but they are never wrong. That’s how we see it, and that’s how we deal with it. No arguments, no long threads with explanations (proving they’re wrong). Get them back on (testing) track, make sure things are stable again and move forward.