In many ways, Richard Branson could be the world’s most famous customer support rep.
His willingness to relate to customers—even by dressing up in a flight attendant’s outfit and serving drinks—reveals a very important, genuine belief that Branson has about quality service in business: “It’s everything in the end.”
More specifically, he believes that truly knowing and understanding your customer’s entire experience should always be a priority.
His sentiments are echoed by the likes of Jeff Bezos, who famously said that everyone in the company should be able to work in a call center; in fact, the top brass at Amazon all do exactly that.
Why might this perspective on customer service be so important? Why should the entire company be involved in the support process?
Because it allows everyone to feel the customer’s pain.
Putting your whole team on support
The customer support team is at the forefront of handling customer issues. They’re the ones first confronted with customer issues, feature requests, and problems with the product. They’re the ones who apologize to customers and get the deepest experience of a customer’s needs.
All issues are then collected and handed over to the development teams to improve or fix.
Why is that beneficial?
Everyone can (and should) ease the customer’s pain
With developers in particular, there’s a common question that arises when the entire company is encouraged to be involved in customer support.
Shouldn’t developers be writing code, shipping new features, and fixing bugs? After all, they’re an expensive resource, and their time is much better spent improving the product rather than talking to customers, right?
But how will developers know best what kinds of problems their code solves and creates? It’s common for that type of feedback to be distilled first through customer support, then through product management and project direction, until it finally ends up on a task sheet for the developer.
Feeling the pain your code (or design) creates first hand is an invaluable experience compared to just getting a list of a tasks to fix or improvements to make.
Hearing a customer complain directly to you about something you’ve built creates a sense of ownership and obligation to the product.
As it should. This obligation can immediately be turned into positive energy. Hearing these issues directly gives developers or designers more urgency to fix or improve them, and it gives them a better understanding of how to fix them.
The same is true for missing features. While product roadmaps handed down by management are useful tools, asking customers directly what kinds of problems they’re having is incredibly powerful in determining new features.
Each member and every team needs to trust each other beyond just doing equal shares of customer support; they need to trust and support the idea that everyone can be a driver to move the product forward.
Empowering the team
When the entire team participates in customer support, it gives an incredible sense of empowerment for each member to make decisions about what needs to be done.
It also empowers the team to hold one other accountable, as everyone has better exposure to certain problems. People can huddle together to work collectively on fixing issues and small teams can form as needed to tackle specific problems.
If something is important to you because it seems important to a number of customers, the ball is in your hands to fix the issue. In that way, customer support can become a driver for product development.
How do you optimize team resources for customer support?
At Travis CI, one of our core company values is that everyone plays a role in support. As a small team, initially we threw as many of our resources at customers support as we possibly could.
As we grew, this turned out to be rather chaotic. While everyone jumping in on customer support was great, it lacked a bit of structure as the team grew. We found that other work got overlooked as everyone was waiting for that next ticket to come in or for the next customer to pop into our support chat.
So we brought some order to this chaos. Instead of having everyone ready to jump on support, we now rotate through the team on a regular basis.
Each day, a different person is responsible for handling the first line of support. This person’s focus is responding to customer support tickets, possibly fixing any issues that can be fixed quickly, and improving our documentation and our support tooling.
This person’s focus is more than talking to customers: it’s to make handling future customer issues easier for both parties.
Make it easy for everyone to do customer support
There was one more hurdle we had to overcome. Our product is focused on developers, on running builds and tests for their code projects and products. Not everyone on the team can handle every problem in the same way.
When people who have less exposure to the technical side of things rotate in, we make sure that others are around to help out with more complex issues.
But every single issue triggers thinking on how we can make our product easier to figure out and easier to fix. Support tooling has been essential for us. When everyone is on customer support, everyone needs to be able to access relevant data for a customer, their projects, and their builds.
Before we instilled support rotation, most data access would happen by opening a console. That approach was prone to errors and it prevented less technical people on the team from accessing the same data.
So we took two weeks to build support tooling through an application that everyone can access and that enables everyone to do the most common tasks. As new customer issues are added and new things accomplished by the support person of the day, the tooling improves step by step, benefiting everyone helping with future customer issues.
It instills the trust that each member of the team can figure out which issues are important and which ones need fixing as soon as possible.
Empowering people to solve problems, together, is what business is about, after all.
