The Knowledge Roundtable is a group of Zendesk customers who have responsibility for knowledge and self-service at their companies. They share their expertise with you here on a specific topic.

The topic this time is: What is your strategy for restricted content?

Meet the panel and read their advice below:

• Maggie St. Clair, Community Specialist, Cargas
• Anton Maslov, Operations Manager, Plesk
• Jim Kimble, Customer Experience Manager
• Mary Paez, Knowledge Manager, Veeva
• Sherri Anderson, Product Manager, Laivly
• Maggie Ungerboeck, Manager of Training & Education, Ungerboeck Software
• Andrei Kamarouski, Private Consultant & CEO, Pythia
• Ben Garris, KCS Program Manager, Republic Wireless
• Allison Sargent, Customer Support Advocate, Pinger

Be sure to add a comment to ask a question or share your ideas. And check out the complete list of KM Roundtable discussions.

Maggie St. Clair, Community Specialist, Cargas

Last year we implemented restricted content in our Help Center. We have some content that we only want our customers to have access to, but we have both customers, partners, and a few outside business contacts set up in our Help Center.

Since our partners and the outside business contacts work with many of our competitors we feel that there is some content that they should not have access to. This includes information on our product roadmap, beta release content, and certain processes and procedures.

We also have restricted content that is based around the current beta release of our software. We only allow customers that have been accepted into our Beta Program to have access to the content relating to beta features and processes. This helps keep customers focused on the features that they have available to them in their version of the software.

For both methods of restricted content, we set up user segments based on organizations. We created a user segment called Customers and then added all of our customer organizations into that user segment. Our partners are also all assigned to an organization, so we exclude those organizations from the user segment setup. We also have a user segment called Beta Testers which has only those organizations that were accepted into our Beta Program – usually 3 to 5 organizations at a time.

When an article is being reviewed prior to publishing, we make sure that the “Visible to” drop down is set to Customers if the content should be hidden from our partners. If the content should be visible to customers and partners we use the  Signed-in users option. For our beta content, we select Beta Testers from the “Visible to” drop down.

We have opted for a very basic setup for our restricted content, but it has worked well for us so far. As both our customer base and content grow we may need to expand or adjust this setup, but for now, this process works great for our needs.

Anton Maslov, Operations Manager, Plesk

Let me share our implementation. Generally, we believe this idea: in result all the _actual_ content should be visible to our customers.

But, to keep a high level of content and healthy database you have to consider the following:

• You should archive old articles
• You should make sure your instructions are valid and safe

Now a bit more details about above:

Archiving articles: It is needed to keep your search results good and relevant. Thus, we do archive (move to internal section) automatically articles that were not used in tickets and did not receive likes from our customers.

Keeping articles valid: Even all the articles are reviewed by experts before being published, there is a still chance they missed something or it will work a bit different environment. To avoid this, we first publish each article to internal section, so it is available for engineers. As soon as it is reused in 3 tickets successfully, we consider it as “verified” and publish externally.

Along with that, we also monitor satisfaction per article: if something is getting a lot of dislikes we move it to an internal section and review it to find out why it might not work for customers. 

That’s it.

A side note here: We would really like to have internal comments in articles (I know you have a feature request for that). Sometimes you need to leave internal comment for engineers, but keep in overall solution shared.

Jim Kimble, Customer Experience Manager

We don't have any content that is restricted to a particular subset of users. The majority of our knowledge base is published to the end-user with a small subset of developing content visible only to agents.

Our content pipeline combines traditional "seeded" content with content developed in response to customer inquiries using the Knowledge Centered Service methodology. This means that content created by agents develops and is published to end users based on usage, while a very small set of seeded content is published to end users immediately.

Agent created content is published into a specific section of the site that is restricted to Agents and Managers. As that content gets used to solve tickets we promote into an end-user visible section under the associated product.

When content is no longer used, falling below a threshold of views and references during ticket resolution, is it removed from the site.

Mary Paez, Knowledge Manager, Veeva 

The ability to have various levels of restricted articles is important.  This allows the information to be used by a variety of audiences. We have three types of content in our Knowledge Base.

We use Management Permissions to secure the articles.

• Everyone (Public): anyone can view our articles and community posts and can do a Google search to find content. These articles include: ticket solutions, Q&As, Getting started topics, known errors, etc.
• Internal-Only: this information can be accessed by support staff or members of other Veeva departments globally. Much of this information is used for internal enablement of new staff. These articles can include: configurations, specific customer-related information, issues to be aware of, etc.
• Signed-In Users: Part of our KB requires that only Veeva customers & partners can access. It includes Release information, Data Model information, and product webinars.

We created User segments to help divide people into different groups:

Staff Members:

• KCS1: Can create, save, edit, and send their own article for review using the Team Publishing Assign button
• KCS2: Can create, review, save, edit, and their own  article
• KCS3: Subject Matter expert can create, review, save, edit, and publish anyone’s article
• Agents and Managers – (built in segment) all internal staff who publish articles are assigned to this group

Signed-In Users

• Signed-In Users (built in segment)
• Veeva Internal – all support agents are assigned to this group

For our publishing workflow, we allow anyone with a KCS1 tag on their user profile to create, save, edit, and submit articles for review.  Anyone with KCS2 or KCS3 is a publisher in addition to the KCS1 permissions.

Current needs:

• We need a way to provide internal comments on articles (any of the three types) so that agents can add notes for other agents and staff regarding the article content
• We need a way to restrict Sections on the portal.  This would act as a 2nd layer of security.  We have had situations where an agent or two have accidentally set the article Visible to field as “Everyone” when it was clearly Internal.  The article was placed into a section labeled Internal, however the settings to secure a section were removed by ZD in the Permissions EAP. If a section could be secure, then just classifying the article into that section would change the visible to propery of the article properly.
• We need a way to associate the article back to the ticket. Often an agent wants to view the related ticket to the article. And, vice versa, easily see the article created from a ticket. But, at this time it is not available.
• The Ability to set expiry dates on individual articles since we have such a variety of content.  Some of that content will be good for a number of years. Other content must be reviewed as of the next product release to keep it current, relevant, and accurate.

We believe with some of these extra features, it will really help us keep the right content secure and allow us to get to the information we need quickly. Since our Company value is Speed, this is truly important and top on our list.

We are excited about new ZD EAPs to hopefully address some of these very helpful features.

Sherri Anderson, Product Manager, Laivly

Maggie Ungerboeck, Manager of Training & Education, Ungerboeck Software

We restrict Help Center content to only signed-in users and use user segments to control which articles a signed-in user can view.

User Segments

We use user segments to restrict content within the Help Center because we have a single software package that serves three different industries. The parts of the software someone may use depends on what industry that person represents. Because we have so much Help Center content (almost 2500 published articles) we use the user segments to show signed-in users only the articles that apply to them when they are searching or browsing the Help Center and to hide the articles for software products that don’t apply to them.  

User Segment Setup

We have about 15 user segments that we use to restrict access to Help Center content. Each user segment is assigned a tag. Below is an example of a user segment:

If the organization a Zendesk user is attached to has the tag on the user segment, then the user can view the article.

We tag organizations in Zendesk using the Zendesk API. We use the API to update the tags in Zendesk from the software our company uses to manage our customers. This automates the entire tagging process for us.

Since a user’s user segments is dependent upon the organization assigned to the user, we must make sure each Zendesk user account is assigned to the correct organization. Most of the time, this handles itself because the user signs up and uses the email domain that exists for the organization in Zendesk. The user gets automatically assigned to the Zendesk organization and everything works as it should.

However, there are times where someone signs up using a domain that isn’t assigned to an organization. To catch these users, I use a view for users that have no organization assigned. I review this weekly and either assign users to the proper organization, suspend them or delete them as appropriate. Most weeks, there are 10 or less users who fall into this category so managing these has not been difficult.

User Segments for Topics

We have also taken the user segment approach with our community topics. We have used the same concept as we have with articles; users can see the topics for the products that apply to them. We have also created some invite-only topics and control who can post using the user segments.

Andrei Kamarouski, Private Consultant & CEO, Pythia

In my consulting practice, I'm rarely using content restriction feature (I have assisted 100+ businesses in Zendesk setup/administration). However, this is a very powerful feature when you need to manage content access for different segments of customers/employees.

I have one use case of content restriction which is used more or less often. This case is applied by 2 of my clients – large telecom brand and multi-brand ecommerce company. It's Internal KB, a special KB for support managers and agents (new or existing ones).

Typically there is a dedicated category for this purpose and many sections inside. In both cases, all agents are 'universal' (it means serving any kind of request) so they are not restricted to access content inside Internal KB.

I should note that using the restricted content is very comfortable with Knowledge Capture app – agents can find all the articles right inside ticket and they are limited to link restricted articles to end-users' tickets. That way agents avoid sharing private content.

Ben Garris, KCS Program Manager, Republic Wireless

Allison Sargent, Customer Support Advocate, Pinger

Do you have restricted content in your Help Center? Why or why not?

We currently do not require end-users to sign into our Help Sites. Our mission is to make as much of our content external as we can in order to provide full transparency to our end-users. We are an application developer, and thus our users come to our Help Site for a variety of reasons, from troubleshooting calling/messaging issues, to learning more about the features and benefits of our apps.

We believe that the additional step of having users sign-in to view content would deter most of them from attempting to self-serve. Our users might get frustrated that they have to sign in to view the content when we know how important it is for them to self-serve in a timely manner. Many of our customers use our application for their business, so it is crucial for them to find a solution as soon as possible as any delay could cause a disruption in their business. 

Is all content restricted or certain content? What kind of content is restricted? 

The only content that we restrict is our internal knowledge-base which includes (but is not limited to):

• Internal processes & procedures (i.e. when/how to escalate a ticket)
• Internal Tool Usage (i.e. how to make adjustments to a user’s account using our support tools)
• Tips on communication with customers (i.e. how to handle difficult or angry customers)

How are the restrictions implemented? Please give setup details.

The current setup for our internal knowledge-based content (restricted) is in a category titled “Shared Knowledge.” I broke up our restricted content into sections based on some of the common topics that we receive tickets for (i.e. calling, messaging etc.)

We are working on re-structuring our internal knowledge base, but we definitely see the value in having restricted content for our agents as this will help them give our users a solution to their problem which should increase our customer service efforts and CSAT.