A long time ago I was working in customer support, spending my days speaking to unhappy customers who had purchased some sort of electronic device. People generally didn’t pick up the phone to tell us how pleased they were with their purchases. Sometimes they would call to ask for a technician, others to ask how to properly use their machines. And of course, there were the ever fun moments of somebody simply yelling and venting about their faulty product.
Writing tickets about these incidents addressed to the company, I was wondering about things like “Don’t they see that step x of the manual doesn’t work?”, “How hard is it to make a note telling us how long it will take to be fixed?”, “No, YOU tell the customer that it is normal for the machine to make a buzzing sound, loud enough to be heard next door”.
Years later, working on the other side in a development team, I thought about my frustrations from my customer support years. The last thing I wanted was to make the same mistakes I had been complaining about. So, here are some of the measures we put in place to get the most from the customer support’s expertise and knowledge and to enable them to provide better solutions for our customers.
One backlog to rule them all
All issues coming from customer support requiring technical assistance were logged in the development backlog. The only thing that distinguished them from a “normal” internal bug ticket was that they were marked with a “support” label. Filtering on that label made it easy for the product owner to assign priorities to them or even turn them into new features. Another benefit of having support tickets in the development backlog was that it improved the transparency of the efforts put in developing new functionality versus fixing existing issues.
Make backlog accessible to support
We gave customer support access to view the development backlog, so they could follow the resolution of their ticket. Instead of having a generic comment on their plate like “working on it” or “TBD” they could see the priority given to it as well as the work it took to fix it. The more details you have on the history trail of the fix, the easier it is to convince the customer that their problem is being addressed. Urgency is perceived differently by customers than production teams.
Support ticket – Handle with care
We agreed that support tickets needed to have a higher degree of information than the average bug ticket. If the ticket could be closed because the software “worked as designed”, we needed to point out where this was documented, so that the next time support could point customers to that. If it was not documented, we needed to provide solid arguments why the implementation made sense. When an issue would take long to fix or be addressed we needed to add some justification of our actions. Preferably, something that we wouldn’t be embarrassed to say out loud ourselves.

Analyse customer support requests
Besides the obvious bugs that people reported, we took time to analyse the issues that customer support handled on the fly and never reached development. If people would call for the same problem over and over again and support would help them solve it over and over again, why not take care of it and make everybody’s life easier? Besides that, closed support tickets sometimes contained excellent features ideas. Customers might not actively get in contact to request a feature but might drop an idea or two while waiting for their problem to be fixed.
Keep support in the loop
One of the worst situations that you can get in as support, is to have a customer ask you questions about a feature you are not even aware it exists. Sometimes you can swing it with a “please describe to me what you see” and then hope you can improvise something based on previous functionality. To avoid this situation, before releasing a new feature we would first enable it for our support (we had toggle switches in place) so that they could try it out and be ready for customer questions. We also asked them to note down anything positive that the customers noticed to have a better understanding of what people like. As a bonus, their feedback provided a good usability and acceptance test.
Respect customer support
If you measure your product’s quality by customer satisfaction, you probably want to have the people that talk to your users feeling respected and valuable. This is especially the case when customer support is outsourced and doesn’t have an invested interest in your product’s success. Take the time to listen to the people that deal with the end users of your product and learn from their experience. Give them a channel to communicate the difficulties they face and what they need to improve their work. Create an environment of trust so that they can provide an honest feedback to you and how you handle your support requests.
Nowadays, we would have more automation in place to improve our customer support. Maybe training an AI system to triage tickets or to even provide automatic responses to common requests. To extract behaviour patterns from existing tickets and help define new features based on them. But will customer support be completely automated? Forrester’s top customer service trends for 2018 sees a decrease in the number of support agents employed, nevertheless predicts that there will still be a need for highly skilled professionals to handle difficult customer issues. So improving the collaboration between customer support and your development team to create super agents that care about your product might not be a bad idea after all. Heck, they will be the ones that your AI system learns from.
2 thoughts on “Have you Tried Turning it Off and On Again? – Appreciating Your Customer Support”