Stop Doing All Hands Support

This is going to be a controversial opinion. It's okay if you disagree. A lot of people do.

I think that companies should not ask or expect non-support team members to do all hands support. In fact, I think all hands support is a net negative to customers, companies, and support professionals. There are more effective alternatives that benefit everyone.

Let's get into the details

I'm defining "all hands support" as the situation where everyone at the company spends some amount of time working in support, helping customers directly. Everyone - finance, sales, engineering, marketing, managers, and executives - has to spend some time doing the work of a customer support agent - answering emails or phones or Twitter threads or whatever other channels the company uses. The company might require folks to work a few hours a week, a few days a month, or a week or two per year. Different companies implement it slightly differently, but the general concept is the same. Everybody at the company chips in and acts like a customer support agent for some period of time. This is different from emergency all hands support. For example, when a website goes down or there's a problem with a product that affects a large percentage of customers, a company may ask folks from other parts of the business to jump in and help support with the sudden spike in customer requests. Emergency all hands support is typically not planned, though it can be planned for. I also generally don't think you should be doing it, but that's a topic for a different day. Today we'll only be covering planned all hands support.

There are a lot of reasons a company might want to implement some form of all hands support. I've worked at and with several companies who have wanted it and the most common reason I was given was, "The CEO says we need to do it." While that's a valid enough reason for most people, I asked a bunch of CEOs why they wanted it and distilled all the responses down to three common themes.

1. Companies want to instill and reinforce a sense of customer empathy across the company. This is especially true as a company grows and teams that often felt very connected to customer needs now seem further away, often focused on OKRs and KPIs and other acronyms rather than the people using the things they're making and selling.
2. Companies also want more information about what customers are experiencing. By having everyone talk directly to customers, everyone gets a bit of a sense of what customers' pain points are - and what makes them happy! This gives people fuel to take back to their daily work, whether that's engineering or marketing or design. Having a visceral sense of what people want and don't want, love and don't love, helps them direct their work in ways that they may not have been doing before.
3. Finally, a lot of the people I talk to said that one of the key reasons they want everyone doing support work is to build empathy for the customer support team. That by seeing and feeling how challenging the day-to-day work is, other teams would be less likely to ignore requests coming in from the support team.

Those are, for the most part, laudable goals. I would like to think that we can all agree that having more data on customer experiences, and more empathy for the customer and for the support teams, would benefit everyone and therefore benefit the company as a whole. I just don't think all hands support is the best way to achieve those goals. And I think in some cases it actively undermines some of those goals.

Let's look at some of the issues with all hands support to see what I mean.

It's time consuming and expensive

Managing a rotating staff of new hires is a lot of work. Every time a non-support team member joins support for a day or a week they need some level of onboarding. It's time consuming for the support team, which takes away from the time spent resolving customer issues. Some teams account for this and staff up the team to make up for the loss of time. Some have specific teams devoted to managing the rotating cast of non-support members in the queue.

However you handle it, it's extra work and it's expensive. I'm not saying that a thing isn't worth doing if it's expensive, of course. But as I'll explain further, the project does not bring in a lot of value and it's expensive.

It lowers support quality

Customer support professionals have a specific skill set used for the job. They tend to be strong communicators and empathetic people - needing to read a person's level of understanding (and level of discontent) quickly and with little data and responding with the right information in the right tone and language. But that's only part of it.

Support professionals also need to have a general understanding of a large amount of the product, the business, the customers, and the current and past state of the support inbox. It's a classic "T-shaped" skill set with a very broad coverage of knowledge and a very deep ability to assimilate all of that information and use it to resolve problems quickly.

In practice, most people outside of the support team have not honed that set of skills. They also don't have the history of the work stuck in their memory that comes with doing support day in and day out over months and years. And it's that history and insight that is often used to make a customer interaction a success. Outside team members aren't bringing in that existing knowledge and don't often have the trained skills to bring all of that knowledge together to answer a customer's questions, to spot a flaw in the product, or to find a workaround to a known issue that hasn't been prioritized by the business.

Non-support staff can't recreate that consistent quality of help if they lack the holistic view unique to customer support.

It devalues the support team

Last on my list is my personal pet peeve. If this is the only reason you choose not to implement all hands support, I think it's a good one.

Conceptually, by asking everyone at the company to act as a customer support agent for the day, you are openly saying that anyone in the company can be a customer support agent with little to no preparation. An activity that is supposedly meant to increase empathy for the support team implicitly devalues the skills that those team members bring to the organization.

Several times when a CEO has asked me to implement all hands support at their organization, I have asked how they implement "All Hands Finance" or "All Hands Engineering". We don't do those things because we understand that those roles require unique skills and it takes time to hone those skills for the specific business. Asking someone to do "all hands account payable" for one week a year would seem both preposterous and dangerous. And I think the same applies to customer support. If we believe that support professionals bring a unique skill set and a unique value to the business, as I mentioned in the last section, then we should also believe that not everyone at the company can do that job successfully.

So we can see there are some issues with all hands support. It doesn't do a great job in meeting our needs and it makes some of our work more difficult and expensive. Let's talk about what we can do instead.

Alternatives to all hands support

First, let's remember what the goals of all hands support are.

We want to

1. Gather data about the customer experience
2. Build empathy for the customer
3. Build empathy for the customer support team

I'm going to suggest three things that will help us achieve these. However, they are not full solutions in isolation. I recommend implementing them in combination. All hands support seems like a great way to knock all of these out in one go, but that's idealistic. Sometimes doing things a better way takes a little extra work.

Team updates

This one seemed obvious to me until I started doing consulting work for support organizations. It surprises me how many support teams don't send out regular updates regarding the things they're seeing every day.

When a non-support team member works in the queue for a day, or even a week, they see a cross-section of customer issues. And often, they get excited to go solve the problems that they saw. However, since they were only there briefly they don't see the full picture of what customers are experiencing. So they might get excited to work on things that aren't, or shouldn't be, the top priority.

On the other side, we have the support team who does see the larger picture but may not be communicating it. We talked about support's skill at holistic assimilation. Support teams will often send bug reports or feature requests to other teams, but don't have a mechanism for talking about issues in a larger context.

I suggest writing a short one or two page summary every two weeks. It should include:

• Data on the inbound volume over that period of time, and if that's higher or lower than normal.
• Top five customer issues over that time. (or top three or ten… depends on your business and what makes sense for you)
• A couple of customer stories and quotes. Make the data feel real by using the customer's own words. These can be for good things, too. It doesn't have to be a customer complaining about that bug that hasn't been fixed in four years.
• An update on something that happened in another part of the company and how it affected the customer or the support team. Maybe the company released a new product that week and customer feedback was great. Or maybe people had a lot of questions about how it was meant to work with the existing products. Support work is inherently related to other work at the company, so use the space to show some of that.
• And lastly, your update should include a little blurb about the support team. What is the team doing right now? What are some near-term plans? Introduce new hires, talk about the team retreat, or maybe talk about the team's new process for filing refunds and how it's saving the company time and money.

I've heard nothing but overwhelmingly positive responses from bi-weekly support team updates. And in some cases, it has prompted other teams to start doing a similar sort of newsletter. I've seen them from Marketing, Recruiting, Design, from across the company. And it does a great job of bringing teams together and exposing cross-functional issues and potential solutions.

Export support data

In addition to contextual updates, make sure data from your support tools is getting to other parts of the company.

The data I'm referring to could be things such as contact rate, contact rate per product or per feature, volume of feature requests vs bug reports, etc.

In a lot of cases, these bits of information remain locked in your help desk or back-end tooling and only support sees them. So non-support people may only see them - or may only hear about them - when doing an all hands support rotation. I've seen this happen and it's been a revelation for people. I once worked with a product manager who had done a week of support and they were shocked to see what data was available to the support team and wanted to get more access to it for the rest of the product and engineering teams. In particular, they were fascinated that we could track the number of customer requests related to a specific feature they'd been working on. They had no idea this data existed or what it could mean, and they immediately start thinking about how it could be applied to their work and to other parts of the business.

There's no reason to keep this locked away. It's not always easy to get it out of the support tool, but it's important. Dedicate some time to getting support data exported to whatever tools are being used in your company. In my experience, it's best to export to the company-wide business intelligence tool - like Mode or Looker. That's where managers and executives go to find the data to make decisions around business priorities. Make sure your support data is in there alongside everyone else's so that your needs - and more importantly your customers' needs - are not left out of important conversations.

Shadow sessions

Finally, let's talk about empathy. As much as I hate to admit it, I don't think we're going to build empathy with data. I think non-support team members need to hear from customers directly to build empathy for customers. And I think they need to work in the shoes of a support agent to build empathy for support agents. But that doesn't mean we have to have everyone do the work of the support team. As I've already said, that's not realistic and assuming it's possible devalues the support team's contribution. Instead, I recommend shadowing sessions.

In a shadowing session, a non-support team member sits with the support agent and watches them work (it could be physically next to or over Zoom, it doesn't matter). The support agent goes through their normal operations and the shadower watches, reads, and asks a ton of questions. They don't need to respond to tickets or calls themselves, but they need to understand why the support agent is doing everything they're doing.

This does slow the support agent down a little bit, because they need to work out loud. But it isn't as slow as having a new person fully in the queue. And it gives the shadower more context on each issue. And more context on how a support agent resolves issues and responds to customers - how they assimilate all of the information they have in their heads and at their fingertips.

The key to making this work, I think, is to do it in blocks of about 4 hours. About half a day. More than that and everyone gets a little exhausted, less than that and you're less likely to catch something really interesting happening. Because let's face it, some days in support are a couple of hours of boredom with one new and exciting thing thrown in once in a while.

All together

The goals of the company are to get more valuable data out of support and to increase empathy, both for customers and for the support team. All hands support is not the magical process that gets this done. It can actively undermine some of these goals.

Instead, we can achieve these goals with a combination of tools and processes.

1. We can write bi-weekly updates for the rest of the company to give them context and a deeper understanding of what the support team is seeing from customers.
2. We can export support data from our tools into the tools used by the rest of the business to make strategic decisions.
3. We can invite non-support team members to shadow a support agent for a half day at a time, to see what support sees directly and to understand how we do our jobs.

In the end, I think this results in better data across the company and more empathy for customers and for the support team than any implementation of all hands support I've seen.

If you need help convincing your CEO I'm happy to tell them directly.