All Hands Support

And why it just isn’t for Big Cartel

There’s a concept in the tech world — All Hands Support. Not sure if it could be called 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.

But if the main problem is that the people building the product don’t know what customers’ issues are, is All Hands Support really the best solution? 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 tickets are handled by designers and developers who only do this a few times a year?

All Hands Support assumes that customer support is such an easy job that anyone in the company can do it well. I’m here to say that is absolutely incorrect. I hire members of our support team with as much care and consideration as any hiring done for engineering or design positions. These are highly empathetic individuals with amazing communication skills, the ability to translate user frustrations into actual questions, they have patience for miles, and a great sense of humor. They are a highly skilled team, and not just anyone can do their difficult job.

Our engineering team would never assume that 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 that 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 user 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. I’m just not okay with that.

We’ve tried a couple rounds of All Hands Support at Big Cartel, and all the teams seem to like it well enough. Folks 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. Yet when I look at our customer satisfaction for those periods, it is down. Way down. As I then review some of the email responses from our non-support team, I understand why our customers aren’t satisfied. 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’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 that handles any 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 customer service when they are talking to a user 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.

It isn’t a perfect process, and we still need a better way to get our design and leadership team a bit 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, as the Support Director, I keep our leadership team informed of support concerns in our weekly meeting. My voice represents customer issues and the support team when leadership works on our product roadmap, deciding what gets built and when. I work with our Creative Director to get user concerns to our designers when needed — although I think this will soon be evolving into a more regular conversation between our designers 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.