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: 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 panel by
clicking on the gear icon on the left-hand side of the page. From there, you
will locate the Service Level Agreements link under the Business Rules
section. 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: 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 panel by
clicking on the gear icon on the left-hand side of the page. From there, you
will locate the Service Level Agreements link under the Business Rules
section. 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: 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 panel by
clicking on the gear icon on the left-hand side of the page. From there, you
will locate the Service Level Agreements link under the Business Rules
section. 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, use the following template:
As per the request ISSUE_LINK of REQUESTER, we are planning to implement BRIEF_SUMMARY_OF_CHANGES. This is slated to be done on DATE. The impact you might see is BRIEF_SUMMARY_OF_IMPACT.
You will announce this in two places:
#support_operationsAfter posting, you then want to cross-link (copy the link to the post) the
announcement in the slack channel #support_operations to the following
channels:
#support_team-chat#spt_managersIn 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 it! To do this, use the following template:
As per the request ISSUE_LINK of REQUESTER, we have implemented BRIEF_SUMMARY_OF_CHANGES. The impact you might see is BRIEF_SUMMARY_OF_IMPACT. Please direct any issues/comments/feedback you see to the issue linked above.
You will announce this in two places:
#support_operationsAfter posting, you then want to cross-link (copy the link to the post) the
announcement in the slack channel #support_operations to the following
channels:
#support_team-chat#spt_managers