Intercom Educate

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.

‍

Our researcher conducted a study to find out what jobs our customers are hiring knowledge base products for, what’s working well and what’s not.

We found that 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.
• Have shallow topics 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

• 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.

I conducted a workshop with the product team and leadership team to explore multiple product ideas to address the problem.

• 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?

Working with the 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.

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).

While competitor products provide the option to create many nested levels of content, we've decided to restrict a maximum of two levels hierarchy in order to keep it simple for companies to manage, and for end-users to navigate.

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.

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, we would be able to show the conversations people had after reading the content, as a way for content creators to learn from the feedback and improve their articles.

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.

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 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.

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, Envoy, Atomic.