This training material will cover the following topics:
agents is a project that runs a daily CI/CD schedule (at midnight UTC) to update support agents within Zendesk. This manages the following:
The preferred method for managing Zendesk support agents is via the sync repos (see Useful links down below).
See the above video for how this repo works.
The preferred method for managing Zendesk agent signatures is via the sync repos (see Useful links down below). This would mean managing the messaging or context with agent signatures is going to be done via merge requests to the repo itself, normally the agent_signatures.rb file.
See the above video for how this repo works and how to make changes to the agent signature formatting itself.
To manage a signature via the Zendesk UI, you begin by going to the User page of
the user who's signature you wish to edit. From there, you will click in the
Signature box and make the edits you wish to make. Clicking outside of the box
will save these changes.
Note: This should not be done without very good reason. We maintain agent signatures via sycn repos for good reason.
When it comes to making changes to Zendeks agent signatures, we utilize the agent-signatures repo instead of doing this via the Zendesk UI. This allows us to easily revert a change and ensure what is running in our production instances is what we have approved. To ensure each runs smoothly, we do our changes in set stages.
All Zendesk agent signature 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.
To prepare for the implementation, you will need to create a merge request to the corresponding agent-signatures repo (see Useful links down below).
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).
At that juncture, update the issue with a comment to state the merge request is ready. You should give the requester an opportunity to review the changes. 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. an implementation date can be determined.
Note: All merge requests in the agents 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, 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 |
This stage should be the simplest one to implement, as you already have a merge request ready to go! Simply mark the merge request as ready and merge it. If you encounter any issues here, reach out to your fellow Support Ops team members for assistance.
As the sync runs once a day, the changes will occur during the next run schedule (00:00 UTC).
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 |