This training material will cover the following topics:
Schedules in Zendesk are like schedules in most other things: windows of time. We use these to determine business hours and various regional working hours.
Within Zendesk, these have the ability to use a specific timezone and allow for the setting of holidays.
Note: As of 2021-09-21, Zendesk has changed the location of the schedules
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 schedules management pages
under Objects and rules
> Business rules
> Schedules
. All videos are of
the old location (i.e. in the admin panel). Once you access the management
pages, the steps to create/edit/etc. are the same.
To manage schedules in Zendesk, you'll 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 schedules
management pages under Objects and rules
> Business rules
> Schedules
.
From here, you can add, edit, and delete schedules.
To create a schedule, click the white Add schedule
button on the top
right-hand side. From here, you need to enter a name for the schedule. After
doing so, you can then select the timezone for this schedule to use. With that
done, select the hours for this new schedule to cover. Once you have it all
set up in the way we need, click the blue Save
button in the bottom-right of
the screen.
To edit a schedule, click the name of the schedule you wish to edit. From here,
you will see a screen very similar to the creation screen. Make your changes
and then click the blue Save
button in the bottom-right of the screen.
To delete a schedule, hover over the schedule in question and click the three
vertical dots on the right-hand side of the schedule. Click the Delete option
and then click the red Delete
button on the popup that appears.
To ensure all schedules we utilize are both consistent in nature and transparent in their actions, we strive to meet some standards on all schedules we work with.
The name of the schedule should be very explicit. Try to aim to make the name of the schedule reveal what it is to be used for.
The timezone used for schedules should be reflective of those using it. For example, if this schedule is for those in the EMEA region, you should use a timezone within the EMEA region. We have some preferred regions to use that you should aim to select when appropriate. There might be situations where none of these are correct, at which point it is best to use your best judgment.
Timezone name | Use | Uses Daylight Savings |
---|---|---|
(GMT-07:00) Pacific Time (US & Canada) | For use in the AMER region or for global use | Yes |
(GMT+02:00) Amsterdam | For use in the EMEA region | Yes |
(GMT+10:00) Brisbane | For use in the APAC region | No |
(GMT+00:00) UTC | For global use when DST needs to be taken into effect (avoid use if possible) | No |
Holidays are important settings on schedules, as when a ticket is using a schedule and has a SLA timer, the SLA timer does not run on the holiday itself. Here at GitLab, we have 3 holidays we put into schedules:
No other holidays may be used without approval from both Legal and a Support Operations Manager.
Schedules by themselves are not "critical" when changed or modified. It is when tickets with SLA timers are using them they become critical. Changes should not be made to these lightly in our current setup. To ensure each runs smoothly, we do our changes in set stages.
All Zendesk schedule changed should start with a request issue. This issue should stem from a support-team-meta issue where the proposal was discussed.
The request itself should detail what schedule hours to use and for what schedule (or specify this is for a new schedule). It should also detail why this change needs to be made. We aim to not have extra, unused schedules in Zendesk, so if there is no plan to use the schedule, we should not act on the request.
All request issues should contain the following labels at creation:
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.
This is the easiest stage, as you merely make the changes to the schedule(s) in the Zendesk sandbox. This should take less than a day or so, as these changes do not require much effort.
Once this is done, update the original request issue with the following:
/spend X minutes
, where X
is the number of
minutes you spent.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 the changes were done in the sandbox. You should give the requester an opportunity to review the results. Ask the requester to confirm the changes are correct. reviewed the results.
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 |
For this change, you simply make the changes in the production Zendesk instance. As you have already done this in the sandbox, you should know what all to do without any complication.
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 |