Speed to lead

The problem

A lead fills your form at 9:14 and a rep calls at 4:30. By then they have filled two other forms and spoken to somebody else. The lead was not bad; the response was slow.

Text beats a call here for a simple reason: it gets answered. The message arrives while they are still on your site.

The build

Trigger on form submission, send within 60 seconds, notify a human on reply, stop the sequence on any reply.

// POST from your form / CRM / webhook, whatever fires on new lead
export default async function newLead(req, res) {
  res.status(200).end();
  const { firstName, phone, source, recordId } = req.body;

  await fetch("https://api.bluereacher.com/v1/messages", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.BLUEREACHER_API_KEY}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      to: phone,
      message: `Hi ${firstName}, it's Marcus from Northside. Just saw your ${source} enquiry come through. What's the best number to reach you on, or is this it?`,
      send_mode: "instant",
      metadata: { crm_id: recordId, recipe: "speed-to-lead" }
    })
  });
}

That opener does three things: identifies the sender and company, proves the message is about something the person just did, and asks a question that is trivially easy to answer. A question someone can answer in one word gets answered.

Two implementation notes. send_mode: "instant" is right here because the lead just raised their hand and a 10-minute drip delay defeats the recipe; instant sends are velocity-capped (10/min, 75/day per key), which speed-to-lead volume fits comfortably. And these are opted-in contacts, so the line's opted-in capacity applies; the moment they reply they are engaged and unlimited.

Timing

Send inside 60 seconds. The measurable drop-off starts within five minutes, and by an hour you are competing with whoever else they contacted.

If the form fires outside your send window, hold until the window opens rather than sending at 11pm. Queue the send and let the platform pace it; the window rules and why they matter are in state texting laws.

Handle the reply in seconds, not hours

The whole recipe fails if a fast message gets a slow answer. On message.received, notify a human immediately with the contact name and reply text, and make the notification something they already watch: Slack, a phone push, the CRM's own mobile alert.

if (e.event === "message.received") {
  await slack.post({
    channel: "#leads",
    text: `Reply from ${e.data.contact_name ?? e.data.phone_number}: "${e.data.content}"`
  });
}

Stop on reply

Any inbound message cancels the rest of the sequence. If someone answers message one and still gets the scheduled message two, you look automated, which undoes the whole point.

if (e.event === "message.received") {
  const recordId = await crmIdForPhone(e.data.phone_number);
  await sequences.cancel({ recordId });
}

The follow-up, if they do not reply

One follow-up at 24 hours, one at 3 days, then stop:

Hey [first name], still happy to help with [the thing they asked about]. Want me to send a couple of times?

[First name], last one from me. If it's not the right time, no problem. If it is, just reply here.

Three messages total including the opener. A fourth converts near zero and produces opt-outs.

What breaks this

Phone numbers that are not E.164, which fail validation. Normalize at the form, not at the API call.

Leads arriving faster than the instant-send velocity caps during a paid traffic spike. Fall back to the drip lane for the overflow (drop send_mode and the platform paces it), and check available_today on GET /v1/devices before big pushes.

Nobody watching the notification channel. This is the real failure mode. Assign the queue to a named person per shift.

What to measure

Reply rate on the opener, median time from form fill to first human reply, and booking rate on replied leads. If reply rate is healthy and bookings are not, the problem is what happens after the reply, not the message.