An assistant that keeps working after the office closes is useful for about as long as it takes to send one text at the wrong hour. The capability and the damage are the same capability: something that can follow up without being asked can also follow up at eleven at night, on a Sunday, to a customer who has already replied.
Quiet hours are the set of rules that decide when background work is allowed to reach a person. They are deliberately boring, they are configured per business rather than inferred, and they are the difference between an assistant that people keep switched on and one they disable after the first complaint.
Send windows
Nothing customer-facing leaves the system outside the hours you configure, evaluated in the recipient’s timezone rather than yours. A roofing company in Dallas following up with a customer who has moved to Phoenix does not send at seven in the morning because seven in the morning was correct for the sender.
The distinction that matters is between doing the work and delivering it. Work continues overnight regardless: drafts get written, quotes get priced against the rules, records get updated, the queue for the morning gets built. What stops at the window boundary is the outbound message.
This sounds like a small design decision and it is the one that makes overnight work viable at all. If the assistant had to pause the work as well as the delivery, the morning would start with a backlog rather than with a finished queue, and the whole point of working overnight would be lost.
Windows are set per channel, because the tolerances are not the same. An email arriving at six in the morning is unremarkable. A text at six in the morning wakes somebody up. A phone call at six in the morning is an emergency or a mistake, and there is no third option in the recipient’s mind.
Weekends and holidays are their own windows rather than an afterthought, and businesses that genuinely operate on Saturdays say so rather than being assumed into a Monday-to-Friday default.
Retry budgets
A follow-up that goes unanswered is the most common situation in this system, and the least interesting way to handle it is to keep trying. A retry budget puts a hard ceiling on how many times any single thread may reach a person, and over what span.
The rules are deliberately conservative:
- A follow-up retries on the schedule you set, never faster.
- Each retry must be materially different from the last, or it does not send.
- A reply cancels everything downstream immediately.
- An exhausted budget escalates to a person rather than looping.
The budget is per thread rather than per message, which is the part that stops the pathological case. Three separate automations each politely retrying twice produces six messages to somebody who has done nothing wrong except not reply yet, and each automation is individually behaving correctly.
A reply, any reply, on any channel, cancels everything downstream immediately. This has to be immediate rather than eventual, because the alternative is the message that arrives four minutes after the customer has already answered, which reads as though nobody is listening.
When a budget is exhausted the thread does not silently die. It surfaces in the morning queue as something that needs a person, with the history attached, because a customer who has ignored three messages is information rather than an error.
When to wake someone
Some things genuinely cannot wait until morning, and the honest problem is that the list is much shorter than anybody expects it to be. Businesses configuring this for the first time tend to mark far too much as urgent, then quietly turn the whole feature off a fortnight later because it woke them for a scheduling question.
The cases that justify an overnight notification are the ones where waiting until morning changes the outcome: a booked job at risk of falling through, a payment failure that stops work starting, a line explicitly designated for emergencies. Everything else is a morning problem being experienced at night.
Escalation is set by you, per case, and it is off by default. The assistant does not decide that something feels important; it matches the situation against the rules you wrote and does nothing when nothing matches.
There is a deliberate asymmetry here. Waking somebody unnecessarily costs trust that takes weeks to rebuild, and the second unnecessary wake-up usually ends the experiment. Failing to wake somebody for a genuine emergency is worse, but it is also much rarer, which is why the threshold sits where it does rather than in the middle.
Overnight escalations carry the full context: what happened, what the assistant already did, and what decision is being asked for. Somebody woken at two in the morning should not also have to reconstruct the situation before they can act on it.
The morning brief
Everything that queued overnight arrives as one brief rather than as a notification storm at the moment the window opens. This matters more than it sounds: a business that comes back to forty individual alerts has been given a second inbox to process, which is the problem the assistant was supposed to remove.
The brief is ordered by what needs a decision, not by what happened first. Items the assistant handled completely are summarised in a line; items waiting on a person are at the top with the context and the options already assembled.
Queued outbound messages send as the window opens, staggered rather than in a single burst, so a customer who is on three threads does not receive three messages in the same minute at nine o’clock.
The result is that overnight stops being a gap in coverage without becoming a source of interruption. Work continues, nothing reaches anybody at an hour they would resent, and the morning starts from a queue that somebody else has already sorted.