SMS chatbots: examples, tools, costs, and how to build one

What is an SMS chatbot?

An SMS chatbot is software that receives text messages and responds through an SMS-enabled sender. It can follow a fixed conversation, interpret requests with AI, or combine both approaches. A reminder that only sends a scheduled message is one-way automation; a bot also needs a plan for what happens when the recipient replies.

A useful first project answers one recurring question or completes one short process: checking an order's progress, collecting appointment preferences, or routing a request to the right person. The conversation should end with a recognizable result. ‘Thanks for your message’ is an acknowledgment, not a resolved request.

SMS is the delivery channel. It does not determine which model you use, which data the bot can see, or whether the bot has permission to change a record. Keep those decisions separate so you can improve the conversation without replacing the entire messaging setup.

Rules, AI, or a combination?

Choose the smallest amount of flexibility the job needs. If every valid response is one of three choices, a fixed flow may be enough. If people describe the same problem in many ways, AI can help interpret the request while ordinary application logic checks what actions are permitted.

Example: collect a service appointment request

Here is an original sample dialogue for a repair business. It illustrates a design, not a conversation observed in a commercial product. The customer has initiated the exchange, and the bot's job is to collect a request for a person to confirm.

How the send-and-receive flow works

Twilio's receive-and-reply tutorial documents one common implementation: an incoming message causes an HTTP request to a configured webhook, and your application returns instructions for the reply using TwiML. A webhook is simply an endpoint your provider calls when an event happens.

A production design also needs conversation state: what has already been asked, what the customer approved, and whether a person owns the next response. The following sequence is a suggested architecture around that delivery mechanism. It keeps policy decisions and record changes in your application.

• Receive the event and validate that it came from your messaging provider.
• Identify the conversation and handle opt-out or help signals before ordinary replies.
• Retrieve only the approved information needed for the current request.
• Use a rule or model to propose the next question, answer, or action.
• Validate any action and check required approval before changing a connected record.
• Save the resulting state, send the reply, and record delivery or failure information.

Tools: a visual flow, custom application, or finished service

Twilio publishes both a Studio no-code SMS quickstart and a developer receive-and-reply tutorial. These are two starting points for building your own workflow. As an example of a finished product, Apten currently describes enrollment conversations across SMS, voice, email, and webchat. Its target use case matters when assessing fit.

A visual builder can shorten setup for a fixed conversation. A custom application gives your team control over the data and action logic but also makes it responsible for operation. A finished service should be evaluated against the actual industry workflow, integration, and handoff your organization needs.

How much does an SMS chatbot cost?

Separate the messaging bill from the software and operational costs. Twilio's US pricing page charges text messages by segment and identifies additional carrier, number, and applicable registration charges. The rate depends on the route and sender; use the current quote for your destination and use case rather than a single headline price.

A planning formula is: monthly fixed costs + inbound segments × inbound rate + outbound segments × outbound rate + applicable carrier and registration charges + model and hosting costs + human support. Some vendors bundle parts of that bill, so check what the quoted plan actually includes.

Hypothetical volume example: 1,000 conversations with three one-segment customer messages and four one-segment bot replies each produce 3,000 inbound and 4,000 outbound segments. If each bot reply becomes two segments, outbound usage doubles to 8,000. This is a volume illustration, not a vendor quote; insert your own rates and measured conversation lengths.

Twilio documents 160 characters for a single GSM-7 SMS segment and 70 for UCS-2. Multipart capacity is typically 153 and 67 characters per segment respectively. Encoding and special characters affect the count, so inspect actual generated replies with the provider's segment calculator. Concise answers also make the conversation easier to use.

Keep consent and opt-outs outside the model's discretion

Twilio's messaging policy distinguishes a reply to an individual's incoming request from permission for recurring engagement. It requires appropriate consent, evidence of that consent, sender identification, and an accessible opt-out. Read the current provider rules alongside the requirements for your destination and campaign before activating outbound messaging.

Twilio's Advanced Opt-Out can handle configured opt-in, opt-out, and help keywords for a Messaging Service. It also describes provider-side blocking after an opt-out. Connect those signals to your own conversation and campaign state so another scheduled job does not keep attempting to contact the person.

Do not ask a language model to decide whether it feels like honoring an unsubscribe. Process recognized control events deterministically, and route other clear withdrawal requests to the appropriate handling path. Test a stopped conversation against later queued messages, imported contact lists, and a handoff to another system.

Plan for duplicate events, slow answers, and human handoff

Twilio recommends validating webhook signatures with its SDK's validation library. A request reaching your endpoint should not by itself be enough to trigger an account lookup or a record change. Keep provider credentials and business-system secrets on the server.

Design record changes so processing the same incoming event twice does not create two bookings or requests. Track the provider's message identifier and the operation's state. Before retrying an action after a timeout, inspect whether the action already succeeded. Sending a second acknowledgment and repeating a transaction are different problems.

Decide who owns the conversation while a human is involved. Pause normal bot replies, pass a concise summary and the relevant history, and record when the person returns control. Otherwise a customer can receive conflicting answers from the bot and the support team.

Use a short acknowledgment only when it helps explain a real delay. If the underlying source is unavailable, say what remains unconfirmed and offer the next available route. A fluent invented status is worse than a clear incomplete result.

Check the whole conversation before launch

Use a small set of realistic conversations that include corrections and exceptions, not just the ideal script. The checks below are an editorial starting point. Test through the real sender and destination setup you intend to use, with recipients authorized for that test.

• A clear request reaches the correct source and produces a short, accurate reply.
• An ambiguous date causes clarification before anything is booked.
• A duplicate incoming event does not repeat a record change.
• An unavailable source produces an honest fallback and an assigned owner.
• An opt-out stops the intended future messages, including queued follow-ups.
• A person can take over with enough context and without competing bot responses.
• Delivery failures, unresolved requests, and actual segment usage are visible to the operator.