A classic customer support dilemma faced by small teams with nascent products is in deciding whether or not they need a dedicated person for handling support. In the initial days of a product, it is important for stakeholders and developers to handle customer support because it helps them understand how the product gets used by customers and prospects. This understanding feeds into the development process. However, as the product usage scales, customer support requirements scale, thus making it difficult for developers to manage customer support effectively along with product development. Handling customer support would mean unpredictable interruptions in the developer’s schedule that could affect project deadlines.

At SupportBee, until recently, customer support was taken care of by developers splitting their time between development and handling support. There are two immediate advantages in this model:

1. You save on hiring a dedicated customer support resource.
2. You save on time that takes to train such a resource.

The reluctance to hire a dedicated resource also comes from the argument that certain tech requests or questions can only be handled by developers in which case a customer support resource only becomes a barrier who delays the delivery of solutions. At least that is the case until you can setup an infrastructure (like an admin portal or readymade scripts) for a non-tech person to handle common issues like resetting passwords.

Why we moved our developers away from front line support

Though the hybrid model worked out fine for a while, it started becoming counterproductive when developers had to handle more than a handful of requests per day, per developer.
Here are two important reasons why we decided to hire a dedicated support resource.

To reduce response times

In a hybrid role, developers are constantly juggling between support and development. To manage their productivity, they would reply to support requests at specific intervals of time.

As Nisanth from SupportBee’s development team explained,

“Programming productivity demands uninterrupted stretches of work hours. Most developers need a length of time (usually around 3-4 hours) that is free from interruptions to find their groove for finishing the task at hand. This means that developers who are also assigned to take care of customer support are likely to check support emails at specific times of the day. For example, I check support emails before starting work, during midday and before closing work. Developers tend to have some schedule like this to manage their programming productivity.”

Our response time for support requests was around 1-3 hours depending on how developers fit support into their schedule. Such high response times may not be acceptable for companies that have service level agreements with their customers or will it work for companies that have strict guidelines to ensure customer satisfaction.

To keep up developer morale

Developers are not usually trained to handle complaints from frustrated customers. Software development is in itself a very intensive job, hence, even the occasional unpleasantness in interactions with frustrated customers tend to have a negative effect on the developer’s morale.

Developers handling support - How it helped us

Though the reasons stated above were important enough for us to hire a dedicated support resource, we still involve developers in support through a scheduled weekly rotation because it has helped us immensely to do so. Here are some reasons why we believe it is productive to get developers involved in customer interaction.

Handling customer support gives new hires a head start

For newly hired developers, interacting with customers and solving their problems is the fastest way to understand the product and its inner workings. This is because, without customer perspective, it is tough to comprehend the product in its entirety with all its use cases.

Apart from helping developers get up to speed with their understanding of the product, customer interaction gives them an opportunity to grasp the impact of development decisions and software design while exposing them to company’s philosophy on customers and product roadmap. This understanding is the key to better engineering, and is the most important reason why everyone in the development team, at least in their initial days, should be handling customer support.

Developers troubleshoot technical problems faster

Technical support requests usually involve a lot of “to and fro” between the support team and developers before they get resolved. Having developers interact with customers directly without the barrier of a non-technical customer support resource means that customers will receive timely, detailed and accurate responses to such queries without
delay, thus resulting in a better support experience for them. Also, if developers come across issues over and over, they are more likely to prioritize and find a permanent fix for common complaints which in time will reduce the volume of customer complaints.

Customer interaction gets developers emotionally invested in the product

Though this is hard to quantify, our experience has shown us that developers who also handle customer support care more about the end product. A developer’s sense of purpose is derived from the knowledge that the software he/she develops has an impact
on people’s lives. Interaction with customers reinforces the knowledge that their work is meaningful. Without that feedback, all of their time and efforts go into a black box, and they never find out the true extent of the impact of their work.

Our verdict

When your company is small, and your customer support requests are proportionately small in number, it’s best to have your developers pull double-duty by also answering customer support requests. Furthermore, when your company is new, each customer’s feedback goes a long way in understanding the product’s various use cases. But, when your company scales up, and you have enough customer support requests to employ someone full-time, it’s better to keep your developers mostly on development, only giving them a few hours of customer support duty per week, or when there is a particularly difficult support issue.