Intercom helps internet businesses communicate with their customers, personally, at scale. Co-founded by Eoghan McCabe, Des Traynor, Ciaran Lee, and David Barrett in 2011, Intercom has raised $66M in venture backing and serves more than 8,000 customers. I met with Des Traynor to learn more about Intercom and use the 4 P's framework: people, purpose, process and platform, to break down how their Customer Support team delivers a world-class experience.
Alex McClafferty: Who are your customers today?
Des Traynor: Intercom customers tend to be around our stage [170 people] or younger, but it's a bit more complex than that. It's really about team size more than company size. We sell products to marketing teams, support teams, sales teams and product managers. Bigger companies use us as well, but usually for a certain job within a certain team.
Take New Relic for example. Product managers in New Relic use Intercom's Learn product to learn what their users think of their product, to get feedback on their current features and decide what they want to work on next. We're selling to a certain team at a certain company for a certain job. Generally, that's what we call "jobs to be done." And Intercom is used for a bunch of different "jobs to be done." So at New Relic, product managers want to understand what their customers are thinking, ask them specific questions and get the right feedback from the right customers. So they use us for that job.
That's why we can't really say our customers are typically between 0 to 250 staff, because it's about specific teams. You could be a 10,000-person organization but if you've got a 25-person product team who wants to learn about their customers, you'll still pick Intercom for that job.
McClafferty: Can you tell me more about customer support at Intercom?
Traynor: From the moment somebody decides to use Intercom, anything that's an obstacle to them having a great experience is dealt with by our Customer Support team. That means if somebody is trialing one of our products and they want to learn how to send a newsletter to 250,000 people, or an existing customer has questions about how to use a template, all of the questions will go to our Support team.
Since the advent of SaaS, seven to ten years ago, you can't sell and forget any more. You can't say: "Here, I sold you a car. Don't ever talk to me again; I'm gone." When you sign up for Intercom today and you sign up for a plan that's $49 per month- if we don't do our job, that first $49 is all the money we'll ever see from you ever, because you're going to quit.
The reason why onboarding, engagement and support are really important is because we need to always be protecting our future revenue. That blurs the roles between what someone calls success, what someone calls sales, what someone calls support.
The best example of this is if I'm trialing your software on your $499-a-month plan and I'm on day 13 of a 14-day trial and I ask you a question, is it support? Or sales? Or success? Whatever you want to call it, if you don't do it right, the deal's gone. The customer has churned or failed to convert, depending on your business logic. If you do your job right, you've won a deal, but is that a sale?
The way we see it at Intercom is that our Customer Support team is responsible for when somebody wants to use our product, making sure there's no obstacle and no confusion and that no problem whatsoever will ever prevent them from doing so.
McClafferty: Could you tell me a bit about the size of the Support team and how it's structured?
Traynor: Sure, so there's 18 people on the team. We have ten people here in North America, six in Europe and two remote. We offer 24/7 coverage. The key roles are Customer Support Engineer (CSE) and Customer Support Representative (CSR), the difference being that the engineers have an engineering background. We get lots of questions that are technical in nature. That's why we have a lot of engineers on that team.
We also have four products. There's a lot of depth-of-knowledge per product that needs to be known. So our Support Representatives, are great for answering questions along the lines of awareness, confusion, user interface, how-tos, why-tos, "How should I think about this?" That's the breakdown. Typically, a conversation would start with a CSR and, if the conclusion of the conversation would be, "You need to use our API," or, "You should probably add our SDK," it'll then get informed by a CSE as well.
McClafferty: How do you think about people development within Intercom?
Traynor: We've had reps transition to engineers, and there's seniority within roles, too. You can be a senior CSE or a regular CSE, a senior CSR or a regular CSR. The way we think about it is that a lot of it has to do with a combination of depth-of-knowledge plus depth-of-judgment, so it's, "What decisions are you entrusted to make here?" As people grow and mature in their role, and their product-knowledge fully fleshes out and their workflow-knowledge is fully complete ... They know how the product works and they know what customers are trying to do with the product, so they can advise customers to take the best course of action.
An example of that might be when a customer says "I want to send an in-app message to my 250,000 users about this new feature launch we're doing." The zero-points answer is: "Sure, here's how you do that." The better answer is to remember what it is Intercom exists to do, and that's to make internet business personal. The better answer is, "Sure, here's how you do that. But in our experience, it's not necessarily the best idea to send the same in-app to 250,000 users. You should probably think about it from the point-of-view of who are best equipped to receive this and what's the best medium to contact them in. All 250,000 of your users probably aren't active, so they're not going to see an in-app if you post it. Let's consider emailing those who are inactive. Is this feature good enough or useful enough to merit using it to try to reactivate customers? If so, let's go down that route. Secondly, for the in-app messages, is this feature available for all of your users? If not, should we send a different message to those who can access it now, and those who need to upgrade to get access, and other scenarios?" That's the level of support we like to provide, which is not just how-to, but it's why-to and how to think about. That's the real value add.
If the majority of your customer support is answering how to do things, you need to go back and have a look at your interface. The best value you can give is not just in terms of, "Point here, click that, type this, click send, done." Certainly, some of our support will always be that. There's just people who want that very tactical specific itemized answer, but the value add support, the stuff that actually has people tweeting, "Holy s***! Intercom's Support is amazing!" isn't because they told me I had to click send. It's actually because they taught me how to think about onboarding emails. Customers leave the conversation not just with the knowledge, but also with a framework for how to think about it for the future.
McClafferty: What inspired this approach? Was that coming from empathy or other products of companies that you've had experiences with?
Traynor: A lot of it is empathy. A lot of it is coming back to understanding what the customer's actually trying to do. In the hypothetical, they're like, "I want to send an in-app message to all of my users." It's about getting to a level of abstraction. Basically, customers only speak in terms of what it is that they think they want to do, but what you want to try and identify is what's their real desired outcome here? The desired outcome of somebody who wants to in-app message 250,000 people is engagement with their new feature. That's what they actually want to get to. Intercom is a tool that can help them get there, however what they've done for themselves- and people do this all the time.- is prescribe a notion on what they think is the right thing to do, and ask us to help with that prescription.
McClafferty: Like self-diagnosing on WebMD?
Traynor: Precisely. So they've said, "I believe in-apps are the thing," and they're not wrong. They're just not 100% correct. It's a relentless focus on helping the customer achieve their desired outcome. That's, genuinely, one of our Customer Support values that we have. We call it "treat the problem, not the symptom." People will come to you with symptoms, but it's problems that they actually have. Symptoms are "I can't find how to auto-message somebody on Day 1," whereas a problem is, "Our users are disappearing after they sign up." We're like, "Okay, we can help you with that, but not by using your prescribed recipe. We have a better way to do it and here's what it looks like." Otherwise, if you do give them the very specific answer, what you get the following day is, "I did that and it didn't work." Then, you're like, "That's because it wasn't the right thing to do."
The best writer in this area is Kathy Sierra. Her whole angle is creating passionate users, and it's really about how to make users awesome at their job. People have jobs, and their job requires them using Intercom, and we want them to be awesome at their job. That, honestly, is what generates the passion and the affection our customers have for us.
McClafferty: How does Support inform the Product team?
Traynor: I think it's a shocking mistake people make when they try to outsource or segregate Support from other teams in the company. It's one of those real core strategic blunders. We don't do it at Intercom: Support is at level footing with Sales, Marketing, and Product. They're equal people; they sit out there, you walked right past them on your way in.
Every single support conversation we have is recorded through a system of tags and categories. The tag set is collectively exhaustive. That is, every conversation will get tagged in some manner. We can analyze this data from lots of views. You can look at time points, what people ask for in their first week and what product they are using and what is the nature of the question. This yields a bunch of insights. For instance, people who sign up for our Engage product, after a week, who haven't sent a newsletter, they ask us about newsletter-sending. We can break that down.
The Customer Support team analyze all these symptoms, pass it over to our Research team, who'll then create what we call a Customer Voice Report which will go straight to the Product team. This is is a qualitative behavior-driven list of incidents that cause customers to need to contact us to complete their desired outcome. There's a few nuances to that, but behavior-driven is important, because they're trying to do something and they hit a wall and that's when they talk to us. Which is very different from, "We surveyed our customers and asked them, 'What should we do next?'" It's instead looking at where our customers hit walls and had to talk to us to get through them.
The Customer Support team's job is to identify this and pass it to the Research team. The Research team's job is to identify the 50 different questions that all have the same end outcome. Some people will say, "I want to in-app message all my users," and other people will say, "I need to email all my users," but they'll have lots of different ways of saying it. If we treat each of these things as valid problems, rather than symptoms, we'll build a new way to solve it every single time someone talks to us. What the research team will do with the CVR is abstract it to the generalizable job or problem. What is the general workflow that the people are struggling to complete and what is the barrier to it?
This goes to the Product team who will then, basically, prioritize it and build it. That's one example of a more general thing, which is having Customer Support on level footing, connected and dialed-in to the rest of the company. It is fundamental to maintaining product-market fit, because the alternative is you stop listening to your market and instead you only listen to your marketers and your sales people and your product people. Reality is over here (points to opposite corner of the room) running around in circles, and you're too busy falling in love with this fictitious notion of what you think your customer behavior is.
McClafferty: It seems action-oriented instead of opinion-oriented.
Traynor: It's more context-oriented. Surveys are great and I'm not against them, but the meaning can be lost. When I'm staying in a hotel and I come down to the lobby and I'm wearing flip-flops and swimshorts and I've got a towel over my shoulder, I'm clearly looking to go swimming versus you surveying me and saying, "Would you like to swim in our hotel?" I'm like, "Yeah, okay." There's always a difference when it's tied into a workflow.
You also get more urgency, because it's like, "I'm trying to send this email today," or, "I need to get results today." That's why you have a Customer Support team that's super-responsive and super-sympathetic and will always help people achieve their outcome. I think there's a beauty and a truth of behavior-driven contact. It's always contextual and it's always loaded with the right desired outcome. You can learn a lot from it.
McClafferty: Can you tell me the purpose of Customer Support at Intercom and share some of your core values?
Traynor: The purpose of Customer Support is that any time a customer wants to try to achieve any desired outcome and is struggling to do so, either through product error, through user error, through lack of awareness, through lack of clear usability, or whatever, it's the Customer Support team's job to bring them to their desired outcome. It's also the Customer Support team's job to ascertain that they choose the right path to get that outcome, so they might want to engage their users, but they don't want to have their users upset about being spammed, so it's our team's job to say again, "I can see why you might think that emailing five times in the first five days is good, but here's a few ideas about how you'll get to where you want to get to without doing the things that upset customers." That's the purpose.
One value we already talked about was "treat the problem, not the symptom." Some others:
"Always responsive." We have a very very fast response time; we offer live chat to all of our customers. We fundamentally believe the Customer Support aspect of a product is a feature, and speed of Customer Support is a feature as well. All things being equal, if you sit down and try to use two different products and you hit a wall on both of them, the one with the better support's going to win that fight. I would say the same thing about your onboarding. Product A could be way better than Product B, but if Product B has better onboarding, you're going to get to your desired outcome quicker with Product B. You have to think about these things not purely as software, but think about the things around it.
"Patient and empathetic." We live to make internet business personal and we strive and will always fight to behave in a way that represents how we think internet businesses should be treating their customers. What that means is if somebody's struggling to do something- like a non-technical person is trying to use our API- the easiest thing in the world to do is to say, "let me talk to an engineer on your side," but instead we'll help them as best we can and we'll give them all the information they need, we'll give them all the different exit routes they can have. Basically, we won't give up on them if they want to pursue this themselves, but we'll also happily explain to them the alternate routes, like saying, "Give us an email address to an engineer. We'll send them an email with what they have to do." It's about being consistently empathetic to what it is they're trying to do, and if we know that they can do it, it's just going to be a bit more work on our side, we'll eat that no problem.
"Thrive under pressure." Anytime you launch a new product, you launch a new feature, you make a significant product update or change, etc- with the volume of customers we have you can see a massive massive spike in customer conversations. That will result in a lot of pressure, and sometimes, you launch something and it would've otherwise been a busy day, but now it's a 3x busy day. For example, we launched a new product recently, Acquire, which is an alternative to "live chat" products. We had a very successful launch. We had thousands or tens of thousands of people come to our site and check it out, and naturally start live chatting with us. So a quality we always look for, when we're interviewing, is the ability to thrive under pressure. Somebody who should get more focused when things get bad, not less focused, and should actually get more patient at the severity of the situation, not less patient. It's one that's really important.
"Resourcefulness." Because Intercom's vision is quite big, to be this singular customer communication platform for all different businesses, to communicate with the customers with the end goal of making internet business personal, there will always be things people want to use us for that Intercom doesn't yet support. Customers will say, "When a customer signs in, I want to get an SMS to my phone." We don't have that right now, but it's not to say we wouldn't in the future. However, it is possible right now using IFTTT plus our webhooks. Resourcefulness is the quality that will help the customer complete their desired outcome, even when it exists beyond the scope of what Intercom is today. Again, this is something we test for when we're hiring as well. We have different ways of checking every single one of these values.
McClafferty: How do you use resourcefulness as a lens when you're bringing people onto the team?
Traynor: If we were checking if a candidate had good resourcefulness, we'd give them an incomplete set of information and ask them to prepare a customer response. We wouldn't explain to them two or three things, and a great response to that is, "I didn't know what you were talking about, so I Googled and I looked up all these things, and I found out this thing, and it turns out this is possible through this." You're like, "Okay, that's great. You're resourceful." A bad response is, "I presumed this question was a mistake because I couldn't find it anywhere."
The same goes for "thrive under pressure;" we test that by acknowledging and at the same time telling people, "We're going to ask you, in the next ten minutes, to answer x number of questions, just to see can you maintain a high-quality bar while getting through this? Do you get freaked; do you get frazzled?" These are the things that we're looking for.
Our last team value is "dedicated to exceptional quality." It is universally true; we believe all businesses should be talking to their customers. Not talking at their customers, but talking to or talking with. To that end, we are forever determined to make sure that every conversation people have with our Support team results in a happy experience for the customer. It's an incredibly hard challenge, but, if you have a demotivated team, it can snowball. This quality's the first thing to go. Then, quality goes and you have other problems that follow that, but everyone on our team holds each other incredibly accountable to the idea of trying to deliver an amazing experience- and that stops other problems from forming.
McClafferty: Onto process now; how do you measure the performance of your team?
Traynor: It's hard to really measure support performance. Just like we can't give you points that measure that Intercom is one of the most compelling modern products, but at the same time, we know it is.
It's easy to count the number of positive happy conversations we've had or the number of great Tweets we've had, but that doesn't tell the full story either. Operationally, what we track is time to first response, because that's one of our values, "always responsive."
We talk with our customers. When we conclude a conversation with a customer, we ask them for feedback on how it went. "Were you happy, or middling, or sad about the outcome here?" We track all that data but, honestly, I don't think our data or metrics tell the full story. I think there's a lot of qualitative gut reasoning that goes on as well.
McClafferty: What do you do internally to innovate on gaps and break-points and things that are not working?
Traynor: Our Product team's roadmap has five inputs, and one of those inputs is what the Customer Support team have been recording, true to proxy of the Customer Voice Report, which is basically the analysis on it. It's not a hack or a short-term thing; it's a systematic activity that we will routinely identify and fix recurring customer confusions or issues or whatever. That's the true answer. I'll talk through the other things we also do, but if you're not doing that, then nothing matters in my opinion.
We have an initiative called Customer Day, where, basically, everyone who does not work on the Customer Support team, once every two quarters, will spend a day working as a Customer Support person. There's multiple ways that this works. One is it reinforces this idea of empathy, that they understand what it is our customers are confused by and what's causing problems. Another benefit is the intercompany bonding and respect. People get to learn how tough the Customer Support job can be and they tend to leave their day very impressed with the quality of what the Customer Support team do. We ask them at the end of that day to write up their thoughts on using Intercom the product, because, we do all of our support through Intercom. They write up their feedback, and these individual Customer Day stories are anecdotes, that can occasionally be so emotive that they'll trigger a change in what we're going to do.
If you put our Product Manager on Customer Day, they'll have a newfound appreciation for the complexity of their own domain. They might be like, "I've realized there's a way better way to fix this." You can rely on product iteration from that standpoint, but sometimes it does actually pop out some interesting things.
Aside from that, we do a good job of keeping our internal documents up to date. We treat our documents like a software product. We file bugs against them; they all get resolved. It'll be like, "This page is out-of-date because we don't support this feature," or, "We now have AB tested this section, instead of that section." The natural tendency of any form of documentation is to go stale, go out-of-date, become irrelevant, and become worked around. Again, you don't solve that by a periodic blitz on all the content; you solve that by having a system, and a system means that whenever a Customer Support person bumps into a document, either reported by a customer or not, they will have to file a bug against it.
They can also go and fix it, if they want, as well, but their specific job is to file a bug against it, because now there's a bug in the documents and we hold our documents as accountable in quality as we do the rest of our product. Internally, we have voice and tone guidelines that say how we talk, what we say to customers, how we react to situations, what information we share, what information we don't share and how to deal with inappropriate behavior from customers.
McClafferty: How do you identify that someone's going to have the deep empathy to become part of a team that genuinely cares?
Traynor: Empathy, or you could also call it sympathy when it's in this state, is saying- it's not enough to feel bad for the customer. What's the change in your behavior caused by this sense of emotion that you feel? Empathy is what will cause a Customer Support person to say, "I know exactly the problem. It's absolutely with your CSV file; it's not with Intercom. Send me the CSV file; I will fix it for you and I'll give it back to you. You can import it and that will get you to your end goal." That's an empathetic reaction, which is, "I know where you are. I know the pain and I know why that pain is acute and why it's urgent. I also know that you're not capable of resolving this yourself and in a lesser world, on a lesser team, you may not be my problem." Empathy is what has you saying, "I know I can fix this because I can write a quick script that's going to correct this new file and the whole thing will work smoothly. It will take me three minutes, but it'll save you three hours." That's empathy. The value it touches closest to is probably resourcefulness, but it's absolutely something you need to look for.
Another way to run support is to focus on closing "tickets," but as a customer you're focused on your problem not closing a ticket- so our goals aren't aligned. What we do at Intercom is, "I want your problem solved for you. I want you to achieve your desired outcome of a happy engaged user. You might have different language to describe it, but we're both working towards it." Empathy is the lifeblood of that conversation. The opposite of empathy there is, "I'm running a metrics-driven organization where I'm going to try and minimize my time to close across all of my tickets and you're ticket 117 and we're not required to help you in this circumstance, so you're on your own." That's not how we work.
McClafferty: I'm assuming that Intercom is the platform where all of the magic happens on the Customer Support side?
Traynor: Yes, absolutely, we use Intercom's Support product. Our customers can start a live chat with us within Intercom via in-app messaging, or email. What's great is that the entire company uses Intercom- so depending on the conversation, the Support team might want to bring Sales into the conversation, or a product manager, or whoever. And Sales will carry on the conversation through Intercom as well. The Support team also uses Intercom to proactively reach out to customers based on behavior; for instance, if a new customer hasn't added new teammates within 20 days, they'll get a message from us offering to help. We use Intercom for all of our customer communications.