Skip to content

Implementation: Office Hours Routing

Route each lead by the time it actually arrived.

A lead that comes in at two in the afternoon on a Tuesday should ring a live rep's phone. A lead that comes in at eleven at night on a Sunday should not, it should go to a text-back or a next-morning queue instead. This workflow makes that split automatic.

  • $0 setup, month to month
  • 30-day guarantee, pay only if satisfied
  • Free proposal within 1 business day

What this workflow covers

The clock check, the time zone, and the holiday gap.

The field map

The submission timestamp is compared against a stored hours-of-operation table, an open and close time for each day of the week, per location if there's more than one. That comparison produces a simple in-hours or after-hours flag on the new lead.

The identity match is a clock, not a person

There's no identity involved here, only a timestamp compared to a table. What matters most is which location's hours apply, since a business operating across more than one time zone needs the right table checked for the right location.

Where the data enters

The check runs at the moment of submission, inside the routing automation, tagging the lead before it's assigned to a rep or a queue. The after-hours path can trigger an automatic acknowledgment, a text or an email, while the live handoff waits for the next open period.

How failures surface

Daylight saving time shifts twice a year, and an hours table hardcoded to a fixed offset instead of a real named time zone will misfire for about a week each transition, routing in-hours leads to the after-hours queue or the reverse. A holiday closure left out of the table produces the same failure on that specific day.

Where an hours rule quietly stops matching your day.

Hours tables need a real time zone, not a fixed offset

Storing hours as a fixed number of hours from UTC breaks twice a year at the daylight saving transition. Storing them against an actual named time zone lets the underlying system handle that shift correctly on its own, without a manual fix every spring and fall.

Holidays are the most commonly forgotten exception

A closure for a specific holiday needs that date added to the table in advance, not discovered the day of. Without an entry, the default behaviour treats that day as a normal business day and routes leads straight to a rep who isn't actually in.

Multi-location businesses can run different hours per site

A routing rule built around one set of hours for the whole business misroutes every lead for a location that opens or closes at a different time, which becomes common the moment a business operates across more than one market or time zone.

After-hours doesn't mean unanswered, it means a different path

The after-hours flag should trigger its own response, an automatic text or a promised next-morning callback, not silence. A lead that gets nothing until a rep happens to check the queue the next day is functionally the same as a lead that was simply ignored.

How we set it up.

01

Document real hours, including holidays

We build the hours table per location, including holiday closures for the year ahead, since this is often known but never written down anywhere central.

02

Build the timestamp check

We set the routing automation to compare submission time against the table using the correct named time zone for each location.

03

Set the after-hours response

We define exactly what an after-hours lead receives immediately, and when a live rep actually follows up the next open period.

Lead routing by office hours FAQ.

Stop routing after-hours leads to a phone nobody's answering.

We'll document your real hours, including the holidays, build the timestamp check on the right time zone, and set an after-hours response that actually reaches the lead.

Keep exploring:

All implementation workflowsLead routing by service areaDuplicate lead dedupe rulesGet a free proposal