Process Change for Knowledge articles in Zendesk

GitLab Support: Process Change Rollout Plan

`Process Change for creating knowledge articles

The Story

We are changing the process for creating knowledge articles. Our goal is to use ZenDesk as a unified platform for both Support tickets and knowledge base development. By keeping support engineers in ZenDesk, we can streamline both support operations and article creation. ZenDesk offers the tools for efficiently creating articles, (and maintaining articles) which supports our overall objective of driving customer knowledge and enabling self-service.

The Roles

Schedule

  • Rollout to begin on this date May 19, 2025
  • Will the rollout be phased, such as by team or region? There will be phased features that are rolled out, but this will not be by region. See phases here
  • Adoption complete by this date June 2, 2025

Training

What do the users need to learn and how will they learn it? Do managers need to deliver training? Are there videos or tutorials or handbook pages or other materials? Training will be available Friday May 16th and will be added to the handbook.

Success Determination

We will measure Multiple aspects of knowledge. Articles Created, Drafts, Published, Views, Link to ticket, Updates, Performance, Feedback. As we grow our knowledge base, we will measure success by usage, but also by ticket deflection. As we proceed, we want to make sure we are seeing the benefit from creating and using knowledge. We expect to see Shorter resolution time for tickets, We expect to see that ticket deflection. Ticket deflection means that by using a knowledge article, the customer did not have to submit a ticket… As we go through phases, we expect that number to grow.

  • How we’re going to get that deflection? Growth in Article Views (Trend over time) As-is-Assessment
  • We look at the Impact on Support Engineers Volume/workload - are we doing the right thing, do we adjust
  • We look at the (Feedback) are we seeing feedback asking for where other knowledge is that we havent yet provided/ do we need to create more in certain feature areas.
  • Work with the Support Stable Counterparts/Product Teams to implement more knowledge. Where can we connect, add more knowledge.
  • Align with Product Documentation - we are about to implement Troubleshooting into knowledge articles. We are working with the product team to determine how we process these. Implement a review process (to refine current knowledge that we have) can we make it better, do we need to add more to our existing articles, is it accurate and is it relevant.

Over the phases, we know we’ll see knowledge views grow less tickets being created Which means that Our Self Service Success rate will be higher users being able to solve their issues through a knowledge article without opening a ticket. Also, we’ll see Tickets being resolved using knowledge articles - That means that our support engineers are consistently using knowledge to solve tickets and also contributing to the knowledge base. We metrics this by linking articles to support tickets. We’re going to create a dashboard that allows us to show the full story of Knowledge- The articles, the deflection, the performance, and activity. We have alot we can measure, and right now we are working on how we pull it all together to really show the ROI, the story, the trends.

Action Plan

  1. Create an item in the SWIR to announce the change and include The Story on date
    • NOTE: On the SWIR form, add the Manager Attention tag for policy changes and action items for Support Managers specifically (you can add multiple tags to a SWIR item)
  2. Post a message in the #support_team-chat Slack channel (or other support channel as appropriate) announcing the change and pointing to the SWIR announcement on date
  3. Announce the change and tell The Story in Team meetings by date
    • EMEA team meeting
    • AMER team meeting
    • APAC team meeting
  4. Other communications channels
    • Discuss in 1-1s, telling The Story, by date
    • Other communications channels, if required - for example, post to a CSM Slack channel if the CSMs are "impacted non-users"
  5. Report back on change adoption, concerns, etc. by date

Manager Acknowledgement Section

Expectations

Describe what is required of the managers when they review this issue.

  • Example: Your input is required before this change goes into effect. Check off your name when you have analyzed and commented as appropriate.
  • Example: Your acknowledgement is required for this change that takes effect on date XYZ. Check off your name to indicated you have reviewed the information, and will share it with your team.

Due Date

Check off your name by midnight UTC on: 202x-xx-xx

Names

Remove any subsections that are not applicable to your issue.

Support Managers

Sorted alphabetically by region / GitLab handle

AMER + USFed

APAC

EMEA

Staff Support Engineers

Ops

  • @jcolyer (remove backticks if Support Operations involvement is necessary for this)

Senior Management team

Follow-Up Plan

How will you follow-up to understand the results of the change, to make adjustments appropriately, and to rollback if necessary? These are typical questions you might want to answer here:

  • How will results be captured? By whom and by when?
  • What is the plan for considering and making quick improvements?
  • What is the plan should the change be deemed unsuccessful?
    • Is a rollback feasible, and if so how will it happen?
Edited by Lee Matos