On the Rally Flowdock team, everyone does customer support. We don’t have dedicated support people. The people who respond to email@example.com are the ones who develop, market and lead Flowdock. This is surprising for many. We often receive requests to “pass this message on to the development team”.
Shouldn’t a software developer spend their time building a better service, not handling customer support? More generally, shouldn’t people spend their time on what they were hired to do, and not waste time doing support? These are common thoughts that lead to the creation of dedicated support teams, outsourcing customer support. We find this to be a detrimental, even dangerous practice. Having the whole team do support is crucially important for many reasons, outlined below.
Feel for Your Users
Increased empathy for your users is the most obvious benefit. There’s no better way to understand users than by having a constant line of communication open with them. Even if you dogfood your own product (as we do, heavily), you’re still looking at it from one perspective. What seems like a minor bug may be extraordinarily frustrating for some, while a small new feature can be tremendously beneficial for others.
Having the whole team interact with customers leads to a surprising benefit: a shared understanding. We rarely have disagreements about what we should work on next – the team simply knows which features will provide the most benefit for our users.
Communicate with the Ones Responsible
When you’re solving a problem with a user, you often have to dig into parts of the product that you aren’t familiar with. You might have intricate knowledge about how your product’s integrations work, but be clueless about the signup process. When you start helping a user who is having problems signing up, you force yourself to expand your expertise. This leads to everyone on the team having a better understanding of the product as a whole.
This is great for users as well. When they have an issue, the foremost experts on the product – the people who designed, built and thoroughly understand it – are the ones answering. Instead of having to look for answers or delegate problems (aka. handovers, see below), the responder often provides a knowledgeable answer, quickly. And if not, they can ask for help in the team’s flow.
We’ve received lots of positive feedback about our customer support. Users appreciate being able to talk to the ones responsible for a product.
Chat as a Bug-tracking System
Unless a lot of effort is spent grooming its contents, the value of a formal bug tracking system decreases over time. The volume of bugs that are no longer relevant grows gradually, making it harder to pick out the important ones.
Our current process for handling bugs is lightweight while still ensuring that important and easy bugfixes get delivered. When we encounter a new bug, a quick triage takes place. If the severity is high, it’s fixed as soon as possible. The bug is reported in our flow with a#bug tag and a @mention of the person who has agreed to fix it. Once fixed, the #bug tag is removed. Low severity bugs with trivial fixes are fixed right away, while the rest of them are mentioned in our flow. If a low severity bug starts affecting many of our users, we will see more mentions of it, increasing its severity.
Because the development team handles support, this type of lightweight bug handling is possible. Customer support is an important input when assessing the severity of bugs – important bugs will rear their head via support messages.
Finally, not having a dedicated support team removes at least one handover. When a support person handles a case by escalating it to a developer or team, they can (correctly) feel that they’ve done their part without actually resolving anything. This is in no way the fault of the support person – they’re acting as they should. But it’s an indicator of a badly designed system.
If you design your customer support system to include handovers – points at which responsibility is absolved – you’re setting users up for disappointment. In addition to delaying resolutions, each handover throws away the rapport that was painstakingly built between a user and a support person.
There are, of course, situations when a handover is necessary. An example is when a team member is unable to fix a reported bug by themselves. We’ve tried tackling this by making the original responder responsible for finding the person to take over the problem – hence the @mention that gets added to the bug report in our flow.
Scaling Support Without a Support Team
Since our user base grows at a faster rate than the Flowdock team, this presents a problem: will we be spending too much time handling support at some point? We could hire people to take care of the so-called level 1 support cases.
Unfortunately, this might take away most of the benefits outlined above. Easy support cases are our background hum. They don’t take up a lot of the team’s time and effort, yet provide us with valuable insight into our users: what aspects of Flowdock they love and which features are causing confusion.
We haven’t come up with a silver bullet solution for this challenge. The end result will most likely be some sort of hybrid approach, with the Flowdock team still continuing to handle support. In addition to scaling support, having dedicated level 1 support people does provide a few other benefits: easy issues are handled quickly, on all time zones.
For now, we will continue handling support ourselves while building a user-friendly service that is as bug-free as possible, minimizing tricky support requests. When the scalability of our support becomes an issue and forces us to evolve our process, we’ll be sure to share the outcome on our blog.
Flowdock team members in snowy Helsinki
This post originally appeared at the Flowdock blog.