Current Location ：
Time-Based Routing: Business Hours, Holidays, and Follow-the-Sun
Opening hours look like a configuration detail and behave like a business policy. Every call that arrives outside the hours the system believes are open is handled by rules somebody wrote, usually once, often years ago, and rarely revisited. The consequences are quiet and expensive: calls going to a closed office's voicemail while another site is open, holiday schedules that were never updated, and timezones that were right until a daylight saving change nobody tested. This article covers how to structure schedules, how to handle holidays as a maintained asset rather than a one-off, where timezone correctness actually comes from, and how to keep an override available for the days when reality does not match the calendar.
Structure Schedules Around Exceptions
The natural way to build a schedule is to define normal hours and add exceptions. That works until the exceptions accumulate and begin to contradict each other. A more durable structure separates concerns: a base pattern for recurring weekly behaviour, an exception list for specific dates, and an override for unplanned events. Keeping these three separate means a planned closure does not require editing the weekly pattern, and an unplanned closure does not require editing either.
| Layer | Purpose | Ownership |
|---|---|---|
| Recurring pattern | Normal weekly opening behaviour for each site or queue | Reviewed when business hours actually change |
| Planned exceptions | Holidays, shutdowns, training days, and known closures | Maintained annually, ahead of the calendar year |
| Unplanned override | Weather closures, incidents, and anything decided on the day | Named owner able to apply and to revert it |
Holidays Are an Annual Maintenance Task
Holiday schedules fail in a predictable way: they are built for one year, work for that year, and are never updated. The following year the system applies last year's dates, and a closure day is treated as a working day or the reverse. Treating the holiday list as an annual maintenance item, owned by a named person and checked before the end of the preceding year, removes a recurring source of embarrassment.
- Assign a named owner for the holiday calendar, with a review date before the new year
- Cover every site separately where locations observe different holidays
- Include partial days, early closures, and shutdown periods, not only full-day closures
- Confirm the behaviour of a call arriving exactly at a boundary time
- Test the schedule once by placing a real call in the after-hours state
Timezones and Daylight Saving
Multi-site organisations discover that a phone system's idea of local time is more fragile than expected. The system needs accurate time, correct timezone definitions per site, and the ability to apply daylight saving transitions correctly. Where any of those is wrong, calls arrive an hour early or late relative to what the site expects, and the symptom is usually reported as 'the phone system is doing something strange at the start of the day' rather than as a time problem.
Verification is simple and worth doing twice a year, at each transition: check what time the system believes it is at a site, place a test call just before and just after the opening boundary, and confirm the correct greeting or destination. It takes minutes and prevents a class of defect that is otherwise found by customers.
Follow-the-Sun Needs an Explicit Fallback
Routing to whichever region is currently open is attractive and has one dangerous property: if no region matches, the call has nowhere to go. Every follow-the-sun design needs a stated fallback destination, tested deliberately, and it should be somewhere that is answered rather than a general mailbox. The fallback is also the answer for the gaps between regional hours, which exist more often than designers expect.
Redstone Approach
Redstone supports schedule design on the REX IP-PBX platform, including recurring patterns, exception calendars, timezone handling, and override procedures for unplanned closures. Our teams can help structure schedules for multi-site and follow-the-sun designs, verify behaviour at boundaries and daylight saving transitions, and document ownership so calendars are maintained rather than forgotten. Configuration details are scoped in writing against your site list, business hours, and regional holiday requirements.
Redstone Systems, Inc. founded in Delaware, USA in December 2002, has been the ODM vendor for many well-known communications companies, serving the Southeast Asian market. In 2020, Redstone Systems will begin to return to the North America market with its self-developed brand.
Redstone has a complete product line of intelligent voice gateways, providing IP-PBXs, analog VoIP gateways (FXS/FXO), digital VoIP gateways (E1/T1), border appliances, and session boundary controllers (SBCs).
With advanced technology in digital signal processor (DSP), speech coding and speech processing, as well as efficient operational tools such as cloud remote management, auto provisioning, Redstone gateways are widely used in markets of enterprise communications, cloud communications, call centers, operators’ IMS/SIP trunks, bringing users friendly, efficient and reliable communication experience.
For more information about Redstone, You can follow us on Facebook, Linkedin, and Youtube to be the first to get the latest news.
