← Back

Intercom Educate

Self-serve customer support platform
OVERVIEW

I led the design work for one of the biggest projects 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. After two months, it’s making $1.5M in annual recurring revenue.

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

TEAM

Tom Richards & Mark Ryan - Product managers
Emma Meehan - Product researcher
Elizabeth McGuane - Content Strategist lead
Jakub Antalík - Visual designer
Kostya Gorskiy - Design manager

TIMELINE

Late 2015 - 2016

LINK

Intercom Educate

Problem to solve

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. From the end-user perspective, they need to wait a long time for support teams to respond even for a simple problem.

This problem has been reported as one of the top customer requests, and from our own support team. It led us to the motivation of developing a self-serve support product.

“I'm struggling to keep up with the volume of messages we're getting…”

Discovery research

I partnered with our researcher to find out what jobs our customers are 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.

When they receive a large volume of support questions, they want to use knowledge base products to help answer the simple repeated questions, so that their customers can get help faster and their teams can focus on resolving conversations that require more investigations.

Our targeted customers

We're designing for customer success teams of small startups who...

  • Usually have a single person as the owner of the knowledge base.
  • Have a team of 5-10 CS staffs who will use the knowledge base articles as reference to answer user questions.
  • Their products are unlike large scale complex products that require deep hierarchical levels of help content.

Top pain points

Almost all companies highlighted the job of maintaining help content as the biggest pain point:

  • It is hard to figure out what content are out of date, especially when there are changes in the product.
  • When they plan to write new help content, it’s not easy to know what topics they should write next that would provide the most impact.
  • It is usually one person’s job to maintain content, not a collaborative effort. A simple small content fix require requesting the person in charge.
  • Web analytics for knowledge base answers some basic questions such as what content are viewed most or least, but is not insightful enough to inform actionable changes.

End-user research findings

We also did some research with the consumers of knowledge bases to better understand their behavior and perceptions:

  • Some people would naturally look for self-serve channels before they’d consider contact support.
  • They perceive contacting support as more barriers to get their question answered quickly.

Ideation

Having enough signals to validate it’s a problem worth solving, I conducted a workshop with the product team and leaderships to explore multiple product ideas to address the problem. We ask ourself questions such as:

  • How might we provide better ways for users to find answers they need?
  • How might we make this product more personal? 
  • How might we provide better feedback loops for companies to write new content or update existing content?
  • How might it be more integrated with the Intercom product?

System design

Working with our product manager, we've translated these whiteboard level product ideas into a product system. It describes how the product would work at a high level. (I wrote a post on how we’ve developed this system design)

This system tells a story:

  • At its core, the system evolves around articles. Articles are help content written by the company to help answer common questions.
  • Teammates in the company use a content management system to create and manage articles. They can be grouped and organised into collections for users to browse.
  • Articles can be browsed and searched from the Intercom Messenger as well as a public Help Center. They can be delivered in a conversation manually by support team, or automatically by a bot.
  • In certain cases, a suggestion system will recommend relevant content for teammates in their conversation inbox, so that they may be able to answer people’s question faster.
  • Last and most importantly, no matter which channel users interact with the content, there will always be feedback loop in place to help the company improve their content, and to help the suggestion system learn improving its suggestion over time.

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, we wanted to develop the content management system so that our own CS team can start using it to write help articles and organize them into groups.

Fortunately there are many components within the messages product that we can reuse (The design pattern of grouping multiple messages; The WYSIWYG content editor).

We’ve also decided to keep the content hierarchy as simple as possible by restricting a maximum of two levels of groupings. This decision is based on a mix of data and our beliefs:

  • Looked at samples of knowledge base sites to find out content hierarchy companies need.
  • We believe deep and nest content hierarchy would introduce complexity for companies to manage, and for end-users to navigate.

Help Center

Next, we needed to design and develop the Help Center for the articles to appear in a publicly visible site that is indexable by search engines.

After evaluating the current standard of knowledge bases, I’d summarise them as “Impersonal”, “Static”, and “Basic”. Almost all of them were designed prevent any connection to support teams if users really couldn't find the answers they need.

DESIGN PRINCIPLES

  • Personal and alive - We want to clearly demonstrate that the content are prepared by the people in the company, and that they are up-to-date.
  • Part of the Intercom system - In terms of visual design, the look and feel should be similar to the Messenger’s visual system; In terms of product design, the Messenger and Help Center should feel they’re integrated, not two disconnected products.
  • Not static pages - We wanted to make the Help Center feels modern, fast, and create visual connection between pages through transitions.

Article feedback loop

One small delightful design detail to make the product more integrated with the Intercom messenger - when a person indicate they don’t find the article helpful, it’d automatically trigger a message from the content creator to ask further feedback.

When we tested this interaction in user testing, people naturally describe this interaction as “presently surprised”, “feels personal”. It makes them feel like the content creator really care about the quality of the content.

Within the Intercom app, content creators would be able to learn from the qualitative feedback and improve their articles.

Article cards in conversations

To better support CS teams answering user questions, we wanted to make help articles accessible directly within the support inbox, so that they don’t have to open a new tab, find the right content, and copy and paste link into the conversation.

On the end-user side, we designed an experience where they could read the articles in situ where the conversation is happening.

Article suggestions

We wanted to develop a recommendation system to automatically 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

Insights is the last piece of product we wanted to develop within the scope of the first launch. Instead of designing a rich data analytics tool, we wanted to focus on providing actionable insights to our customers.

When designing Educate Insights, we focused on addressing the following 3 main use cases found from research.

When evaluating how my help content are performing, I want to know…
  • How much support time and effort has been saved, so that I can decide if we should continue invest time in updating the content.
  • 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.

🚀 Launch!

After a couple of iterations based on learnings from beta and finalising the product on-boarding experience, we launched the product in December 2016. The feedback were overwhelmingly positive both qualitatively and quantitatively.

After the first month since launch, we had:

  • 2738 trial customers
  • 1737 paying customers
  • 553 customers with over 20 articles created
  • 628 customers with over 100 Help Centre views
  • 196 customers with over 20 articles used in conversation

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, Frame.io, Figma, Atomic.