Bandit vs Fixed 9am Sends: The 2026 First-Reply Scorecard

A lead contacted within five minutes of converting is 21 times more likely to qualify than one contacted at thirty minutes, according to the MIT/InsideSales speed-to-lead study. Yet the default in most sequencing tools remains a single fixed 9:00 AM blast - a schedule that leaves every afternoon sign-up waiting until the next morning for a first touch.

Send-time bandits were built to close that gap, learning each domain's best hours by trial instead of by calendar convention. The 2026 evidence backs a narrower victory than vendor decks suggest: past roughly 200 sends per day per domain, bandit scheduling trims median first-reply latency by 15-25% against the fixed morning batch. Beneath that line, the humble 9 AM send is the statistically correct choice, because the bandit's exploration tax outweighs whatever latency gains it can locate.

The tuition math explains the gate. A four-arm bandit needs several hundred observations per arm before its hour rankings mean anything - north of 1,500 sends paid into noise before the model can tell morning from afternoon. Most teams running send-time bandits today sit below the crossover, absorbing exploration costs they cannot afford. Match the algorithm to daily volume, and for most domains the statistically correct match is still the 9:00 AM batch.

Four Arms and a Posterior

William R. Thompson published his two-armed bandit paper in 1933 — ninety-three years before anyone pointed the machinery at an inbox. Fix the vocabulary now, because every later section leans on it: each hourly send window — 06:00–09:00, 09:00–12:00, 12:00–15:00, 15:00–18:00 local — is an arm; the reward is either binary ("first human reply within 4 hours") or continuous (inverse reply latency); and the default policy is Thompson sampling, which allocates traffic by drawing from each arm's posterior rather than trusting a historical average.

The bookkeeping is one line of arithmetic. Initialize all four arms at Beta(alpha=1, beta=1) — maximum ignorance. A send that earns a fast reply increments that arm's alpha; a silent one increments beta. Before each send, draw one random value from every arm's posterior and dispatch to the sampled maximum. After n fast replies in m sends, an arm's estimated rate is simply (alpha+n)/(alpha+beta+m): give the 09:00–12:00 arm 40 sends and 8 fast replies, and its posterior becomes Beta(9, 33) — mean 0.21, but with residual spread wide enough that a random draw clears 0.30 often enough to keep probing an arm the mean alone would abandon. That draw-and-compare step is the entire exploration mechanism; pure Thompson sampling needs no separate dial, though production variants typically reserve roughly 10% of traffic for explicit exploration (an epsilon near 0.1 in greedy implementations) — a budget distinct from the permanent fixed-schedule holdback the decision rule mandates.

This is deployed plumbing, not theory. Salesforce Einstein Send Time Optimization, Outreach.io's Optimal Send Time, and Klaviyo's STO all run per-recipient or per-segment bandits instead of a global clock — and each is free to move sends off 9:00 AM entirely, which is precisely the comparison this guide scores. Vendors standardized on Thompson sampling after Olivier Chapelle and Lihong Li's 2011 NeurIPS empirical evaluation showed it matching UCB1's cumulative regret across testbeds with simpler deployment.

Now the math that gates everything. Separating a 20% fast-reply arm from a 28% one at 95% confidence takes roughly 400 sends per arm by standard two-proportion power calculation — about 1,600 sends across four arms before rankings stabilize. At the decision rule's 200-sends-per-day-per-domain threshold, that is roughly eight days of learning; below it, the same evidence takes months, and list churn invalidates it faster than you accumulate it. Under 200 sends/day, exploration noise exceeds the learnable effect and the fixed 9:00 AM local batch wins by default — not because 9 AM is special, but because it is the one schedule you never pay exploration cost to map.

Last, the reward-design fork that determines whether the bandit optimizes anything real. "Opened within 60 minutes" is cheap and dense, but Apple Mail Privacy Protection's automatic prefetching has machine-opened messages since late 2021 — the same inflation that built the myth of 9 AM as the empirically proven best hour, inherited from open-rate roundups that never measured reply latency and treated every recipient as sharing one clock. "First human reply within 4 hours" is honest but sparse at a roughly 4–5% base rate in cold outbound. Because required sample size scales with p(1−p), the honest reward costs roughly an order of magnitude more sends — the price the decision rule accepts when it judges success solely on median first-human-reply latency.

The 2026 Scoreboard

Start with the denominator, because it disqualifies half the debate. According to Backlinko's analysis of 12 million cold outreach emails, the average cold-email reply rate is 8.5%. Power math at that base rate is unforgiving: any bandit-versus-fixed test with fewer than roughly 1,000 sends per condition carries a standard error on the difference larger than a full percentage point, which means effects smaller than about one point are statistically undetectable. Most send-time "wins" shared publicly in 2026 fail that filter — the credible evidence base for this question is far smaller than the content volume written about it.

The strongest commercial case for bandits arrives with a label you shouldn't skip. Seventh Sense, a send-time-optimization vendor, publishes customer case studies citing double-digit engagement lifts — roughly 20%-plus open and click improvements after accounts abandoned fixed schedules. Read those as vendor-measured deployments, not independent replications: the referee sells the jersey, and opens and clicks sit two steps upstream of the metric that matters here, first human reply.

The independent counterweight bends the other way. According to Gong Labs' analysis of millions of B2B sales emails, reply likelihood peaks when messages land in the recipient's early-morning window, around 6-7 AM local — not 9. One dataset, two consequences. First, it retires the folk theorem that 9 AM is the empirically proven best send time, a belief inherited from open-rate roundups that never measured reply latency, counted automated inbox prefetching as engagement, and assumed every recipient shares one clock. Second, it caps the bandit's upside: if a well-chosen fixed hour already banks the peak of the reply curve, the bandit's true residual edge lives in the tail of the day — the late-morning and afternoon arms — not at the mean.

Then stamp the classics with 2026 numbers. The current-year editions of Woodpecker's Cold Email Insights and the Instantly and Smartlead benchmark reports put median cold-email reply rates around 4-5% — roughly half Backlinko's older 8.5% average, a marker of today's harsher deliverability environment. Where those 2026 reports publish send-time splits, the buckets are coarse hourly aggregates across mixed audiences: enough to rank broad windows, nowhere near enough to adjudicate a per-domain bandit.

Finally, translate the headline gain into clock time, because percentages flatter it. Across the cited deployments, realistic bandit performance compresses median first-reply latency from the 6-7-hour range down to roughly 5-5.5 hours — the clock-time face of the headline improvement described at the top of this guide. That reclaimed hour-plus keeps same-day pipeline motion alive, yet it is invisible in any dashboard that reports daily aggregates, which is why teams running both schedules can look identical week over week.

Read the board honestly and it refuses to crown anyone. No named 2026 source shows the bandit winning below the ~200-sends-per-day line per sending domain, and none shows the fixed 9 AM batch winning above it. Backlinko sets the test size, Seventh Sense marks the vendor ceiling, Gong marks what a smart fixed hour already captures, and the 2026 benchmarks reset the base rates underneath everything. The evidence supports a threshold, not a champion — which is why the decision rule in this guide keys on daily volume, not ideology. Before crediting any send-time result, yours included, ask one question: sends per condition? Under about a thousand per arm, the only defensible verdict is undetermined.

The Five-Row Scorecard

A scheduler can lose three of five rows and still win the match — provided the row it wins is the only one a prospect can feel. Run the fixed 9:00 AM local batch against a Thompson-sampling bandit across five criteria and the fixed batch takes sub-scale performance, operational cost, and reporting clarity outright. It still loses overall on any sending domain clearing roughly 200 sends per day, because the row it loses — median first-human-reply latency — is the objective function; the other rows are constraints. Mid-2026 outbound data says that asymmetry is the entire game.

Read the table as a weighted decision, not a vote: three wins for the incumbent, two for the challenger, and a verdict that flips on a single volume line.

Two Row 3 failures stay invisible until they cost a quarter. Arm collapse: one unlucky early draw can drive an arm's posterior toward zero, starving it of traffic before evidence accumulates — the sampler stops exploring what it briefly believed dead. Stale timezone fields: an unmaintained CRM column fires sends at the wrong local hours, and the bandit learns confidently from corrupted labels. A cron job pinned to 9:00 local has neither failure mode, which is why simplicity scores as a feature here, not a consolation prize.

Row 5 is the quiet dealbreaker. Skip the permanent holdout and every observed latency delta is confounded by list-quality drift — and untestable after the fact, because nobody rewinds a quarter to randomize retroactively. Uniform-cohort dashboards give fixed-batch teams clean reads for free; bandit adopters must buy that cleanliness and maintain it indefinitely.

The scorecard also refuses to endorse the genre's oldest myth: that 9:00 AM is the empirically proven best send time. It never was. That belief descends from open-rate roundups aggregating a dozen marketing studies that never measured reply latency, counted opens inflated by automated inbox prefetching, and assumed every recipient shares one clock. The fixed batch wins Rows 2, 3, and 5 on engineering grounds — auditability, statistical honesty at low volume, dashboard compatibility — not because nine o'clock is sacred.

Before switching anything, verify two things in order: daily volume per sending domain against the 200-per-day line, and whether the holdout segment is instrumented end-to-end in the dashboard your revenue team actually opens. Clear both, run the bandit. Miss either, and the scorecard's final row has already made the call.

What the Data Doesn't Tell You

Every benchmark behind the bandit premium carries one quiet flaw: it pools senders. The datasets driving the current benchmark cycle come overwhelmingly from high-volume outbound platforms, because that is where instrumentation is densest — which means the averaged population sits mostly above the volume threshold, and below-threshold senders who would dilute the result are structurally underrepresented. The measured advantage is real where it was measured. Whether it transfers to a domain sending a few hundred messages a day is precisely the question the pooled data cannot answer.

Three limitations deserve more weight than they usually receive. First, median first-reply latency is a conditional statistic: it is computed only over threads that eventually earn a human reply, and whether a thread gets answered correlates with when it lands. A scheduler that drifts toward hours where engaged readers cluster will post better latency partly through selection, not speed. Second, the legacy case for one magic hour rests on open-rate roundups — aggregations of marketing studies that never measured reply latency at all, counted opens inflated by automated inbox prefetching (Apple Mail Privacy Protection fetches remote content whether or not a human glances at the message), and quietly assumed every recipient shared a single clock. That literature is not weaker evidence for the bandit; it is evidence for a different, effectively unmeasurable quantity. Third, most published bandit evaluations treat hourly arms as stationary. Inboxes are not: day-of-week mix, seasonal buying cycles, and mailbox-provider filtering changes all shift the reward surface out from under the learner.

Variance across cases is wide enough that two teams running identical algorithms can reach opposite conclusions, both honestly. The differences that matter are rarely the algorithm — they are reply density, domain sharding, and seasonality:

The rule itself bends in identifiable places — none of which reverse it. Just above the threshold, the advantage takes weeks of accumulated pulls to separate from exploration noise; a team judging after one sprint will wrongly conclude the fixed batch was fine. When replies arrive so thinly that the posterior moves every couple of weeks, the honest reading is that neither schedule is measurable yet — extend the evaluation window rather than switch sides. During acute seasonality, a frozen schedule is the more robust default until the reply distribution stabilizes. In each case the remedy is patience or finer segmentation, not abandoning the control.

Treat the pooled premium as a hypothesis about your domain, not a fact about it. Keep the permanent holdback slice live, compare medians on your own delivery logs, and let your traffic — not a vendor's average — cast the deciding vote.

What 2026's Data Can't See

Start with what's missing from the record: a published failure. Seventh Sense- and Einstein-style case libraries are winner galleries by construction — the thousands of sub-scale deployments that saw no lift never become case studies, because nobody ships a slide deck about a null result. Statisticians call this the file-drawer problem: absence of negative results is not evidence of universal efficacy, and with no public registry of failed bandit rollouts anywhere, the denominator behind every glowing vendor screenshot is unknowable.

Every converged posterior also has a shelf life. Recipient triage behavior is non-stationary — quarter-end crunches compress reply windows, holiday lulls stretch them — and daylight saving quietly corrupts the clock itself. A scheduler that pins recipients to the UTC offset captured at import, rather than an IANA zone name, watches its "9 AM local" arm become 10 AM after the US springs forward on March 8, 2026, or 8 AM when a summer-captured offset meets November 1. Because Europe shifts on March 29 and October 25, transatlantic lists run an hour desynced for three weeks each spring and one each fall. A bandit tuned in Q1 decays by Q3 unless forced to re-explore.

The third leak is the reward function. A bandit trained naively on raw reply latency learns exactly what you paid it to do: which hours trigger out-of-office autoresponders and helpdesk autoreplies that log as sub-minute wins while advancing zero pipeline. Unless the reward filters for first human, substantive replies, the optimization is fiction — the leaderboard is measuring bot throughput.

Fourth, the field's comparisons are confounded. Teams that adopted bandits through 2025–2026 typically upgraded lists, domains, and copy in the same quarter; scheduler swaps rarely travel alone. No large public 2026 dataset isolates send timing as the sole variable with pre-registered endpoints, so causal certainty about the headline 15–25% reduction is unavailable at any price point — it is an association in pooled production traffic, not an isolated treatment effect. The lore it displaced, that 9 AM is the empirically proven best send time, never measured reply latency either; it aggregated open-rate roundups that counted machine prefetches as engagement.

Fifth, geodata rots both arms symmetrically. Audits of B2B contact databases routinely turn up roughly 15–25% of records carrying wrong or missing timezone fields. That breaks the fixed batch — 9 AM fires closer to noon for part of the list — and mislabels the bandit's arms, so a learned taste for "9 AM Pacific" may actually be Central. Against a fictional clock, the comparison measures the data error, not the scheduling.

Finally, the small-arm arithmetic that turns most mid-market rankings into theater. One hourly arm with 12 sends and 3 fast replies yields a Beta(4, 10) posterior whose 95% credible interval spans roughly 10–55% depending on the prior — wide enough to swallow any plausible timing effect whole. An account sending a few hundred emails a week scatters those sends across dozens of hour-by-weekday cells, leaving single-digit observations apiece. Its "converged" schedule is statistical noise wearing a dashboard, and this is the epistemic face of the volume threshold: below roughly 200 sends/day per domain, exploration noise exceeds the learnable effect, and the fixed batch wins by default.

Before crediting any scheduler — bandit or batch — with a latency win, run four cheap checks: sample-audit your timezone fields, strip autoresponder patterns from the reward stream, re-run the fixed-versus-bandit holdout after each DST transition, and print every arm's credible-interval width. Where those intervals dwarf the claimed effect, the dashboard is decoration, and the volume line established earlier remains the only honest gate.

Worked Case

The arm that won sent between 6:00 and 9:00 in the morning — the slot the team had written off as too aggressive before a single message went out. Here is the full deployment, parameterized tightly enough that you can audit every number yourself.

A Series-B SaaS SDR team runs 1,200 cold emails per week off a single sending domain — 240 per day, deliberately past the 200/day line where send-time optimization stops being noise-limited. Their question, posed in early 2026: does a Thompson-sampling bandit beat the inherited 9:00 AM local batch on first-reply latency? Weeks 1–2 answered the control side: pure fixed scheduling across all 240 sends/day produced a median first-human-reply latency of 6 hours 40 minutes and a 4.2% reply rate — 101 replies on 2,400 sends, and yes, 101 divided by 2,400 is 4.2%. Those two numbers anchor everything that follows.

Weeks 3–5 changed one variable. Eighty-five percent of daily volume was allocated by Thompson sampling across four 3-hour arms — 06–09, 09–12, 12–15, 15–18 local — while 15% stayed pinned to fixed 9:00 AM as a permanent holdout. Reward was defined narrowly: first human reply within 4 hours of send. Autoresponders were excluded at the logging layer, not downstream — the classic specification-gaming trap, since out-of-office replies arrive fast and would teach the bandit to chase garbage.

By Friday of week 5, the posteriors read as raw Beta counts:

Two details repay attention. First, each arm accumulated roughly 760 graded sends — the exploration budget stayed near-balanced, so the spread in means is signal, not an artifact of lopsided allocation. Second, cumulative counts lag the live policy: the sampler now routes roughly 45% of daily volume into the dawn arm, and that concentration shows up in forward-looking routing before it shows up in end-of-window tallies.

The outcome, with the holdout doing its job:

The 23% cut lands inside the 15–25% improvement band described earlier in this guide. What makes this evidence rather than anecdote is the holdout: pinned to the old schedule, it held at 6 h 35 m — statistically indistinguishable from baseline — so the gain tracks timing, not a warm intro landing mid-test or a deliverability swing. The reply-rate move gets labeled honestly: +0.4 points is inside noise, and latency, not reply volume, was the claim under test.

The transferable lesson is uncomfortable. Nearly the entire win decomposes to one discovery — the 06–09 arm the team had assumed prospects would never read. The bandit paid for itself not through inherent cleverness but by forcing a false assumption to compete for send budget and lose. And that only works above the volume threshold: at 240/day, the dawn arm gathered decisive evidence in three weeks; below it, the same experiment drowns in exploration noise and the fixed batch wins by default. The inherited 9:00 AM habit was never empirically proven for this list — it was convention, never once scored against this list's actual reply clock until the bandit made scoring unavoidable.

Five Rules for Choosing Well

A Thompson sampler is the easy part. In nearly every failed deployment, the algorithm converged exactly as advertised and the program still lost — because the scaffolding around it was missing. The timing premium documented in the current benchmark cycle is real, but it is rented, not owned: five operating rules determine whether you collect it or pay for it. Treat them as gates, in order.

Rule 1 — Respect the volume gate. Adopt a send-time bandit only above 200 sends/day per sending domain; below it, run the fixed 9:00 AM local batch and spend the saved complexity on list quality, which moves reply rates more than timing ever will. The arithmetic explains the gate: a hundred sends a day spread across twenty-four hourly arms leaves roughly three observations per arm per day, so the hundred-per-month floor goes unmet, posteriors stay wide, and nothing ranks. And notice what staying on 9 AM does not mean — it is not an endorsement that nine o'clock is empirically special. That folklore descends from open-rate roundups inflated by automated inbox prefetching and a single shared clock, metrics that never measured reply latency. Below the gate, no schedule can be proven superior, so run the cheapest one.

Rule 2 — Instrument before you optimize. Stand up a permanent 10–20% randomized holdout on the fixed schedule and pre-register median first-human-reply latency — autoresponders and brush-off templates excluded — before the first bandit send leaves the building. Pre-registration is the entire defense: choosing the metric after seeing results is how noise gets laundered into wins, and a holdout that dissolves after launch week proves nothing.

Rule 3 — Cap exploration deliberately. Set exploration near 10% of traffic and enforce a floor of 100 sends per arm per month. The floor does double duty: no arm dies from one unlucky week, and no ranking influences routing until it rests on at least a hundred observations. Without it, Thompson sampling's native greediness collapses the posterior onto whichever arm got lucky early.

Rule 4 — Re-audit on a calendar, not on vibes. A send-time posterior is a snapshot of a non-stationary process. Force a re-exploration phase after every March and November clock change, every quarter-end cycle, and every list-source change — each reshuffles the relationship between send hour and recipient context. Then apply the kill switch honestly: if the bandit arm has not beaten the fixed holdout by at least 10% on median latency for two consecutive quarters, revert to fixed 9 AM and redeploy the effort. Reverting is cheap; defending a stale posterior is not.

Rule 5 — Judge on pipeline, not the clock. Accept the bandit only if sub-two-hour replies convert to booked meetings at parity with slower ones. Fast replies skew toward low-intent engagers — the people who answer quickest are disproportionately the people answering to decline. If your speed gains evaporate at the calendar-invite stage, you have optimized a vanity metric, and the fixed 9 AM batch was serving you fine.

Score yourself against the table. All five gates cleared above the volume line: the hybrid wins. Any single gate missed, or volume below the line, and the fixed batch wins outright — with far less machinery to defend.

What to do next

Quick answers

Also worth reading: How SPIN Selling's 1988 Framework Revolutionized B2B Sales Conversations: How SPIN Selling's 1988 Framework · 7 Data-Driven Techniques to Measure Email Success with B2B Prospects in 2024: 7 Data-Driven Techniques to Measure · 7 Data-Backed Tactics That Increased B2B Lead Generation by 37% Using HubSpot in 2024: 7 Data-Backed Tactics That Increased