Providing Better Customer Support
It helps to have developers involved
As a business grows, the number of customers increase and the number of issues those customers have increases. The founders can no longer do all the customer support themselves like they did when the company was less than 5 people. A customer support team has to be built out. A ticketing process is created. Conditions are set for escalation to the development team.
This all sounds organized and clean, but numerous issues pop up. The biggest ones are seen by B2B businesses.
The first is that B2B use cases are by their nature uncommon outside of being a business that uses that product/service. You don't use Salesforce in your personal life. Salespeople use Salesforce. You don't use Netsuite for your personal finances. Accounting teams at big businesses use Netsuite. Those salespeople and accountants are unlikely to switch careers and join your customer support team so most people joining that team don't have prior experience with your product. They need to be trained. What's a good amount of time for that? 1 week? 2 weeks? 1 month?
I've never seen a training period longer than 2 weeks before they are expected to start talking to customers. Compare that to customers who have been using your product, or a competitor's product, for years and you have people on your support team with less product experience than the people they are supporting.
This leads to the second problem. Your development team also has less product experience than your customers. That can create a disconnect between what they intend and what customers expect. It is guaranteed that you will eventually get calls to your support team from customers who claim something is a bug when the software functions as intended. What happens then? The person on the support team is unsure of what to do, so they file a bug ticket that escalates to the development team. A developer will look at it eventually (maybe). Now you hit the problem that most B2B systems are large enough that no single developer will know all the requirements. That means the developer that looks at that ticket may not realize that everything functions as intended by the developer who built it. It can sometimes take hours of debugging for that realization to kick in.
You've spent a lot of time on all this and still have an angry customer. Awesome.
Now comes the third problem. Support is rarely put on a roadmap. Handling customer support is usually accounted for when planning development tasks, but things often fall behind in development. The result is that any time spent on support at all makes it less likely for a developer to complete their planned work by the time their boss expects it done. Any support ticket is treated as if it is in the way of the "real work". The support team feels like they're often being ignored. The development team complains how often they get interrupted from the support team. The resulting office politics can take many forms, but rarely are they productive.
None of these problems can be solved with a new process or a different ticketing system. They're solved by getting people to actually talk to each other.
The way that's worked for me is having developers go on support rotations. Every week, a different developer on a team pairs with someone on support for a bit (e.g. 2 hours). They go through the gnarliest customer issues together. If all we cared about was solving specific customer issues, this would seem like a waste of development time. This isn't done to just solve customer issues though. It has a host of other benefits.
The first is training for the person on the support team. Pairing with a developer will give them insight onto the design of the system and how things are intended to work. That will make up for the gap in product experience between that person and users. This will make them more effective at resolving every other customer issue on their own. They're happier because they're better enabled and customers are happier because their issues are more likely to actually be resolved.
That benefit results in better classification of issues escalated to the development team. Instead of dealing with a host of bug tickets that were actually misunderstandings, the tickets get flagged as feedback (which actually gets looked at hopefully). The development team is now spending a lot less time on support than they were before, even when you account for the time being paired up.
The development team also builds a better intuition about how people use their software. Software requirements end up being better because of this understanding. Developers also make a ton of micro-decisions that are rarely covered in requirements, such as error logging or loading states. Those decisions are now better aligned with providing a better product to users.
The only downside that I've seen is that the people on your development team may be resistant to the idea. From the faces interviewers make after I talk about this, I'm pretty sure I've lost numerous job opportunities because of this idea. Yet, it doesn't take long to see the benefits. Your team will find that things run smoother after a couple months of support rotations, sometimes sooner. Find a way to overcome this initial resistance and you'll end up with a better product, better customer support, and happier users.