Zendesk Schedules Training

1. You are here:
2. Handbook
3. Support Team Handbook
4. Support Operations Team
5. Support Operations Training
6. Zendesk Schedules Training

On this page

• What this covers
• What are schedules
• Managing schedules via Zendesk
  • Creating a schedule
  • Editing a schedule
  • Deleting a schedule
• Schedule standards
  • Naming standards
  • Timezone standards
• Holidays
• Change management
  • Request stage
  • Testing stage
  • Pre-implementation announcement stage
  • Implementation stage
  • Post-implementation announcement stage
• Useful links

What this covers

This training material will cover the following topics:

• A broad overview of what a Zendesk schedule is.
• Managing Zendesk schedules via the UI.
• GitLab Support Ops schedule standards.
• Holidays
• GitLab Support Ops change management process for Zendesk schedules.

What are schedules

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.

Managing schedules via Zendesk

To manage schedules in Zendesk, you'll first go to the admin panel (the gear icon on the left-hand side). From there, scroll to the bottom and select Schedules under the Settings section. From here, you can add, edit, and delete schedules.

Creating a schedule

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.

Editing a schedule

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.

Deleting a schedule

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.

Schedule standards

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.

Naming standards

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.

Timezone standards

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.

Holidays

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:

• Easter (this is a "movable feast" holiday, so it changes each year)
• Christmas Day (December 25th)
• New Years Day (January 1st)

No other holidays may be used without approval from both Legal and a Support Operations Manager.

Change management

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.

Request stage

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:

• "Support-Ops-Category::Settings"
• A priority label, which is one of:
  • "Support-Ops-Priority::Urgent"
  • "Support-Ops-Priority::High"
  • "Support-Ops-Priority::Normal"
  • "Support-Ops-Priority::Low"
• "Zendesk::Global" if this is about the Zendesk Global instance
• "Zendesk::US-Federal" if this is about the Zendesk US Federal instance
• "SupportOps::To Do"

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.

Testing stage

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:

• A screenshot of the schedule changes in the Zendesk sandbox
• However much time it took you to implement the changes in the sandbox
  • This can be down using the /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.

Pre-implementation announcement 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.

As an example, if you are implementing a change that adds the schedule Regional hours - Pluto, which was requested via https://example.com/not_real by Alice, on 1991-10-20, the announcement would look like this:

As per the request https://example.com/not_real of Alice, we are planning to implement a new schedule named Regional hours - Pluto. This is slated to be done on 1988-12-18. The impact you might see is new windows for SLA timers on tickets using this schedule.

You will announce this in two places:

• Post in the slack channel #support_operations
• Add to the most recent "Things to Know About" section of the Support Week in Review document

After 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

Implementation stage

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.

Post-implementation announcement stage

Once an implementation has 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.

As an example, if you are implementing a change that adds the schedule Regional hours - Pluto, which was requested via https://example.com/not_real by Alice, on 1991-10-20, the announcement would look like this:

As per the request https://example.com/not_real of Alice, we have implemented a new schedule named Regional hours - Pluto. The impact you might see is new windows for SLA timers on tickets using this schedule. Please direct any issues/comments/feedback you see to the issue linked above.

You will announce this in two places:

• Post in the slack channel #support_operations
• Add to the most recent "Things to Know About" section of the Support Week in Review document

After 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

Useful links

• Zendesk Global Schedule documentation
• Zendesk US Federal Schedule documentation