Supporting users for over 10 years, and communicating with customers regarding future plans, new features and their needs, has proved challenging but rewarding at the same time.
There are many ways to support users of your services and tools. Not only how it’s technically done (online, email-based in our case), but also – and mainly in our opinion – the approach, the attitude and therefore the rules and procedures, of this support.
We decided, when we just started many years ago, to try to help users in the same way we would expect providers to help us, as users of other services/tools. Setting this as the starting point of it all, helped us to agree that:
- We will not use automatic replies (developed now days to bots)
- We will tell the truth. Sounds obvious but it isn’t so to many vendors
- We will be proactive. No need to wait for complaints or bug reports if you know there’s a problem and can share the information with your customers and users
- We will be available 24/7/365. If someone works, we should be there for them.
10 years after
We believe we had good reasons to set these, and think it worked out well.
Automatic replies: We have people at our support team, our users are… people. Why not have a simple conversation? Just so the user will get an immediate meaningless reply? We reply fast enough, and then it is a real reply, with a real answer, or request for specific information that will help us to get that answer. The discussion is personal, the answers are better, the user gets what he wanted (mostly to solve his issue, and more than that understand what’s the issue and get information about it).
To get it does right we needed to make sure our support team is good at what they do (and they are), and that they get the best cooperation from our developers and testers (and they do).
Truth and transparencies: We tell the truth. It sounds simple and obvious but it isn’t. If there’s a problem, we share it with the user. If it will take time to fix the problem, we tell the user how long it will take (and not just ‘soon’, or false time table). We try to back it with optional workaround, temporary fixes and sometimes help the user directly in their accounts. And we give high priority to fixing and resolving users issues and reported bugs.
Same goes for requested new features. If we decide not to do them, we are not shy of saying so. We usually do add them though…
Proactive: If we know there’s a problem, a known bug, an issue with one of the servers, we will tell our community. We will not wait for users to find out the hard way. This goes together with the general transparency policy of Testuff.
Being proactive also means that we take questions, first answer or resolve the issue of course, but then we research them. This means we ask ourselves questions about these users queries, concerns and reports. We learn from them and can, in many cases, initiate a change, an improvement even before or without it was requested.
Availability: We have customers all over the world, which means different time zones, different working days, different holidays. Customers might have to work during a weekend as they have a tight schedule to meet, or they might have a problem and they stay late to work it out. We need to be ready to help – on anything related with our tools and services – in any point of time. So we are. 24/7/365.
Open communication line with users
Every company has support. Even the giants, like Google and Facebook. But their size is a disadvantage in this case, since it is impossible for them to really reply to users (too many), or communicate with them directly. But for companies of our size, this is an advantage. We can do it, and it has proved to be a benefit not only for customers (who get the attention and service they deserve) but also for us.
For many years now, our main way for creating our ever-changing, ‘agile like’, road map, is by getting ideas from users, mainly understating what they really need while working with Testuff. No need to guess and assume when you can simply ask, or better – someone tells you without you asking.
And it goes further. Any request for assistance is a source for a new look at that are of Testuff. If that question was raised, if that wasn’t understood or found without sending us a question, there must be a problem there. So we can use it to improve and not stop by just giving the answer to that specific user. If there’s one thing we learned, it’s that if one has asked then there are many out there that have the same question/problem and didn’t bother to ask.
As we wrote many years ago, communicating with customers is another way for creating better software. In our case, of users whom are testers, we get also another layer of testing for our products, on top of our own testing. It can be harsh and painful, but at least we get the reports in the professional way that makes it easy to fix :-).
Turning a mad-about-the-problem user into a ‘mad’-about-you user
The best is when an angry user, or a very worried one, contacts you with what they perceive to be urgent and a big problem. If you deal with it right (as we described above) you will find yourself with a happy user at the end of the story.
We learned that users, who were dealt with in the right way – and even if the problem is still not fixed – are more happy, satisfied and loyal users. People want to be heard, to know someone listens (not just hears) and is working for them. All the rest is a bonus.