Nov 15, 2012

Scaling Support for 2 Million Users

[Foreword from Ben]:  MailChimp has more than 2 million users and is currently growing at roughly 6,000 users per day. This growth curve started back in 2009 when we launched our freemium plan. Here’s what I mean:

That’s a graph taken from Joe’s post about our infrastructure. This kind of rapid growth can really screw up company culture, because it sends a tidal wave of new users to your product, some of them totally unfamiliar with your brand (see: “The Cruel Irony of Freemium” in this post). It’s not just the sheer volume that’s a challenge. Customers from all walks of life are joining now. Things were a little easier when we had mainly one type of customer to support (tech savvy web designers who spoke HTML fluently), but now we’re attracting e-commerce marketers, startups, business owners, consultants, bloggers, nonprofits, and on and on. This is a challenge for our design team, our dev teams, and our abuse team, but most of all, it’s a challenge for our support team. I’ve asked Bill Bounds, our head of support, to blog about this. [/ben]

Despite the massive jump in signups since launching freemium, our total support ticket volume has "only" tripled:

Our support team has done exceedingly well dealing with the increase in demand, in that we haven’t gone totally insane, caused any riots, or murdered any office printers. So, how have we handled everything?

Empowering Customers

On the product side, we make MailChimp a self-serve application that’s as easy to use as possible. For our customers, we work hard at all levels to make sure they have the tools and knowledge they need to get the most out of our app. If we didn’t focus on being easy to use and empowering our customers then we both would be walking a path toward frustration. It’s harder to teach a man to fish than it is to just sell him one over the phone. But we’d much rather feed you for life than force you to keep coming back for every meal.

Above all else, our goal is to educate and empower our customers, because it’s the customer who is completely in charge of their account and its success. In a way, it’s an investment. An empowered customer is less likely to need support in the future, and more likely to try and buy new features. In business jargon, we don’t treat support like a cost center. Which, we’re told, is very weird.

Empowering Tech Support

Some companies assign their customer service people to teams based on experience and seniority. We handle our customer service team members in the same way that we do our users: by educating them and ensuring that they have access to every tool they could ever need. We don’t like to create teams based solely on experience, because every member of the team should be able to contribute to a discussion with a customer at the same level. Educating and empowering our teams just as we do our users allows us to have an environment where traditional escalations aren’t needed.

Conversations. Not Tickets.

We don’t look at customer requests as “tickets that need answers.” Instead, Dan Kurzius, our company’s co-founder and Chief Customer Officer, says, “a customer’s question is our chance to have a conversation, an opportunity to empower.” If you have an issue, we don’t just help point you in the right direction, we provide a map with details of all your surroundings, potential pitfalls, and secret paths that take you to awesome views.

We don’t script anything. If we did, then we could probably reduce our average resolution time, but our customers would feel like they were talking with a robot. Thankfully, since we don’t treat support like a cost center, “resolution time” is a metric that means squat here. Not having a script lets us have a conversation with a natural flow so we can talk about the things that matter the most, even when that changes. The length of the conversation doesn’t matter. To do this, we need sharp, verbally agile humans in support. In fact, sometimes we keep on talking with the customer, well after the ticket is "resolved." Our staff has an endless supply of t-shirts, postcards, and monkey hats they can send to customers:

We don’t just send them if a customer has a problem, though. Sometimes, we send them when a customer makes us chuckle. Or, you know, just because. We have a small team that monitors social networks for customer conversations, and they update our team whenever they find stuff like this:






Training and Educating Staff

To ensure our teams are up to the task, we go through a rigorous, year-long education process about the app and how to support it.

Throughout that year, there’s a lot of training, shadowing, training, shadowing, taking live chats, training, shadowing… you get the idea.

This means we have to have people in-house, otherwise we couldn’t properly support the very people we expect to support you.

No Cubicles

If you’re chatting with someone, it’s entirely possible that three people are having a discussion on our end to make sure you get the help you need—and a lot of times, one of those three people is an engineer. You just can’t get that experience with an outsourced support team.

We achieve that experience with an open environment. Support team staff can yell across the room for assistance, tap someone on the shoulder, double-tap someone with a couple nerf rounds, or hop into company group chat to get help from our UX or dev teams.

Building to Scale

Instead of putting the job of Quality Assurance in the hands of our devs or our UX team, or even making it an independent team, it’s actually a function of our support team. We’re on the "front lines" with customers, we know what breaks, and we know what’s confusing, so our QA team works directly with our dev team during each release cycle. Members of the QA team are typically very technical, and can confidently hold conversations with customers and devs.

We have a researcher who sifts through support data to help us optimize our schedules, and finds common questions asked by customers. He sends those questions to the folks who update our knowledge base, who then write support articles that we can link to from live chats, Twitter, and Facebook. Sometimes, they ask our video team to build quick tutorials. The result is something like this. Scalability is empowering the customer.

Experts. Not Escalations.

All that training and internal support and focus on scalability and empowerment exists to get you the answer you need. No escalations required. You need to talk to an expert right off the bat because what starts off as a simple list import question can morph into a discussion about best practices for opt-ins, DKIM and SPF authentication, or how to see that revenue chart in the last release.

Conversations with an expert: That’s what we believe in. We feel so strongly about it, that any job opportunity or promotion within our Support and Compliance teams is an education-based opportunity. In other words, we take our best educators and promote them to “teaching” positions that help our team learn more, so they can help our customers learn more, so our customers will love MailChimp more. While traditional support teams are measured on things like “duration of chat” or “time to resolution,” we believe in taking our time and truly helping our customers, so we measure our success using 37Signals’ Happiness Report as our model. (We talked about that here.)

The result is an entire team of awesomeness that’s battle-hardened, knows the app blindfolded, and can whip out an animated gif so fast it’ll make your head spin. We like to think of ourselves as your human support team, and from what we can tell, you seem to like it too.