Why it is a good idea to involve a development team in a customer support

Yurii Sekretar
ButterflyMX Engineering
4 min readSep 3, 2019

Customer satisfaction is the ultimate goal of any business. But how to solve problems or implement new features in ways customers love, yet work for a business?

Customer support is a division of a company which faces customers directly. Even with all of the monitoring infrastructure implemented — the end-customer will be the one who will experience any product bug or service interruption.

Usually to deliver a good and quality product it takes a lot of steps and people. A product team works to ensure value and viability of a feature, sharing the work among the team and working through implementation, QA, the resulting bug fixes and finally: deployment.

Unfortunately, in a lot of cases the same chain will happen when the bug appears on the customer side. A user is having an issue with the product, he is not satisfied, he calls or sends a message to customer support. The issue may or may not be reported to the quality assurance team, they will try to recreate it from the words of a customer support, and finally, pass it on to the product team with their own version of the bug. So at the end of the chain — the issue description could be misstated and (what is especially important) the initial bug environment may not exist anymore.

The worst

This is the point when a chain can become very long. If a customer support operator has standard instructions to answer all kinds of questions simply to get rid of the customer — all bugs, problems and suggestions from customers will go nowhere.

The usual

Most probably this is a case you have experienced yourself. When you talk to a support operator and explain your issue and even try to suggest how to change a product or add a new feature. However, at the end of conversation you understand the company is so big and, even if your discussion was recorded, chances that your input will be heard are very small. It does not mean that they will be lost or ignored. Rather, the usual approach is to filter, collect and accumulate. And only then to implement or solve.

The good

But what if that chain could be shortened? What if a customer could communicate directly to the creator — a software developer who built a product or a feature? In this case, a developer can get a sense of a real-world use case of his creation. He will put himself in the place of the customer and try to understand how a product or a feature could be used.

ButterflyMX customers expect high availability of the service as we attend to some everyday needs — opening doors to the places they live or work, as well as the successful delivery of their packages.

If the service experiences interruptions or if a newly implemented feature results in an awful user experience, we should react fast.

At ButterflyMX, we came up with the idea to involve software development team members in the support process when we noticed a gap between our reviews from customers and feedback from our development team. Customers were reporting bugs and interruptions of the services. Their user experience as reported in reviews was different from the experience we expected them to have. But from the other side, the product was well-built and tested by our software development and QA teams.

The problem was in our artificial environment we used to test and run our product or new feature before its release.

Usually software developers, when working on a product or new feature, just simulate a real-world use case. But in practice, what a user actually experiences could be different. It depends on how they use the product, what Internet connection they have, how many devices they have, even the timing of when the feature is used can play a big role.

Fortunately, we got this right in the beginning when our teams were small and customer support was able to communicate easily with the developers. Problems were directly transferred to the developers, using analytics and direct communications with the customers — bugs, misbehavior were determined, issues were recreated. Accordingly, developers would know what to fix and what to update.

With the growth of the company, we kept this approach and each of the team members participates daily in customer support. Everyone helps in reading all feedback and answering questions from the support team and suggest what is the best way to serve the customer.

We get tons of feedback every day from our customers, but we make sure that people who build ButterflyMX and people who use it are on the shortest chain possible.

--

--

Yurii Sekretar
ButterflyMX Engineering

I’m a professional software developer currently shaping the future of the smart intercom at ButterflyMX.