On this page
Send-time optimisation stamps each recipient of a broadcast with their own individual send time, based on the hour of day they have historically sent the most inbound messages, instead of sending your whole audience at the exact moment you click send. This article explains how the underlying heuristic works, what happens for contacts with no history, and how it interacts with the campaign's own pacing window.
Send-time optimisation
- 1Reach the Schedule step of the composer
- 2Set your pacing window
- 3Turn on "Send at each contact's best
- 4Finish the rest of the Schedule step
- 5Understand what happens once the campaign fires
Before you start
- This is a checkbox on the Schedule step of any broadcast; no separate setup is required beforehand.
- It works best on an audience with real conversation history in VGraple CRM. A brand-new audience (fresh CSV import, no prior conversations) falls back to the default hour for every contact, which still works, but has nothing individual to optimize yet.
- Decide your campaign's overall pacing window first, since send-time optimisation operates inside it, not instead of it.
Steps
- Reach the Schedule step of the composer. Build your audience and message as normal, then move to the third step.
Set your pacing window. Choose how the campaign is paced (as fast as the number allows, or spread over 1, 4, 8 or 24 hours). This window is the outer boundary send-time optimisation works inside.
Turn on "Send at each contact's best hour." This checkbox appears alongside the other Schedule-step timing options. Its helper text explains: "Uses the hour each contact has historically replied in. Nobody is delayed past the pacing window above."
Finish the rest of the Schedule step and send. No further configuration is needed; the system computes each recipient's send time automatically once the campaign starts.
Understand what happens once the campaign fires. At the moment sending begins, every pending recipient is stamped with a computed send time based on their preferred hour, then the send loop only picks up recipients whose stamped time has arrived, batch by batch, until the campaign completes.
What you will see
Recipients of a send-time-optimized campaign do not all move to "sent" at once, even on a fast connection; they are released in waves as each recipient's computed hour arrives, visible on the campaign detail page as the funnel fills in gradually rather than jumping straight to a high sent count. This is expected and by design, not a sign of a slow or stuck campaign. The delivery funnel and per-recipient table work exactly the same as any other campaign once each message actually sends.
How is a contact's "best hour" actually computed?
A nightly job looks at the last 90 days of inbound messages across your organization and, for each contact, finds which hour of the day carries the most messages from them, requiring at least 3 observations before trusting the result. A contact with fewer than 3 inbound messages in that window, or none at all, falls back to a default send hour (11 AM) rather than being treated as having a "known" preference that is really just noise from one or two data points.
This is deliberately a heuristic and not a predictive model. The honest version of this feature at typical business message volumes is "message people at the hour they have actually been awake and responsive before," computed directly from their own behavior, rather than a black-box score nobody on the team could explain if a customer asked why they got a message at that particular hour. When the campaign starts, each recipient's stamped send time is calculated forward from the current moment: if their preferred hour is later today, they wait until then; if it has already passed for today, the delay is capped at the campaign's own pacing window rather than pushing them to tomorrow, so nobody misses the campaign entirely because of the hour they usually reply.
Example
A salon's contact base includes a mix of working professionals who reply to WhatsApp mostly around lunchtime and retirees who reply mid-morning. A festive offer broadcast with send-time optimisation on reaches the lunchtime group around 1 PM and the mid-morning group around 10 AM, both inside the same overall campaign window, rather than everyone receiving it at whatever moment the salon happened to press send.
Settings and options
| Setting | What it does | Default |
|---|---|---|
| Send at each contact's best hour | Stamps each recipient with their own computed send time within the campaign window | Off |
| Preferred hour recalculation | Nightly job recomputes each contact's preferred hour from their last 90 days of inbound messages | Automatic, no configuration |
| Minimum observations | Inbound messages required before a contact gets an individual preferred hour | 3 |
| Default hour | Used for contacts without enough history | 11 AM |
| Pacing window | The outer bound send-time optimisation cannot move a send past | Set separately on the Schedule step |
Why is inbound message history used instead of read receipts?
Choosing which signal to trust matters here: a read receipt can fire in a batch the moment someone unlocks their phone after hours away from it, which says nothing about when they were actually alert and receptive, only when their phone happened to sync. An inbound message a contact sent is a much stronger signal specifically because it means they had the phone in hand and made an active choice to type something to your business at that hour, which is a genuinely different, more reliable statement about when that person tends to be engaged than a passive delivery receipt could ever provide. This is also why the computation requires at least 3 separate inbound messages before trusting an hour for a given contact: a single message sent at 2 AM because of one unusual night does not make 2 AM that person's real pattern, and the minimum-observation threshold exists precisely to avoid mistaking noise from one or two data points for a genuine preference.
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| Campaign is sending very slowly compared to a normal broadcast | Recipients are being released at their individually computed hours, spread across the pacing window, which is expected with this option on | Not an error; check the funnel is still progressing, or turn the option off for future campaigns that need to land all at once |
| Most recipients seem to send at the same default hour | Many contacts in the audience have little or no inbound message history yet | Expected for a newly imported or low-engagement list; the feature has more to work with as real conversations build up |
| A recipient received the message immediately despite having a "best hour" later in the day | Their computed hour had already passed relative to the campaign start, so the delay was capped at the pacing window instead of waiting until tomorrow | Expected behavior; nobody is ever delayed past the campaign's own window |
| Preferred hours do not seem to reflect recent behavior changes | The nightly recompute job runs on a schedule, not instantly after every new message | Wait for the next nightly run; the hour updates automatically over time as new activity accumulates |
Does this feature ever conflict with A/B testing or a holdout group?
No, all three can run on the same campaign without interfering with each other, because they operate on different layers of the send. Send-time optimisation only changes when a recipient's message goes out within the campaign's window; it never changes what they receive or whether they receive it at all. A/B testing decides which of two versions a recipient gets, independent of timing, and a holdout deliberately withholds a slice of the audience from receiving anything, also independent of timing. A campaign can validly combine all three: two versions being tested, each recipient sent at their own best hour, with a small holdout group receiving neither version, and each mechanism does its own job without needing to know the other two exist.
Related reading
Combine send-time optimisation with A/B testing a broadcast to test both message and timing together, and review quiet hours and the marketing frequency cap for the org-wide timing rules that apply on top of any per-contact optimisation.