Why All Hands Support Didn’t Work for Our Company

There’s a concept in the tech world  called all hands support. Not sure if it could be referred to as new, but it’s getting a lot of attention lately from CEOs and managers. It’s the idea that everyone on staff—developers, designers, management, everyone—has to spend regular time in support answering customer tickets.

There’s some great (perceived) benefit here. Mostly that members of the product teams get a firsthand glimpse into real customer pain points and can turn around and fix those issues ASAP.

Can designers and developers truly understand the scope of customer issues with just a day a quarter answering tickets?

And most importantly, are customers getting great service when their issues are handled by people who only do this a few times a year?

Try the customer support platform your team and customers will love

Teams using Help Scout are set up in minutes, twice as productive, and save up to 80% in annual support costs. Start a free trial to see what it can do for you.

Try for free

Too Many Hands in the Pot

All hands support assumes that customer service is such an easy job that anyone in the company can do it well. That is absolutely incorrect.

We hire members of our support team with as much care and consideration as any hiring done for engineering or design positions. These are empathetic individuals with top-notch communication skills, the ability to translate user frustrations into actual questions, patience for miles, and an infectious sense of humor. No surprise, not just anyone can do their job.

Our engineering team would never assume our support staff could fill their shoes for even a moment, so why should we assume that putting a developer in direct contact with a customer having billing issues would yield a better result?

Will the developer learn something from that customer interaction? Surely. Will it be good for the company or product? Hopefully. Is it the best service for our customer who we value dearly? Unlikely.

And that’s my biggest problem with all hands support. It values what we can possibly learn about our product more than it values the people using our product.

Who Are We Making Happy?

We’ve tried a couple rounds of all hands support at Big Cartel, and all the teams seem to like it well enough.

The people building the product come away with a new respect for our support team and our users. Our support team feels validated and appreciates the extra eyes in the queue. There’s just one problem...

When I look at our customer satisfaction for those periods, it’s always down. Way down.

As I review some of the responses from our non-support teammates, I understand why. The rest of our team isn’t qualified to provide the excellent service that our users should expect from Big Cartel ,  and that is (rightfully) disappointing to our customers.

What Are We Actually Learning?

All of this might be worth the headache if we were actually gaining a deeper understanding of our customers across departments, but I don’t believe support emails are the best (or even a good) way to get valuable customer input on UX, marketing, and many other cases.

Sometimes we get great feedback from the support queue in these areas, but it should never be treated as the primary resource for this information.

No user of a product wants to write into a support team with an issue—sometimes the person’s feedback is skewed by their own crummy day, their own expectations, their own technical issues. We’re not getting the most valuable feedback in emails that come to support because of many external factors.

We recently launched a new page in our admin for customers to try out, and we got an email from one person who was upset at the changes we made. After some back and forth with our support director, the customer apologized for being so quick to judge and offered some praise for the changes. He was then able to provide more constructive feedback on how he uses Big Cartel and how our changes affected his work-flow.

I firmly believe that a designer who answers support tickets a few times a year would not have been able to have that same valuable conversation with our customer simply due to this not being their job or skillset. Because our Support Director handled this conversation, our customer is now happier and feels heard, and we have practical, valuable feedback to provide our design team as we work to improve the feature.

Bridging the Gap with Communication

What’s the solution then — how do we let the people building our product better understand user problems, without letting them loose in our support queue?

At Big Cartel, this is done through a lot of regular communication, primarily between our support and dev teams. Each week, Big Cartel has an on-call developer who handles outages, meltdowns, and generally keeps Big Cartel alive should anything break in the night or on a weekend. That same on-call dev spends a lot of their week working on bug fixes, slack projects, and (most importantly) helping our support team. They work with support, behind the scenes, handling tech issues that we come across. They hang out in the support Slack room getting really immersed in our ticket issues (and inside jokes). This allows developers to quickly identify bigger problems, easy bug fixes, customer pain points, and gives them the information required to better prioritize development work.

We’ve also started doing some specialized feature/builder support — for example, if we launch a new theme for our stores, then the person responsible for our themes will handle those initial support inquiries. Developers and designers tend to offer a different (better) level of support when they are speaking to a customer about their own project that they’ve poured their heart into. This is just a temporary period while bugs and minor tweaks are worked out, and once the feature has been through the customer ringer — all tickets go back to our awesome support team.

Getting Better as We Go

It isn’t a perfect process, and we still need a better way to get our design and leadership team more regularly involved — but I’d rather leave them in the dark a bit if the trade-off is at our customer’s expense. For now, our support director keeps the leadership team informed of support concerns in our weekly meeting. Her voice represents customer issues when leadership works on our product roadmap, deciding what gets built and when. She works with our creative director to get user concerns to our designers when needed — although this has recently evolved into a more regular conversation between our designer team and support team as new features are designed with our customers in mind.

In the end, this process keeps our customers in contact with our trained and empathetic support team, offering them the highest level of support we can. It keeps our product teams involved through lots of communication and hands-on support, but keeps their talents in their own specialized field.