Send window

Mostly it is about plausibility and courtesy. Business mail that arrives at three in the morning local time, or on a Sunday, looks automated regardless of how it is written, and automation is what filters and recipients are both alert to. Restricting sends to working hours on working days removes the tell.

It also smooths volume. A window forces a day's sends to spread across a range of hours rather than firing the moment a delay expires, which is a gentler pattern for the receiving side.

There are two reasonable answers and they behave very differently. A window in the sender's timezone is predictable for the team and wrong for half the recipients. A window in each recipient's timezone is better for the recipient and requires reliable location data you may not have.

The honest default is to state which one is in force. A tool that quietly uses server time while presenting a working-hours setting is producing three-in-the-morning mail while claiming otherwise.

Send-time optimisation means modelling an individual's past behaviour to pick a moment. A window means a person typed some hours into a form. Both are legitimate; only one of them requires a model, and only one of them makes a claim about the recipient.

Worth being precise about, because the two are routinely marketed as the same feature — and a window described as optimisation is a claim that cannot be substantiated.

A SalesShift sequence carries a start time, an end time, the days it may send on and the timezone those are read in. Steps that come due outside the window wait for the next opening. It is a window you set, not a model of the recipient.