Build an AI SMS Assistant with Twilio and OpenAI

Introduction

Set a response target your business can support, then measure delivery, useful replies, qualified enquiries and completed bookings. A fast acknowledgement can help, but it should not imply that a person reviewed the request or that a service is available.

An AI SMS sales assistant fixes this by doing one thing: responding to every inbound lead within seconds, carrying on a natural text conversation, qualifying the lead, and either booking a call or handing off to a human. No missed leads. No forgotten follow-ups. No "sorry I just saw this" messages sent three days later.

This guide walks through how to build one from scratch using Twilio for SMS delivery, OpenAI or Claude for the AI brain, and a CRM to log everything. We build systems like this at Luminous Digital Visions, and the architecture below is the same pattern we use in production. If you want to skip the build and have us set it up, get in touch.

Make the first reply useful and accountable

A quick acknowledgment can help a customer know their inquiry arrived. It should identify the business, stay within the permission and purpose of the conversation and give a clear next step. Speed alone does not establish that the inquiry is qualified or that a booking will follow.

Measure time to first useful response, delivery failures, staff handoff and completed bookings. Compare the same definitions before and after the pilot. Do not apply an old industry statistic as a forecast for your own lead volume.

System architecture overview

Here's the full flow from lead to booked call:

Website Form / Landing Page
        ↓
   Webhook (POST)
        ↓
   Your Backend Server
        ↓
   AI Layer (OpenAI / Claude API)
        ↓
   Twilio SMS API → Lead's Phone
        ↓
   Lead Replies → Twilio Webhook → Your Server → AI → Reply
        ↓
   Qualification Complete → Book Call / Human Handoff
        ↓
   CRM Updated (deal stage, tags, conversation log)

The pieces:

Twilio can send and receive messages through its APIs and webhooks. Budget for the number, message segments, carrier and registration fees, destination and any platform charges using current messaging pricing.

Your backend server (Node.js, Python, Go, or whatever you prefer) receives webhooks from both your website forms and Twilio's inbound message handler. It orchestrates the flow.

The AI layer takes the conversation history, the lead's context, and a system prompt you've written, then generates the next message. You send this through OpenAI's chat completions API or Anthropic's messages API.

Your CRM (GoHighLevel, HubSpot, Pipedrive, etc.) stores the lead record, conversation log, deal stage, and any tags. We typically use GoHighLevel for service businesses because its pipeline and automation features pair well with this kind of system.

This architecture works whether you're handling 10 leads a day or 500. The AI layer and Twilio both scale horizontally. Your database is the only bottleneck, and for conversation storage even SQLite handles thousands of concurrent threads without issue.

Set up messaging, registration and webhook verification

Select an appropriate sender and confirm current registration requirements for its destination and use case. For US application-to-person traffic over local long-code numbers, review Twilio’s A2P 10DLC documentation. Confirm current fees and review times instead of using a fixed timeline from an older tutorial.

Configure the inbound webhook on a server you control. Validate the request using Twilio’s supported signature-validation method before trusting the payload. Its webhook security guide explains the process.

Record the provider message identifier for deduplication. Verify sender, account and recipient routing. Keep credentials in server-side configuration and test delivery errors and retries before connecting a live audience.

Generate a draft before authorizing a send

Separate response generation from sending. The model receives the permitted conversation context and approved business information. Application logic checks consent, suppression, recipient, current booking state and escalation before an outbound message is queued.

This isolated Node.js example generates a draft with the OpenAI SDK. It assumes server-side OPENAI_API_KEY and OPENAI_MODEL configuration and deliberately performs no messaging action:

import OpenAI from 'openai';

const client = new OpenAI();
const model = process.env.OPENAI_MODEL;
if (!model) throw new Error('Configure OPENAI_MODEL');

export async function draftReply(approvedContext, incomingText) {
  const result = await client.responses.create({
    model,
    store: false,
    instructions: 'Draft a brief service reply using only the supplied facts. '
      + 'Do not confirm prices or appointments that are not established. '
      + 'Ask for human assistance when the request is outside scope.',
    input: JSON.stringify({approvedContext, incomingText})
  });
  if (!result.output_text?.trim()) throw new Error('No reply draft returned');
  return result.output_text.trim();
}

Choose and evaluate an available model rather than copying a retired identifier. Add timeout, refusal and error handling appropriate to the application. A returned string is a draft, not proof of factual accuracy or authorization to contact a person. See the OpenAI quickstart.

The conversation flow from first contact to booked call

Here's what a real conversation looks like with this system. The lead filled out a form on ABC Plumbing's website asking about a leaking water heater.

[AI - 0:47 after form submit]
Hey Mike, this is Sarah from ABC Plumbing! I saw your request
about a water heater issue. Can you tell me a bit more about
what's going on?

[Lead - 3 min later]
Yeah the water heater in my garage is leaking from the bottom.
It's pooling on the floor

[AI - 4 seconds later]
That's definitely something we can help with. Is the leak
steady or does it come and go? And do you still have hot water
or has it gone out completely?

[Lead - 1 min later]
It's steady and getting worse. Still have hot water but I'm
worried it's going to go out

[AI - 3 seconds later]
Got it. Sounds like it could be the drain valve or the tank
itself. How old is the unit, roughly? And what's your zip code
so I can confirm we service your area?

[Lead - 2 min later]
Maybe 10 years? I'm in 78745

[AI - 4 seconds later]
78745 is right in our service area. A 10-year-old unit with a
steady leak usually means it's time to talk replacement options.
We do free estimates for water heater work. Want to hop on a
quick 10-min call with our team? I have openings tomorrow at
10am or 2pm.

[Lead - 5 min later]
2pm works

[AI - 3 seconds later]
Perfect, you're booked for 2pm tomorrow. You'll get a call
from our office number. Talk soon Mike!

That entire exchange happened without a human touching it. The AI asked qualification questions naturally, confirmed the service area, identified urgency, and booked the call. Total elapsed time: about 12 minutes. Compare that to most businesses where the lead would still be sitting in an unread inbox.

Keep the automated scope explicit: approved questions, supported services and a defined handoff. Measure which conversations it completes reliably instead of assuming a fixed share of enquiries will be automated.

Handling multi-turn conversations and edge cases

Real conversations are messy. Leads go silent for hours, change topics mid-thread, send one-word answers, or ask questions the AI can't answer. Your system needs to handle all of these.

Threading by phone number. Every conversation is keyed to the lead's phone number. When a message comes in, your server looks up the existing thread, loads the history, and continues the conversation. If there's no existing thread, it's a new lead and you start fresh.

Stale conversation handling. If a lead texts back after 48 hours of silence, the AI should acknowledge the gap. Add logic that checks the timestamp of the last message. If it's been more than 24 hours, prepend a note to the system prompt: "The lead has been inactive for [X] hours. Acknowledge the gap naturally and re-engage." This prevents the AI from picking up mid-sentence as if no time has passed.

Human handoff triggers. Some messages should immediately route to a human. Build a classifier (or just use the AI itself) to detect: complaints, legal questions, pricing pressure beyond what the system can handle, or explicit requests to talk to a person. When triggered, the system sends a notification to your team and pauses automated responses.

Opt-out detection. If a lead texts "stop," "unsubscribe," "don't text me," or anything similar, your system must immediately stop all messaging. This isn't optional. More on compliance later.

Short/unclear responses. Leads often reply with "ok" or "sure" or "yeah." Your system prompt should instruct the AI to ask a clarifying follow-up rather than making assumptions about what they agreed to.

These patterns show up in every AI SMS system. We cover more of the conversational design side in our complete guide to conversational AI chatbots, which applies to SMS just as much as web chat.

Automated follow-up sequences

The first response is the most important, but the follow-up sequence is what actually converts leads who don't book on the first exchange. Most leads need 2-5 touchpoints before they commit.

Build a follow-up scheduler that triggers when a conversation goes cold. Here's the cadence that works:

4 hours after last message (if no response to a question): A gentle nudge. "Hey Mike, just circling back on the water heater. Want me to set up that call, or do you need more time?"

24 hours after last message: A value-add message. "Quick heads up Mike, water heater leaks that start at the base tend to get worse pretty fast. Happy to get someone out this week if you want to get ahead of it."

72 hours after last message: Final attempt with a different angle. "Hey Mike, just wanted to check in one more time about the water heater. If the timing isn't right, no worries at all. We're here whenever you need us."

After three follow-ups with no response, the system stops and tags the lead as "cold" in your CRM. No lead should receive more than 3-4 follow-up messages total. More than that and you're spamming.

The timing and content of these follow-ups can be AI-generated too. Pass the conversation history to the AI along with instructions like "Generate a follow-up message for a lead who hasn't responded in 24 hours. Be helpful, not pushy."

We've written a full breakdown of AI follow-up workflows for small service teams that covers the 14-day cadence across SMS, email, and call tasks.

CRM integration and deal tracking

An AI SMS assistant that doesn't log to your CRM is just generating conversations in a void. Every message, qualification answer, and status change needs to flow into your CRM so your sales team has full context.

Here's what to sync:

Contact creation. When a new phone number texts in (or a form submission triggers the first outbound), create a contact in your CRM with the phone number, name (from the form), and source.

Conversation log. Append every SMS (both directions) to the contact's activity timeline. Most CRMs have a notes or activity API. GoHighLevel's API makes this straightforward with their conversations endpoint.

Deal stage updates. Map conversation milestones to pipeline stages. "New Lead" when the first message sends. "Engaged" when the lead replies. "Qualified" when the AI has collected the key info. "Call Booked" when they pick a time. "No Response" after follow-ups exhaust.

Tagging. Auto-tag leads based on what the AI learns. Service type, urgency level, location, budget range. These tags let your sales team filter and prioritize.

Human handoff alerts. When the AI determines a lead needs a human, push a notification (Slack, email, CRM task) with a summary: "Mike at 512-555-1234 has a leaking 10-year-old water heater in 78745. Wants a call tomorrow at 2pm. Conversation attached."

If you're running GoHighLevel, the CRM integration is native and you can trigger workflows based on tags or pipeline stage changes. For other CRMs, you'll build webhook integrations or use their REST APIs. We've written about connecting AI systems to your CRM in detail.

Our full AI systems automation service covers this end-to-end if you'd rather not build the integrations yourself.

Enforce consent and stop rules outside the model

Define the permitted purpose and recipient population before launch. Keep a record of the applicable consent, its scope and revocation. Registration with a carrier or messaging platform is not a substitute for consent.

Apply opt-out and suppression checks before every send, including scheduled follow-ups. Stop pending messages when the person opts out, a staff member takes over or a booking changes the workflow. Do not rely on a model to infer whether contact is legally permitted.

Review the actual flow against provider policy and applicable rules with qualified counsel. Twilio’s messaging policy is a provider starting point, not a complete legal review of your business.

Price the whole conversation

Count inbound and outbound segments, sender rental, registration and carrier charges, model usage, retries, storage and human review. Verify the rates for the exact destination and sender type. A message containing Unicode or a long response may require more than one billable segment.

Run a representative pilot and divide total cost by correctly handled conversations. Report bookings and collected revenue separately. Check current messaging rates and API pricing when preparing a budget.

How to get started

You have two paths. Build it yourself using the architecture and code patterns above, or have someone build it for you.

If you're building it yourself, start small. Get Twilio set up, write a basic system prompt, and run the AI layer against your first 10 leads manually before automating the full flow. Watch the conversations, adjust the prompt, and add edge case handling as you discover real patterns.

If you want it built and managed, our AI agent development service covers this exact system. We handle the Twilio setup, AI prompt engineering, CRM integration, compliance, and ongoing optimization. You can see how our process works or book a call to discuss your setup.

Either way, the gap between businesses that respond in seconds and businesses that respond in hours is only going to widen. The tech is available now, the cost is minimal, and every day without it is leads you're losing to whoever texts them back first.

Questions before a live SMS pilot

Will customers know they are using an assistant?

Identify the business and assistant clearly, and provide a route to a person. Do not design the conversation around misleading the recipient about who is responding.

How do we prevent duplicate messages?

Store provider event identifiers, serialize conflicting updates to a conversation and check current suppression and booking state immediately before sending. Test retries and delayed events.

Which model should we choose?

Evaluate currently available candidates using the same inquiries and expected answers. Include ambiguous requests, complaints and attempts to obtain unapproved prices or commitments.

How long does implementation take?

Scope sender approval, integrations, message review, testing and staff training first. A quick prototype does not establish a production delivery date.

Can it run in another country?

Confirm sender availability, destination rules, provider policy and the organization’s legal requirements for that jurisdiction before reusing the workflow.

For help implementing the workflow, explore AI revenue systems.