How we use Intercom to support Intercom customers

We recently wrote about scaling a product team and we’re keen to share more of how we work. In that spirit here’s how we use Intercom to support Intercom.

As with Paul’s post, it bears remembering:

• Our process is opinionated and very personal to our structure, team size, customer base, and culture. Your mileage will vary.
• This is what works for us right now, it’s not how we worked when we were smaller, and it may not work when we’re bigger.

Our fundamentals

“There are two aspects to delivering great service. Firstly, you need a great process for communications (both internal and external) that defines how issues are resolved, who hears about them, and what happens after resolution. Secondly, you need a great, coherent style of conversation that consistently reminds customers that they are working with a great company.”

That’s the opening of our internal guide to customer communication, which underpins our entire process. The ability to communicate at a consistently high level is the mark of any great organization; whether it’s a newspaper, your local non-profit, a startup or a large corporation.

Bearing in mind that our mission is to make web business personal, here are the 10 characteristics of customer communication most important to us.

1. Concise: We get to the point, the thing the customer cares about, the question they asked. We don’t pad conversations with meaningless intros or outros.
2. Natural: If we would not say the words out loud in a normal conversation, we’re not going to say them in a customer support conversation.
3. Conversational: It’s better to have a lightweight exchange with quick back and forth messages than it is to exchange monolithic, 10 paragraph mails, slowly, over many days.
4. Personal: We are people. Our customers are people. We do our best to refer to our colleagues and our customers by name, not by title, department, or otherwise.
5. Helpful: We understand what end outcome a customer is trying to achieve, and offer them the best solution we can, within our purview.
6. Responsible: If a customer is disappointed or frustrated, it’s on us. We don’t blame our colleagues, or expose our internal limitations as a justification.
7. Customer focused: Our customers (broadly) don’t care about why a problem happened, why we don’t have the necessary privileges to fix it, whose fault it is. We focus on the customer, their problem, and its resolution.
8. Literate: Whilst casual language, smilies, etc. are encouraged, frequent typos, bad punctuation, poor phrasing, etc. are bad. They make us look less professional.
9. Region agnostic: Local phrases, spelling, terms are bad. We always write so as to be universally understood.
10. Careful: We occasionally test beta features and occasionally type test messages. Make sure customers don’t receive these.

These are our table stakes. An expanded version of this style guide is the first thing new members of the team read and something we regularly refer to internally.

Day to day

We have a team of nine people responsible for talking with our customers every day. Until last year, installing Intercom required adding customized JavaScript to your product, so as a result five of the nine team members have software engineering backgrounds. Additionally our team must cover several timezones, so some distribution is inherent in the work. Currently we cover 19 hours of the day with plans to solve the remaining 5 this summer. (Interested?)

Our use of Intercom to support our users has been instrumental in the development of our customer support package and our unique team inbox. Users send messages to us through the in-app messenger in Intercom or email to team@intercom.com, which forwards to Intercom. New messages are initially routed to the unassigned inbox and we work collectively from there. Conversations are assigned to whoever responds first to the user. We rely heavily on keyboard shortcuts (press shift+? in the inbox to see the full list) to quickly reply, add notes and tags, close, and assign conversations as well as to navigate between conversations and other parts of the app.

To track bugs that are reported in the product we use Github Issues. All issues get assigned a priority and are labeled with the product team responsible for that part of the product. We also have a set of labels to show the frequency – daily or weekly – that our users are reporting a particular issue.

We’re currently experimenting with a Github/Intercom integration that allows us quickly link a conversation in the inbox to a Github issue. By simply pasting the URL to the conversation in a comment on the issue or vice versa, we connect the two. When the issue is closed in Github all linked conversations in Intercom automatically reopen so we know to update the user. It helps keep our inboxes clean and ensures we never forget to get back to a user.

What we measure

Peter Drucker said, “what gets measured gets managed”, allegedly at least. It may have been more accurate to say “what gets measured gets gamed”, as we’ve pointed out before. We don’t use metrics as part of our team’s performance review process but rather as a set of indicators of the overall health of our team.

Contacts per active user per week: Are our active users getting in touch more or less over time? We keep a very close eye on this stat. Think of this as a growth-adjusted gauge of your workload. It can vary greatly between different sectors and businesses but any sharp increase here deserves swift investigation.

Time to first response: It is important to know how long customers wait before they hear back from anyone. Being an easy stat to game however, makes this a terrible performance indicator. A related aside: Instead of focusing on “first contact resolution”, which receives far too much attention in our industry, we strive for “next contact avoidance”, i.e. how can we answer the next question a user is likely to have before they know they have it.

Overall number of contacts per week: This is a measure of your overall load, if your business is growing it’s likely this is growing more or less in lockstep with your user base. We use it mostly to plan hiring.

Contacts per hour of the day and per day of the week: These are two other stats that are helpful for hiring planning. e.g. “Do we need someone in GMT or PST?” or “Should we think about a dedicated person on the weekends?”

Percentage of new users contacting within their first week: This is a very loose measure of how confusing or intimidating your product is for new users. While we’ve captured this for a long time, because it’s influenced by so many factors, it’s of limited use. Ideally, we would be able to graph the distribution of contacts over the life of a customer. While the percentage of users getting in touch in the their first week gives us a small (yet important) window into the most important part of this distribution, knowing how your users need to lean on your expertise over time would reveal very interesting things.

Tracking user feedback

Staying on top of hyper growth is challenging when it comes to customer support. Having the right types of customer conversations is key to maintaining and handling that growth. This means methodically tracking user feedback is critical.

Whatever process you use to capture all the great feedback your users regularly offer you needs to be lightweight, both mentally and physically, for both the person recording the feedback and anyone looking to read it. Any bloated process in feedback tracking results in inefficiency or inaccuracy, likely both.

We use tags on messages and replies from users to track what is being said and which team it relates to. We have a tag for each of the teams within the company and a set of topic tags that describe what each question pertains to. Each message or reply that constitutes a new question or piece of feedback is tagged with both a team and a topic tag (Pro tip: “shift+t” allows you to quickly tag the last contact from the user in a conversation).

Our topics are as follows:

1. Feature request: Just what it sounds like.
2. Bug report: Fairly obvious, any user issue that results in the creation of a bug report.
3. Unaware: The user is unaware something is possible or that documentation already exists.
4. Confused: The user is confused by how the product works or how UI looks.
5. User issue: The user requires some help/info/debugging from the team. This is one step below a bug report insomuch as the user needs help to move forward but it isn’t a bug in our software.
6. Pricing question: The user has a question about our pricing.
7. Positive user feedback: When someone says something nice about us or the product.
8. Churn feedback: The user is telling us about why they cancelled.
9. Outage/Degradation: When the app is slow or down and users get in touch. We track these to help our infrastructure team track the customer facing effect of outages.

Important note: Our tags are deliberately mutually exclusive and collectively exhaustive, everything gets recorded but only recorded once.

These tagged conversations make it easy for product teams to quickly see what customers are requesting from their parts of the product and where customers are confused or having trouble. The fact that it’s so quick and easy ensures that this feedback is regularly read, processed, and considered in our roadmap.

Everyone talks to customers

Intercom, the product and the company, is all about communicating with customers. To help re-enforce that connection every Intercomrade is expected to regularly spend a day in the inbox supporting our customers. These customer days give people the chance to experience the demands of a very busy inbox, gives them insights into where we’re falling short, and reminds everyone that we’re doing all of this for our customers. We encourage everyone to write a few notes after each customer day and the archive of these notes are a fantastic reminder of just how far we’ve come. If your company doesn’t push everyone to talk to users I strongly recommend starting a customer day scheme.

The bigger picture

At a very high level, it’s important to think in both the short term (solving today’s customer questions) and the long term (making sure this confusion doesn’t scale). If 1 in 10 new sign-ups for your new product or feature has a question about adding teammates, it might seem like “no big deal” to simply answer that a couple of times a day. But as you scale this just doesn’t work. Soon you’ll be employing people in full time jobs, just to tell customers how to add their teammates.

Using a support team as a crutch for bad design or implementation causes long term damage, it robs the product team of necessary feedback to create a great product, and robs the individuals involved of the feedback necessary to make them great designers & engineers. A scaleable feedback loop is the best way to avoid this.

Supporting your customers is one area where, contrary to other startup advice, you do things that scale well.