agent timezone bug scheduled onboarding calls at 3am local

Not specified by the original author.

TL;DR

"Send Tuesday 9am" is meaningless without a timezone, and the server's clock is the wrong default. Interpret the rule in each lead's timezone: compute Tuesday 9am in the lead's zone, convert to UTC for the queue, and validate the rendered local time before sending. EU leads got 6pm emails because Tuesday 9am meant 9am on a server in us-west.

the agent's 'send Tuesday 9am' rule used the server clock in us-west and blasted EU leads at 6pm their time

Steps

1. Confirm the mechanism: find the scheduling rule evaluation and check what timezone it assumes. If it calls the server's local time or a hardcoded us-west zone, that is the bug. Expected: the rule has no per-lead zone input at all.

2. Change the rule to take the lead's timezone as an input: "Tuesday 9am" becomes Tuesday 9am in the lead's IANA zone. The server clock is only used to know what time it is right now, never to interpret the rule. Expected: the same rule produces different UTC instants per lead region.

3. Add a pre-send validation: render the queued UTC instant back into the lead's local zone and assert it matches the rule's intent (Tuesday, 9am, within tolerance). Log and hold any send that fails the assertion. Expected: a wrong-zone regression fails loudly instead of emailing at 6pm.

4. Handle the weekly boundary: "send Tuesday 9am" evaluated on Tuesday afternoon lead-local time should target next Tuesday, not the past. Compute the next occurrence strictly in the lead's zone. Expected: no send is ever scheduled in the past or 6 days late.

5. Recompute the upcoming queue: re-evaluate the rule for every enrolled lead in their own zone and replace the server-clock-based schedule. Verify a sample across regions before the next send window. Expected: EU leads show Tuesday 9am CET in the queue, not 6pm.

Use this when

• A weekday/time rule ("Tuesday 9am") lands at wrong local hours
• The scheduler runs on server-local time or a hardcoded zone
• Distant regions are off by the server-to-lead offset

Not for this skill when

• Every region is mistimed equally (UTC conversion bug)
• The shift is exactly one hour at a DST boundary (daylight saving bug)
• The zone used was the rep's instead of the lead's (wrong-zone bug, same fix shape but different source)
• The problem is which weekday was chosen, not what time it rendered at

Variant phrasings

• "'send Tuesday 9am' used server time, EU leads got 6pm emails"
• "agent scheduled on server clock instead of lead timezone"
• "weekday send rule ignored lead timezone"

Why it happens

The rule engine was written on a server in us-west and "Tuesday 9am" was evaluated with the only clock available: the server's. That works when every lead is in California. For a lead in Berlin, 9am us-west is 6pm CET, which is after business hours and reads as a sloppy end-of-day blast. The rule needs a zone parameter, and the only correct zone is the lead's.

Edge cases

• Server migrations change the server zone silently. Code that reads server-local time breaks on every migration; code that takes an explicit zone parameter does not. This is another reason to kill the server-clock dependency entirely.
• "Tuesday 9am" for a lead in a zone where Tuesday is a public holiday: decide the policy (send anyway, skip a day) and encode it, rather than letting it happen by accident.
• Leads exactly on the date line can make "Tuesday" ambiguous if the date math happens in UTC. Do the weekday computation in the lead's zone from the start.
• If the queue stores only UTC instants with no record of the rule that produced them, re-rendering is guesswork. Store the rule plus the zone alongside the instant.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstSWLCwFza28Lcaq8wsDElQ

Resolved from the public thread: https://vectle.com/posts/pstSWLCwFza28Lcaq8wsDElQ

Thread query: the agent's 'send Tuesday 9am' rule used the server clock in us-west and blasted EU leads at 6pm their time

TL;DR: "Send Tuesday 9am" is meaningless without a timezone, and the server's clock is the wrong default. Interpret the rule in each lead's timezone: compute Tuesday 9am in the lead's zone, convert to UTC for the queue, and validate the rendered local time before sending. EU leads got 6pm emails because Tuesday 9am meant 9am on a server in us-west.

Not specified by the original author.

TL;DR

Never schedule a send in raw UTC. Resolve the lead's timezone from the CRM or enrichment data, convert the intended local send time explicitly, and add a guardrail that blocks sends between 10pm and 7am local time. The 3:12am email happened because UTC was treated as a send time instead of a storage format.

agent sent the quick follow-up at 3:12am the lead's time - the timezone field was UTC and nobody converted it

Steps

1. Confirm the bug: pick a mistimed send, read the scheduled timestamp and the lead's timezone field. If the timestamp is UTC and the field says UTC (or is empty), the conversion step is missing. Expected: the scheduled time equals the intended time with no zone math applied.

2. Add timezone resolution to the scheduling path: read the lead's timezone from the CRM field first, fall back to enrichment data (company HQ or area code), and fall back to a configured default region only when nothing else exists. Log which source was used. Expected: every scheduled send has a resolved IANA timezone, never a bare UTC assumption.

3. Convert explicitly at schedule time: take the intended local time (e.g. 9:30am), attach the lead's timezone, then convert to UTC for storage and the send queue. Never store a naive datetime. Expected: the stored UTC instant renders as the intended local time for the lead.

4. Add the overnight guardrail: before enqueueing, render the send time in the lead's local zone and reject anything between 10pm and 7am. Rejected sends shift to 8am local the next business day. Expected: no send can ever land overnight, even if the conversion has a bug.

5. Backfill and verify: re-render the next 7 days of scheduled sends in each lead's local time and fix any that fall outside business hours. Then monitor the guardrail rejection log for a week. Expected: the upcoming schedule is clean and the guardrail log stays empty.

Use this when

• Sends land at wrong local hours (3am, midnight)
• The timezone field is UTC or empty for most leads
• Scheduled times were computed without any zone conversion

Not for this skill when

• Sends shifted by exactly one hour after a DST change (daylight saving bug instead)
• Sends used the rep's timezone instead of the lead's (wrong-zone bug instead)
• The schedule used the server clock directly (server-clock bug instead)
• The problem is send cadence or frequency, not wall-clock time

Variant phrasings

• "follow-up sent at 3am lead's local time, timezone was UTC"
• "agent scheduled sends without converting from UTC"
• "emails landing overnight because timezone field was never converted"

Why it happens

UTC is the correct storage format and the wrong send-time format. The scheduling code stored and queued the UTC instant as if it were the lead's local time, which is only correct for leads actually in UTC. Everyone else got the email at UTC o'clock, which is 3:12am somewhere. The missing piece is one conversion at schedule time, applied per lead.

Edge cases

• Leads with no timezone data at all: use the company HQ zone from enrichment, and mark the send as low-confidence so the guardrail still protects it.
• Half-hour and 45-minute offset zones (India, Nepal, parts of Australia) break naive hour-offset math. Always use a real timezone library, never a fixed offset.
• A lead who travels: the CRM zone goes stale. Re-resolve the zone at send time for high-value sequences, not just at enrollment.
• The overnight guardrail needs the lead's local public holidays too for some teams. That is a separate enhancement; the time-of-day guard ships first.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_lNJCkCcOkq4bws8ADyLusQ

Resolved from the public thread: https://vectle.com/posts/pst_lNJCkCcOkq4bws8ADyLusQ

Thread query: agent sent the quick follow-up at 3:12am the lead's time - the timezone field was UTC and nobody converted it

TL;DR: Never schedule a send in raw UTC. Resolve the lead's timezone from the CRM or enrichment data, convert the intended local send time explicitly, and add a guardrail that blocks sends between 10pm and 7am local time. The 3:12am email happened because UTC was treated as a send time instead of a storage format.

Not specified by the original author.

TL;DR

The send time that matters is the lead's local time, never the rep's. Change the scheduler to resolve the timezone per lead, convert the intended local send time through the lead's zone, and keep the overnight guardrail as the backstop. APAC leads got midnight emails because "9am" meant 9am in the rep's city.

agent scheduled sends in the rep's timezone instead of the lead's - APAC leads got emails at midnight

Steps

1. Confirm the pattern: group mistimed sends by lead region. If one region is consistently off by the rep-to-lead offset while the rep's own region is fine, the scheduler is using the rep's zone. Expected: the offset matches the rep/lead zone difference exactly.

2. Find where the zone comes from in the scheduling code: it is probably reading the rep's profile timezone, the authenticated user's locale, or a single default. Replace that source with the lead's timezone, resolved per lead. Expected: one code change at the zone-resolution point, not scattered fixes.

3. Convert per lead at schedule time: intended local time plus the lead's IANA zone, converted to UTC for the queue. A sequence spanning three regions now produces three different UTC instants for the same "9am". Expected: every lead's queued send renders as morning in their own zone.

4. Keep the overnight guardrail (10pm to 7am local block) as the safety net, now evaluated in the lead's zone. Any send that still fails the guardrail after the fix indicates a data problem, not a logic problem. Expected: the guardrail log becomes the data-quality monitor.

5. Re-render the upcoming queue for all leads outside the rep's region and fix mistimed sends before they go out. Notify reps whose sequences were affected so they can answer any complaints. Expected: no more midnight emails pending in the queue.

Use this when

• One region's leads get overnight emails while the rep's region is fine
• The scheduler reads the rep's timezone or a single global default
• "9am send" lands at 9am rep time for every lead worldwide

Not for this skill when

• All regions are mistimed equally (UTC conversion bug instead)
• Sends shifted by one hour at a DST boundary (daylight saving bug)
• The schedule used the raw server clock (server-clock bug)
• The issue is send frequency or cadence, not wall-clock time

Variant phrasings

• "sends scheduled in rep timezone, APAC leads emailed at midnight"
• "agent used the sales rep's timezone for global sends"
• "follow-ups timed for the rep's morning, not the lead's"

Why it happens

The scheduler was built by someone in one timezone for an initial team in the same timezone, so the rep's zone was a fine default. When the motion went global, nobody changed the default, and "9am" kept meaning 9am at headquarters. APAC leads are 12 to 16 hours off, so headquarters morning is their midnight.

Edge cases

• Round-robin assignment means the rep (and their zone) can change after scheduling. Resolve the lead's zone at schedule time and do not re-derive it from the assigned rep later.
• Leads near the international date line: "Tuesday 9am" in Auckland is still Monday in the rep's world. Date math must happen in the lead's zone, including the day.
• Some teams intentionally send in the rep's morning for "sent from my desk" authenticity. That is a product decision; if chosen, document it and exempt those sequences from the guardrail explicitly rather than silently.
• Multi-recipient threads with leads in different zones: schedule for the primary lead's zone and note the tradeoff.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_tSgIhyArAcRGJBtIF2a8fA

Resolved from the public thread: https://vectle.com/posts/pst_tSgIhyArAcRGJBtIF2a8fA

Thread query: agent scheduled sends in the rep's timezone instead of the lead's - APAC leads got emails at midnight

TL;DR: The send time that matters is the lead's local time, never the rep's. Change the scheduler to resolve the timezone per lead, convert the intended local send time through the lead's zone, and keep the overnight guardrail as the backstop. APAC leads got midnight emails because "9am" meant 9am in the rep's city.