teamwork

All-Hands Support is a trendy concept in the SaaS support. All-Hands Support is the idea that all employees regularly spend time in support answering customer tickets. This includes developers, designers, sales, marketing, IT, management, everyone.

A quick Google search of “All-Hand Support” returns a solid four pages of relevant content. These are mostly blog posts about how All-Hands works at various organizations.

However, there is a recent trend away from All-Hands Support. Many recent posts about All-Hands are from companies that tried All Hands and found that it didn’t work. Further, my colleagues and I have heard similar rumors in various support communities. Organizations that were All-Hands Support champions are no longer doing it or have implemented a modified enough version that it doesn’t qualify as all hands.

In this post, I will cover the benefits that most companies site as a reason for implementing/continuing to do All-Hands Support. I’ll also cover the common challenges that companies that have either tried or are doing All-Hands Support site. Finally, I’ll cover alternatives to All-Hands Support that mitigate many of the challenges but allow you to glean many of the benefits that make All-Hands Support popular.

Benefits of All-Hands Support

After reading through the All-Hands Support content on the web, I’ve identified four main categories under which the benefits of All-Hands Support fall.

Customer-Focused Organization and Product

All-Hands Support leads to a customer-focused organization and product. When all employees interact with customers, everyone has a better understanding the user’s experience. This is thought to be particularly beneficial when it comes to developers. When developers learn what is broken, they’ll fix it a straightaway. When developers learn what is confusing, they’ll build a better product in the long term.

Product Knowledge

Support representatives often have the most comprehensive knowledge of the product. Because your whole team touches the product in All-Hands Support, your whole team touches the product, everyone has a better understanding of the product and where it can be improved.

Culture

There is also a cultural component to All-Hands Support. When everyone helps, this builds empathy into the organization’s culture. Helping is rewarding and fulfilling. And a helping culture boosts morale.

Better Support

All-Hands Support can be remarkable. Developers learn about bugs and promptly fix them. You have multiple teams thinking about how support can be more efficient; internal tools get built, pain points get smoothed out, etc. Further, support teams learn from their more technical colleagues how to handle more technical requests.

Problems With All-Hands Support

The first article I could find on All-Hands Support was from Wistia in 2010[1]. We’ve had enough time to learn that All-Hands isn’t necessarily a panacea. Some common problems have bubbled up in the 6 or so years that organizations have been trying out All-Hands Support

Many Employees Don’t Want To Do Support

Many, maybe even most, non-support employees don’t want to do support. For some, the idea of picking up the phone and talking to a customer is terrifying. Making people do something they don’t want to do – indeed something they weren’t hired to do – can mean sending morale plummeting. And if you let candidates know at the outset, it can make hiring harder.

Not Everyone Is Cut Out For Service

As I argued in a previous post[3], service is a skill just like programming is a skill. We shouldn’t assume that anyone in the company can do it well.

At SurveyGizmo we look high and low for candidates that have service in their blood, people that have cultivated a career in service. This is true of many SaaS companies who make it clear with job titles like  “customer hero, champion, devotee, etc.” that they’re not just looking for a warm body to pick up the phone. As Anna Brozek of Big Cartel so eloquently states:

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.

-Anna Brozek[2]

All Hands Support
All-Hands Support Challenges: Not everyone is cut out for service.

Everyone suffers when people that are not hard-wired for service are asked to do support. It can lead to a poor customer experience as well as burnout for the employee.

It’s Wasteful

It costs time and money to put non-support people in support. You’ll need to pay for more users in your chat and email services. Your support team will become less efficient as they spend time helping non-support employees with the ins and outs of tickets, chats, and phones. It also leaves employees out of the loop on their core responsibilities which slows projects down.

It Leads To Questionable Conclusions and Prioritization

Many posts that tout the benefits of All-Hands Support talk about developers fixing bugs on the fly for customers thus giving the customer exceptional service. As inspiring as this, is this the best use of a developer’s time? Certainly, it will wow that one customer; who will likely become a long-term, customer, possibly even an evangelist. But at what cost? Aren’t there other bugs that affect far more customers? Further, how many other customers do not contact you with issues?

We can do better by collecting data. Humans are notoriously bad at aggregating data. We tend to think that the things we experience or more prevalent than things that we don’t directly experience. This problem worsens when a frustrated customer is involved.

An All-Hands Support Flop

At SurveyGizmo we barely dipped our toes in the All-Hands-Support water. We did what we called All Hands on Deck (AHoD). The concept was that when 3 or more customers are waiting on hold, or a customer has been waiting in the phone queue for 5 minutes, the phones would go into AHoD mode. When AHoD mode was activated, calls to the support queue would ring everyone in the entire company, and the customer’s call should be picked up by any available SurveyGizmo employee.

The above picture is a SurveyGizmo Alumnus

AHoD was a flop for a number of reasons.

  1. Some employees didn’t have phones or their phones mysteriously disappeared (wink).
  2. Employees were reluctant to answer the phone. Phones are the hardest. For people who are scared of doing support, phones are the scariest medium.
  3. As a result of 1 and 2, AHoD burdened the select few who were willing to answer the phone.
  4. The calls were disruptive. Non-support employees were expected to keep doing their day-to-day job but drop everything to help a customer.
  5. Customers issues weren’t getting solved. Because employees just wanted to get back to what they were working on they focused on getting the customer off the phone rather than solving the customer’s issue.
  6. It was hard on support. Employees that were not experienced at helping customers would lean on support for help. They would chat the support heroes, who were also helping customers, asking questions. Support also felt guilty that they were not pulling their weight. They often refrained from taking breaks so the phone wouldn’t go to AHoD.
  7. Customers often received poor service. People who aren’t used to support aren’t as effective. Requests that should have taken a few minutes took hours.

Alternatives To All-Hands Support

Fortunately, our failure resulted in creative innovation.  We came up with better ways to create a customer-focused organization and product, improve product knowledge, create a culture of helping, but leave the support to the professionals.

Start All New Employees Support

Nearly all new SurveyGizmo employees spend at least some time in support. For most new hires, this has meant shadowing support for a few days. This could stand to be much longer, a couple of weeks to a month at least. When I started, I spent two months doing support and am glad of it. I’ve not done a survey, but I think a lot of people would like to have done the same.

Support Development / Customer Experience Development

Support Development was probably the single most successful All-Hands Support Alternative at SurveyGizmo. Support Development emerged out of our then support manager Marybeth Alexander’s desire to harness the coding skills of some of the support heroes. These support heroes were helping customers with custom solutions that demonstrated the ability to improve our core code base.

On weekends, support heroes could learn the ins and outs of our core application’s code. The began making improvements to core features that were ultimately too small for the core development team to take on. Their improvements were successful enough to eventually create a support development team that was initially comprised of 3 former support heroes. One of the support heroes even moved straight to the core development team.

The support development team worked on customer-requested improvements and bug fixes. The team grew over time. Some support devs moved to core development. Many moved on to other jobs outside SurveyGizmo. The team evolved into what is now our Customer Experience team which now owns a number of customer-focused metrics including our Net Promoter Score, the System Usability Score, and the percentage of active users that need help.

Whereas, the core development team owns the development of new features needed for us to acquire new business.

App Sanding

This task falls under the purview of the customer experience team but it worth noting separately. App sanding is a cool concept for improving users’ experiences that one of my colleagues learned about from a Wistia employee at UserConf (now Elevate Summit).

To quote Jeff Vincent, the sage who gave the talk:

App Sanding means finding places in our customer’s experience that aren’t quite right.[1]

The idea being that instead of answering the same question over and over because the application isn’t clear, just fix the application!

What is worth nothing here is that we empowered support to send this type of feedback. The Customer Experience team them tracks and prioritizes app-sand requests for the Customer Experience developers to work on. We took the app-sanding idea and ran with it. In an average week, we release as many as three app-sand improvements to the application.

 Feedback Survey

Finally, a feedback survey is one if the easiest methods for ensuring that your focus is on your customers.

At SurveyGizmo each user that logs into the application has a 10% chance of receiving a survey. Once they receive the survey, they will be eligible again in another three months. We get around 150 responses from customers each week. We use this survey to prioritize much of what we do.

Are You Doing All-Hands Support? Why? Why Not?

Have you tried All-Hands Support? Did it work for your organization? What does it look like at your organization? Have you developed modified versions of All-Hands Support? Have you implemented other alternatives? I would love to hear from you!

Resources

[1] https://wistia.com/blog/all-hands-support
[2] https://www.helpscout.net/blog/all-hands-support/
[3] http://servicerockstar.com/customer-service-career-is-respectable/
[4]https://blog.olark.com/why-we-do-all-hands-support
[5]https://zapier.com/learn/ultimate-guide-to-customer-support/everyone-on-support/
[6]http://blog.statuspage.io/all-hands-support


392601_2856971068781_2133367532_n Bri Hillmer is the Survey Sorceress/Documentation Coordinator at SurveyGizmo. An Ohioan at heart, bri wound up in Colorado by way of DC where she honed her skills in survey sorcery redesigning a fancy gubbermint survey that collected very crucial data on very weighty things. At SurveyGizmo she continues to use her powers of sorcery for good writing how-to documentation. Read more inspiring blogs from bri over at KnowledgeOwl. Find her on Google+ and LinkedIn. Check out her documentation at: Help and Developer Resources

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>