When Smart Send-Time Delivery Should Fall Back To Immediate Sending

Smart send-time delivery, sometimes called send-time optimisation (STO), chooses when an individual subscriber should receive a message within a permitted window. It generally uses historic engagement patterns to predict when that person is most likely to notice or act on the email.

That can be useful for a newsletter, a weekly product round-up or a non-urgent promotional campaign. It becomes risky when the message loses meaning as time passes.

The central rule is simple: use smart timing only where the business can genuinely tolerate the delay. If the recipient needs the information now, or if the underlying event may change before the selected send time, immediate sending should take precedence.

This is not an argument against send-time optimisation. It is an argument for treating it as one scheduling input among several, rather than an automatic setting applied to every email programme.

What smart send-time delivery can and cannot do

A send-time model usually looks at past interactions and assigns a likely high-engagement period for each person. For example, Salesforce’s implementation analyses recent engagement history and can place contacts into a queue for a recommended time within a chosen window. Its documentation is clear that the purpose is to maximise the probability of engagement, rather than reduce latency for messages such as reservation or booking emails. Salesforce’s send-time optimisation model card also excludes transactional messages from its intended use.

That distinction matters. A model can be well calibrated for promotional email and still be entirely unsuitable for a password reset, an order confirmation or a notice that an appointment has changed.

Smart timing is also not a deliverability fix. It may spread a campaign’s submissions across several hours, which can make operational sense in some programmes. But it does not repair weak permission, poor audience quality, excessive contact frequency, broken authentication or a high complaint rate. Gmail’s sender guidance, for example, focuses on authentication, alignment, complaint rates, correct message formatting and easy unsubscribing for marketing mail. Google’s email sender guidelines do not present a preferred send hour as a substitute for those fundamentals.

In practical terms, optimising the send time can improve the chance that an already wanted email is seen at a convenient moment. It cannot make an unwanted message wanted, or guarantee inbox placement.

The test: does delay change the recipient’s decision?

Before enabling an optimised send window, ask a more useful question than “is this email automated?”:

Would a reasonable delay make the email less accurate, less useful or less fair to the recipient?

If the answer is yes, use immediate sending. If the answer is no, an optimised window may be appropriate.

This puts event relevance ahead of channel labels. Some lifecycle messages are technically marketing communications but are closely tied to an action the person has just taken. Equally, a regular promotional send may be time-sensitive because the offer, stock position or registration deadline is short.

Message type	Default delivery approach	Why
Password resets, sign-in codes and security alerts	Immediate	The recipient is actively trying to complete a task or needs to respond to a security event.
Order, payment, booking and cancellation confirmations	Immediate	These messages provide evidence of a completed transaction and may be needed for support or travel arrangements.
Service disruption, safety or material account-change notices	Immediate	Delaying the notice can prevent the customer from taking timely action.
Welcome messages after a new subscription or account creation	Usually immediate	The subscriber’s intent is fresh. A delayed welcome can feel disconnected from the action that prompted it.
Triggered marketing tied to a recent action, such as a browse or basket reminder	Immediate or a short, predefined delay	The useful window is set by the event, not merely by a predicted future open time.
Weekly newsletters, editorial digests and broad non-urgent campaigns	Smart send-time delivery can be suitable	The content normally remains relevant across a wider period.
Long-running educational or nurture programmes	Smart send-time delivery can be suitable	A delay of several hours is unlikely to change the substance of the message, provided journey sequencing remains coherent.

Use an immediate fallback for expiry-bound messages

Every send-time programme needs an explicit latest acceptable delivery time. This is different from the campaign’s nominal end date.

Consider an invitation to a live webinar at 14:00 on Thursday. A marketer may decide that the email is only useful if it arrives by 09:00 on Thursday, giving the recipient time to plan. If the optimisation engine’s next recommended slot is 11:00, the system should send immediately rather than wait. Waiting until the model’s preferred hour technically follows the optimisation logic but fails the campaign’s real purpose.

The same principle applies to:

• offers ending soon, especially where redemption needs time;
• event reminders and registration deadlines;
• messages linked to perishable availability, such as a limited booking slot;
• renewal or payment reminders where a customer must act before a service consequence; and
• time-zone-sensitive notices.

Define this in the workflow as a hard rule: if the recommended send time falls after the latest useful time, bypass optimisation and release the message immediately. Do not leave the decision to a campaign operator who may not see the queued population in time.

Some platforms impose their own minimum or maximum optimisation windows. For example, Salesforce Account Engagement allows a selected delivery window of three to 168 hours and notes that its model needs processing time before it identifies send times. Its configuration guidance recommends allowing an hour before the desired arrival period. That makes a defined deadline especially important: a message with a four-hour useful life is a poor candidate for a multi-day optimisation window.

Do not confuse missing data with a reason to delay

Send-time predictions are inherently weaker for people with little usable history: new subscribers, infrequent recipients, people returning after a long absence, and contacts whose engagement data is sparse or distorted.

Platforms handle this differently. Some use an aggregate model or a randomised recommendation when there is insufficient individual data. Salesforce notes that its optimisation uses 90 days of engagement data and may use aggregate data or a general model where individual information is lacking. Its explanation of how send-time optimisation works is a useful illustration of why a predicted time for a new contact should not be treated as a personal preference.

The right fallback depends on the message:

• For a welcome email or a confirmation of a new preference, send immediately.
• For a routine newsletter, use a sensible fixed local-time send or include the person in the normal batch, rather than pretending a low-confidence prediction is personalised.
• For a triggered message with a narrow relevance window, send immediately or apply the trigger’s own deliberate delay.

It is worth separating “no prediction” from “immediate send” in reporting. Otherwise, a large unmodelled group can make the programme look more personalised than it is and hide whether the fallback audience performs differently.

Re-check eligibility when the message is released

Optimised sending introduces a queue between campaign selection and delivery. Conditions can change during that interval. A recipient may unsubscribe, receive another campaign, purchase the item being promoted, cancel the booking being referenced, or become ineligible for the offer.

For this reason, evaluate critical suppression and eligibility rules at release time as well as at entry to the queue. At minimum, the final send decision should honour:

• global and programme-level unsubscribes;
• recent hard bounces and known invalid addresses;
• complaint-derived suppressions where available;
• frequency and contact-pressure limits;
• changes to consent or channel preference; and
• the business event that made the email relevant in the first place.

This is particularly important for commercial triggers. If a customer buys after entering a basket-abandonment journey, suppressing the reminder is more valuable than finding an excellent hour to send it. If an offer has been exhausted, do not send an impeccably timed email advertising it.

An immediate-send fallback should follow the same suppression rules. “Immediate” means no optional timing hold; it must never mean bypass consent, safety or audience controls.

Protect the journey, not just the individual email

Optimising each email independently can damage the experience of a multi-message journey. A welcome series designed around day-one, day-three and day-seven messages can become oddly paced if a later message is released before an earlier queued email, or if optimisation extends a planned gap.

Set journey-level constraints before enabling STO:

• a minimum interval between related messages;
• a maximum permissible delay for each step;
• precedence rules for operational and high-priority service messages;
• a rule for what happens when a person becomes eligible for two campaigns during the same optimisation window; and
• a release-time check that avoids promoting a state the customer has already moved beyond.

For example, a retail programme might intentionally wait 45 minutes after a basket event before sending a reminder. That is a business-designed pause, not send-time optimisation. Once the 45 minutes have passed, it may give the model another two hours to choose a suitable time. If it has not sent by then, it should release immediately while the basket is still likely to be relevant. The next day’s general promotion should also be held if it would create unnecessary pressure.

Use immediate sending when the sender needs a dependable operational deadline

There are cases where a marketer or service team needs to know that all eligible recipients have entered the mail stream by a particular time. This may be because support staffing, website capacity, event operations or coordinated communications depend on it.

Set a firm cut-off and use immediate sending for any contacts remaining in the queue at that point. The purpose is not to force all mail to arrive at the same instant; mailbox providers still control acceptance, deferrals and inbox placement. It is to avoid allowing the optimisation queue itself to introduce avoidable, uncontrolled latency.

Where a programme uses provider-level pacing, that pacing should remain in place. Switching a campaign from smart timing to immediate submission does not justify disregarding temporary deferrals, connection limits or established throughput controls. The safer interpretation of “immediate” is “submit now under the normal, responsible delivery policy”.

Be careful with engagement data

Most send-time systems use engagement signals such as opens and clicks. Those signals can be useful at an aggregate level, but they are imperfect. Apple’s Mail Privacy Protection is designed to prevent senders learning certain information from remote content, including IP-based location and when a message is viewed. Apple’s explanation of Mail Privacy Protection is one reason open events should not be treated as a precise record of human reading behaviour.

That does not make optimisation useless. It does mean that teams should validate it against outcomes closer to the message’s purpose: verified clicks, completed registrations, purchases where measurement is lawful and appropriate, preference changes, or retained subscribers. Review unsubscribe and complaint signals alongside those outcomes. A send-time model that increases measured opens while increasing complaints or reducing conversion is not a success.

For bulk marketing traffic, make unsubscribing straightforward regardless of when the email is sent. Gmail requires one-click unsubscribe support for relevant bulk marketing and subscribed messages, and the underlying standard describes the signed List-Unsubscribe and List-Unsubscribe-Post mechanism. See RFC 8058 on one-click unsubscribe signalling.

How to evaluate the fallback policy

A useful test compares a clearly defined optimisation policy with an appropriate control, rather than comparing this month’s campaign with last month’s. Keep the audience, offer, creative and measurement period as consistent as practical.

Measure at least three separate things:

1. Timeliness: the time from qualifying event to submission, and where available the time to delivery. Check whether messages are reaching people before the agreed useful deadline.
2. Business outcome: the action the message was designed to support, such as account activation, registration, purchase or attendance.
3. Recipient and deliverability signals: unsubscribes, complaints, hard bounces, provider feedback and mailbox-provider reputation indicators.

Segment the results. A model may work well for established, frequently engaged subscribers while adding delay for new contacts. It may help a regular newsletter but harm a trigger. A single blended average will conceal both outcomes.

If deliverability is already under pressure, resolve the underlying issues before attributing a change in results to send time. Authentication and alignment, list acquisition and suppression, sending-domain reputation, content expectations and contact pressure deserve more attention than marginal gains from an algorithmic send hour. Google explicitly advises bulk senders to monitor Postmaster Tools and keep reported spam rates below 0.3%. Google’s sender-guidelines FAQ also notes that senders classified as bulk senders remain in that category.

A practical policy for immediate fallback

A mature policy is usually short enough to explain to campaign, product and engineering teams:

• Send immediately if the email supports an active customer task, confirms an event, concerns security or service, or has a narrow usefulness window.
• Use smart timing only for permission-based marketing or lifecycle messages that remain valid throughout the allowed window.
• Set a latest useful send time for every optimised programme. Send immediately if no recommended slot falls before it.
• For people without a meaningful individual prediction, choose the fallback that fits the message type: immediate for fresh, event-driven communications; a controlled standard time for routine campaigns.
• Run eligibility, consent, suppression and contact-pressure checks when the message is actually released.
• Keep normal responsible delivery controls in force. Immediate scheduling is not a licence to override provider-aware pacing.

The policy should be documented in the journey design, rather than left as an informal judgement call. That makes it easier to audit, test and revise when a programme changes.

Where specialist deliverability support fits

When send-time optimisation is being used to compensate for falling engagement or delivery problems, the more valuable question is often why the programme is underperforming. A deliverability review can separate queueing and timing issues from authentication gaps, audience deterioration, excessive contact pressure or provider-specific reputation signals.

For permission-based senders, Email Foundry can be relevant where that work requires a managed view of authentication and infrastructure, audience suppression, contact-pressure controls, mailbox-provider telemetry and sensible pacing. The aim should be to establish a safe sending baseline first, then decide whether smart timing improves a particular class of message.

Send-time optimisation is best treated as a refinement. Immediate sending is the correct fallback whenever relevance, accuracy, fairness or operational certainty matters more than finding a statistically attractive hour.

Frequently asked questions

Should transactional emails use smart send-time delivery?

Normally no. Password resets, sign-in codes, confirmations, cancellations, security alerts and similar messages should be sent immediately because their value depends on prompt delivery. They should still pass ordinary authentication, suppression and responsible delivery controls.

Does immediate sending improve inbox placement?

No. Immediate sending removes an optional scheduling delay; it does not guarantee acceptance, inbox placement or prompt delivery by a mailbox provider. Authentication, permission, complaints, audience quality and sending behaviour remain more important deliverability factors.

What should happen if there is not enough data to predict a recipient’s best send time?

Choose a fallback based on the message. Send fresh event-driven messages immediately. For routine campaigns, use a controlled standard send time or normal batch rather than assuming that an aggregate prediction represents an individual preference.

How long should a smart send-time window be?

Only as long as the content remains useful. Set the window from the recipient’s and campaign’s deadline, then configure an immediate-send fallback before that deadline. A broad newsletter may tolerate a day or more; a time-sensitive trigger may only tolerate minutes or a few hours.

Sources and further reading

• Google email sender guidelines — Google
• Google email sender guidelines FAQ — Google
• Salesforce model card: Einstein Send Time Optimization — Salesforce
• Salesforce: How Einstein Send Time Optimization works — Salesforce
• Use Mail Privacy Protection on iPhone — Apple
• RFC 8058: Signaling one-click functionality for List-Unsubscribe headers — RFC Editor