# Speed to Lead When the Lead Is Still on Your Website > Speed to lead assumes the lead already left. For founders the lead is often still on the site, so reframe speed to contact as a present-tense loop. - **Author**: George Borelli - **Published**: 2026-08-22 - **Category**: Sales - **URL**: https://heyzinc.com/blog/speed-to-lead-while-visitors-are-live --- ```tldr "Speed to lead" was built on a 2011 study about how fast a team calls a form submission back. That assumes the lead already left. For founder-led teams, the lead is often still on the site -- so speed to contact is a present-tense operating question, not a callback metric. The loop: intent event, automatic message, reply, push notification, founder response, text, and a live in-browser website call. ``` Every few months a founder asks me whether the "five-minute" speed-to-lead rule is real. I get why they ask. The number is everywhere. It shows up in vendor blog posts, in sales-tool landing pages, in LinkedIn threads. It is usually attributed to "a study" without a name, a date, or a source. Here is the source. In March 2011, the *Harvard Business Review* published [The Short Life of Online Sales Leads](https://hbr.org/2011/03/the-short-life-of-online-sales-leads). The authors were James B. Oldroyd, Kristina McElheran, and David Elkington. The public summary says plainly that most companies are not responding nearly fast enough to online leads. That is the article the entire "speed to lead" category is built on. Two things are worth knowing before you repeat it. First, one of the authors was the CEO of InsideSales.com -- the vendor whose product category the research supports. That does not make the study wrong. It makes it vendor-adjacent industry research, not a neutral academic finding. Second, the study is from 2011. The specific magnitudes that circulate -- the five-minute window, the huge multiples in qualification odds -- are not in the public summary. They travel secondhand, stripped of context, and get repeated as law. I am not going to repeat them as law here. The directional claim, that most teams respond too slowly, is supported. The precise numbers are not something I can verify for your business, and they were never meant to be a universal rule. What interests me more is the assumption hiding inside the whole category. ## Where "speed to lead" came from The 2011 unit of work was a form submission. A visitor fills out a form, the form becomes a lead, the clock starts, and speed is measured in minutes-to-callback. Everything built on top of that -- CRM cadences, auto-dialers, callback SLAs, "respond within five minutes" dashboards -- optimizes the same moment: the follow-up that happens *after* the lead is captured. That framing has a quiet premise. It assumes the lead is gone. For a founder who can see live traffic, a different question is available. A visitor is on your pricing page right now. They came from the reply you posted this morning. They have not submitted a form. They have not left. The question is not "how fast will we call them back." The question is "is the conversation happening while they are still here." This is the reframe. Speed to contact is not a callback latency metric. It is a present-tense operating question. The unit of speed is not minutes-to-callback. It is whether the conversation happens before the visitor closes the tab. If you have ever looked at [traffic that does not turn into customers](https://heyzinc.com/blog/why-your-website-traffic-is-not-turning-into-customers) and recognized "nobody was available when intent was highest" as the bottleneck, you already know the shape of this problem. The fix is not a faster callback. The fix is operating in the seconds the visitor is actually there. ## Three things that get blurred Before I describe the loop, one distinction matters, because "speed to lead" content loves to blur it. - **Identity** is who the visitor is. Their name, their company, their email. - **Behavioral intent** is what they are doing right now. Dwelling on pricing. Returning for a third visit. Looping between a feature page and a pricing page. - **Attribution context** is where they came from. The specific reply, DM, email, or campaign that produced the click. A present-tense response can act on behavioral intent and attribution context without knowing identity. You do not need to know someone's name to know they are reading your pricing page for the fourth time and that they arrived from a conversation you started. What you must not do is pretend to know identity you have not captured. If a visitor arrived from a tracked link, the opening message can acknowledge where the conversation came from -- "saw you came over from that thread" -- without inventing familiarity the captured context does not prove. That distinction is the difference between helpful and creepy, and it is what [conversation attribution](https://heyzinc.com/blog/conversation-attribution) is for: preserving the source conversation so the message can be honest about how much it actually knows. Keep those three separate. Speed to contact operates on intent and context. Identity is its own problem, solved when the visitor decides to share it. ## The present-tense loop Here is the loop, end to end. The reframe is only useful if there is a system that actually runs it. ### 1. Intent event A visitor shows high-intent behavior. Meaningful time on the pricing page, not a two-second bounce. A repeat visit to the same feature page. A return session after an earlier look. HeyZinc notices the event. This is behavioral intent, not identity -- the system is reacting to what the visitor is doing, not claiming to know who they are. ### 2. Automatic relevant message HeyZinc opens a contextual chat message with the visitor. If attribution context exists -- a tracked link from a reply or a DM -- the message can acknowledge where the visit originated, within the bounds of what was actually captured. The point is to be useful first: offer an answer, not a pitch. One principle here is non-negotiable for me: if a bot opens the conversation, say so. [Nielsen Norman Group's work on chatbot UX](https://www.nngroup.com/articles/chatbots/) is blunt -- people want to know whether they are talking to a bot or a human, and they want a clear way to reach a person when the bot hits its limit. Transparency is what lets the visitor calibrate their language. It is also what keeps a proactive message from feeling like a trap. ### 3. Visitor replies Until the visitor replies, the team has not been interrupted. The automatic message is a low-cost probe. Most visitors will not reply, and that is fine -- the goal was never to talk to every visitor. It was to be available the moment one wanted to. ### 4. Push notification When the visitor replies, HeyZinc sends an alert through the companion app and mobile notifications. This is the part that matters for a small team: you are pulled in only when there is something to respond to. You are not watching a dashboard waiting for traffic. You are doing everything else a founder does, and the phone tells you when a real conversation has started. An honest qualifier: live and mobile signals depend on your workspace and device configuration. They are a configured workflow, not a universal delivery guarantee. Set them up deliberately. ### 5. Founder responds I pick up the thread. From the dashboard if I am at my desk, from the phone if I am not. I can take over the conversation mid-thread without the visitor leaving the page, and the visitor can see who they are talking to. This is the handoff from the automatic message to a person, and it is where the conversation actually starts to earn trust. ### 6. Continue by text A lot of questions resolve in a few messages. "Is this included in the plan?" "Does this integrate with our stack?" "How long does setup take?" Those are the questions that decide whether a visitor stays or leaves, and they are faster in text than in a scheduled call. Let them. ### 7. Escalate to a live website call Some questions are faster live. A pricing objection, a technical setup question, a "does this work for our workflow" thread that is dragging. When text gets slow, I start an in-browser call. HeyZinc uses [WebRTC](https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API) to place the call inside the browser the visitor is already on. They click answer on the site. No phone number. No dialer. No calendar shuffle. This is the step that most "live chat" setups cannot do, and it is the step that usually decides whether a conversation becomes a customer. Text can carry the easy questions. The hard ones need a voice, and forcing them back to email is where they die. That is the whole loop. Intent event, automatic message, reply, push notification, founder response, text, website call. If you want the feature-level walkthrough of how messaging, calling, and meetings fit together, the [proactive outreach](https://heyzinc.com/blog/proactive-outreach) post is the product view. This article is the operating reframe around it. ## What this changes for a founder-led team The first thing it changes is the metric. You stop measuring speed as callback latency and start asking whether the conversation happened while the visitor was still there. That is a different number to optimize, and it is a more honest one, because it measures the moment you can actually influence. The second thing it changes is attention. A team of one or two cannot watch a live dashboard all day. The loop is built so the team is pulled in after a reply, not on every page load. The automatic message handles the first pass. The human handles the part that needs judgment. That division is what makes present-tense response survivable for a small team instead of a constant interruption. The third thing it changes is the escalation step. The website call removes the friction that usually kills it. No phone-number exchange, no "let me find a time next week," no dialer. When a text thread needs voice, the call happens on the page the visitor is already on, in the same session. There are limits, and I want to be plain about them. Not every visitor is a prospect. Intent behavior is a proxy, not proof of buying, and treating every pricing-page dwell as a hot lead is how you burn out and annoy people. A trigger you cannot staff is worse than no trigger -- a proactive message with no reply is a broken promise, and a second one five minutes later is what makes people install chat blockers. Seeing a visit does not prove a conversion. A click is not causal lift. And HeyZinc is not a CRM; it does not replace HubSpot, Salesforce, or whatever you already use to run your follow-up process. It is the link layer and the live-activity layer. The CRM and the rule are yours. For the tactical side -- which behaviors to trigger on, what to say in the first message, how to move from chat to call without being pushy -- the [start a conversation with a website visitor](https://heyzinc.com/blog/start-conversations-with-website-visitors) playbook is the companion piece. This article is the operating system. That one is the technique. ## Speed to contact, redefined The "speed to lead" category inherited a question from 2011: how fast did you call the form back. It spent fifteen years optimizing the follow-up. The question I care about is narrower and more useful: was the visitor still on the site when the conversation started. That is speed to contact. Not a callback metric. A present-tense operating question, answered by whether your system can detect intent, open a relevant message, alert you after a reply, and let you continue by text or a live website call -- all before the tab closes. If you want to see the complete workflow -- the intent event, the automatic message, the reply, the push notification, the founder response, the text thread, and the in-browser call -- [talk to the HeyZinc team](https://heyzinc.com/contact) and we will walk you through it. --- - [More Sales articles](https://heyzinc.com/blog/category/sales) - [All articles](https://heyzinc.com/blog)