Skip to content

Guide · 13 minute read

How to build an SMS lead follow-up system after form submit

This is the implementation pattern behind a form that texts the owner, follows up with the lead by SMS, and sends a useful summary before callback.

Benjam Indrenius

Benjam Indrenius

Published 2026-06-01

The useful version is a state machine, not a notification

A basic form-to-SMS setup texts the owner once. A real SMS lead follow-up system has to manage consent, owner alerts, lead text-back, replies, quiet leads, opt-outs, quotas, failures, and the final summary. That is why this guide starts from the actual localbot backend flow instead of a simplified Twilio snippet.

Lead loop

The system has four jobs

Step 1

1

Save lead

Validate and store the form submission.

Step 2

2

owner SMS

Text the owner with enough context to call back.

Step 3

3

Lead reply

Ask the lead for missing context when SMS consent allows it.

Step 4

4

Summary

Send the owner a summary before callback.

The source-backed localbot flow

In localbot, the public widget posts into src/app/api/widget/submit/handler.ts. That handler validates the widget, checks origin and rate limits, suppresses unsafe bursts, then hands the accepted lead to src/lib/lead-ingest.ts. The ingest layer saves the lead, sends the owner SMS, creates the optional lead follow-up conversation, and schedules lifecycle work. Idle or finished conversations are completed by src/app/api/engage/lifecycle/route.ts, which can nudge the lead or generate the owner summary.

Implementation flow

1. Browser submits the widget form
2. src/app/api/widget/submit/handler.ts validates widget, origin, rate limits, and subscription
3. src/lib/lead-ingest.ts saves the lead
4. localbot sends owner SMS with callback context
5. If lead SMS follow-up is allowed, localbot creates an SMS conversation
6. The lead gets a text-back message
7. src/app/api/engage/lifecycle/route.ts completes idle or finished conversations
8. The owner gets a summary before callback

The minimum data model

You need two records: the lead and the SMS conversation. Do not hide conversation state in a queue payload only. You need it later for retries, opt-outs, summaries, and support.

Data shape

Lead
  widget_id
  source_url
  name
  phone
  email
  message
  sms_sent
  consent_text

Conversation
  lead_id
  widget_id
  lead_phone
  status
  turn_count
  current_locale
  summary

Step 1: save first, then notify

Save the lead before sending SMS. If SMS fails, the business should still have the inquiry in the lead table. localbot stores the submission, marks whether owner SMS was sent, and can still queue email notification when that channel is enabled.

The owner SMS should make the next action obvious. Keep it short: who contacted you, what they need, and how to call or text back.

Owner SMS template

New website lead
Name: {{name}}
Phone: {{phone}}
Message: {{message}}

Call: {{call_link}}
Text: {{sms_link}}

Step 2: text the lead back only when the rules pass

Lead follow-up is separate from the owner alert. Before you text the lead back, check that you have a normalized phone number, consent, active billing, follow-up enabled, an available conversation quota, and no matching opt-out. localbot does those checks in src/lib/lead-ingest.ts before it creates the SMS conversation.

Lead text-back template

Thanks {{first_name}}. Quick question before {{business_name}} calls:
what do you need help with and when would you like it handled?

Step 3: schedule lifecycle checks

SMS conversations do not finish at the first outbound message. The lead may reply, go quiet, or answer only part of the question. That is why localbot schedules lifecycle work after the first reply. The lifecycle route can complete a no-reply conversation, send a nudge when configured, or summarize the conversation for the owner.

The key engineering detail is optimistic locking before completion. Without it, a retried queue job can send duplicate summary SMS messages.

Step 4: hand the owner a callback summary

The owner does not need a transcript before calling. They need a compact summary: what the lead wants, location, timing, constraints, and missing details. That is the handoff. The system should stop before it tries to sell for the owner.

This fits localbot's product boundary: localbot handles the first response and the qualification context. The founder or business owner handles the actual sales conversation.

Build or buy?

Build this yourself when the SMS workflow is core infrastructure and you have a developer who will maintain delivery, retries, opt-outs, abuse limits, billing gates, and summaries. Buy it when the business goal is simpler: get every website lead onto the owner's phone and keep the lead warm until callback.

To install the localbot version of this flow, start with the SMS contact form setup guide.

SMS lead follow-up FAQ

What is an SMS lead follow-up system?

It is the flow after a website form submit: save the lead, text the owner, text the lead back when allowed, ask qualifying questions, and send the owner a summary before callback.

Should the lead receive an SMS automatically?

Only when the form collects proper SMS consent and the business has a clear reason to text back. The owner alert can be separate from lead follow-up.

Can I build this with Twilio?

Yes. You need a submit endpoint, lead storage, SMS sending, opt-out handling, retries, conversation state, summaries, and monitoring. That is why many businesses should buy the workflow instead of building it.

What should the owner SMS include?

Name, phone, request summary, source page, and one-tap callback links. The SMS should be actionable without opening a dashboard.

localbot

Want the follow-up system without building it?

localbot already runs this flow: form submit, owner SMS, lead text-back, qualifying questions, and owner summary.

Get started

For service businesses that need fast callbacks without maintaining Twilio and queue code.

Cookie preferences

Essential cookies plus optional analytics. No ad cookies.