## TL;DR
Schedule every send in the recipient's local timezone and spread sends across business hours. A midnight burst from a scheduler that only knows UTC looks automated in the worst way: hundreds of messages landing at 3am local. Timezone-aware, evenly spread sending fixes both the filter signal and the open rates.

## The error
```text
Follow-ups scheduled for 3am recipient-local time - the midnight burst looked like bot behavior to receiving filters
```

## Steps
1. Audit recent sends: convert each send timestamp to the recipient's local timezone and confirm the clustering.
   Expected: a clear spike of sends in the 12am to 5am local window.
2. Add timezone resolution to the scheduler: store each recipient's timezone (from their location, area code, or stated preference) and convert send times before queuing.
   Expected: every queued send carries a recipient-local timestamp.
3. Restrict automated sends to business hours in the recipient's local zone (for example 8am to 6pm) with an even spread.
   Expected: no sends land in the overnight window.
4. Cap per-domain and per-hour send rates so the spread is real, not just shifted.
   Expected: sends flow evenly instead of bursting at the window open.
5. Monitor open rates by local send hour for a week and tune the window.
   Expected: engagement peaks inside business hours and overnight sends stay at zero.

## Use this when
- An agent schedules follow-ups or drip emails
- Sends cluster at odd hours in the recipient's timezone
- Engagement is low and the audience spans timezones

## Not for this skill when
- The audience explicitly opted into alerts at any hour (transactional mail is exempt)
- The problem is volume or content, not timing (check those first if timing is already sane)
- Sends are manual and already timezone-aware (then look at frequency)

## Variant phrasings
- emails sending at 3am local time, hurting deliverability
- scheduler sending follow-ups at midnight recipient time
- timezone-aware email scheduling for outreach
- batch sends look like bot behavior to spam filters

## Why it happens
The scheduler queued everything in UTC (or the server's timezone) with no conversion, so a scheduled morning send became 3am for recipients hours behind. Receiving filters correlate overnight bursts with automation abuse, and humans do not open 3am mail anyway, so the same bug hurts deliverability and engagement at once.

## Edge cases
- Daylight-saving changes: re-resolve timezones around DST transitions; a stored offset goes stale.
- Unknown timezone: fall back to the recipient's country default or the sender's business hours, never to a raw UTC blast.
- Candidates who asked for evening contact: honor explicit preferences over the default window.
- Interval-based drips (for example 3 days later) still need the local-time clamp applied at send time.

## Provenance

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