Featured Article
Implementation
“Call me tomorrow at nine” is not a complete scheduling instruction. A voice workflow needs a confirmed calendar date, local time and time zone before it can create a reliable callback. Store both that local agreement and the corresponding UTC instant, then check that the task is still valid before placing the call.
This guide is for developers and marketing operations teams building that scheduling layer. ConversAI Labs publishes it as an implementation design; the suggested fields are application-owned examples, not a claim that the platform provides a native calendar connector or these scheduling features.
What should the voice agent confirm?
Ask for the missing details before accepting a callback: the date, time and the time zone the caller intends. A phone country code, company headquarters or your server's location is not enough to establish where the caller will be.
For example, on 23 September 2026 a caller says, “Tomorrow at 9, London time.” The confirmation should be explicit: “Thursday, 24 September at 9 AM London time—is that right?” With the Europe/London rules for that date, this means 08:00 UTC, or 13:30 in Asia/Kolkata. It does not mean 9 AM on an India-based server.
Use an IANA time-zone identifier such as Europe/London, rather than storing only an abbreviation or today's UTC offset. The IANA Time Zone Database records local-time rules and is updated when governments change offsets or daylight-saving arrangements.
Confirm that the callback was booked only after your system has saved it successfully. If storage fails, say that scheduling could not be completed and offer the configured alternative.
What should a callback task store?
Keep the human agreement alongside the machine execution time. These are suggested application fields, not a ConversAI API request schema.
| Field | Example or purpose |
|---|---|
| Callback reference | An opaque task identifier, separate from contact details |
| Agreed local date and time | 2026-09-24 09:00 |
| IANA time zone | Europe/London |
| Resolved execution instant | 2026-09-24T08:00:00Z |
| Schedule revision | Increment when the caller reschedules |
| State | Pending, cancelled, dispatched or completed, with defined transitions |
| Timing policy | What to do if the job is late or the intended time becomes invalid |
The execution instant lets workers compare due tasks consistently. The local agreement lets an operator explain what the caller requested and review future rule changes. Keep contact information in the appropriate protected system; a scheduling log should not need a full transcript to identify a job.
What happens when clocks move forward or back?
Daylight-saving transitions create two different problems. A local time can occur twice when clocks move back, or not occur at all when clocks move forward. Python's PEP 495 describes these as a fold and a gap.
Do not silently choose an interpretation when the requested time is ambiguous or missing. Offer an unambiguous alternative or confirm which occurrence the caller means, then validate the resulting instant. For Python implementations, zoneinfo supports IANA rules and the fold flag for repeated times. Merely attaching a zone to a datetime is not sufficient validation of a missing local time.
Keep the runtime's time-zone data maintained. If rules change before a future callback, decide explicitly whether to preserve the agreed local time or the previously resolved instant. For a promise such as “9 AM London time,” preserving that local agreement is a sensible application policy; recalculate unexecuted tasks through a controlled schedule revision rather than silently changing them.
Is a recurring callback different from a one-off callback?
Yes. “Every Monday at 9 AM in London” expresses a local recurrence. Adding a fixed number of hours to a UTC timestamp can shift the local appointment after a clock change.
Store the recurrence rule with its intended zone and resolve each occurrence. Google Calendar's event and time-zone documentation explains that recurring events need a time zone to expand their instances. This is a useful model even if your application uses another scheduler.
A request for one callback is not a request for a recurring campaign. Keep that distinction in the task model and the caller confirmation.
What should the worker check before calling?
Before dispatch, reload the task and verify that it is pending, due, within its agreed timing policy and on the current schedule revision. A rescheduled job can leave an old queue message behind; that message must not trigger the superseded call.
Cancellation and dispatch need coordinated state transitions so two workers cannot independently act on stale state. Define what happens if cancellation arrives after dispatch has already started, and avoid promising that it can always stop a call in progress.
If the scheduler restarts late, do not immediately dial every overdue contact. Apply the agreed lateness policy: reschedule, request confirmation or send the task for operator review. Track requested time, dispatch time and final outcome separately; a queued job is not a completed conversation. For repeated delivery, use the principles in our voice AI webhook retry guide.
What should you test before launch?
Test a normal cross-zone callback, an unknown zone, a spring-forward gap, a repeated autumn time, a reschedule with an old queue message, cancellation near dispatch and recovery after an outage. Include a caller travelling to a different zone and an operator viewing the task from India.
For each case, check the spoken confirmation, stored local agreement, resolved instant and final worker decision. Measure late dispatches and duplicate attempts separately from successful calls.
Start with the human-handoff fallback guide if you have not yet defined who owns an unanswered transfer. Then review the ConversAI Labs documentation for the supported call API and build scheduling around the capabilities you have actually validated.
About ConversAI Labs Team
The ConversAI Labs team writes about building and operating voice AI workflows.