How to Set Up Business Hours & After-Hours Messaging in Live Chat

A good after-hours message sets a specific expectation for when the customer will hear back, offers a self-service option where one genuinely exists, and avoids a flat, purely transactional "we're closed" tone that reads as indifferent to the fact that the customer took the time to reach out.

Set expectations for when they'll hear back

Specifying an actual timeframe, "we'll respond within one business day," rather than an open-ended "we'll get back to you," gives the customer something concrete to plan around instead of an indefinite, anxiety-inducing wait.

Offer a self-service option

Linking directly to a relevant knowledge base or FAQ section inside the after-hours message gives an impatient or urgent customer a real chance at self-resolving before the team is back online.

Avoid a flat "we're closed" tone

A message that reads as purely transactional, stating only that the team is unavailable with no acknowledgment of the inconvenience, feels colder than one that briefly recognizes the customer reached out at an inconvenient time and still tries to be genuinely helpful within that constraint.

A chatbot configured to handle simple, common requests around the clock can meaningfully close the after-hours gap, resolving order status checks, account questions, and other routine requests without requiring any live staff to be present at all.

What a bot can reasonably handle unattended

Well-scoped requests that don't require judgment calls or account changes with real consequences, like order tracking or general product questions, are usually safe to fully automate overnight, while anything involving a refund, cancellation, or dispute is often better routed to a next-business-day queue instead.

The most common mistakes are configuring the wrong time zone as the default, forgetting to set a holiday schedule, and writing an after-hours message that states the team is unavailable without offering any next step at all.

Wrong time zone default

A widget configured to the wrong time zone shows as online or offline at the wrong actual times, creating exactly the kind of mismatched expectations the whole setup process is meant to prevent.

No holiday schedule configured

Without explicit holiday configuration, the widget defaults to its regular weekly schedule, which means it will incorrectly show as online during a holiday closure unless someone remembers to manually override it in advance.

After-hours message with no next step

A bare "we're currently offline" message with nothing further leaves the customer with no idea what to do next, missing the opportunity to at least point toward self-service resources or set a clear expectation for response time.

Multi-region teams often adopt a follow-the-sun coverage model, handing off active support across time zones to maintain something close to continuous human coverage, alongside region-specific holiday schedules and after-hours messaging translated and localized for each supported language.

Follow-the-sun coverage models

A follow-the-sun model staffs support from teams in different time zones handing off to one another, aiming to keep at least one team actively online at nearly any hour without requiring any single team to work overnight shifts.

Region-specific holiday schedules

A single global holiday calendar rarely fits every region a business serves, making region-specific holiday configuration necessary to avoid either an incorrect closure on a non-holiday or an incorrect open status on a real regional holiday.

Language-specific after-hours messaging

An after-hours message should be available in every language the business actively supports, since an English-only offline message defeats much of the purpose for a customer who doesn't read English fluently.

Business hours are most effective when communicated consistently everywhere a customer might look, displayed clearly on the website itself, reflected in email auto-reply messages, and kept synchronized across every channel rather than accurate in the chat widget alone while other channels show outdated or missing information.

Displaying hours on the website itself

A visible, clearly labeled hours section, on a contact page or footer, gives customers a way to check availability before they even open the chat widget, reducing the number of after-hours messages that arrive simply because the customer had no way to know the team was offline.

Setting expectations in email auto-replies

An email auto-reply confirming current business hours and expected response time reinforces the same expectations set inside the chat widget, giving a consistent message regardless of which channel a customer happened to use.

Syncing hours across all channels

Manually updating hours separately across chat, email, and any listed phone hours creates a real risk of one channel drifting out of sync with the others, which is why centralizing hours configuration in one place, where the platform supports it, is worth prioritizing.

Beyond planned business hours, a team also needs a plan for unexpected downtime: a distinct emergency offline message, a way to proactively communicate the outage, and a smooth, tested process for reopening once the issue is resolved.

Configuring an emergency offline message

A separate, quickly-activatable emergency message, distinct from the normal after-hours message, lets a team communicate an unplanned outage honestly rather than leaving customers to interpret an unexplained offline widget during otherwise scheduled hours.

Communicating outages proactively

Where possible, proactively notifying customers of a known outage, through a banner, a status page link, or a brief chat message, reduces the frustration of an unexplained silence during a period customers expected the team to be available.

Reopening smoothly after unplanned downtime

Confirming systems are genuinely stable before switching back to the normal online status avoids the frustrating pattern of a widget flickering between online and offline states as an issue is only partially resolved.

Testing the emergency message flow in advance

Having the emergency message and its activation process tested and ready before it's actually needed avoids the added stress of configuring it correctly for the first time in the middle of a genuine, live outage.

Business hours settings and any formal service level agreement a business has committed to should be explicitly aligned rather than configured independently, since a mismatch between the two, an SLA promising faster response than the actual staffed hours can realistically support, quietly undermines the credibility of both.

Matching hours to SLA commitments

An SLA promising a response within a certain number of hours needs to be built around the team's actual staffed availability, since a commitment that assumes round-the-clock coverage the team doesn't actually provide sets an expectation that's structurally impossible to consistently meet, regardless of how hard the team works during its actual hours.

Documenting hours in the SLA itself

Explicitly stating the business hours a response-time SLA applies within, rather than leaving the relationship between the two implicit, prevents a customer from reasonably but incorrectly assuming a response-time commitment applies equally at 2 AM as it does at 2 PM.

Adjusting SLAs during known low-coverage periods

For businesses with predictable lower-staffing periods, a holiday season or a planned team offsite, temporarily and transparently adjusting the communicated SLA for that window is more honest than either quietly missing normal commitments or maintaining unrealistic expectations the team knows it can't meet.

Communicating SLA-hours relationship to customers

Making the connection between business hours and SLA commitments visible and easy to find, rather than buried in fine print, helps customers form accurate expectations upfront rather than discovering the relationship only after being frustrated by an unmet commitment.