Slack’s Ali Rayl on supporting 5 million daily active users

In your startup's early days there are two inputs connecting customers to your brand: the product experience and the support experience.

The latter not only shapes impressions, but also serves as the primary pipeline for product feedback. And if you’re going to keep customer support running smoothly as you scale, it’s critical to think deliberately about the experience well before heaps of customers come rushing through the door.

Ali Rayl, Head of Global Customer Experience at Slack, has been there and done that at the fastest growing business app ever. In February 2013, Slack had just pivoted away from the video game industry, had no product, no customers and only 8 employees, one of which was Ali. She was tasked with creating the support experience from day 1. Fast forward four years, and Slack is north of five-million daily active users and 800 employees, with more than 100 providing customer support around the globe.

Ali recently joined me on our podcast to share her lessons learned from Slack’s early days, the unconventional way she measures her team’s performance, how her team promotes knowledge sharing and much more. If you enjoy the conversation check out more episodes of our podcast. You can subscribe on iTunes or grab the RSS feed in your player of choice. What follows is a lightly edited transcript of our conversation, but if you’re short on time, here are five key takeaways:

  1. Well before it was mainstream, Slack recognized the need to invest in customer support. That began with answering, what expectations do people have from using the product that we need to mirror in our support experience?
  2. In support hires, Slack looks for someone who can write and express themselves well, and comes across as an empathetic human in the process.
  3. Ali believes volume metrics are the wrong way to measure a support team’s output. These quotas peel back autonomy and lead to lesser support experience.
  4. All systems and workflows will break at different, unpredictable intervals as you scale, so Ali engineer her team’s processes to last for 6-9 months.
  5. Slack has put a company-wide emphasis on creating progression paths that aren’t limited to people management, and Ali’s done this with her team through specialization.

Adam: Ali, welcome to the show. Let’s start at the earliest days of Slack. What was your day-to-day like then? Were you developing the support experience there from day one?

Ali: When I joined Slack, we were actually called Tiny Speck. We were a videogame company, working on a game called “Glitch”, and I was employee number 43. I had been there for about two months when we decided to shut down the game. That’s when we cut forces and ended up with about eight people, which was incredibly difficult. People had poured their hearts into this game for three years and suddenly it was, “We’re not going to do the game anymore.”

I had joined the game as Director of QA, and my background is in software engineering, specifically around automated testing tools and then testing itself. So for the first four to six months of writing Slack, most of my job was testing it. At the very beginning it was a bunch of APIs and a very rough UI, so most of my testing was actually on the back end.

We started rolling out to friends and family, and then we started rolling out to more of an outer circle. As we got customers, they needed support. Throughout my career, no matter what my title was or my role was, I was always working with customers. I have always done support. So I just raised my hand and said, “I could do that.” At the time, there was eight of us: Stewart (Slack’s CEO), six engineers and me.

Adam: Today you are the Head of Global Customer Experience of Slack. How does Slack define the Customer Experience team? Is QA still part of that? Is sales in the equation?

Ali: QA has actually moved into engineering. Support is under the customer experience umbrella. We also handle all the support on the Twitter account. We do the app directories, so we’re doing all the reviews and publishing of apps for our app directory. We do developer support, so if you write us needing help with the app you’re building or an API, that’s our team helping you. We’re doing translation for the entire company as we work on internationalizing our product. We also do all the Help Center content. Everything on the Get.Slack.Help site is us. We’re working on user education as well. No matter how sophisticated a user you are or what your role is, we would like to help you understand how to use Slack better and turn you into an expert who’s really comfortable and confident with our tool.

Building an early-stage foundation for customer support

Adam: A lot of our listeners are at very early stage start-ups, where they’re making their first few support hires. What did you do in those early months after the pivot that you would repeat or even possibly avoid?

Ali: We got aggressive and optimistic about our support infrastructure. One thing that I think is tempting when you’re in the early stage is to say, “Well, we don’t have a lot of customers, we don’t really need a super robust support tool or support experience.” It’s very easy to look at the pricing model and say, “This one is very cheap, it’ll serve our purposes for now.” The thing is (with support) you’re gathering all sorts of intelligence about your customers – how people feel about your product, what you need to iterate on through that support tool. This is your primary feedback mechanism on the thing you’re building. So when it does take off, when you do get a lot of traction, that is the absolute worst time to realize, “Aw man, our support tool isn’t really up to snuff. Now we’re super busy and we have to migrate all this data.” That’s bad. I got aggressive about that early on and migrated us to a more robust support experience before things really took off, which paid off super well for us.

This is your primary feedback mechanism on the thing you’re building.

Another thing that worked really well was defining what it meant for a customer to interact with Slack. At the time, we didn’t have marketing, and we weren’t doing a lot of PR. If you weren’t interacting with our product, the only other opportunity you had to interact with the Slack brand was the support experience. A lot of this was trying to understand, what are the expectations people have from using the product that we need to mirror in the experience with our support team? How does this support experience feel authentically Slack? How does it fit in with the thing they’re using everyday?

Company-wide we figured out that we are asking an enormous amount of people. Not only are we asking a single individual at a company to try our product, but we are asking them to get buy-in from all the people around them to change how they communicate. We’re asking them to get off email, we’re asking them to switch tools, and we’re asking for an enormous amount of trust.

Part of upholding our end of that bargain is being the trustworthy partner on the other side, so that person who really put themselves out there – who’s in some cases their reputation within the company depends on the success of Slack – we want to support them. We’re going to be the person who’s says, “We’ve got your back, and we’re behind you. If you have problems we’re totally here for you.” So much of the initial support experience was really understanding what we’re asking from customers. When they come to us, how dire is it? How important is it to them? This is some high stakes stuff, so we designed our support experience to support the business that we knew we needed to build and not just the problems that our users have.

Why your support agents should be writers

Adam: When you’re setting that up, did you have to create a strict voice and tone for what support at Slack was, or did you let agents feel that out for themselves as they came onboard?

Ali: There was a little mixture of both. When we were hiring people, we actually had them do a writing test. One thing about Slack, the product itself, is it feels very friendly. We’ve tried to make it feel conversational because it is a conversation tool. Part of weaving the brand experience through support is to make sure that we’re upholding our end of the bargain on that. In that writing test, we look for people who feel like humans when they’re writing. It’s like, “This is an interesting person who’s answering my support question, not just somebody cranking out macros.”

Adam: What type of prompts do you give candidates?

Ali: We actually sanitize a few questions that we’ve gotten from customers. We also give them all the factual information they need to solve it. We’re saying, “Give us your answer.” When we’re doing that, we’re not looking for a specific tone or voice. We’re looking for someone who can write well, who can express themselves well, and who really comes across as an empathetic human in the process. Everything else is just tweaks around the edges, so for somebody that has that natural predilection towards fantastic written communication it’s very easy to say, “You used this word. Instead, we use this word.” Or, “You use ‘I’ language, we use ‘we’ language.” That stuff is very easy to train when they get in-house. Either you can or you can’t write in a very conversational tone.

Either you can or you can’t write in a very conversational tone.

One interesting thing I’m starting to research is how this conversational tone translates to other cultures. In the U.S. and in Canada, it’s obviously fine – “Hey, we’re just people hanging out, talking about problems with our software product.” How does that translate to Japan, for example? These are some of the things that we’re researching.

Adam: How do you localize this support experience where certain metaphors or euphemisms you use just don’t work or people speak to each other on the street in a much different way than they would here – that’s fascinating.

Ali: In Japan, it’s a very hierarchical structure. We don’t want to come in and insert ourselves as higher than the person writing in, because we definitely aren’t, but we don’t want to come in too low and make ourselves seem unable to help. This is a lot of what we’re figuring out. We did the initial revision of this on our Help Center, which we just translated into French, German and Japanese. We have Spanish coming out soon.

The first part of translating the Help Center was actually coming up with the style guide. We didn’t dig in and start translating stuff. We did a lot of thought around, “What does Slack sound like in French? Who is Slack in french? Who is Slack to the French customer?” We are developing a style guide that is used now as we translate the rest of the product. We’re using it product-wide.


Measuring success in support: a “no numbers” philosophy

Adam: When it comes to measuring your support team, you use something called “the no numbers philosophy”. It’s quite different than the industry norm for managing a support team’s performance. Walk me through the thinking behind this. What exactly is this philosophy, and why has it ultimately been so effective for you?

Ali: As humans, as people, we thrive at our work when we have a lot of autonomy. If you give someone the information, tools, skills, resources – everything they need to do their job well – and you let them run off and do their best work, then it’s going to be much more deeply gratifying. When someone feels good about the work they’re doing, not only does it cascade to all those around them but customers can feel it as well. You can just tell when a happy person is helping you.

One part of it is, “Let’s give people the autonomy they need to decide what needs to happen for the customer. If the customer needs a half hour of attention instead of five minutes give them that half hour. If a customer needs ongoing work over two or three weeks on something, let’s give that time to them.” I never want to constrain someone’s work by telling them they have a strict amount of time or a quota or anything like that.

We thrive at our work when we have a lot of autonomy.

The other thing about quotas, which is interesting, is they assume a team that is always behind. If you’re going to tell a team of five people they have to do 30 tickets a day, then you know that you’ll always have more than 150 tickets in the queue that day, which is a terrible state to be in. It’s the bucket that you can never clear out. You’re never catching up; you’re always behind.

We want to zero at the queue as much as possible, and we often do it several times a day. You can’t have a quota if you don’t reliably have a huge backlog for people to work against. Fundamentally for how we run our team and the expectations we have of ourselves for getting back to customers quickly and clearing things out rapidly, a quota system just doesn’t fit. We could run into the a situation of, “Well, everyone failed their quota today because we just didn’t have enough work for you to do. Sorry about that.”

Then there’s the flip side, which is if I say, “Okay, everybody has to do 30 tickets today.” When we have a very busy day, for example when we release a new feature like custom status, our volume spikes. We have a ton of work to do. But if I told everyone, “30 tickets, that’s your goal.” Then they’re like, “Well, I got my 30 tickets. I’m out of here.”

I don’t think anyone on my team would do this because they’re fantastic. Everybody takes a lot of ownership. But the success criteria for those days is higher than on a normal day. So quotas just don’t work for the way we run our team and the way we approach the volume of work to be done. We try to normalize the team with, “Here is roughly the amount of work coming in today. You collectively are all responsible for doing it.” As people we are pretty adept to adjusting how quickly we do things based on the amount of time we have. Think about moving a house. If you know you have a month to go, you’re carefully packing all the glasses in newspaper, you’re tucking it in the box, you’re labeling the box with “My Star Wars Glasses”. If you have one day left, you say, “Screw it, I don’t care about these glasses. Wrap them up. Get them out there.”

We are very good as humans at adjusting how quickly we work and how well we work based on the amount of time we have. A lot of it is situational awareness for people. People begin to learn, “Here is roughly the work volume for today. That means this for me. Maybe that means I go on ‘do not disturb’ mode on Slack for an hour.” Or on the other side, “Wow, I have a lot of time to take care of this thing I wanted to learn.”

Adam: How large was your team when you put this type of thinking in place, or did it simply evolve organically from the beginning?

Ali: It evolved organically. I never wanted a quota system. I generally don’t think that’s a good way to manage people. In engineering we talk about lines of code as being a completely terrible metric for measuring quality or output of an engineer. think it’s the same way for everybody. Once you start looking at volumetric measures, a lot of autonomy is taken away, and autonomy is what gives us pride and joy in our craft. Ultimately at Slack we are all craftspeople. We all delight in the experience of executing our craft to the best of our ability, for the good of the company and for the customer. So it’s evolved organically, but it’s very rooted in the values we have as a company.

Adam: Slack has more than 100 support agents now, is that right?

Ali: The overall customer experience team is about 150, but our direct support team is over a hundred now.

Adam: Say someone puts this no numbers philosophy in place very early, but is now entering a phase of growth. What type of things do they need to adjust on the way to a 100-person team?

Ali: Things break at many different intervals. What we’ve learned is that we don’t know exactly when they’ll break and we don’t know why, but we do know they will. So we engineer our processes so that they’ll last for six to nine months. We’re not precious about them. We don’t dig in and spend months on them where it’s like, “This is no longer working. Let’s build a thing that’ll work for now, and let’s try to anticipate what’s gonna happen in a little while, and then we’ll throw it away and start fresh again.”

One thing that we emphasize a lot with the team is proper change management practices, which is constant awareness that things will change and it is a necessary and exciting part of being in a growing company. Do not get too attached to any one thing that is happening because the growth of our company will necessitate a difference.

Early on the product was smaller and the number of people were fewer. It was both possible and necessary to know everything about everything and to answer questions regardless of topic. That situational awareness is very hard to get when you have 20 people working out of the same queue. If you are new to the company and suddenly you have all of Slack to support, which is getting larger and larger, it just becomes an impossible task. So we split it up into specialty teams. For example people now are experts in the Mac app. There’s a small group of them doing that so they have a lot of situational awareness on everyone around them and what they’re doing.

This also gives people, especially new people, the opportunity to come in, master one thing, and believe, “I am doing excellent work. I have only been here for three months and I’m contributing and I feel like I’m a part of the team. This is an exciting job.” One things about growth is it’s harder and harder to onboard to a growing company and understand how it functions, how all the pieces fit together, what all the people do. The more you can give people a nice, big, soft handle to grab onto and thrive, the better they’re going to be in the long run for the company. They’ll think, “I’m here. I’m succeeding. I want to do more.”


Progression paths: more than just people management

Adam: You mention that tilt from generalists and specialists, which is common across growing companies. We’ve certainly seen it here. How do you make sure that there are knowledge-sharing measures, so that the specialized knowledge isn’t accrued in a silo?

Ali: We have a lot of different mechanisms for this. Another thing I really don’t want to do is build a big team of managers. One way you avoid that is to make sure that as many people as possible are doing the information sharing, the task-based stuff that managers traditionally do. Each specialist team (at Slack) has an aggregation of people. One we call the ambassador. They’re the ones who work with the product managers to understand what features are coming and give customer feedback to our product managers. We have the bug boss, and they’re the ones who know all the outstanding bugs in their specialty area. They work with product and engineering on prioritizing and getting fixes. Specifically to your question, we have a learning specialist in each specialty group. They’re responsible for all of our internal documentation about that area – making sure it’s up to date as we update the product. As needed they do presentations or guided learnings, or spin up new courses for new parts of the product or parts that people tend to struggle with.

So we’ve distributed a lot of that down to the team itself, which is great in a lot of ways. We don’t have a lot of managers doing a lot of manager-type stuff. We all learn better when we do it ourselves. Coming up with a training is a fantastic way to force you to learn something. I really like the fact that people have opportunities to do things that aren’t just grinding away at a support queue all day.

Adam: People management simply isn’t everyone’s desired path.

Ali: We’ve focused on that company-wide. How do we ensure that everybody has a path to grow that isn’t just people management? The worst thing that you want to do is promote someone to people manager who doesn’t want to manage people.

We all learn better when we do it ourselves.

There are a lot of interesting paths that people can go into. More of those emerge all of the time. For example, with our enterprise product, which just came out in January, suddenly we have all sorts of pathways opening up that look more like customer success work, or more like solutions engineering work, than traditional customer experience work. All of these options begin to emerge and people begin to learn and exercise leadership qualities without actually having to manage people.

Adam: You now have four or five offices where your team is based. Slack has a very tight culture, but how do you keep people across the globe plugged into that?

Ali: We have Melbourne, Vancouver, San Francisco, Toronto, and Dublin, and Slack helps quite a bit. We have several channels in Slack where we do our work. We have one channel that is #CE-random. For everybody on the customer experience team that’s our own little subset of random, which is the social channel for just chatting.

We also have a program called “CE Meets” where periodically two random people get paired up for half an hour, and it’s always people from different regions. You’re never going to meet someone in the same office. If you’re in Dublin, you’ll get someone in Toronto, Vancouver or San Francisco, but probably not Melbourne because that time overlap is brutal. We have people mixing that way.

And then we have the specialists groups, where different people in different regions are focused on the same thing. Our enterprise learning specialist, for example, is in Australia, and our enterprising bug boss is in Vancouver. So they work together in order to execute on all the CE needs for the enterprise support product.

Operating at the enterprise level

Adam: You mentioned moving up market. How does Slack decide what level of service to offer customers? Do you guys have different levels for different segments?

Ali: We don’t offer different kinds of service. Everybody gets basically the same people with the same amounts of knowledge. We (do) prioritize. Someone on the enterprise plan, for example, we have much tighter SLAs on getting back to them, and that’s about it. It’s really, “How quickly do we respond? How tight is that feedback loop? Are we passing it around the sun?” It’s substance is the same; it’s really rapidity. Our mean turnaround time is under an hour, so it doesn’t make a ton of difference. It only makes a difference when we have a super busy day and we have to start prioritizing those enterprise customers over the people who are running something like a My Little Pony conference or whatever. In general, everybody gets the same thing.

Adam: It’s apparent that Slack has some major challengers entering its product category at the enterprise level. What role do you see your customer experience team playing in making sure that Slack remains a piece of workplace software that teams can’t live without?

Ali: Obviously we’re aware of what’s going on in the market, but it’s exciting. As a company, it’s great. It raises the awareness overall that there are new workplace collaboration tools and that the way we work together is changing. It’s an exciting time to be in the space. We think there is plenty of room for a lot of people to play in this space, and we are completely focused on how we enable people to collaborate more effectively together.

As far as my team specifically, so much of that is continuing to uphold our part of that trust and all the work that the team around us has done. Because as you go up market, these deals take longer and more people get involved. These relationships are forged between the customer and Slack. It’s our duty to uphold those relationships so that we have a continuation of service where, unlike a somebody coming in and putting in their credit card number where we never talk to them, there are preexisting relationships and it’s up to us to uphold them.

Adam: At this point for me it’s pretty difficult to imagine a work day without Slack – it gives me email anxiety. Ali, thanks again for joining us today.

Ali: Thank you for having me.

The New Economics of Customer Service Guide CTA vertical

Most Popular