Everybody helps: the evolution of all-hands support

All-hands support can be a touchy subject for customer support professionals. When you ask designers and programmers to reply directly to customers’ questions, doesn’t that imply that anyone can do our job?

At Basecamp, we learned the hard way that you shouldn’t expect other people to be able to do the work of your support team. The good news, which I shared at the Support Driven Expo Europe 2019, is that we’ve found new ways to leverage people’s existing skills into valuable work which helps improve things for our customers, our team, and the company as a whole.

If you’d like to learn more, watch my talk, “Everybody helps: the evolution of all-hands support”:

If this sounds promising, I have some tips on rolling out all-hands support at your company. And if you’d rather read my talk than watch it, click through to the full post.

Everybody helps: the evolution of all-hands support

I’d like to share how Basecamp has found new ways for people outside of support to help improve things for our customers, our team, and our company as a whole.

Six years ago, we launched what most of you would recognise as all-hands support. For one day a month, each person at the company would take a break from designing, programming, or whatever else they usually do to answer emails.

We figured that if people heard first-hand how customers use our products, they would come away with ideas for how to improve that usage, and would squash the bugs that get in the way.

We called the initiative “Everyone on Support”, EOS for short.

Our barrier to entry was pretty low. When we first launched Basecamp, our CEO would respond to all emails himself, so he didn’t have to be sold on the benefits of direct customer contact. And, as a remote company that relies on clear communication, we make sure that everyone we hire is a good writer. So we started off with management buy-in, and a group of people with solid fundamentals we could build on.

We scheduled everyone’s shifts, and paired them up with buddies on the support team who could help them find answers to customers’ questions.

We thought that Everyone on Support was something that we could just “set and forget”. We were wrong.

When I joined Basecamp a year later, I could sense some frustration and resentment among the people we were asking to join us in the queue. When I took over scheduling, I realised that I’d have to work out how to make that time more fun, more fruitful.

I decided to get to the root of those negative feelings, by messaging some EOS participants:

Eron, on Ops, told me:

I don’t think I’m very useful in the queue.

I just take easy cases that I don’t have to bug people about or spend a ton of time researching.

And it’s an interruption to the other work I have to do.

Jason, a designer, said:

The only thing I’d ask is that we always get to feel busy.

I’ve not enjoyed shifts where I didn’t seem to be needed.

Either the ticket load was light or the support team was too aggressive about grabbing everything out of the queue.

And, according to another designer, Kris:

It feels like “bring your kid to work day.”

I try to get through as many tickets as I can, but I never feel like I’m truly helping.

After speaking to people, I realised we were missing the mark when it came to what we’d hoped to accomplish.

But what exactly had gone wrong with Everyone on Support?

Well, first, we weren’t giving people the support they needed. When I started at Basecamp, I got 3 weeks of in-person training, followed by 3 months of feedback, before I was considered ready to handle cases on my own. Doing 1 shift a month, it would take someone 6 years to get to this standard!

And our EOS people were getting nothing like that level of training. We didn’t have any organised way to onboard them, or to give them ongoing support. And the busier we got, the less support we were able to offer.

Around the time I took over EOS, 2 support team members left, and we lost another to parental leave – just as we rolled into our busiest time of year. We were flooded with work, we didn’t have enough people to deal with it, and each support rep went from answering 60 emails a day to answering 150. With an average response time of 3 minutes, we didn’t have any time left over to answer questions from the people joining us on support.

And that’s why Eron was cherry-picking the kind of cases he’d dealt with before, not learning anything new, and feeling like he was wasting his time.

That busy period is when our team developed an unhealthy obsession with reaching and maintaining Inbox Zero. Even when our workload dropped off and we hired up again, we felt driven to reply to every email as quickly as we could.

Hence people like Jason being left with nothing to do.

Despite our best intentions, we were expecting EOS people to do our jobs, at our pace, without our training. And if they couldn’t keep up, they were doomed to feeling either useless or overwhelmed.

But, I asked myself…

Even if we could support people better, and shield them from the pressures faced by our team, should we be expecting them to do the same work as our support professionals?

What if, instead, we could use Everyone on Support to get people to do less of our job, and more of their own?

What if we could leverage their skills and expertise into truly valuable work that supports us and our customers?

So I put EOS on pause for a few months, to try and answer these questions.

I spoke to people in the support team and the rest of the company, and uncovered examples of customer-focused work they’d already done outside of the queue.

I ran a pilot scheme with Kris, the designer I mentioned earlier, during which we explored what we could achieve in a series of mock support shifts. We collaborated on a kind of farm-to-table product pitch, picking a requested feature, speaking to customers to get to the “why” behind the “what” they’d asked for, scoping out the smallest viable solution for this problem, and presenting it to the company.

And I pulled out parts of the training syllabus for new support hires and worked on documentation of my own, tailored to the unique position people found themselves in when they took part in EOS.

When I relaunched EOS about 18 months ago, I wanted to reset our ideas, and set some clear expectations for the initiative.

The key to this was a simple guide called “What Everyone on Support is (and what it is NOT)”, and this explained *why* we launched the initiative in the first place. Here’s what it told people:

Everyone on Support is a chance for each person to talk with our customers on a regular basis.

You’ll get a buddy from the support team to work with, and, together, you’ll spend a day helping our customers.

You’ll get to see how our customers use Basecamp, the questions they have, and the problems they run into.

Along the way, you’ll help to squash bugs, dig into ways to make our existing features better, and unearth promising new ideas.

EOS also helps us to prepare for the unexpected.

In an emergency, everyone at the company should be able to jump in and help answer emails.

We’re giving you a safe place to practice those skills.

It’s a useful training tool.

You’ll get to work on all our products, and help us support them ’til the end of the Internet.

And for folks in the support team, it’s a regular opportunity to build a bond and a working relationship with you.

Finally, Everyone on Support is a valuable reminder about why we’re all here – to help our customers.

Without them, the company, its products and our jobs wouldn’t exist.

That is, we want to create a customer-focused culture.

As well as explaining why we were asking people to get involved, my intro guide laid out some goals about *how* we plan to achieve those things:

EOS is not a way to bolster the coverage of the support team.

There’s no ticket quotas or targets, no pressure, no cracking of whips.

If we have a capacity problem, we’ll solve it with our own resources.

EOS shouldn’t be a chore.

We want you to learn, to fix, to glean insights – not to smash that queue headfirst.

If a programmer spends their whole EOS shift squashing a bug that’s been bothering us for a while, that’s a win.

And it shouldn’t be boring.

The support requests never stop, so if you find yourself with nothing to do, we’re doing it wrong!

Chat with your buddy, and they’ll help find something helpful to work on.

Here, I’m telling participants in Everyone on Support three very important things:

You have freedom. You’re free to join us on emails without the weight of expectations that the support team carries, and you’re free to stay out of the queue if there’s something else you’d prefer to work on.

You should feel empowered – to decide how to spend your time, and where to devote the very skills you were hired to flex.

And we’re going to communicate with you, to make sure you have something helpful to work on, and all the support you need to get going. Finally, we’ll make it safe for you to speak up if you feel like you aren’t getting what you should be out of the experience.

So, that’s the theory behind Basecamp’s new approach to all-hands support. But how does this work in practice?

First, we still require people to answer customer emails. But we do so intentionally, with some simple aims in mind.

Each person’s first two support shifts are spent in the queue with their buddy. The buddy will make sure people have access to all the tools they need to help a customer, and that they know how to use them. They also make sure that they’re striking the right tone in their emails, connecting with the customer as a human, and being as helpful as possible. And they’ll ensure that their EOS charge can help someone get logged in, a baseline requirement for everyone at the company.

After two email shifts, it’s up to people how they spend their EOS time.

They can work on anything they like, as long as that work will help our customers, or help the support team to help them, and can be scoped to a single working day, or broken down into day-long chunks.

We start each shift with a conversation about what the person wants to do or see that day, and end it with a discussion about what they achieved and learned. If they’re feeling uninspired, we have some suggestions for what to work on, with real examples that have come out of EOS. And, if none of that takes their fancy, they can jump back into the email queue, so the customers can open their eyes to new use cases, issues and ideas.

So that’s how Everyone on Support is now supposed to work. But is it working?

It sure is! I’d like to share some of wins we’ve had in the last year and a half, work that lives up to the expectations we outlined earlier:

First, we gained insights – about Basecamp’s customers, how they use our products, and how we can help improve that.

Basecamp has this feature called automatic check-ins, and we use that to share what we’ve been working on. People used to talk about how few tickets they’d resolved, and how bad that made them feel. At the end of their shifts they dwelled on the “dubious” distinction of their “all-time low” figures.

Now they talk about how much they learned while on support, focusing on the quality of their customer interactions, rather than the quantity.

A couple of highlights from our heads of product. Jason, our CEO:

I focused on feature requests.

Always a fun day talking to customers, hearing what’s on their minds.

Got some good ideas about groups and roles.

Ryan, product strategy:

Taking requests from people who haven’t bought yet is helpful for figuring out what we could better explain on the marketing site.

But those insights would be nothing if we didn’t do anything with them. In 2018, we made 30 (three zero) improvements for my team and our customers. Those changes included: Squashed bugs, updates to our products, pitches and explorations, and new and improved tooling for the support team.

A good example of this is some work that a developer, Zach, did on our iOS app. Recently, App Store review guidelines forced us to remove trial sign-up from the app, and we started to get emails from confused prospects who’d downloaded it and didn’t know what to do next.

Zach heard these complaints and wanted to do something to help. During a single EOS shift, he defined the problem, asked for the support team’s input, dug into customer conversations for insights, then pitched and deployed a solution. As well as redesigning the UI to make it clear what prospects should do if they don’t yet have an account, Zach set up a system to track signup issues, so he could test his changes and look out for other improvements to make in upcoming support shifts.

Changes like this are significant, because they show how, with EOS, we’re going beyond just answering customers’ immediate questions, to lightening their load in the long term, by clarifying, fixing and improving the things they’re bringing to our attention.

On top of all this, we’re much better prepared to respond to emergencies.

Last November, Basecamp experienced its worst code red in about a decade, during which our primary product was stuck in read-only mode for nearly five hours. That meant that hundreds of thousands of people weren’t able to work, and they wanted to know why – and when they would be able to get back to business.

While I was helping to coordinate our response, I headed to our emergency chat channel, and I noticed a message from Tom:

I’ve been replying to people on Help Scout. Hope that has been helpful.

Tom’s a developer on the product side. He held no responsibility for fixing the problem, or for responding to customers about it. But, because of EOS, he appreciates the work my team does, and feels empowered to step in and start doing what he can to help – without having to be asked.

And it wasn’t just Tom. While Basecamp got fixed, other developers were replying to emails, as well as designers, podcast producers, even our founders.

As Scott, a product designer, said:

You guys! You have our backs every day — it’s the least we can do.

And, now that we offer appropriate resources and support, Everyone on Support is a great training tool, for introducing new employees to the business, helping everyone get to grips with Basecamp, and reminding them of the legacy products we’ve committed to supporting until the end of the Internet.

Here’s what one of our newer hires had to say about that:

Great times buddying up with James and rocking some interesting puzzles.

Today I learned quite a bit more about Basecamp 2 and Basecamp Classic.

I’m Matthew’s buddy for Everyone on Support, and, with him on Ops and me on support, we’d only otherwise overlap when things go wrong. Because of EOS, we’ve built a working relationship far more quickly than we would have without it.

So Everyone on Support is bringing together people in different teams with different experiences. It’s one of the few formal ways we have at Basecamp to understand each other’s jobs better, how they fit together, and how that collective work serves to benefit our customers.

That’s an appreciation that Flora, a product developer, took away from her very first support shift:

It was good to be reminded of how many people use Basecamp and care about it.

I was impressed by how much our customers take the time to write a detailed explanation of what they’d like Basecamp to have.

The whole experience made me appreciate the work that the support team does even more.

At Basecamp, we’re in the privileged position of having no outside investors or shareholders to answer to. We decide what to work on, and when, which problems to tackle, and how. We don’t share our plans, don’t have a public roadmap, and we’re free to change, delay or scrap any work we’re undertaking at any time.

But that doesn’t mean we’re beholden to no one, it means that we only answer to our customers. By opening up a direct channel with them, Everyone on Support helps to close the gap between our plans for the product, and the customers’ hopes for it.

As well as helping to centre the customer in everything the company does, Everyone on Support has had other lasting effects on our culture.

To borrow a vivid phrase from Jeremy, our head of security, it’s helped the support team to infect Basecamp like a “merciless empathy virus”.

One of Basecamp’s company values is generosity, and working on support is the best way to put that value to the test. We’re constantly giving customers the benefit of the doubt, taking care to decode their requests and encode our responses in language they’ll understand, going the extra mile to anticipate their future needs, and doing so in a human and helpful way that will make their day go a little better.

On the support team, we try to model that kind of behaviour when working with each other. By inviting others into this generous working environment, we encourage them to practice compassion with each other as well, and that’s changed the company culture we’re all a part of.

EOS is where company values like being straightforward, fair, generous and independent, intersect with our support values of being human, empowered and responsive, and where all of that is put to the test. It’s where everyone at the company is encouraged to embody those values, to live them.

So that’s how we’ve taken all-hands support to a much healthier, happier, more productive place than it was two years ago.

Through all of this, I’ve learned the importance of:

• Dedicated resource: one or more people need to take responsibility for keeping an initiative like this running
• Clear goals: you shouldn’t ask people to do the support team’s job. Let them know what you do expect of them, and why
• Choosing your own adventure: give people the freedom to do the kind of work they’re interested in, and good at
• Celebrating wins: I regularly share customer feedback and the work people did, and summarise them in larger updates called “heartbeats”, the first of which included the contributions of literally everyone in the company! If you track results and celebrate people’s achievements, it’ll give them confidence in all-hands support
• Living your values: make sure that whatever you set up aligns with the values of the company and your support team.
• Listening: this is the only way I could find out what was wrong with EOS and how to fix it. I still have more work to do to make sure all-hands support works for everyone, and I’m going to start by asking them about it.

I’d love to hear from you if you’ve set up all-hands support at your company, or are thinking of doing so. You can hit me up in the comments below!