## 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