Intercom Educate

Through late 2015 to 2016, I led the design work on one of the biggest project in Intercom - Educate. The product was launched in December 2016, and was helping more than 1700 businesses provide self-serve support in the first month (And continuously growing!). After two months, it’s making $1.5M in annual recurring revenue.

It was an unique experience for me to be able to work on a new product offering from the very beginning to launch, and continually leading post-launch iterations.

Product mission and vision

Educate is Intercom’s rethink of the “Self-serve support” job can be done.

Prior to Educate, user questions rely on support teams to read, investigate, and respond in a timely manner. As Intercom and its customers grow, it’s getting harder and harder to handle the scale of support volume. This led us to the motivation of developing a self-serve support product.

It’s true that Intercom’s mission is to make Internet businesses personal, so how would a self-serve product aligns with the company’s mission? As a team, we’ve came up with the following mission statement:

It turns out users sometimes don’t want to talk to a teammate and want to be able to find help content on their own. Companies need to produce help content in order to meet this need and allow them to scale their teams non-linearly to customer growth. They do this not to hide from customer relationships but in order to deal with the scale of relationships they need to maintain. Those users who do talk to teammates also benefit; the teammates are able to share help content in conversations, speeding up reply time whilst maintaining high quality and consistency.

By thinking through the product’s mission, it’s clear that what we’re building should not be a replacement for human contact. We’re not trying to hide customer support, but to provide a more efficient way for people to find help and with a clear path to contact the company if they couldn’t find the answer they needed themselves.

Ultimately, we didn’t want to just create a better version of a knowledge base product. We want to create a better solution to the problem.

Initial research and ideation


At the start of the project we’ve talked with our customers to understand what jobs they’re hiring knowledge base products for, what’s working well and what’s not.

The main findings pretty much aligned with the product mission: Companies value personal communication with their users, but find it hard to scale as their user base gets bigger. They hire knowledge base products to help answer simple repeated questions, so that their customers can possibly get helped faster and the team can focus on resolving conversations that require more investigations.

Almost all companies we’ve interviewed highlighted the job of maintaining help content as the biggest pain point:

This research inform the idea for opportunities to build feedback loops between the users and content creators, so that the product can provide signals for what content needs improving and what topics to write next.


In additional to input from research, we also had brainstorm sessions to try to imagine how we could tackle this self-serve job from first principles. We asked ourselves: how could we make this product more personal? How could it take advantage of the existing Intercom platform and be more integrated?

System design

With all these individual ideas written in words and sketched on whiteboard, the next thing I have done was to design a system to encapsulate the main product ideas, and describe how the product would work at a high level. (I wrote a post on how I’ve developed this system design)

This system tells a story:

Having developed a high level system for this product, we could then break it down into smaller and manageable parts to tackle one by one.

Content management system

First thing first, we need to enable companies create and manage articles.

Fortunately, Intercom already offer a rich WYSIWYG (What you see is what you get) editor for composing messages, and a folder pattern for organising messages. Sticking with our design principles, we’ve decided to be consistent and reuse as much of the similar concepts and components as possible, so that our users don’t have to learn a completely new system when using our product.

We’ve intentionally minimised our effort on innovating the content management system as that’s not our primary area of innovation.

Help Center

The Help Center would serve as one of the primary channels for self-serve support as its content are indexed by search engines. From research we understood that people would try to search for answer directly through search engines if they failed to find their answers.

After evaluating the current standard of knowledge bases, I’d summarise them as “Impersonal”, “Static”, and “Basic”. Almost all of them were designed provide to help content without a sight of human touch. This is not the fault of the companies, but they’re inherited from the design thinking behind the knowledge base providers.

When we design the Help Center, we had the following principles in mind:

These principles led us to making design decisions such as showing faces of the help content authors, when they last updated the content, and to have a Intercom Messenger always available if people have further questions (We don’t aim to hide human contact).

Article feedback loop

As mentioned previously, we want to enable end-users to give feedback to the content creator whenever possible, so that they could continuously improve their content. We’ve designed a delightful interaction that, when a user reacted negatively to an article, it triggers a personal message from the author to provide further assistant.

During the user tests, a few people naturally described this experience as “Personal” and “Helpful”. It makes them feel like the author really cares about the helpfulness of their content. This matches exactly the experience we wanted to create.

Article cards in conversations

So far, we have created a content management system and a public help centre. In theory, we could have launched what we’ve developed. But we didn’t want to stop here, we didn’t just want to create a “better knowledge base”. And this is when we focus our effort on expanding the help content to other channels - in Messenger conversations.

The basic premise simple - when support teams are having conversation with users, they should be able to find, preview, and send articles that help answer user’s question with ease. This should be integrated into their main workflow, instead of having to manually copy and pasting links from the Help Center.

On the end-user side, we believe that it is not an ideal experience to send them to the Help Center when they’re in the middle of a conversation flow. Instead, we designed an experience where they could read the articles in situ where the conversation is happening.

Article suggestions

Drawn from one of the ideas from the initial brainstorm sessions - we have an interesting opportunity to develop a recommender system to suggest relevant articles based on the user question.

Without going into too much detail, this system would operate by learning how articles are used in past conversations, and recommend articles if a new question contains similar keywords.

My role as a designer was to design how the suggestions are surfaced to support teams, the interaction of preview and send the suggested articles, and to educate support teams that the more articles they send, the better the suggestions will become.

This interaction follows the pattern of how suggestions are usually made in mobile apps (e.g. iOS keyboard suggestions, Facebook Messenger, Telegram, etc.), so that the support teams will have some level of familiarity with the interaction for a relatively new concept.


Insights is the last piece of product we wanted to develop within the scope of the first launch. Historically, Intercom doesn’t aim to become a comprehensive analytics tool. Instead, we focus on trying to understand the job to be done and directly provide actionable insights to our customers. Educate Insights is no exceptional to this.

When we design Educate Insights, we focused on addressing the following 3 main jobs we learnt from research.

When I evaluate how my help content are doing, I want to know…

  • How much support time and effort has been saved, so that I can continue invest time in updating content for the help site.
  • What content we need to write next, so that we can address the demand.
  • What articles we need to improve or update and why, so that we can make the right content update.

The top section of this page proves the success of help content by showing the volume of people read the help articles, and how often support teams use them to answer questions in conversations.

The second section highlights what people have been searching for in the Help Center and got no search results. This shows what topics of article they could write to answer people’s questions.

The last section ranks existing articles by performance (A score based on factors such as number of views, last updated date, number of questions people had after reading, etc), so that the author can look into how they can improve their articles.


What I haven’t covered in this case study was the iterations we’ve made after learnings from beta, and the design of the on boarding process. In December 2016, we've hitted our milestones and launched the product publicly.

In retrospect, I believe our product success isn't because we've built a more powerful knowledge base product, but because we've built a simpler product for the job from first principles. Launching the product was just a start. It sets us up for a lot of opportunities where we can make the product even better.

As you can see, this is a massive team effort which took months to get the multiple product parts to production ready.

In this project I was very forunate to collaborate with:

Aside from the financial success as I’ve highlighted at the start, I’m particularly proud of seeing Educate is powering the Help Center of good companies such as Product Hunt, Expensify, Barematrics,, Figma, Atomic.

The sentiments we got since launch was very positive as well. As an ending to this case study, let me just highlight some of my favourite quotes 😃