1. Library
  2. 1000 Tickets Per Day with 1 Support Employee

1000 Tickets Per Day with 1 Support Employee

Light Mode
The Problem in Doing Everything Yourself
Automating Support for Testers
The Evolution of Our Support Stack
Getting it Right
5 min

AtRainforest, our tagline is “never ship bugs to production again” and the way we do that is by employing an army of testers to help us serve customers like AirBnB, Zenefits and Meteor. After two years of strong customer growth, our tester community was at 5000 unique testers per day. The only problem was that we were handling support tickets from these testers on an ad-hoc basis. We just couldn’t deal with the volume and tester churn was starting to become a real issue for our business.

The Problem in Doing Everything Yourself

In the early days, my cofounder and I managed all of our tester support requests by email. But as our team and tester-base grew, we found that email was failing us in a couple of ways:

  • Siloing Information: There was no convenient record of support tickets, nor was there a way for an employee to pick up where another had left off.
  • Siloing Expectations: Users became dependent on specific individuals and there wasn’t a great indication of when there’d be a system-wide fix.
  • Erratic Response Times: Inconsistent response times meant that quality of service varied on a case-by-case basis.

Automating Support for Testers

As our tester-base grew, we received a much higher volume of tickets. Our testing community performs tens of thousands of small tasks daily. With an email system, it meant I was answering 700 tickets per day. Any early stage startup founder will tell you that this was time I couldn’t afford to waste.

All of this contributed to a terrible support experience for our testers.

So we assessed our biggest challenges and hired a human (Stephanie) to tackle a couple of our problems. We knew we needed to:

  1. Automate Responses: Most of our tickets fall into a few broad categories and most can be dealt with in an automated fashion.
  2. Standardize Docs: We needed to codify our documentation to ensure we weren’t continually rewriting and emailing individuals.
  3. Increase Cross-Team Collaboration: We needed greater visibility into all of our tickets; first to fix individual issues, and secondly to prioritize product changes.

The Evolution of Our Support Stack

When we first started fixing our support system we turned to the following for help:

  1. Middleman: A static site generator to manage all our support documentation.
  2. HelpScout: A shared inbox for collaborating on our support emails.
  3. Intercom.io: A helpdesk for your customers.

Each of these proved to be a good start, but as the volume of tester requests grew, the cracks began to show. We dropped the entire V1 support stack and replaced them with the following (which we’re using today):

  1. Zendesk: A higher level of support ticket threading allowed us to manage a larger volume of tickets and maintain a tidy queue. Unlike the earlier tools, Zendesk’s macros allowed anyone on the team to respond to common requests. Most importantly, Zendesk’s Help Center product replaced our homegrown documentation and enabled us to iterate faster against our support docs.
  2. Olark: This customer support chat app helps our team increase responsiveness, use canned responses to fix simple issues and decrease support volume.
  3. Customer.io: This tool lets us automatically reach out to users based on patterns of behavior that correlate to user confusion. This replaced Intercom because it lets us send messages in a more granular fashion.

Getting it Right

Regardless of the tools you choose, here are a few things we learned in getting our tester support process right:

  • Make it simple for users to help themselves. Create better, searchable and up-to-date docs linked to from the relevant parts of your product. Write new documentation every time a support ticket is applicable to more than one customer and socialize these new docs.
  • Make it simple for everybody on your team to help your testers. Pick tools that let you move fast and scale to your entire team.
  • Do more than just care about your users. Demonstrate that you care by being there for your users when they need you most. Guess what? That’s nearly always when they need support.

BIO: Russell Smith is the co-founder of Rainforest QA – a Heavybit member company – that gives you on demand testing of web and mobile-websites as a service; create tests in plain English and run them across major browsers with a single click. Russell also runs several popular meetups in San Francisco – the MongoDB Meetup, Rethink DB SF and most recently the Move Fast and Break Things Meetup. He’s on twitter as @rhs if you’d like to say hi.