Improve digital support experience through KB
Problem Statement
What is the problem?
We've talked about improving the customer experience through ticket deflection in the past.
We have touchpoints on each of the four pillars outlined there, but our "Documentation" pillar is disconnected from the flow customers go through when opening a ticket.
More, the type of content that a customer might look to be encountering at the time of opening a ticket may not be just a docs page. There's a content gap between our technical documentation and how-to/troubleshooting information.
Why is this a problem?
We want to delight our customers, specifically:
Improve our ways to serve customers and resolve their problems before a ticket is even opened while keeping that context to enrich tickets for Support Engineers if a ticket is needed.
Not having a compelling digital support experience:
- increases ticket volume
- reduces ticket quality
- reinforces a reactive cycle when it comes to helping customers
Proposal
Start to build out KB articles within Zendesk that can:
- be surfaced to customers at the time of ticket creation
- updated by Support Engineers with minimal friction
- provide a source of information that helps customers self-serve, or enrich their tickets with more troubleshooting information.
The intent is not to replace documentation or duplicate information. (In fact, I expect we'll be linking to documentation quite a lot!). The SSOT for technical reference material is and will continue to be our docs.
Knowledge Base content suitable for a customer audience should:
- be instructive
- address specific, common issues with practical step-by-step solutions
- include real-world examples to illustrate points and solutions
- provide links to technical documentation
In the past, for some topics, we created blind redirects to docs - which I think may also be a valid strategy in some cases, or even a great first iteration.
The outcomes I'm looking for:
- reduction in overall cases, in particular ones where we have KB articles
- live-population of KB articles as a customer types a subject (ZD does this already if relevant articles exist)
DRI
This is probably going to get promoted to an epic, so I expect multiple DRIs.
I'm certainly coordinating.
Required Resources
We don't actually need a ton for this, as we already have a repo set up for articles that can/will sync to Guide after some initial setup: https://gitlab.com/gitlab-com/support/support-pages
(See: https://handbook.gitlab.com/handbook/support/readiness/operations/docs/zendesk/articles/ for more)
The main things we need to start are data and effort.
Data
Fortunately, I have some data already!
FrameAI
Last quarter, our top categories of Support tickets (gathered from Frame) by cost:
- CI/CD
- Problems, Errors, Performance
- Project / Group Management
- GitLab Runners
- Maintaining / Administering GitLab
- Authentication and Authorization
- Secure (SAST, DAST)
- Installing/Configuring/Migrating
- Upgrade Assistance
- Packages and Registries
By volume, subcategories:
- 2FA Removal
- Docker (in the context of CI/CD)
- Cannot login
- Kubernetes - Helm
- GitLab.com Shared Runners
- Pipelines
- Cannot get confirmation email
- Linux
- Other/Unsure
- SAML
Barriers to Adoption activity
Last quarter, we had William Arias (Community) and Kevin Dietz (Data) did some analysis of Support Ticket data. You can view the full readout here: Barriers to Adoption: Support Ticket Analysis (SAFE, internal only)
William and Kevin's analysis were separate and using two different, unique methodologies. The overall deck is interesting, but Slide 29 and 30 (as well as some earlier slides) call out some specific areas we might consider investing in:
- SSO, LDAP and SAML configuration
- Kubernetes Runner Executor
- Multi-project / Parent-Child pipelines
- Merge Request Pipelines and approval rules
There also noted Secure tickets as a high area of support interest from Ultimate customers.
Effort
Potential Roadblocks/Things to consider
We want to avoid:
- duplicating content between docs and KB articles
- duplicating effort between groups (SAs may have some relevant content already, for example)
Desired Outcome
What does success look like?
Success is:
- Creating 5-10 articles
- Looking for reduction in support costs in those areas
- Looking at views on those articles (Google Analytics)
Areas I want to immediately target for KB articles, based on the data above:
-
SAML -
2FA Removal: support-pages!29 (diffs) -
Confirmation emails -
Upgrade assistance -
GitLab Performance problems -
CI/CD -
GitLab in K8s (Helm and Runner) -
Others??
As an initial iteration, I think the articles should focus on the support story for these items:
- what info will we typically ask for in these cases
- what are some common pitfalls that aren't documented (question: should they be in the documentation?)
- cross link to any/all relevant documentation
How do we measure success?
- Ticket volume in targeted areas: down.
- Views on articles and exits in Google analytics: up.
- Support costs in targeted areas: down.
Where would future feedback go?
Let's use this issue - it'll be a longer term project to gather the data to validate the approach.