How to build a self-service strategy from the ground up

Several years ago, the B2B SaaS company I was working at did not have a self-service strategy — its Help center was not the talk of the town, nor did it have a community. It was a startup of around 200 people, and hadn’t yet realized the importance of self-service. I’d been there a year building a UX team and a platform design when all of the sudden, I was asked to also take on the content team. As a former technical writer, this was right up my alley. Content and design are two sides of the same coin.

In this article, I’ll cover:

• determining your current self-service score
• building the self-service — live support partnership
• identifying missing content and optimizing SEO
• ensuring users can recover from errors quickly
• creating an engaged community
• building a feedback mechanism for customers
• integrating live support
• improving ticket resolution time via built-in customer account access

What’s not covered

There are two areas that aren’t covered here — creating a content style guide to make any existing and future content consistent and setting up Google Analytics (Universal) so that you can track Help center usage. For a content style guide, you’ll need to figure out your own standards, and there are a lot of good guides out there that you can steal from.

For Google Analytics tracking, you’ll need to install the tracking snippet script from Google Analytics into the head of your help center code. Once you have that, you’ll be able to see which content is most frequently accessed in the Search Terms section. You can also set up Google Search Console in Google Analytics to see how people are searching for and accessing your Help center from search engines.

Once you have Google Analytics tracking, you can see the number of Help center users that have. That, along with the number of unique users that are submitting support tickets, are critical to determining your self-service score. A unique user means that only 1 ticket requester is counted, no matter how many tickets that person submits.

Determine your current self-service score

At the time I took over the content team, the Help center was a place where no one went. No one was measuring anything like a self-service score. But, as a UXer, I know benchmarking where you are (your as-is state) is critical to figuring out how to improve it. Since I was using Zendesk, I calculated the score by number of users in the Help center / number of unique ticket requesters. The score was a dismal 3:1, which meant that only 3 of 4 users were using the help center, the other was entering a ticket. But we now had something tangible to get started from. It was a base on which to build the content strategy and to justify scaling up the team from just me to a much larger, international team. By the time I left, it was 22:1!

Build a strong relationship with your partner, the support team

Having worked with support teams in previous companies and having most recently worked in IT Service Management (ITSM) product design (issue and change management), I knew that one of the critical things for anyone working in self-service — which encompasses anyone who is designing products, creating onboarding call-outs and guides, improving a free trial experience, testing products, creating technical content for users, writing help text and microcontent, etc. — we’re all partnering with the live support service. If we do our jobs well, we’ll be making our customers’ and our support agents’ lives easier, freeing them up from the mundane questions of “How do I get started?” and “What do I do next?” to meatier customer problems that actually impact their business, their own career success, and that ideally convert them to your product champions. Thankfully, the head of support was open to such a partnership, and I quickly strengthened that by helping improve her support team’s experience.

Improve the support agents’ experience and ticket resolution time

The first thing I did to build up the support-self-service relationship was to understand the pain points the support team was running into. A big one was that the Help center, as afore-mentioned, did not have enough content to help them answer questions quickly, but the other big one was that the Help center wasn’t integrated into their support agent UI. In this case, we were using Zendesk. As a UXer, I know the importance of not taking someone out of the context of their task. So how could I improve this?

Lo and behold, Zendesk has a widget, Knowledge Capture, that will suggest articles based on the support ticket’s subject and description. You could also set it up with templates so that the support team could create articles on the fly. That latter part hasn’t been too successful, although I’ve helped some of the support agents to become better article writers. However, the ability to link suggestions or search within the Help center for a better match has been invaluable. This also reduced the Time-to-Resolve (TTR), as support agents could now look for information directly in the integrated Help center and no longer needed to jump out of the support UI or try to remember particular links in the Help center.

Build a self-service community: What questions are your customers and employees asking?

In addition to the fact that the Help center didn’t have enough content, there was no community to help in self-service. So I determined to build one. I’d not built a community before, so I read up on the best practices of community platforms that had helped SaaS customers build engaged communities.

There were a few untouched areas that we could plumb for content to seed the community — one was “one-touch tickets”, or tickets that are resolved with just one outreach from support; the other was a huge backlog of support tickets that our support team had been optimistically flagging as needing updates. A third was search terms that our customers had searched on, but either not been able to find or the results returned didn’t meet their needs. And a fourth was internal questions — that is where we started, but we soon had to move into support tickets. Our goal was to create a new valuable support ticket-based community post every day, and between three of us, we did this for an entire year.

Missing content cave #1: Articles flagged by support as needing updates or more robust content

After looking into several one-touch tickets, I determined to start with the flagged tickets. After all, you have to start somewhere and unless you’re a huge company, which we weren’t, you will have a limited amount of resources and bandwidth to do too much spelunking down into missing content caves! I took the two tech writers I had and enlisted them on a revolving basis to boldly seek out and destroy missing content wherever it may hide. The three of us went through many flagged tickets each day. Whoever had a community post ready and reviewed by our intrepid support agents that we had pulled into our master plan would publish it on the community.

This was a technical platform, so it took some pretty thorough spelunking and iteration to get content ready, but it was still faster than putting it into a PM review cycle, which was a problem for another day. The goal was to get quality content out every day, to show our customers that the community was becoming a place to get answers to common and not-so-common questions. The challenge was that we needed to take specific questions from customers and try to generalize them to the point that they would be helpful for other customers. This had the added benefit of improving our Google search results, as well as garnering interest from other teams at the company, particularly Marketing, which can be a challenge to break down silos with and to optimize the omnichannel experience. But that’s a challenge for another article!

Missing content cave #2: search terms with no results or with inadequate results

I used a few different sources to understand what our customers were searching on. As of January 2023, I was still using Google Analytics (Universal). I know that I need to upgrade to Google Analytics 4 by July, but that’s a problem for tomorrow! Here’s what I’m using:

• Google Analytics > Acquisition > Search Terms: This shows what search terms your customers are searching for within your Help center.
• Google Analytics > Acquisition > Search Console: This shows what search terms potential customers are searching for outside of your Help center (such as Google search), including how often your result displays on the search results (what it calls Impressions), as well as click-through rates.
• Zendesk Explore > Zendesk Guide dashboard: This shows what search terms customers are searching for, whether they’re refining search terms to improve search results, whether the search results meet their needs, top content, and more. I’ll explain that in more depth in this article.

Understanding Zendesk Guide SEO

If you’re using Zendesk, like I was, your ability to target particular best articles for SEO is limited. There are a number of factors that play into Zendesk’s SEO model:

• Meta descriptions are the first 140 characters of your article or post. It will be used as the summary when your article or post displays in Google’s or another search engine’s search results
• Canonical URLs. Per Google, “if you have a single page that’s accessible by multiple URLs, or different pages with similar content (for example, a page with both a mobile and a desktop version), Google sees these as duplicate versions of the same page. Google will choose one URL as the canonical version and crawl that, and all other URLs will be considered duplicate URLs and crawled less often.” If Zendesk encounters duplicate content on your Help center, it chooses which canonical URL it thinks is most important.
• Mobile-friendly pages. In 2015, Google changed its algorithm to boost mobile-friendly pages in their search results.
• Article title is most important for both articles and community posts, as well as for external searching. As of January 2023, they had the heaviest weighting at 3 across the board.
• Labels, or keywords, come in 2.8 for articles, but are not applicable for community posts. They also have no impact whatsoever on external searches from a search engine. As Google search is better than Zendesk’s own search, this is indeed a problem, as people will often search on Google to find content within your Help center. No matter how much great labeling you do, this isn’t a very effective means of boosting search accuracy.
• Section title is a 1.5 for articles, but has no impact on community posts or external searches.
• Body of article counts as a 1 for articles, as well as for external searches.
• Comment on an article or community post is a 1 for each, but has no impact on external searches
• Body of community post is a 1, but has no impact on external searches.
• There are many other factors such as exact match, stemmed match (e.g., “park” returns “parking”, “parked”), term frequency (number of matches in the title or body), length of article title (shorter titles are better for SEO), proximity of search terms in a search phrase to each other in a title or body, exact word order, query length (short queries of 1–2 words must have search results matching all words, while longer query search results must contain 40% of the search terms), fuzzy searching. See the Zendesk SEO model for more information.
• Article votes and community post votes. Oddly, even if you revise an article or community post after a downvote, you can never cancel out that downvote. It makes it so that you’re better off just creating the article or community post again, which goes against all best practices of content editing and content reuse!

With all of those factors in play, your best bets are to optimize the first 140 characters of your articles, your article and community post titles, your article section titles, and the body of your articles or community posts. And of course, test to make sure that your Help center is optimized for mobile.

Optimizing SEO in spite of Zendesk limitations

Discover your “no results” search terms

These are search terms that your customers are trying to find information on, but your Help center has no results for. This is the lowest-hanging fruit. In my case, I could find this in Google Analytics’ Search Terms, but for more depth, I could use Zendesk Explore. If you’re interested in digging into this further, here’s some more on optimizing search experience.

For example, you may find customers looking for an HTTP status code or an error code from a particular ERP or ecommerce application, such as NetSuite or Shopify. These are very easy to add. Take a look at what your competitors are doing to fill this doc gap. Remember, in the words of Austin Kleon, it’s okay to “steal like an artist”, as long as you make anything you borrow from better than the original!

How many “no results” search terms do you have? See if you can target a few of them every week or month. Many of them are easy to add. Make sure to measure this impact, and that you are adding the most valuable content first. In my case, since customers ran into HTTP status codes quite often, it made most sense to keep them in our product and in their task context by adding a topic on these codes. We certainly didn’t want them to go to competitors to find information on how to recover from errors in our product!

In my case, the next one to add were common errors from third-party applications used most frequently by our customers to integrate data. Although we couldn’t include all API errors from all these external applications, we could include those from most popular applications, particularly those API errors that customers ran into most often. For this, it was back to our invaluable partner — the live support team! They provided a list of common errors for the top 5 third-party applications, as well as possible resolutions.

Make sure your error messages enable users to recover quickly

Whether you’re optimizing your own platform or product’s error messages or those of an integrated third-party application, it’s critical to provide information to allow users to gracefully recover from the error quickly. Work with your development team to get a list of all errors. Review these errors. If they were originally written by engineers, they will likely contain technical jargon. If they were written by non-native English speakers, they may also contain typos or more formal English than you desire in order to align with your product’s voice and tone standards. If your company doesn’t have those standards yet, that’s a problem you’ll need to solve, but it can be done in part during this error message review. I also touch on it in the Content style guide section above.

For error messages, you want to be friendly, grammatically correct, and professional, but most of all, you want to enable your users to quickly recovery from the error. That means you will have to work with your engineers, QA, and support to determine how users are likely to encounter this error, as well as the known methods by which they can resolve the problem.

Build a community: Define what your community will encompass

To get started, I focused on creating the first line of self-service support. I also planned for future expansion, such as raising awareness of events, gamification, urgent notifications, and more. Since I was a team of one creating this vision and it didn’t have top-down support, I needed to start small to build momentum and interest from the rest of the company. The other person I pulled in was the woman who became my work spouse and partner in crime, the intrepid head of support.

Build feedback loop for customers

In addition to setting up a feedback email that customers could use to let us know about problems they’d run into, experiences that needed to be improved, and features that they’d like to see, the head of support and I integrated a third-party help bot widget into the product, which allowed users to choose the type of issue they’d like to report or whether they’d like to renew or upgrade: General UX, Bug, Issue, Renewal, Upgrade. We were limited by the bot’s drop-down list of issue types being about 8 characters, with no option to provide descriptions. This was using a tool called Gainsight PX that we had inherited, but our needs were quickly outstripping its functionality. As you read further, you’ll see that we replaced that with Zendesk’s Answer Bot.

Gamification with Zendesk

If you have a more robust community tool than Zendesk, then you’re luckier than we were! As it was, we had to create badges and promote people manually using Zendesk. There wasn’t a gamification board, either. It was very rudimentary and our plan was to get to a better community tool, but after analyzing the price of offerings against other hungry tool mouths we had to feed, at the time, we couldn’t justify the cost. We had to create manual badges to show those community members who were engaged and providing quality answers, as well as integrating the university and other application certifications. If we’d had the budget, I would have chosen Insided, as I created my community plan from reading their excellent documentation on creating a SaaS community.

Integrate Zendesk live chat and Answer Bot

After working with support for several years, we enabled the Zendesk Answer Bot. This was a machine learning (ML) article suggestion bot that improves its suggestions depending on whether the customer rated the suggestion helpful or not. I was quite surprised to find out that despite saying that it’s ML-driven, it does not train itself to give better suggestions based on whether the customers decide to click or not click suggestions. You actually have to do it manually by adding a use_for_answer_bot label in each of your articles if you want it to only pull from select Help center articles, such as most popular.

An unsolved challenge

A big challenge there was how to optimize these Answer Bot suggestions for all customers, as we had several applications than ran on our platform, but not all customers had subscriptions to these applications. Although we could control access to content via Zendesk’s permissions model, that would prevent us from being able to leverage the power of being publicly available with no authentication (sign in) required and thus included in Google search results. While I was there, I wasn’t able to get that problem solved, due to the limitations of Zendesk’s SEO. Unlike a real search engine such as Elastic Search, where I could boost metadata such as date published or updated, Zendesk had no concept of the time an article had been published having any impact on whether it was still relevant. In a Help center which by then had around 2000 articles, this was definitely a problem. The next step was to look into integrating external search engines, such as Elastic Search.

Provide live support to improve time to resolve issues

This was a solution which we integrated most recently. This was very exciting, as it brought decided to integrate Zendesk’s Web Widget for live chat. This enabled people to get Answer Bot suggestions, but if those didn’t meet their needs, they could then choose to live chat with an agent or submit a support ticket the old-fashioned way. If you’re using Zendesk, one limitation is that you’ll need to disable the Enable SSO to submit support tickets checkbox. This means that anyone who is authenticated into your platform will be able to submit support tickets, but that’s okay, because they are already authenticated, meaning that they are already users in your platform.

Enable support to access customer accounts as quickly as possible

Remember, the name of the game is to reduce friction throughout the customer journey. If your company doesn’t provide at least a read-only access to customer accounts or a quick way for users to provide access, this is the place to start. By providing read-only access, support agents can quickly identify if there’s an error in data entry, such as data mapping. In this case, our customers had to use JSON mapping and even handlebars to accurately map data between applications. Rather than spending a day or more with the back-and-forth of providing support access, this could be streamlined to mere seconds!

If your company doesn’t feel comfortable enabling read-only access by default, make this a quick checkbox that users can click, then specify how long to provide your support access. Most importantly, make sure customers have a quick way to revoke access at any time. The other most important thing is to make sure customers can tell the difference between changes they make vs those that the support agent makes. If your support agent has to escalate to Level II support or to Product or Engineering, this process will further ensure that the customer doesn’t have to waste time getting unstuck just to provide access to other people, who from their perspective, are just more people providing support.

Good luck with your own self-service strategy! Thanks for reading!