Why a scheduled auto-responder stops replying on time
The scheduler inside the app calculates time based on local settings of the device or server — and the first discrepancy breaks the schedule.
After the switch to daylight saving time or a time zone change, the rule triggers an hour earlier, later, or not at all: the scheduled auto-responder sends nighttime in-app messages in the middle of the workday, and stays silent on weekends.
The user sees an automatic reply when a live operator is nearby and concludes that no one reads inquiries here.
The second failure is duplicates. If a task is processed twice — when the app restarts, a notification is redelivered, or the connection drops midway through sending — the client receives two identical messages in a row.
The opposite situation is no less costly: the bot replies outside the schedule, and inquiries that arrive between shifts pile up in the queue unanswered until morning, and some are lost when the buffer is cleared or the service restarts.
For support, this translates into lost inquiries: only the last message is visible in the conversation, the history falls apart, and the client writes again — already in another channel.
The share of replies outside the window and the number of duplicates grow along with the volume of conversations, and this can no longer be untangled manually: an operator cannot distinguish a forgotten inquiry from one the bot closed with a formal brush-off.
The root cause is that the schedule lives on the client side, and the decision to send is made without checking the queue state and without protection against repeated execution.
We break down how this is closed — from a single source of time and delivery windows to separate logic for messages that arrive outside a shift.
What changes after setup: response speed and workload
First response and share of answered inquiries
Without a schedule, the client's first message waits for an operator as long as the shift lasts: at night and on weekends, the inquiry simply sits in the queue.
The scheduled auto-responder replies at the moment of the inquiry — during working hours it passes the dialog to the on-duty operator, outside the schedule it clarifies the question itself and puts it first in the morning.
First response speed stops depending on shift workload and is measured in seconds instead of tens of minutes.
The share of answered inquiries grows specifically due to non-working windows, and analysts at Gartner in customer service reviews separately note response speed as the factor that most strongly affects loyalty.
Peak hours and relieving operators
During peak hours, the schedule smooths the inflow: typical questions — request status, booking, schedule, payment — are closed by the scenario, and the operator receives an inquiry with context already collected. The queue does not grow avalanche-like because part of the flow simply never reaches a human.
Support workload is redistributed rather than increased: after scenarios launch, the team spends time on non-standard cases, not on identical replies.
We take exact figures from dialog statistics — we calculate time to first response by hour of day and the share of inquiries closed automatically. This shows where the schedule is already working and where a second scenario is needed.
Formats of scheduled auto-responder operation: comparison of schemes
Schedule mode is not a single toggle in settings, but a set of rules: when the auto-responder turns on, what it replies, and by which event it is removed.
In practice, schemes are combined, and they most often break at the junctions: handoff to an operator, quiet hours, and response confirmation behave differently depending on where the schedule lives — on the device or on the service side.
Below are four schemes that are actually chosen between during implementation. The limitations of each follow from the mechanics, not from mood.
| Variant | When it fits | Limitations |
|---|---|---|
| Hard schedule | The flow of inquiries is predictable, and most are closed by templates | The reply goes out regardless of whether the dialog has been read; during a spike, the operator cannot keep up, and the auto-reply continues to “speak” for them |
| Hybrid with handoff to operator | The flow is heterogeneous, and some questions require a human | An explicit shift indicator and a rule for removing the auto-reply are needed, otherwise one dialog will have two replies in a row |
| Quiet hours | There are nighttime windows and restrictions on contact time | Silence must also apply to manual replies, otherwise the restriction is bypassed with one click |
| Reply with confirmation | Sensitive topics where delivery guarantee matters | A delay appears for the confirmation time; unsent messages must be stored and stuck ones must be resolvable |
How to choose a mode for the flow
We focus on three numbers: the share of inquiries outside working windows, time to first response, and the share of dialogs where a human is still connected.
If the latter is large, the schedule makes sense only as insurance during absence — otherwise response confirmation turns into a formality, and handoff to the operator lags.
A hard schedule is justified where the flow is even and templates cover the bulk of typical questions; quiet hours and confirmation are layered on top as modifiers and do not replace the base scheme.
How implementation proceeds: from scenario review to handoff
A scheduled auto-responder is not one timer, but a set of rules: what we send, in which window, by the user's or server's time, and what happens if delivery fails.
That is why the work proceeds in stages, where each rule is first described, then tested on a narrow segment, and only then rolled out to the entire audience.
- Audit of bot scenarios. We review existing replies and branches: where the bot is silent, where it duplicates messages, which scenarios are already tied to the schedule.
- Time zone map. We establish what the sending window is tied to — the user's device, the region's time zone, or the server. An error here produces nighttime messages.
- Assembly of rules and windows. We configure sending periods, scenario priorities, and exceptions — quiet hours, weekends, days without user activity.
- Test sending. We run the schedule on a closed list of devices: whether the message arrives in the required window and whether it is duplicated on restart.
- Check on live traffic. We enable the mode for part of the audience and compare actual delivery times with the schedule map.
- Handoff of regulations. We provide the rule description, scenario scheme, and edit procedure so changes can be made without us.
Pre-launch check
Before enabling for the entire audience, we run a checklist: window boundaries, behavior when the sending service is unavailable, user re-entry, time zone change on the device.
Separately, we look at what the auto-responder does with a zero result — stays silent or falls back to a backup scenario.
An undescribed rule will still trigger, just unpredictably. Therefore, we consider launch ready only when every window and every exception is recorded in the regulations.
Scenario map, reply templates, and escalation regulations
After launch, the client retains not only a working app but the entire auto-responder contour: scenario map, texts, rules. We hand them over to the client's repository and accounts — without dependence on our contour and closed panels where only the contractor makes edits. Below is exactly what is documented and in what form.
- Scenario map — a table “event → condition → reply → recipient” with the schedule (working hours, weekends, time zones) and the priority order of rules when they overlap.
- Auto-reply templates — texts for each scenario, with variables and separate wording for first and repeat inquiries.
- Escalation regulations — after how many unanswered messages the dialog goes to an operator, to whom exactly, and with what response time.
- Queue scheme — which support branch takes the topic, how the workload is divided, and where to view the history of a handed-off dialog.
- Support instructions — how to enable the auto-responder, remove a rule from publication, and roll back an erroneous mailing.
- Set of test scenarios — what we run before publishing edits: schedule boundaries, repeat inquiries, channel unavailability.
Edits without releasing a new app version
Texts, schedule, and escalation thresholds are stored separately from the code — as configuration that the app requests at launch. Editing wording or a new scenario goes live within the day and works for everyone, including those who have not updated the app for a long time.
If the logic changes or a channel is added, that is already a new version, and we manage it through the usual cycle. We record the boundary between an edit and a release in the regulations in advance so support understands what it can fix itself.
Case: nighttime inquiries stopped getting lost in the queue
An app with round-the-clock orders: the peak of inquiries falls between 23:00–07:00, when support is not working.
Before implementation, this flow simply piled up in the queue — Research on handling customer inquiries records the same pattern: the longer a person waits for the first response, the higher the share of repeat messages and the more often they go to a competitor in the first minutes.
What it was before — a flow no one saw
At night, about 1,400 inquiries came into the app per month: cancellations, payment questions, delivery status. The auto-responder was silent — it was tied to the work schedule and turned on only when the shift began, so time to first response reached 8 hours.
People did not understand whether the message had arrived and wrote again: 38% of nighttime dialogs contained two or more messages.
In the first hours of the shift, support spent time not on solving tasks but on sorting through the accumulated queue, and some inquiries were closed with a formal brush-off.
What it became after — figures and feedback
We configured bot scenarios by schedule: during the non-working window, it confirms receipt, collects required parameters — order number, problem category — assigns priority, and passes critical cases to the on-duty engineer: payment, cancellation, loss of access.
Time to first response dropped from hours to seconds, repeat messages fell from 38% to 9%, and the share of nighttime inquiries closed without human involvement grew to 61%.
The queue barely accumulates by the start of the shift: support works with ready-made cards, not with a raw flow.
What to do if the bot is already working but replies at the wrong time
Usually the bot reacts to an event: a message arrived, a request was created, a status changed.
There is no schedule as a separate layer in such a scheme — so a reminder goes out a minute after purchase, and the morning summary arrives when the operator has already closed the shift. For the client, this looks like “the bot exists, but there is no benefit.”
Everything tied to the calendar rather than an action is moved into the schedule: reminder series, repeat touches after a day and after a week, end-of-day summaries, opening and closing of the support window, renewals. The trigger becomes time with the client's time zone in mind, not an incoming event.
The schedule should not take over exceptions: conflict inquiries, personal terms, cancellations — everything where the cost of an error is higher than the benefit of automation.
Such points are marked as manual: the bot brings the inquiry to an operator and stops the chain rather than continuing it on a timer.
Scenarios are not rewritten in this case. Time is moved out of the code into schedule rules, and the same chains begin to be invoked by a deferred task scheduler on the server side.
Refining an existing bot comes down to the time layer and stop points — the reply logic and interface remain the same.
Scenario migration proceeds chain by chain with a shadow launch: the rule calculates time but does not send, and we compare the hit against expectations.
Chains are enabled one by one, the old branch remains operational until confirmation; rollback is removal of the schedule rule, and the app is not rebuilt and no store update is required.
FAQ: time zones, queues, delivery failures
Before launching a scheduled auto-responder, clients ask the same technical questions. The answers below rely on Mobile platform notification delivery rules — they set the boundaries that an app cannot go beyond.
What happens when a user changes time zone?
We store the schedule in Coordinated Universal Time and tie triggering to the device's local zone. When flying, the auto-responder moves to the new local time: no duplicates and no missed slots. We consider the daylight saving time transition separately.
Where do undelivered notifications go?
They go into a queue with a timestamp and failure reason — the device is offline, notifications are disabled, or a system restriction has triggered.
When the device returns to the network, the queue catches up with the schedule, and we do not send messages that have lost their meaning.
How is resending arranged?
Each message has its own key, so a repeat does not create a duplicate — the server discards one already accepted. The number of attempts is limited: after that, the event goes into the log as undelivered instead of looping endlessly.
Is user consent required?
Without explicit permission for notifications, the schedule does not work — the system simply does not allow delivery. Consent can be withdrawn at any time, and the auto-responder stops rather than switching to a shadow mailing.
Who has access to the conversation?
The bot sees only the dialog in which it replies, and conversation history is limited by the retention period. We separate operator access by roles: exporting someone else's dialog without a separate permission is impossible.
Let's discuss the task: we'll review scenarios and come back with a plan
To make the review substantive rather than general, send the inputs for your scenario — it takes a few minutes. In return, we come back with a work plan and scope estimate, not with clarifying questions.
- Current schedule logic: which time zone the auto-responder turns on by, what happens during non-working hours, weekends, and holidays.
- Platforms and client versions where the scenario already works — to estimate the scope of refinements rather than rewrite everything from scratch.
- Bot replies: texts, buttons, branches, and what should happen if the user writes outside the scenario.
- Schedule source and adjacent systems (accounting, calendar), as well as the access the engineers will need.
- Background operation limitations: notification delivery under poor connectivity and platform limits on background tasks.
- Acceptance criteria: share of delivered replies, accuracy of time triggering, behavior on failure.
The first review is one meeting: we go through the scenario, mark places where the schedule conflicts with the platform's background restrictions, and record risks.
The work plan includes stages, the schedule storage scheme, logging points, and the rollout procedure; scope estimate is provided for each stage separately.
We describe post-launch bot support with regulations: who makes edits to the schedule and texts, how quickly we respond to incidents, and how we roll out changes without downtime.