Recently we spoke to Karissa Van Baulen, Customer Education Lead at Hotjar. We dived into everything from using customer empathy to prioritize which topics to cover next in a help center, and educating customers on how to use documentation, to advice on how to keep knowledge content up to date.
Hotjar is a tool used by organizations that aim to improve the user experience of their website. This powerful SaaS app evaluates online user behavior by combining both Analysis and Feedback tools. With Hotjar, companies can see and “hear” what their customers are saying, and use this first-hand to improve performance and conversion rates.
Karissa’s experience and knowledge in Customer Education and Self-Service offer such valuable and important takeaways. Let’s get into it!
Can you tell us a few words about yourself and your current role?
I’m Karissa Van Baulen, a Customer Education Lead, digital nomad, and cheese enthusiast. My CEd team is made up of 2 content managers, an operations manager (who manages our code), and a Sr. CEd manager focused on eLearning.
Our team owns the help center and our eLearning platform, Hotjar Learning. I started at my company as a Support Specialist and, after finding communities like Write the Docs, realized that help center management was something people did as a career. I was hooked and started getting support from my managers to own the help center. That was about 5 ½ years ago, and our educational content is still growing.
How many help centers do you manage, and how many articles in total?
We only have our main help center help.hotjar.com, hosted on Zendesk Guides, with about 209 published articles.
How do you measure the success of your help center as a whole, and of individual articles?
This is a fun question because the options are endless. I am HUGE into data and analytics for documentation, so we have a lot going on here. I’m a sucker for Self Service Score, the # of sessions/ # of sessions that include a ticket submission. It gives you a ratio that says, “Okay, for every person who submits a ticket, X find what they need from the documentation.” There are some caveats here because someone might leave if they get frustrated, get distracted, or leave their tab open until it times out. That is why it is best to pair this metric with some visual data (i.e., heatmaps, recordings, a feedback tool) to ensure your readers leave because they found their answer rather than getting frustrated.
We also have a very elaborate health metric called our Helpfulness Index. It can’t take credit for this; our brilliant Adrian Kelly masterminded this with the thumbs-up and downvotes that Zendesk lets you do. It takes the total votes, thumbs up, and thumbs down sum and compares it to all the other documents in the entire help center. Then places it on a scale from 0 to 1. The closer to a 1, the better the article is performing. The closer to 0, it immediately needs help.
We also dig into Mixpanel and Google Data Studio frequently to take a look at things like popular sections, how users interact with our product after reading documentation, and of course, basics like bounce %, exit %, and time spent on the page.
As I said, we have a lot going on here 😅
In a fast-paced environment, it is easy for help documentation to become outdated. What processes do you use to keep the content up to date?
Yes, yes, and yes. This is something that we have struggled with historically and still do to this day. No matter how many documentation people I chat with in SaaS, this topic always comes up.
The truth is that we don’t have it figured out - and that is okay. Our workflow is flexible to accommodate our growing product team. That might scare people - it scares me sometimes - but it’s what works for us.
Some structures we have done in the past include having a writer assigned to each product team, having general writers who can write on any topic, siloing writers to work on specific topics, having reps from the support team write documentation, having PMs write bullet points on new features and then the writers (us) elaborating on them … the list goes on. I’d say our most successful setup was when we had one writer per product group. However, we are at a point now where there are about 15 product teams, so we can no longer support that structure.
Be flexible and try new, possibly scary, things to see what works for your team.
My best advice is to be flexible and try new, possibly scary, things to see what works for your team. With a growing company comes a change in the structure, so if you don’t adapt, you will get lost in the shuffle.
Knowledge about a product or service is often spread across the organization. How do you and your team collaborate with subject matter experts to produce the most helpful and accurate content?
Interestingly enough, we see ourselves as SMEs in this aspect. Most of us have a Support background, so we are well-versed in our product. For our newer team members, the onboarding includes two full weeks of product knowledge training.
On top of that, we encourage customer interviews to be conducted quarterly so the team members can ask the questions that they are dying to know directly to the customer.
We find cool use cases, new personas, and even FAQ topics from these calls. Right now, our research calls are mainly done by our eLearning team since it is the latest addition to our platform, but the same practice can be applied for growing out your help center documentation.
It happens quite often that customers are contacting Support for questions whose answers they could easily find in an article. How to teach your customers to use the help center instead?
We like to incorporate help center links within our support ticket responses. Since we use Zendesk, our support team uses macros to answer tickets, making it easy to incorporate related articles in responses. Typically we look at the most frequent questions our users ask and the most common macros sent to decide which ones should have a link to documentation or videos.
Getting the documentation embedded in-app took a while, but it pays off for both the user experience and our discoverability metrics.
Our product team also links to our documentation within the product so users can find documentation as soon as they need it. This increases our discoverability on the help center A LOT. Getting the documentation embedded in-app took a while, but it pays off for both the user experience and our discoverability metrics.
If your product or service is complex, there can be many topics you can write about in the help center at any given time. How do you prioritize? How do you decide which article on which topic to write next?
We look into prioritization in two ways: 1) based on commonly brought-up topics via support, success, and sales 2) visits compared to the helpfulness index.
The first is relatively straightforward - What do our users want to know? What are they struggling with the most? What is something that is always coming up, no matter the situation? We look at the most submitted support tickets and listen to recordings of calls with our CSMs and Sales to see what topics keep coming up.
On the listening to recordings of calls, I’d highly suggest you and your team start listening to recording calls of users. If your company doesn’t record calls, ask to shadow on some Success calls or even Product Research calls. You’d be amazed at some of the perspectives your users have about your product, use cases, and workarounds that your users have that you would have never dreamed of.
Listen to or participate in customer calls. You’d be amazed at some of the perspectives your users have about your product, use cases, and workarounds that your users have that you would have never dreamed of.
The second gets a bit more mathematical. We look at our helpfulness index (thumbs up vs. thumbs down votes) and compare them to our most visited pages. If a page with a massive volume of traffic isn’t performing well - it is our first priority to make sure that the doc is up to date, correct, and fixed up in any way we can to make sure those votes are going back up.
Sometimes we find that if a doc isn’t performing well, maybe there is too much content on it or the opposite, we are missing big chunks of the topic that isn’t documented correctly. From there, you can either update, merge existing content, or even create a new doc that covers areas you didn’t previously have documented very well.
If your help center is multilingual, what workflows do you use to manage translation from the core language to other languages?
We don't have articles in multiple languages, but in the process of doing this for German this year so excited to read others’ responses on this topic.
If you are managing a team: what KPIs do you track and set goals for your knowledge management team?
This might be a bit taboo, but I don’t like using team KPIs for individual contributor (IC) management purposes. It sends the message to the IC to “just hit a metric that was randomly set” rather than analyzing your work style to find learnings along the way of hitting a goal as a team.
For example, if you tell your team that you want them to get the time from R&D to Publishing down by 15%, it turns into a race to get the documentation done, and more mistakes start to appear because of rushing through editing/writing. Instead, I’d focus on having ICs review their writing process and identify 1 to 2 habits or practices they could cut out or change to reduce time.
That is a very specific example, but something I have seen, not only in documentation teams. When you focus on IC-specific metrics rather than an overall team goal, corners are cut to just hit the minimum with no long-term positive change.
Now obviously, it’s important to make sure that everyone is hitting basic quotas like X number of assignments a week/month. Still, ultimately, if you focus on entire team goals rather than tracking specific performance IC KPIs, I find you get better results and have higher morale on the team.
Anything else you'd like to share?
Haha, I could talk about this stuff all day, to be honest. Let me know if you have any follow-ups. Keep up the excellent work! I am really looking forward to seeing everyone’s responses.