Daylight saving time causes confusion and a loss of productivity for the working world each year when we need to set our clocks forward or backward accordingly. For professionals in the customer service industry, this can be particularly painful since so much of our day-to-day operation depends on customers having reliable access to support and on employees abiding by their schedules. The problem is accentuated for teams distributed around the globe, which will observe DST on different days and with different rules.
Beyond the day of daylight savings itself, the transition means that handoffs between timezones and meetings across timezones will vary for a few weeks in both the fall and the spring. To illustrate the point, here’s what a hypothetical distributed office will look like as DST ends in Fall 2020:
The number of hours separating cross-Atlantic teams—e.g. Los Angeles & London—changes each year during their respective transitions into and out of daylight saving time. Similarly, a team with offices in Phoenix and New York goes from a 2 hour difference to a 3 hour difference each year.
This can throw off coverage plans and handoffs between offices. It also means that a manager needs to reorient their teams' schedules after the transition. To keep the same handoffs consistent, one group has to shift their start time by an hour.
In this article, we’ll take a look at the background of daylight saving time and dig into how to plan for it from a scheduling perspective.
Daylight saving time was originally implemented as an energy-saving measure, allowing people to make use of natural light for an additional hour during the summer evenings, thus reducing the need for electricity in theory. Opponents however, say that the benefits are overstated—any energy savings in the US are offset by the additional gasoline drivers use with an additional hour of sunlight and many areas actually use more energy on heating and cooling in the additional hour than they would otherwise.
That’s not to mention the chaos of the change itself. Car accidents increase and productivity is lost in the days following a time change. And to top it off, different countries and regions have their own rules for when to make these changes—if at all. States like Arizona and countries like Japan (along with most of Asia and Africa) do not observe daylight saving time.
Long story short, daylight saving time is complicated but doesn’t seem to be going anywhere. Today, daylight saving time begins in the US with a “spring forward” on the second Sunday of March and ends with a “fall back” on the first Sunday of November.
While daylight saving time can be confusing, there are some best practices to transition your customers—and your team—through the change with less headache. Identifying any gaps in coverage using a common reference point for planning can avoid some of the potential pitfalls associated with time changes. A dedicated software tool, on the other hand, can handle these transitions for you seamlessly with a little bit of configuration.
To address DST from a customer service perspective, first choose a reference point. All of your offices and managers should use the time in your reference office for planning. We’d recommend choosing the region where your customers are primarily based and where you receive the most incoming volume. For example, an Austin-based company would choose Central Time as their anchor while a Dublin-based company would choose GMT+1 (assuming that their support volume came primarily from their home region).
Once you have your reference point, identify the gaps or overlaps in your coverage. An extra hour ("fall back") can mean an understaffed hour in the day or an unplanned hour of overtime to meet your schedule. Skipping an hour on the other hand (“spring forward”) can mean overstaffing for an hour. To ensure neither case, some upfront schedule planning is required.
The practical importance of the hour itself will vary based on your company, your customers and the support channels that you offer. A real-time chat team with a 24/7 SLA will need to have a more in-depth plan than an email-only support team will, for example.
One way to prepare for these transition periods is to use a software tool like Assembled. Assembled builds in daylight saving capabilities based on your teams’ timezones so you don’t need to worry about keeping track of the days when different countries spring forward or fall back. Here’s an example of what it looks like in the scheduling interface:
Fun fact: Technically during the "spring forward," the hour of 1am doesn't exist! And during the "fall back," 1am is technically repeated.
When you assign a timezone to a schedule template, it becomes the reference point described above and any team members in different timezones will have their hours shift to match the reference timezone.
Alternatively, you can create separate timezones for global teams if you do not want your team to shift hours (read more here).
Daylight saving time poses real challenges to workforces across the world, particularly those with workforces in different timezones and different countries. With a little bit of preparation though, you can get ahead of the curve and plan out exactly how you plan to cover these times.