Zendesk Review (formally Zendesk Realignment) is a yearly process we undergo to review how Zendesk is setup and ensure it works with the expectations of those using it. This is a lengthy process, but a vital one for the health and stability of Zendesk.
The first 8 stages are about information gathering. The purpose of each stage is:
| Stage | Purpose |
|---|---|
| 1 | Ticket Forms |
| 2 | Channels (forms, email, etc.) |
| 3 | Organization and User settings |
| 4 | Ticket Forms and Fields |
| 5 | Views, Agent Groups, SLAs/SLOs |
| 6 | Triggers and Automations |
| 7 | Triggers and Automations |
| 8 | Routing |
To start the process, create a new epic under the GitLab Support Team group with the following information:
Zendesk Review - FYxx - Instance (replacing xx with the
current fiscal year you are conducting the review during and Instance with
the Zendesk instance this is concerning)Zendesk Review for FYxx (replacing xx with the current
fiscal year you are conducting the review during)Support-Ops-Category::Zendesk ReviewZendesk::GlobalZendesk::US-FederalMake sure to keep this epic handy, as you'll be linking all future issues into it.
You will kick this off by generating an issue using the Zendesk Review Stage 1 issue template.
In this stage, we ask the teams using Zendesk what types of requests they normally receive. We want as much information here as is possible. The more details we get here, the better the end result. As such, we should encourage those participating to be as specific as is possible.
Once we have compiled a large list of data from those participating, we then need to categorize this data. The categorization table used for this should be done via a Google sheet and have the following column headers:
Request column.This should take a month, as this is stage will shape future stages.
Once you have compiled all the data and categorized it, request those participating review the Google sheet for accuracy. Make adjustments as needed. Once it all looks good, move on to stage 2.
You will kick this off by generating an issue using the Zendesk Review Stage 2 issue template.
In this stage, we need to determine the methods users should be using to reach out to the various teams using Zendesk. We primarily want to focus on if it should be via email or via forms. We want to ensure we catch all the various criteria users might use specific methods of contact.
This should take a week, as this will shape overall routing.
Once the information has been gathered, you are good to move onto stage 3.
You will kick this off by generating an issue using the Zendesk Review Stage 3 issue template.
In this stage, we focus on how end-users are categorized. Generally speaking, this would be by organization and by support level in terms of GitLab, but we still want to double-check and confirm this is correct.
This should take a week, as this will shape overall routing.
Once the information has been gathered, you are good to move onto stage 4.
You will kick this off by generating an issue using the Zendesk Review Stage 4 issue template.
In this stage, we want to focus on what kind of information should be present in a ticket at any given point. This includes both at creation and during the lifespan of the ticket. This is important, as it helps formulate what kind of questions we ask in the forms and what kinds of fields should exist. We also want to focus on what kind of conditional information should be present in the forms.
This should take a week, as this will shape overall routing and play heavily into existing workflows.
Once the information has been gathered, you are good to move onto stage 5.
You will kick this off by generating an issue using the Zendesk Review Stage 5 issue template.
In this stage, we focus on how tickets should be grouped and the SLAs/SLOs to use.
This should take a week, as this will shape overall routing and play heavily into existing workflows.
Once the information has been gathered, you are good to move onto stage 6.
You will kick this off by generating an issue using the Zendesk Review Stage 6 issue template.
In this stage, we help determine what kind of automated tasks should occur within Zendesk. This is important for determining what kind of triggers and automations will be needed.
This should take a week, as this will shape overall routing and play heavily into existing workflows.
Once the information has been gathered, you are good to move onto stage 7.
You will kick this off by generating an issue using the Zendesk Review Stage 7 issue template.
In this stage, we determine what kind of notifications should be sent out. This is important as this touches on both internal and external notifications sent out by Zendesk.
This should take a week, as this will determine how people are notified about the events occurring within Zendesk.
Once the information has been gathered, you are good to move onto stage 8.
You will kick this off by generating an issue using the Zendesk Review Stage 8 issue template.
In this stage, we use all previous information obtained to generate a routing diagram. We traditionally use mermaid for this (and the final result in the handbook will use mermaid), but you can use other means if you so desire.
Once you have generated the diagram(s), post them in the issue and have those participating review them.
Once the participants have approved the diagram (and silence is approval), you are good to move onto stage 9.
Here you will generate all the proposal issues relating to this. This should generate one issue per change and all generated issues should be linked to the epic made in Starting the process.
These are simply proposals. Nothing will be implemented through these issues (as that is handled via stage 10). This should be used to discuss the proposed changes and get approval from those needed:
| Team impacted | Approvers |
|---|---|
| Support | @gitlab-com/support/managers/senior |
| Professional Services | @slee24 @kmarquart |
| AR/Billing | @annapiaseczna @s_mccauley |
Here you will generate implementation issues for all the proposed changes that were approved.
You will then set up the sandbox with the proposed changes and run testing on the sandbox. Make sure to record the test results in the related implementation issue and have the approvers (listed in stage 9).
Once all testing is done and approved, you will then follow standard change management to implement the changes into production.