The Speed-to-Lead Handbook: why response time decides which leads close

Speed to lead is the elapsed time between a prospect raising their hand and a useful answer landing in front of them. It matters because inbound intent decays fast: the person who filled in your form is, at that moment, actively working on the problem you solve. An hour later they are in a meeting. A day later they have three quotes. Nothing else in your funnel is this cheap to change or this easy to get wrong.

This handbook covers what the term actually means, what the research does and doesn't support, why your reported response time is almost certainly better than your real one, where the hours actually go, and what to do about it without turning your inbox into a fast-firing spam cannon.

What is speed to lead?

Speed to lead — also called lead response time — is the interval between an inbound signal and your first substantive response to it. An inbound signal is a demo request, a pricing enquiry, a reply to a sequence, a chat message, a form fill, or an inbound call you missed.

The word doing the work in that definition is substantive. An autoresponder saying "thanks, we'll be in touch" is not a response; it is a receipt. If your measurement counts it as one, your dashboard is measuring your mail server, not your sales team.

A workable definition to instrument against:

• Start: the timestamp on the inbound signal itself, not when it appeared in someone's queue.
• Stop: the moment a reply that a human could act on reaches the prospect — one that answers what they asked, or asks a question that moves things forward.
• Clock: wall clock, not business hours. Prospects do not experience your operating calendar.

That last point is where most reported figures quietly fall apart, and it's worth its own section below.

Why does responding faster change the outcome so much?

Two things happen while a lead waits, and they compound.

Attention decays. Inbound enquiries are made in a window of active intent — someone is researching, comparing, or has just been handed a problem. That window closes. The same message that would have started a conversation at minute five is, at hour twenty, an interruption to something else.

The field fills up. A buyer evaluating a category rarely contacts one vendor. Whoever answers first frames the criteria, and every later conversation gets measured against that frame. Being second is not half as good as being first; it is a different, harder sale.

The best-documented evidence comes from James Oldroyd, Kristina McElheran and David Elkington, published in Harvard Business Review in March 2011 as The Short Life of Online Sales Leads. They audited how long 2,241 US companies took to respond to a web-generated test lead. Firms that tried to make contact within an hour were nearly seven times as likely to qualify the lead — defined as a meaningful conversation with a key decision maker — as those that tried even an hour later, and more than 60 times as likely as those that waited 24 hours or longer.

The earlier Lead Response Management study, by Oldroyd with InsideSales.com, put numbers on the first half-hour specifically. Across three years of data covering more than 15,000 leads and over 100,000 call attempts at six companies, the odds of contacting a lead fell by roughly 100 times between a five-minute and a thirty-minute response. The odds of qualifying one fell by about 21 times over the same half-hour.

The direction has held up: sooner is better, and the steepest part of the curve sits inside the first hour rather than the first day.

How fast is fast enough?

There is no universal threshold, and anyone quoting one precisely is guessing. What the evidence supports is shape, not a number: the penalty for waiting is heavily front-loaded, so improvements early on the curve are worth far more than improvements later.

That gives a practical way to prioritise:

• Under 5 minutes is where the Lead Response Management data puts the steepest part of the curve — the fall between five and thirty minutes is larger than anything that happens later that day. It is achievable for a narrow, well-defined set of signals, a demo request from a qualified segment say, and expensive to guarantee for everything.
• Under an hour is the Harvard Business Review threshold, and a realistic operating target for a small team during covered hours.
• Same day is the point below which you are probably still in the consideration set.
• Multi-day is, for most inbound, functionally the same as not replying. The lead may still convert, but you are no longer competing on merit.

The useful question is not "what is our average?" but "what fraction of inbound gets a real answer inside an hour, measured on a wall clock?" Averages hide the failures. One reply at four minutes and one at four days averages out to something that looks tolerable and describes neither.

Why is your real response time slower than your reported one?

Because almost every default measurement excludes the parts where the time actually goes. Four common distortions, roughly in order of how much damage they do:

Business-hours clocks. A lead arriving Friday at 5:10pm and answered Monday at 9:15am is often recorded as a 15-minute response. The prospect experienced 64 hours. If your CRM reports business-hours-only response time, you are measuring your staffing policy rather than the customer's experience.

Counting the autoresponder. Covered above, but it is worth checking what your system actually stamps as "first response" — plenty of tooling counts any outbound message on the thread.

Measuring from assignment, not arrival. If the clock starts when a lead is routed to a rep, every minute spent in routing, enrichment, deduplication or a nightly sync is invisible. This is often the single largest hidden block of time, precisely because nothing in the funnel view shows it.

Surviving-lead bias. Response-time reports usually cover leads that received a response. The ones that fell through — filtered to spam, assigned to someone on holiday, buried under a busy Tuesday — are excluded from the statistic by virtue of being the worst cases. Count non-responses as infinite, or at minimum report them separately.

Correcting these four usually moves a team's honest number by an order of magnitude. That is uncomfortable, and it is also the entire opportunity: you cannot fix what you are measuring flatteringly.

For what it is worth, slowness is the norm rather than the exception. In the Harvard Business Review audit above, only 37% of the 2,241 companies responded to the test lead within an hour. 16% took between one and 24 hours, 24% took longer than a day, and 23% never responded at all. If your honest number turns out to be bad, you are in ordinary company — which is also why the ceiling on this is higher than it looks.

Where does the time actually go?

For most small teams, almost none of the delay is "someone decided not to reply yet". It accumulates in gaps nobody owns:

1. Arrival to visibility. The message lands in a shared inbox, a form handler, a CRM queue, or a webhook. Depending on the plumbing, this is seconds or hours.
2. Visibility to attention. Someone has to be looking. Overnight, weekends, holidays and back-to-back meeting days are where multi-hour delays are manufactured.
3. Attention to context. Before answering usefully, someone has to work out who this is, whether they've spoken to you before, what they asked, what was promised last time, and what's true about pricing and availability today. On a cold lead this is a couple of minutes. On a returning thread it's a search across the CRM, the inbox and somebody's memory.
4. Context to draft. Writing a considered reply — the actual work — is often the shortest step.
5. Draft to sent. Review, second-guessing, "I'll finish this after standup".

Steps 2 and 3 dominate, and neither is a motivation problem. Telling a team to reply faster does nothing about either. This is why speed-to-lead initiatives that consist of a target on a dashboard reliably fail: the target lands on step 4, which was never the bottleneck.

Does answering faster mean answering worse?

It does if speed is the only thing you change, and this is the failure mode worth naming clearly.

A fast, generic reply is worse than a slow, specific one. "Thanks for your interest! When are you free for a 15-minute call?" sent in ninety seconds tells the prospect you have not read what they wrote. It converts worse than a considered answer the next morning, and it costs reputation on top — at volume, it is indistinguishable from the automated outreach everyone is already drowning in.

So the target is not "reply faster". It is reduce the time to a reply that would have been good anyway. Those are different projects. The first is a stopwatch; the second is an operations problem about steps 2 and 3 above — making context available and making sure someone or something is watching.

What does a fast reply need to contain?

Three things, and they are unglamorous:

• Evidence you read it. Reference the specific thing they asked. This is the entire difference between a reply and a receipt.
• A correct answer to the actual question. Prices, availability, integrations, whether you serve their segment. Getting this wrong quickly is worse than getting it right slowly — a confidently wrong number costs you the deal and the trust in one move.
• One clear next step. A time, a link, or a specific question. Not a menu.

Notice that all three depend on context being available at the moment of reply, not on how fast anyone types. Which is the whole argument of this handbook: speed to lead is a context-availability problem wearing a stopwatch costume.

How do you actually make response time shorter?

In rough order of effort-to-payoff for a team without an SDR bench:

Instrument honestly first. Wall clock, arrival to first substantive response, non-responses counted. Report the distribution. Expect the number to be much worse than you thought; that is the point.

Find your dead windows. Plot response time by hour of arrival and day of week. Almost every team discovers one or two windows — evenings, Friday afternoons, Monday mornings under backlog — that produce the majority of the worst decile. Fixing coverage in a four-hour window usually beats a general "be faster" push.

Close the arrival-to-visibility gap. Every routing step, sync interval and manual triage stage between the signal and a human is pure, invisible latency. This is usually where the cheapest wins are.

Put context where the reply gets written. History, prior promises, and current facts — pricing, availability, what you actually support — need to be at hand when someone answers, not three tabs away. This is what converts a twenty-minute reply into a two-minute one without making it worse.

Then, and only then, automate the drafting. Once context is available, a draft can be produced immediately and reviewed rather than composed from scratch. Sequenced the other way round — automation first, context later — you get fast, generic replies, which is the failure mode above.

Decide your escalation rule in advance. What happens to a lead nobody has answered in four hours? If the answer is "it depends who notices", that is the gap that produces your multi-day tail.

Where Monty fits

Monty is software that watches the inbox after a lead replies and drafts the response for a human to approve.

Scoped honestly, that addresses steps 2 through 4 above: something is always watching, the context needed to answer is assembled at the moment of drafting, and a reply is waiting for review rather than waiting to be written. The approval step is deliberate — replies are held for a human by default, because the failure mode of unsupervised fast replies is exactly the generic-and-wrong problem described earlier. You can read more about how that works on the inbox page and the review workflow.

What it does not do is fix a broken measurement or an unowned escalation rule. Those are yours, and they are worth doing first — they cost nothing and they tell you whether anything else you try is working.

More on this topic in the speed-to-lead collection.