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

Before configuring business hours, a team needs to settle three things: which time zone should serve as the default reference point, whether hours should vary by day of the week, and whether any form of after-hours coverage, bot or otherwise, will be offered at all.

Which time zone to use as the default

For a business with a geographically concentrated customer base, using local time is usually the clearest default; for a business with a widely distributed audience, some teams instead default to the support team's own time zone and communicate that clearly in the offline message.

Whether hours should évary by day

Many businesses reasonably run shorter or no hours on weekends compared to weekdays, which needs to be explicitly configured rather than assumed, since a chat platform's default settings typically apply the same hours across every day unless changed.

Whether to offer any after-hours coverage at all

Deciding upfront whether after-hours coverage will come from a chatbot, an email form, a callback request, or genuinely nothing at all shapes the rest of the setup process and the specific offline message that needs to be written.

Setting up business hours properly involves defining core support hours, configuring holiday and exception schedules, writing a clear after-hours message, offering some form of alternative path, and explicitly testing the transition between the online and offline states before considering the setup complete.

Step 1: Define your core support hours

Starting from the team's actual staffed hours, rather than an aspirational schedule the team doesn't consistently maintain, ensures the configured hours match the real experience customers will actually get.

Step 2: Set holiday and exception schedules

Configuring known holidays and other planned exceptions in advance prevents the awkward situation of the widget showing as online on a day the team is actually unavailable, which undermines trust in the accuracy of the online status generally.

Step 3: Write a clear after-hours message

The offline message should state plainly that the team is currently unavailable and specify, as precisely as possible, when a response can be expected, rather than a vague, open-ended promise to respond eventually.

Step 4: Offer an alternative (bot, email form, or callback)

Giving a customer something productive to do while the team is offline, whether that's a chatbot handling simple requests, an email capture form, or a scheduled callback option, meaningfully softens the experience of reaching out outside business hours.

Step 5: Test the transition between online and offline states

Actually visiting the site right at the configured cutoff time, or simulating it, confirms the transition behaves as expected rather than assuming the configuration works correctly without ever directly verifying it.

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.