Growing customer support in a product-first company

In the three and a half years since I joined Intercom as the third member of our customer support team, I’ve seen the team grow to over 80 people. Last year I actually moved to Chicago to open up our first dedicated customer support office.

When things are moving and changing that quickly, internal decisions trickle down into customer experience in some less obvious ways.

In my talk at the Inside Intercom World Tour, I shared some of what we’ve learned. Read the lightly edited transcript below or skip down to the video at the end of the post. We’ve also released my talk as a special episode of our podcast. You can listen to it above or subscribe on iTunes, stream on Spotify or grab the RSS feed in your player of choice.

Don’t make promises

When I joined the team back in 2014, we were a typical startup. By day two, I was a senior member of the team. I was receiving the most complex customer issues, yet I hadn’t even taken the most direct route to the bathroom yet. One mantra was introduced very early on that was crucial to our success. It was a key concept for support teams of all sizes but especially one supporting a product in its early stages: “Don’t make promises.”

We weren’t being cliché by saying, “Under promise and over deliver.” We were literally saying, “Don’t promise anything.” But when you’re on the front line, there’s a real temptation to make promises in order to keep customers happy and secure them in the short term: “Oh, you want this button to magically increase customer conversion? Sure, no problem. We’ll get right to it.”

“What you can and should know are the principles that guide your product team. This is customer support’s secret weapon.”

But you can’t know anything will be built for certain, especially in the early days. What you can and should know are the principles that guide your product team. This is customer support’s secret weapon. At this early stage and at all other stages to follow, it’s what enables you to spot the difference between a possible feature request (like an extra setting in an admin page) and a probable empty promise (like magic buttons). Saying no upfront shows your customers you have a solid understanding of what you are and aren’t trying to be. When you’re on the front lines everyday, it’s really easy to forget that your customers are human too, and they’ll appreciate that honesty. For features that don’t fundamentally add to what you’re trying to do long term, just say no. Don’t promise.

Give your customers context

But how do you say no, avoid promises and keep your customers happy? It sounds impossible. The key is saying no with a reason. Giving your customers context is essential to keeping them feeling valued and bought in. At the end of the day, you’re building your product for them. You want to make sure they know that. Offering context around why you’re building something different than the feature they requested allows them to hear “no” in a whole new light. Explaining that it’s not a mistake or an oversight – but actually a deliberate decision – is often all you have to do to win them over. It’s like when you try and say no to a kid. They shout: “Why? Why? Why? Why? Why?” Hopefully, your customers are satisfied with the first or second layer of context.

For example, Intercom doesn’t force your visitors to leave their email before allowing them to chat with you. But a lot of our customers really want that feature and think that we just haven’t gotten around to building it yet. In reality, the feature doesn’t fit in with our philosophy. We’re not big believers in contact forms and tickets. Once customers know, understand and buy into that, the conversation becomes a whole lot easier.

What’s the key to ensuring you and your team can say no? Well, it’s a great relationship with product. When a company is small, it’s really easy for customer support to work closely with product. You can hop over to their desks or pop into their Slack channels. That was certainly true to Intercom in the early days.

“Giving your customers context is essential to keeping them feeling valued”

As we grew, in order to not annoy the shit out of our product teams, this communication had to become a whole lot more structured. You can only have so many structured meetings every week. Our solution was to create a whole new position called Product Support Engineer. These people were fully embedded into the product team. They were part of every decision, standup and emergency. But they actually still reported into customer support. They owned the information flow between that product team and the support team.

Adding management

Clearing up how support and product work together isn’t easy. It has a direct impact on the customer experience. It was now somebody’s core job to understand the “why” and share it with the support team, ensuring customers were getting the right context. Suddenly you have another role in a team that’s already growing really quickly. As you add more people, you have to add more layers of management, which causes decision-makers to get farther and farther away from the customers. The people who have the context are now several degrees of separation from not only your customers but also the people who are talking to them.

Jeff, who heads up our support team, works remotely. He lives in the Alps in Italy on the border of Switzerland. It’s beautiful; I’ve already gone twice. When we were a handful of people, we all reported to Jeff. That worked. Managers give roughly 10 percent of their time to each report. When a manager has 10 reports – I’ll do the quick math for you – that’s a 100 percent of their time. Their team feels the pain, and by extension, so do the customers. Say somebody on your team needs help improving the way they talk to customers, but you don’t have any extra time to spare. Your customers are the ones who take the hit. So in order to give Jeff some more time back, we had to add a layer of management. To ease into this, we fell back on dotted-line reporting. This meant I was mentoring and overseeing my peers in San Francisco, but in actuality I didn’t have authority or responsibility over them. It’s a fine temporary solution, but you have to go into it knowing the dangers.

How does this internal Band-Aid have an external effect? I’ll give you an example: If it’s unclear who’s responsible for communicating some constructive feedback to an individual, it takes a lot longer for that individual and your team as a whole to get better. On the upside, when the tipping point does come and it’s time to add a layer of management, this dotted-line reporting makes it an easy transition because the people you’re mentoring and overseeing already see you as a more senior resource. Why is this good for our customers? Because pretty much everything gets faster: answers, improvements, feedback and all of those good things.

How to manage a global team

We learned quickly that this type of organizational growth isn’t easy on our customers. Context now has to travel through so many more people. If you’ve ever been toward the end of a game of Telephone, you know what I’m talking about. “We’ll start that next Wednesday,” quickly turns into, “We shipped that shit yesterday.” New layers of management make this game of Telephone harder. But so does spreading out geographically and literally having to use the phone. From day one, we built our product in Dublin and brought it to market from San Francisco. Between these two offices, we got 16 hours of support cover, which is awesome but only for two-thirds of the world. For those of you who are trying to think of what the other third of the world is, it’s mostly Asia.

Enter our first remote hire. In order to set this new team member up for success, we flew him to San Francisco for two weeks to onboard, and then we sent him back to his part of the world. That should be enough time, right? Well, we didn’t think about how we were going to get him the information he needed at the hours he needed it. He often had to wait whole days to get his own questions answered. Communicating this wait time to our customers made us look really disorganized. I mean, we were disorganized – we just didn’t want everybody to know it. As one remote rep became two, then four, then a small remote team, shit really broke. They felt out of the loop and disengaged. Not only did they suffer for that, so did the customers they were trying to help.

When things go that wrong, hopefully you at least learn a few things. One of the things we learned was that it’s really important to watch your language. There is a ton of legacy language that’s going to need to change. For example, we were so used to saying “Dublin and San Francisco”. Now we have to have this whole new habit of saying, “Dublin and San Francisco and remote people.” It takes time to change. You need to be forgiving and understanding, but also correcting.

Another big thing we learned was to communicate the obvious things. You might think you don’t need to communicate something as obvious as what hour somebody is working, but did you know that some parts of Australia observe Daylight Savings and others don’t? It’s very confusing. You want to err on the side of over-communication. You cannot communicate too much. Recently my team got annoyed at me for bringing up an upcoming work flow change every week at our team meeting for about two months. But I thought to myself, “This is the right amount of communication.”

Another big lesson is that technology is great, but guidelines are necessary. We needed to create some rules to make sure the tech we were using wasn’t just creating more problems. For example, we use Slack. We really needed to encourage people to not use direct messages and instead use our public customer support channel so we didn’t spend all of our time asking each other the exact same questions.

We don’t have this all figured out. Once we nailed it for a few remote individuals, we then broke it again entirely when we tried to open up a new remote office. But it gets better and better.

Don’t be afraid to break up with your customers

You’ve grown your internal organ structure in order to best support your customers. You’ve said, “No.” You’ve given them context. But it’s still not working out. What then?

Sometimes customers just aren’t a good fit. Even the greatest support team can only do so much. The idea of breaking up with a customer and telling them they shouldn’t continue using your product is a really tricky thing for our support teams to get their heads around. You’ve spent all this time and energy growing, scaling, and adding time zones, and vacations, and offices – all to ensure success. Now you’re just calling it a day? It doesn’t feel great, but it is the best option in some cases.

“The interactions your customers have with your support team shape how they think about your product”

As much as we’d all love it, your product isn’t going to be right for everyone. If you don’t accept that and learn that breaking up is okay, you run the risk of having frustrated customers who are struggling to use your product because they’re trying to use it in a way it simply doesn’t want to work. That customer who hacked your API to create their version of a magic button is never going to be happy. No remote teams or fancy management structures or embedded support people are going to be able to fix that. Neither does saying, “It’s not you, it’s us.” But that’s kind of what it is in this case.

This sounds like a bummer to end on. But I promise it’s a real positive. Breaking up with customers like this allows you to focus your time and energy on customers who can actually get the most value out of your product. The interactions your customers have with your support team shape how they think about your product and your whole company. Growing a support team is hard. The interactions you have in order to make it easier will have unintended consequences on your customers.

It sounds simple, but if I had to pick one important thing I’ve learned in the last three and a half years at Intercom, it would be that asking “How will this affect our customers?” is never a dumb question.

If you enjoyed this article, check out our other talks from the 2017 Inside Intercom world tour:

• Brian Donohue’s Builder beware: marketing tension in product-first companies
• Des Traynor’s Lessons learned from scaling a team
• Emmet Connolly’s Design in Interesting Times
• Jeff Gardner’s How to tell your company story
• Greg Davis’s Myths of product market fit
• Matt Hodges’ Aligning product and marketing
• Sharon Moorhouse’s 5 lessons learned from growing a support team