This training material will cover the following topics:
As per Zendesk:
Email is one way that end-users can submit tickets to Zendesk Support and have conversations with agents to resolve their issues.
Basically, Zendesk emails enable an end-user to email an address and have a ticket created from it. Usage of this varies widely from instance to instance.
Note: While you can connect external email addresses to Zendesk, we do not do this at GitLab. Instead, we create Zendesk email addresses and have the GitLab email group forward to said Zendesk email address.
To create a Zendesk email, you first need to go to the admin panel (by clicking
on the gear icon on the left-hand side of the page). from there, click the
Emails link (under the Channels section).
You will then click Add address on the top-right of the page. This will have a
dropdown appear. In this dropdown, click Create new Zendesk address. A pop-up
box will appear asking you to enter the username for the address. This should
match the username of the GitLab email address exactly (this avoids a lot of
confusion).
After doing this, click the black Create now button.
Note: This does not create the GitLab email address. To have that done, you will need to file an Access Request issue to have it created. Make sure in the issue to specify the Zendesk email address to forward the emails to.
Note: You can only edit the name of a Zendesk email after creation. If you need to change the address, you will need to delete the existing one and create a whole new one.
To edit a Zendesk email, you first need to go to the admin panel (by clicking on
the gear icon on the left-hand side of the page). from there, click the Emails
link (under the Channels section).
From here, locate the email address you wish to edit and then click the edit
link on the right-hand side of the email address. Doing so will make a pop-up
box appear.
Here, you can edit the name of the address.
Warning! This can be disastrous and can cause issues. Only do this when you are 110% sure this needs to be done. An unused email address is annoying but safe. A deleted email address that was in use causes many issues!
To delete a Zendesk email, you first need to go to the admin panel (by clicking
on the gear icon on the left-hand side of the page). from there, click the
Emails link (under the Channels section).
From here, locate the email address you wish to delete, hover over it, and then
click the delete link.
link on the right-hand side of the email address. Doing so will make a pop-up
box appear. A pop-up box will appear asking you to confirm the deletion. Click
the black Delete address button to confirm.
Note: While the above video is for Zendesk Automations, the exact same process applies for Zendesk Emails. The sole difference in the tags used on the requests and merge requests (if any).
To ensure each runs smoothly, we do our changes in set stages.
All Zendesk email changes should start with a request issue. This issue should stem from a support-team-meta issue (or similar 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.
When making a change to Zendesk emails (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.
To prepare for the implementation, you may need to create a merge request to the corresponding zendesk-triggers repo. For more info on that, see the Zendesk Triggers training doc.
After creating the merge request, make sure it is linked in the original request and you have added any additional time spent to the requester issue.
From here, have one of your fellow Support Ops team members or a Support Ops Manager review the merge request and add their approval (or comments). Once approval has been added, an implementation date can be determined.
Note: All merge requests in the zendesk-triggers repo should contain the following labels (the same as with issues):
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, you will make the changes in the production Zendesk and merge any related MRs.
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