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.

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.

1. 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.

1. 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.

1. 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.

1. 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