Positive reply rate

Three measurements hiding under one name

At least three distinct quantities travel under one phrase. Raw reply rate counts any reply, including “no” and unsubscribe requests, usually per email sent. Positive share of replies is the fraction of repliers who showed interest. Positive replies per lead contacted is, in effect, the product of the two — and it is the only one of the three that supports a revenue claim, because leads are what a list costs and what an experiment randomizes. All three are legitimate measurements; none substitutes for another.

The slippage is not hypothetical. Sales.co’s February 2026 analysis of 2 million emails states both that 14.1% of replies are positive — which, against its own 2.09% average reply rate, works out to ≈0.30% positive replies per lead — and that a campaign earns roughly one positive reply per 157 leads contacted, which is ≈0.64% per lead. The same dataset, framed two ways, disagrees with itself by about 2.2×. A benchmark quoted without its denominator is not yet a number.

What the 2026 datasets report

Instantly’s 2026 Cold Email Benchmark Report puts the average reply rate at 3.43%, with the top quartile at 5.5% — raw replies, before any positivity filter. The positive share of those replies has no consensus figure: 2026 estimates run from 14.1% (Sales.co) through 25–50% in strong campaigns (Saleshandy) and 40–60% (Puzzle Inbox) to 60–70% (Prospeo) — a 14%–70% spread that depends on definition and dataset. Quoting the top of that range as an industry consensus would misstate the evidence; only Prospeo reports it.

Combining the 2026 reply-rate figures (2.09–3.43%) with that share range implies roughly 0.3% to 2.4% positive replies per lead. The RevenueOS minimum-n table, generated 2026-07-03, plans its three positive-reply scenarios inside that derived band — 0.64% per lead (conservative), 1.2% (mid), and 2.2% (healthy) — and flags the Sales.co inconsistency in its sources note rather than averaging it away: the conservative row uses the larger 0.64% per-lead framing, with the recorded caveat that a program at the 0.30% arithmetic needs roughly twice that row’s sample and calendar.

Why the definition is load-bearing

Sample-size floors are computed on the per-lead definition, and they move sharply with it. In the RevenueOS minimum-n table (α = 0.1 anytime-valid confidence sequence, margin standard w = τ), a program planned at 0.64% positive replies per lead against an assumed 0.1% organic baseline needs 21,928 randomized leads; at 2.2% per lead the floor drops to 4,476. Misreading the per-lead rate by the 2.2× that Sales.co’s two framings span roughly doubles the required rows and the calendar time at a fixed sending volume.

The per-email versus per-lead confusion is just as live. 2026 guides quote meeting rates of 0.1–0.5% per email sent; treating those as per-lead rates — an easy slip when a sequence runs 4–7 emails per lead, the 2026 consensus length — is exactly the conflation an adversarial review pass caught in an earlier cut of the RevenueOS pilot documentation. The published table counts leads, and says so in its header.

How RevenueOS uses this

Positive reply rate — positive replies per randomized lead — is the primary readout rung in RevenueOS’s statistical qualification gate (decision doc dated 2026-07-03). The decision-bearing pilot claim is that a program causally lifts positive replies per lead over a randomized holdout, read as a 90% anytime-valid confidence sequence (α = 0.1). Meeting is the confirmatory rung, modeled for planning as the same program’s positive-reply rate × 40% booking conversion, hedged 30–50%; by that arithmetic the meeting rung costs ≈2.5–2.7× the reply rung’s calendar for the same program, which is why it is shown as a running, usually still-open interval at pilot volumes rather than as the gating number.

The denominator discipline is contractual in RevenueOS artifacts: floors in the minimum-n table count leads randomized into the proof and holdout cells — never emails, never replies — and benchmark citations carry the framing they were published in, including the ones that disagree. RevenueOS is at design-partner stage as of July 2026; every number above is a published industry benchmark or a simulation floor from its own proof engine, not a customer result.

Related terms

Minimum detectable effect · Incrementality · Randomized holdout