After-hours auto-reply: setting the right expectation
How to replace the empty "we will get back to you soon" line with a message that names a window, splits by channel and survives the morning backlog it creates.
Friday, 7:40 p.m. The last support rep shut the laptop forty minutes ago. A message lands on the WhatsApp line: "Has my order shipped? I'm travelling tomorrow morning." Someone reads it Monday at 9:10 a.m. In between, for roughly two and a half days, the customer heard nothing. They wrote twice more, then asked the same question on Instagram, then left a public comment. The problem was not that nobody works on a Friday night — nobody expects that. The problem was that the customer had no idea when an answer would arrive.
This piece treats the after-hours auto-reply as an operational instrument for managing expectations rather than a politeness gesture. We start with why silence costs more than delay, then move through the four pieces of information a working auto-reply carries, why business hours belong to channels rather than to the company as a whole, how the message shifts for holidays and unplanned outages, where the auto-reply ends and a bot begins, how the morning backlog gets absorbed, and which numbers actually tell you whether any of it works. Common mistakes and an FAQ close the article.
Why is an after-hours message a certainty problem, not a speed problem?
Nobody who writes at 8 p.m. expects a reply at 8:05. Everyone understands that a business closes. What they expect is narrower: proof that the message landed somewhere, and a rough window for when it will be handled. Without those two things the customer starts to improvise. They resend the same message, then try a second channel, then call, then post somewhere public where they are confident of being seen.
That chain quietly generates work. When the inbox opens in the morning, the screen holds not one question but four copies of the same question across four channels. The rep first has to establish that these are one person, then decide which thread to answer in. Staying silent overnight does not shrink the morning workload; it multiplies it. And dissatisfaction usually comes from not knowing the wait, not from the wait itself.
There is a revenue side too. A meaningful share of evening messages carry buying intent: a price question, a stock question, a delivery question. When those go unacknowledged, the customer has no reason to keep waiting. Silence reads as "nobody saw this", and people compare options while they wait. The auto-reply steps into exactly that gap: it does not answer the question, but it makes waiting rational.
What four things does a working after-hours message say?
Most after-hours messages are a single sentence: "We're currently outside business hours and will get back to you as soon as possible." Polite, and empty. "As soon as possible" carries no information, so the customer fills it in with their own assumption — usually a shorter one than you can meet. When the expectation is set wrong, even a reply that arrives on time feels late.
A message that earns its place states four things. That the message was received, so a record exists and nothing is being ignored. When someone will return, as a day and a window: "tomorrow between 9 and 11". What counts as urgent and where urgent goes: a number, a form, or the one channel genuinely monitored. And what the customer can settle on their own in the meantime: the tracking page, the order status screen, the invoice download.
Fitting four things into one message means keeping it short. Long auto-replies are not read; anything past the second line disappears. Treat the after-hours text as part of the same template library your team uses during the day. Teams that keep their saved replies tidy store the out-of-hours text in the same place, so when the wording changes it changes once.
Why do business hours belong to channels rather than to the company?
One calendar applied to every channel always sags somewhere. Email is asynchronous by nature; announcing that you are closed there is often noise, because nobody expects an email answered in ten minutes. On WhatsApp the expectation runs at conversation speed — five minutes of silence already feels long. Instagram and Messenger sit somewhere between. Sending the same text to all three is redundant in one place and thin in another. Because WhatsApp is where the expectation runs highest, it is worth thinking through the types of auto-reply on that channel and the human balance on its own terms.
Per-channel hours also match how teams are actually staffed. The phone line may close at 6 p.m. while one person watches social channels until 9. On a Saturday WhatsApp might be open while email waits for Monday. The after-hours auto-reply setting in the Unified Inbox records exactly that distinction: each channel gets its own schedule, and a message arriving while that channel is closed receives that channel's text. "We're closed" then describes the channel the customer chose, not the whole company.
While setting this up, keep greetings and away messages separate; they fire at different moments and do different jobs. We walked through how hours, greetings and away messages divide the work in a separate article. The short version: a greeting opens every new conversation, an away message runs only while the calendar says closed.
How does the message change for holidays, peak season and outages?
A weekly calendar describes the ordinary shape of the business. The irregular shapes need their own text. Public holidays are the most predictable of them: the dates are known in advance, so the wording can be written in advance too. What matters is putting the date inside the message. "We're closed for the holiday" says nothing on its own; "we're back on the morning of the 6th" lands in the customer's calendar.
Peak season is a different problem, because the team is in fact working — just not keeping up. During those weeks the honest move is to widen the in-hours response window rather than edit the after-hours text. If "we usually reply within the hour" stops being true during a sale, change that sentence for the duration of the sale. Missing a promised window erodes trust faster than never promising one.
The third case is the unplanned closure: a power cut, a system fault, a channel connection that drops. Here the auto-reply alone is not enough, because the customer cannot tell the fault is on your side. Tying the after-hours text to an incident notice and status page setup stops you answering the same question hundreds of times. The Channel Health Panel carries the operational half: it flags a dropped WhatsApp connection, so you notice "messages aren't going through" before a customer tells you.
Which message goes with which situation?
The table below is a simple decision frame for splitting after-hours texts apart. The windows are written as examples; your real numbers follow from how fast your team clears the morning queue. What matters is not the figure but that every row commits to a window.
| Situation | What the message must say | Example response window |
|---|---|---|
| Evening close (same day) | First hours of the next business day, urgent route | Tomorrow 9-11 a.m. |
| Weekend | Return day by name, the one channel open meanwhile | Monday during the day |
| Public holiday | Return date spelled out, urgent exception | First business day after |
| Peak season (in hours) | A longer window than usual, reason in one line | Same day |
| Unplanned outage | That the issue is known, where updates appear | Update interval stated |
Read the table for one property: every row hands the customer a next step. No row ends in "as soon as possible". The quickest test of any draft is to ask whether someone reading it can put the phone down and go back to what they were doing.
Where does the auto-reply end and a bot begin?
An after-hours auto-reply is a one-way notice: it goes out once and expects nothing back. A bot holds a conversation, asks questions, opens records. Confusing the two produces errors in both directions. The first is building a full flow where a notice would do — a script asking for an order number at 11 p.m. mostly wears the customer out. The second is settling for one sentence while the team hand-answers the same five questions every morning.
The split follows the question type. Questions whose answer never changes — opening hours, return period, where to track a parcel — can be automated safely at night. Questions whose answer depends on that customer's own record should wait for morning, with a sentence that says so. Building a scripted flow on WhatsApp is covered separately; the hardest decision there is what the bot will refuse to do.
If you do run a bot, define the exit before anything else. What happens when someone types "get me a human" matters most out of hours, because there is no human to reach: the bot has to say so plainly and mark the conversation for the morning queue. When the handoff from bot to human is not wired properly, the customer waits for an agent who was never coming. Keeping the handoff record on the conversation also tells the rep who opens it at 9 a.m. where to pick up.
How is the morning backlog absorbed?
The real test of an after-hours reply is the next morning. The promise you made overnight turns into a queue at nine. Handled unsorted, that queue serves the latest writer first, simply because they sit at the top of the list. That contradicts the promise: you said "first thing tomorrow", and the queue is reading the night backwards.
The fix is to give the queue an owner. Assignment Rules and SLA distribute the overnight conversations across the team at opening and attach a response-time target to each one, so the backlog clears by rule rather than by whoever feels responsible. Labels and Filters then split the same queue in two: threads with a ready answer, and threads needing research. The first group is gone in fifteen minutes; the second gets proper attention.
The queue has a second source: the phone. Missed calls taken out of hours are messages too, and an unreturned one produces the same uncertainty. With call disposition codes and automatic notes in place, the morning list reads as "who called, was it returned, what was said". Follow-up Reminders help here as well: leave a dated reminder on a conversation you cannot close, and it stops depending on memory.
Which numbers show the auto-reply is doing its job?
Success is not "how many were sent" — that only confirms the system fired. Three things carry meaning. The first is the repeat-message rate: after receiving the auto-reply, how many more times did that customer write before morning? If the text works, the number falls. The second is channel hopping: if someone who wrote to WhatsApp at 8 p.m. also wrote to Instagram at 10, the information you gave was not enough.
The third is how fast the morning queue empties. Measuring first response time across the full calendar day misleads any team that does not work nights; the meaningful clock starts at opening. The usual methods for bringing first response time down apply here too, with the clock reset at the start of the shift rather than at the moment the message arrived. Without that distinction the team is judged on hours it does not control.
The Inbox Statistics Dashboard holds the raw material for all three: open, pending and closed conversations, the channel split and the load per rep in one place. Channel Analytics shows the busy hours, and correcting your schedule once against real data is cheaper than carrying a guessed calendar for months. Email measures differently, because expectations there are already wider; what actually moves email reply rates has more to do with the message itself than with your out-of-hours notice.
What are the most common mistakes?
The first is repeating the notice on every inbound message. Someone who writes three times at night should not receive the same automated text three times; that reinforces the sense of talking to a wall. Send it once per conversation, and open with a human sentence in the morning. The second is never revisiting the text: hours change, the urgent line closes, the message stays where it was and starts telling people things that are no longer true.
The third is loading the notice with apology. "We're experiencing delays due to high volume, thank you for your patience," sent every single evening, stops being an apology and becomes background noise. The message should inform rather than apologise. The fourth is the silent channel: when no schedule is defined for a channel, it genuinely goes quiet overnight, and nobody notices until a customer says so in public.
The last mistake is treating the after-hours experience as separate from feedback. Conversations answered late in the morning tend to score low, and the cause is usually the uncertainty of the night rather than the rep's tone. Public feedback deserves the same reading; when responding to reviews and ratings, tracing a recurring complaint to its source often points at a gap in the schedule. To build your own version, open a Rocketly account and define the schedule and after-hours text channel by channel.
FAQ
Should the after-hours reply go out on every message?
No. Once per conversation is enough. Repeating it while someone writes several times in a row underlines that they are talking to a machine. Sending one short update when a new day starts and the conversation is still open, however, is worth doing.
Isn't committing to a time window risky?
Not committing is riskier, because the customer assumes a window anyway and usually imagines a shorter one than you can meet. Give a range and hold it. In stretches where you cannot, widening the range temporarily does less damage than breaking a stated promise.
Can one text serve both WhatsApp and email?
It can, but it works poorly. Expectations on WhatsApp run at conversation speed; on email they run in days. The same sentence is redundant in one place and thin in the other. Short per-channel texts beat one long text sent everywhere.
Is this too elaborate for a small team?
No. Even a team of three needs two texts: evening close and weekend. Those two cover the large majority of out-of-hours traffic. Holiday and outage wording can be added later, as the need appears.