This training material will cover the following topics:
As per Zendesk:
A Service Level Agreement, or SLA, is an agreed upon measure of the response and resolution times that your support team delivers to your customers. Providing support based on service levels ensures that you're delivering measured and predictable service. It also provides greater visibility when problems arise.
While Zendesk calls them all SLAs, we use many of them as SLOs (namely those for non-support tickets and for next response times).
Note: As of 2021-09-21, Zendesk has changed the location of the SLAs
management pages. They are now located in the Admin Center, which you can
locate by clicking the four squares in the top-right of the page and clicking
the Admin Center link. After doing so, you can locate the SLAs management pages
under Objects and rules > Business rules > Service level agreements. Once
you access the management pages, the steps to create/edit/etc. are the same.
Note: Some SLA policies are tied to the contracts our customers sign upon getting a subscription. Please ensure you follow proper change management at all times!
To create a SLA policy in Zendesk, you will first go to the Admin Center, which
you can locate by clicking the four squares in the top-right of the page and
clicking the Admin Center link. After doing so, you can locate the SLAs
management pages under Objects and rules > Business rules >
Service level agreements. On this page, click the white Add policy button.
This will then display a new SLA where you will enter:
After doing so, click the black Save button to create the SLA policy.
Note: As of 2021-09-21, Zendesk has changed the location of the SLAs
management pages. They are now located in the Admin Center, which you can
locate by clicking the four squares in the top-right of the page and clicking
the Admin Center link. After doing so, you can locate the SLAs management pages
under Objects and rules > Business rules > Service level agreements. Once
you access the management pages, the steps to create/edit/etc. are the same.
Note: Some SLA policies are tied to the contracts our customers sign upon getting a subscription. Please ensure you follow proper change management at all times!
To edit a SLA policy in Zendesk, you will first go to the Admin Center, which
you can locate by clicking the four squares in the top-right of the page and
clicking the Admin Center link. After doing so, you can locate the SLAs
management pages under Objects and rules > Business rules >
Service level agreements. On this page, locate the SLA policy to edit and
click on it. This will open the SLA policy settings, where you can make the
needed changes,
After doing so, click the black Save button to update the SLA policy.
Note: As of 2021-09-21, Zendesk has changed the location of the SLAs
management pages. They are now located in the Admin Center, which you can
locate by clicking the four squares in the top-right of the page and clicking
the Admin Center link. After doing so, you can locate the SLAs management pages
under Objects and rules > Business rules > Service level agreements. Once
you access the management pages, the steps to create/edit/etc. are the same.
Note: Some SLA policies are tied to the contracts our customers sign upon getting a subscription. Please ensure you follow proper change management at all times!
To delete a SLA policy in Zendesk, you will first go to the Admin Center, which
you can locate by clicking the four squares in the top-right of the page and
clicking the Admin Center link. After doing so, you can locate the SLAs
management pages under Objects and rules > Business rules >
Service level agreements. On this page, locate the SLA policy to edit and
hover over it. You will then click the gear icon on the right-hand side of the
SLA policy. From there, click on Delete. A pop-up box will appear asking you
to confirm the deletion. To confirm, click the black Delete policy button.
To ensure all SLA policies we utilize are both consistent in nature and transparent in their actions, we strive to meet some standards on all SLA policies we work with.
The name used for the SLA policy should be simple, clear, and concise. You want the name to convey what the SLA policy is used for.
Generally speaking, we aim to make SLA policy conditions as simple as possible.
When possible, you should use condition sets that are very specific and
succinct. As an example, if you wanted a SLA policy to only run when the form is
Support Ops, it is better to simply put a condition of "Form is Support Ops"
than adding exclusions for every other form. This can take time and practice
to learn, so when in doubt, pair with the rest of the Support Ops team!
Note: Because of the serious implications changes to SLA policies can have, only Support Ops Managers should make any modifications to SLA policies.
To ensure each runs smoothly, we do our changes in set stages.
All Zendesk view changes should start with a request issue. This issue should stem from a support-team-meta issue where the proposal was discussed.
The request should not be "make this change in Zendesk," unless the request is coming directly from a Support Ops team member. If the request does not detail what the desired effect is, we as Support Ops should instead push back on the request and ask the requester detail what they want to see as a result and not what they want done in Zendesk.
All request issues should contain the following labels at creation:
While we have scripting and templating in place to find when these are missing, you should strive to ensure those are present. If you find any of them missing, please add them.
Once the request is in good standing, you may assign it to yourself (if it is not already) and add the tag "SupportOps::Doing" to indicate you have started working on this.
As this requires a Support Ops Manager to conduct the changes, you will want to assign the issue to a Support Ops Manager and assign the issue to them.
In this stage, the Support Ops Manager will reach out to Senior Support Managers to discuss the change and get approval. All SLA Policy changes require approval from at least one Senior Support Manager.
When making a change to Zendesk SLA policies (whether it be creation, editing, or deactivation), we start the process in the Zendesk sandbox. In the Zendesk sandbox for the corresponding Zendesk instance this impacts, you will make the desired changes. Once this is done, update the original request issue with the following:
/spend X minutes, where X is the number of
minutes you spent.You will then test these changes. This process should take no less than 3 days after making the changes. This is to ensure that not only is the change tested thoroughly, but others have time to review your tests and the results.
Often, you will need assistance testing out changes. Should this be required, consider reaching out to the following for assistance in testing the changes:
If testing provides failed results, this means we need to update the original request issue with what happened and why. If this is because of a flaw in the request, we should state as much and recommend the requester go back to the original support-team-meta issue to re-discuss. If it failed due to our implementation, we should detail what was wrong with the implementation and propose a new method to try.
Once the changes have been thoroughly tested (and are successful), make sure to add the time you spent doing the testing to the original request.
At that juncture, update the issue with a comment to state testing has completed and was successful. You should give the requester an opportunity to review the test(s) and result(s). Ask if they would like to review them. If they decline, you may move on. If they wish to do so, await their update after they have reviewed the results.
Here, the Support Ops Manager will reach out to the GitLab legal team via the legal tracker to discuss the change and get approval. Once legal has approved the changes, the Support Ops Manager can move onto the next stage.
Once an implementation date has been determined, you need to announce this
upcoming change. To do this, go to the Slack channel
#support_ops-accouncements and click the lightning bolt on the text box (this
is the shortcuts icon). From there, select Support Ops Announcement. This
will cause a form to pop-up. Fill out the form to generate a message in the
#support_ops-accouncements channel.
The form asks for the following:
Once it posts, you will need to screenshot the post message and add that to the
Support Operations Corner of the
Support Week in Review
document
After adding it in the Support Week in Review, you then want to cross-link (copy the link to the post) the announcement to the following channels:
| Channel | When to cross-link |
|---|---|
#support_operations |
Every time |
#support_team-chat |
If this impacts Support only or Everyone |
#spt_managers |
If this impacts Support only or Everyone |
#whats-happening-at-gitlab |
If the change is concerning SLA OR provisioning/deprovisioning |
In this stage, the Support Ops Manager will implement the change into the production Zendesk instance.
Once an implementation has been completed, you need to announce the change. To
do this, go to the Slack channel #support_ops-accouncements and click the
lightning bolt on the text box (this is the shortcuts icon). From there, select
Support Ops Announcement. This will cause a form to pop-up. Fill out the form
to generate a message in the #support_ops-accouncements channel.
The form asks for the following:
Once it posts, you will need to screenshot the post message and add that to the
Support Operations Corner of the
Support Week in Review
document
After adding it in the Support Week in Review, you then want to cross-link (copy the link to the post) the announcement to the following channels:
| Channel | When to cross-link |
|---|---|
#support_operations |
Every time |
#support_team-chat |
If this impacts Support only or Everyone |
#spt_managers |
If this impacts Support only or Everyone |
#whats-happening-at-gitlab |
If the change is concerning SLA OR provisioning/deprovisioning |