Your Business Hours Are Probably Wrong: The Time Zone Trap in Call Routing

Here is a failure that is almost impossible to notice from the inside.

Your business hours are set to nine to five. A customer calls at four in the afternoon, well inside those hours, and goes straight to voicemail. They assume you have closed early. You never find out it happened, because from where you are sitting the phone simply did not ring.

Multiply that by every afternoon.

The cause is usually a time zone assumption buried somewhere in the phone system, and it is one of those bugs that hides extremely well because it only affects the people who are not in the room.

Why phone systems get this wrong

When you type "9:00 AM" into a business hours setting, you have not actually specified a moment in time. Nine in the morning where? The system has to supply that context from somewhere, and there are only a few places it can get it.

The server's clock. Very common, and completely arbitrary. Your provider's servers might be in Virginia, Oregon, or Frankfurt. That is where your business hours are now anchored, and you were never told.

The vendor's home time zone. Slightly better, still wrong for most customers.

Hardcoded to one zone. More common than you would think, especially in systems that grew up serving one market. Everything works perfectly for customers in that zone and is quietly broken for everyone else.

The browser of whoever set it up. Reasonable-looking and still fragile, because it silently changes if someone edits the settings while travelling.

The reason this survives so long is that it is invisible to the operator. If you are in the same zone the system assumed, everything works. Nothing in the interface tells you an assumption was made, and the failure only manifests for callers who are somewhere else, or for you at the edges of your day.

The symptom list

You may be looking at this bug if:

• Calls go to voicemail while you are sitting in the office with the lights on.
• Your after-hours message plays during the day, or your normal greeting plays at midnight.
• The problem is consistently off by a whole number of hours. Three hours off points at a zone gap, not a random glitch.
• It shifted by exactly one hour in March or November. That is daylight saving, and it is the clearest fingerprint of all.
• One location behaves correctly and another does not.

That last one is the giveaway for multi-location businesses, and it is the case most systems handle worst.

Daylight saving makes it worse

A lot of systems store an offset rather than a zone. They record "UTC minus five" instead of "America/New_York."

Those are not the same thing, and the difference matters twice a year. New York is UTC minus five in January and UTC minus four in July. If your system stored the offset, your business hours silently drift by an hour every spring and drift back every autumn.

This is why the symptom so often appears right after a clock change. Nobody touched the settings. The settings were always going to break; the calendar just got there eventually.

The correct thing to store is the zone identifier, because that carries the daylight saving rules with it. Arizona, for instance, does not observe daylight saving at all, so a system that assumes every US zone shifts in March will be wrong about Phoenix for eight months a year.

The multi-location problem

Now add a second office.

You have a number in New York and a number in Los Angeles. Both are set to nine to five, which is exactly right for each of them. But if the system has one time zone setting for the whole account, one of those two is wrong by three hours, permanently.

The instinctive fix is to fudge the hours: set the Los Angeles number to twelve to eight so it lines up with Eastern. This works until daylight saving, or until somebody looks at the settings and "corrects" them, or until you open a third office and run out of arithmetic.

The actual fix is that the time zone has to live on the phone number, not the account. Business hours are a property of a location, and a phone number is the closest thing most systems have to a location. One account, several numbers, each with its own zone, each with its own hours that mean what they say.

How to test your own setup

You do not need access to anything internal. Five minutes and a phone will do it.

1. Set a deliberately narrow window. Pick a number and set today's hours to a fifteen-minute slot starting ten minutes from now.
2. Call it before the window opens. You should get your after-hours handling.
3. Call it inside the window. You should get your normal handling. If you do not, note how far off you are.
4. Count the gap. If the switch happened three hours early, your system is running three zones east of you. That number tells you exactly which assumption it made.
5. Repeat for a second location if you have one. If both numbers switch at the same absolute moment despite being in different zones, the setting is account-wide and you have found the limitation.

Then put your real hours back.

The reason this test is worth doing rather than just reading the settings screen is that the settings screen is precisely where the lie lives. It shows you "9:00 AM" and does not tell you whose nine it means.

What correct looks like

A phone system handling this properly has four properties:

The zone is stored per number, so multi-location businesses are not forced to fudge.

It stores a zone identifier, not an offset, so daylight saving is handled by the underlying time zone database rather than by you remembering twice a year.

The interface tells you which zone the hours are in, right next to where you type them. This is the cheapest fix in the whole list and the one most often skipped. "9:00 AM" is ambiguous; "9:00 AM, New York" is not.

The default is explicit rather than hidden. If a new number has to default to something, the setting should say so plainly instead of silently inheriting a server's location.

What we changed

I am writing about this partly because TelBuddy had this bug. Business hours were evaluated in Eastern time for everybody, because that is where the code was written and nobody had questioned it. Any customer outside that zone had routing that fired at the wrong time, with no setting available to correct it.

Time zone is now a property of each phone number. You set it on the numbers page, the business hours screen displays which zone the times refer to, and the routing logic reads that zone per number rather than assuming one. Existing numbers kept the original behaviour by default, so nobody's routing changed underneath them, but now it is a choice rather than an assumption.

It also handles daylight saving correctly by storing the zone rather than an offset, which means Phoenix behaves like Phoenix.

If you run one location in one time zone, none of this affects you and you can carry on. If you have ever wondered why a customer said they called and got voicemail when you know you were open, it is worth running the five-minute test above.

You can read more about how the routing itself works on the business hours call routing page.