Skip to content
Chatbotscape
Verified
SMS chatbot· Messaging channel
An SMS chatbot is an automated conversation that runs over plain text messaging, where the customer texts a phone number and software answers. What separates it from a chatbot on any other channel is not the software but the channel's poverty: no buttons, no menus, no cards, no read receipts, and no way to show the customer their options except by spelling them out in words they have to type back. In the United States it is also the only mainstream chatbot channel that a carrier can switch off. Before a single automated message reaches a US phone, the sending brand and the specific use case have to be registered under A2P 10DLC, and that registration, not the build, is what sets your launch date.
By Chatbotscape Editorial· Methodology· Published 29 July 2026· Updated 29 July 2026

SMS Chatbot — Definition, the Registration Gate, and Why the Channel Sets the Design (2026)

Quick answer: An SMS chatbot is a bot that talks to customers through ordinary text messages. Technically it is unremarkable: the same conversational AI stack that runs a website widget can answer a text, and most platforms treat SMS as one more channel toggle. Two things make it a different project anyway. The first is regulatory. US carriers require every business sending automated text to register a brand and a campaign under A2P 10DLC, and vendors currently quote campaign vetting in weeks rather than hours, so the gate on your launch is paperwork rather than engineering. The second is design. SMS has no interface. Every affordance a flow builder gives you disappears, so the bot's entire user interface is words, and the customer has to type them back correctly for anything to happen. Get both right and SMS remains the highest-reach channel in the US market. Get either wrong and you have built something that either does not deliver or does not work.

What the term covers

An SMS chatbot sits in the same family as any other bot our what is a chatbot entry describes. A message arrives, something interprets it, something decides what happens next, and a reply goes out. The interpretation layer can be a keyword match, an intent recognition model, or a language model, and the choice matters far less on SMS than the channel constraints below.

The industry vocabulary is worth untangling because it causes real confusion. Business text traffic is classified as A2P, application-to-person, as opposed to P2P messaging between two humans. Twilio's glossary defines A2P as traffic "in which a person is receiving messages from an application rather than another individual, and which is not expected to receive a reply," and then, in the very next sentence, lists chatbots among its examples. Both halves are true and the tension is the point. The classification was built around one-way notification traffic, and a chatbot is the case that does expect a reply. The registry accounts for this directly: The Campaign Registry's own explainer says that "if you use SMS for 2-way customer support, you would register a 'Customer Care' campaign." Two-way is supported. It is simply not what the plumbing was designed around, and that shows up in tooling maturity throughout the channel.

Three things get confused with it, and each confusion costs something different:

  • SMS is not RCS. RCS is the carrier standard replacing SMS in the same inbox, and it restores the buttons, cards, images, and read receipts that SMS lacks. Everything this entry says about missing affordances is an argument for RCS wherever it is available to you.
  • SMS is not MMS. MMS is the separate multimedia lane; Twilio's documentation notes it can carry "up to forty seconds of video, audio, one image, or a slideshow of multiple images." Plain SMS carries text. If a vendor demo shows a product photo in a text thread, that is MMS pricing, not SMS pricing.
  • SMS is not WhatsApp. The two are compared constantly because both reach a phone number, but WhatsApp is an app a customer chose to install, with a richer message format and a different consent regime. Our RCS versus WhatsApp guide covers the campaign-lane comparison, and the same reasoning extends to SMS.

The registration gate, which decides your launch date

This is the part that surprises teams arriving from web chat, and it is the single most useful thing to know before scoping an SMS project.

A2P 10DLC is, in Twilio's words, "the standard that United States telecom carriers have put in place to ensure that SMS traffic to US end users through long code phone numbers is verified and consensual." Registration has two parts. You create a Brand, which establishes who is sending, and a Campaign, which declares what you are sending and, per the same documentation, "how end users can opt-in, opt-out, and receive help." The Campaign Registry runs the central registry, though it is careful to state that it "does not review, approve, or reject campaigns" itself; the approval happens with the connectivity providers in the chain.

The published timelines vary by how much vetting a brand needs, and they are worth reading as a range rather than a promise. Brand review is often automated and completes in minutes, but Twilio documents that manual third-party brand review "take[s] seven business days or more." Campaign vetting is the longer pole: Twilio's onboarding documentation puts it at "between two to three weeks," warns elsewhere that "due to high volumes, this vetting process might take several weeks," and carried a backlog banner quoting 10 to 15 days as of this writing. The registry's own 2026 explainer says "campaign review times can range from 1-4 weeks." None of those numbers is the number. The planning lesson is that the paperwork runs in weeks while the bot build runs in days, so registration should start first and in parallel.

Skipping it is not an option that quietly costs you deliverability. Twilio returns a specific error, 30034, and blocks the message outright: it "blocks messages to U.S. numbers when you send from a +1 10DLC number that is not associated with an approved A2P 10DLC Campaign." Unregistered traffic that does get through picks up carrier surcharges and heavier filtering.

Two structural details are missing from most descriptions of this process, and both land on small businesses hardest. The first is that there is a separate Sole Proprietor brand path, documented as available "for customers in the United States and Canada who do not have a business Tax ID," and it is narrower than the standard route in ways that matter: a Sole Proprietor campaign "can only have one 10DLC phone number attached," there is a single permitted use case, and throughput is capped. If you file taxes on your own Social Security number, that is your lane rather than the standard registration most articles describe.

The second is that registration is a line item and not only a delay. Twilio's documentation has you agree to a one-time brand registration fee before submitting the brand, and separately notes that new US campaign registrations "are charged a campaign verification fee at the time of external vetting," with additional charges possible if a denied campaign is resubmitted. Providers also pass through ongoing campaign charges that vary by use-case type. None of those figures belongs in an article, including this one, because they move. Get the current numbers from your provider before the project has a budget.

There is a faster route, and in fact two other routes. Toll-free numbers sit outside the 10DLC system entirely and use their own verification process; Twilio's onboarding documentation states that it "reviews TFV requests within three business days." Short codes are the third sender type, and they are the high-volume lane with the highest cost and the longest lead time. For most small businesses the real choice is the first two, and the contrast is the cleanest way to frame it: toll-free verification is documented in days and 10DLC campaign vetting in weeks, so a pilot that needs to be live this month has an obvious lane. That choice belongs in the project plan rather than in a later scramble.

Why the missing interface sets the design

Here is the constraint nobody budgets for. On a website widget, WhatsApp, or Instagram, a bot can show the customer what to do next. It offers a quick reply, a menu, a card, a button. The customer taps and the flow advances with an unambiguous input.

SMS has none of that. Twilio's own framing of what RCS adds tells you exactly what SMS lacks, listing "suggested replies, call-to-action (CTA) buttons, dynamic carousels," "large media files," and "delivery and read receipts" as the RCS differences from traditional SMS and MMS. Strip those out and the bot is left with prose.

That single fact reorganizes the design work:

Design decisionOn a widget or WhatsAppOn SMS
Offering choicesButtons the user tapsWords the user types, spelled out in the message
Input reliabilityConstrained; the tap is exactFree text every turn, including typos, "yes pls," and "2."
Message lengthEffectively unboundedSegmented and billed by segment (see below)
Confirming an actionA confirmation message with a cardPlain text, and the read receipt does not exist
Collecting several fieldsA multi-turn form with validation UIThe same form with no UI, so every prompt carries its own instructions
Failure recoveryRe-show the menuRe-explain in words, which reads as nagging by the second attempt

The practical consequence is that SMS bots need better language understanding than the same bot on a channel with buttons, not worse. A keyword-matching bot on a widget is rescued by its own menu. On SMS, that same bot meets every phrasing a human can produce, which is why a competent fallback path and a fast human handoff matter more here than almost anywhere else. It is also why short, single-purpose flows outperform long ones on this channel: order status, appointment confirmation, delivery updates, a reschedule, a one-question reply. Ambitious branching conversation is where SMS bots go to frustrate people.

Segments, not messages, and how one emoji can triple your bill

The billing unit on SMS is the segment, and this catches teams late, usually on the first large send.

Twilio's character-limit documentation lays out the encodings. A message in the standard GSM-7 alphabet fits 160 characters in one segment. Once a message spans multiple segments, seven characters of each segment go to a header, so a concatenated GSM-7 segment carries 153 characters. If the message contains any character outside that alphabet, the whole message switches to UCS-2 encoding and the limits collapse to 70 characters for a single segment and 67 for concatenated ones. One emoji, one curly apostrophe pasted from a word processor, or one accented name is enough to trigger the switch.

EncodingSingle segmentEach concatenated segmentTriggered by
GSM-7160 characters153 charactersStandard Latin text and basic punctuation
UCS-270 characters67 charactersAny emoji, curly quote, or non-GSM character

Run the arithmetic on a 150-character message. In GSM-7 it is one segment. Add a single emoji and it becomes UCS-2, needs three segments at 67 characters each, and bills at three times the cost for the same words. Multiply by a list of 20,000 and the emoji has a price.

The multiplier depends entirely on where you started, which is why the effect is easy to miss in testing. Below roughly 68 characters the same emoji costs nothing extra, since the message still fits one UCS-2 segment. Between about 69 and 132 it doubles the send. Only in the 133-to-160 band does it triple. Short bot replies are therefore not just better writing on this channel; they are the band where the encoding switch is free. That is the kind of number that belongs in the ROI quick math before a campaign, not after it.

Three smaller notes. Most emoji sit outside the basic multilingual plane and consume two UCS-2 units rather than one, so a two-emoji sign-off eats four characters of a 67-character segment. Multi-segment toll-free traffic to the US and Canada carries one fewer character per segment. And dynamic content such as a name or an order number has to be counted at its longest plausible value rather than at the value in your test message.

SMS consent in the US runs under the TCPA and the FCC's rules, and the level required depends on what you are sending. Messages that advertise or constitute telemarketing require prior express written consent. Purely informational or transactional traffic, the category that covers most order updates and appointment reminders, requires prior express consent without the written requirement. Getting a bot's messages classified correctly matters, because a support bot that starts recommending products has quietly changed category.

Opt-out is not merely good practice. Twilio handles a standard set of English opt-out keywords automatically on long codes, including STOP, UNSUBSCRIBE, END, QUIT, STOPALL, REVOKE, OPTOUT and CANCEL, and its messaging policy requires that the first message to a recipient carry "Reply STOP to unsubscribe" or an equivalent. Behind the vendor rules sits the FCC's 2024 revocation order, which took effect in April 2025 and establishes that consumers may revoke consent "in any reasonable manner," names most of those words among its examples, and requires senders to honor a request within a reasonable time and in no case later than ten business days. One narrow piece of that order, the requirement that opting out of one type of informational message applies to a sender's unrelated messages too, remains waived; the FCC extended that waiver to January 31, 2027 in an order adopted this past January.

Now the correction, because it is the most common factual error in current writing about SMS marketing. In December 2023 the FCC adopted a one-to-one consent rule that would have required consent to name a single identified seller. It never took effect. The Eleventh Circuit vacated that part of the order in January 2025, holding that the Commission "exceeded its statutory authority under the TCPA." By the FCC's own account of what followed, the court "issued its mandate on April 30, 2025," and the Commission formally repealed the revised rule that July and reinstated the prior text. The companion restriction requiring consented messages to be "logically and topically associated" with the original interaction fell in the same opinion and is forgotten even more often. If a vendor, agency, or checklist tells you in 2026 that FCC rules require one-to-one consent, that guidance is out of date. Consent obligations are real and the written-consent standard for marketing is unchanged, but that specific rule is not among them. None of this is legal advice, and the consent design for a specific campaign is worth putting in front of counsel.

Where SMS sits in a platform's channel list

Most chatbot platforms list SMS. Reading how they list it is more informative than reading whether they do.

Across the products we review, SMS is typically present as a channel and rarely first-class. Manychat counts SMS among seven channels, with channel access gated by tier: cheaper plans cap how many channels you get, and adding SMS to the messenger pair requires moving up. SendPulse puts SMS in the same account as email, web push, chatbots and CRM, which is the suite case for one vendor across several outbound lanes. Our review covers the bundling at the subscription level and did not price the SMS traffic itself, so treat per-message cost there as a question for the vendor rather than something we have verified. Intercom lists SMS alongside web chat, email, WhatsApp, phone and social, and our review records outbound SMS as documented while full two-way SMS conversation flows were left to verify with sales. BotPenguin places SMS on its top enterprise tier rather than its SMB plans. Our Wati review found its multichannel inbox, SMS included, to be UI consolidation rather than first-class automation depth on every channel, which is exactly the gap the one-line test in our omnichannel chatbot entry is designed to expose.

The Intercom row is the useful one, because the ambiguity it exposes is the whole point. Two questions separate a real SMS capability from a logo on a features page. Can you build and run automation on the channel, or does SMS only appear in the shared inbox for humans to read? And who handles 10DLC registration: does the platform submit brand and campaign for you, or does it hand you a checklist and a carrier account to open yourself? Nothing about a WhatsApp integration prepares a vendor for the second one, and the answer changes your timeline by weeks. Those reviews carry affiliate links, and each records what was verified at its own date; our methodology sets out what that does and does not change about a score.

Two facts about SMS point in opposite directions, and both should shape what you build. It has the fewest features of any chatbot channel and the widest reach. Reach is why it still earns budget in the US market, where the text inbox is where customers actually receive business messages. The missing features are why the bot should do one job per conversation, say what it wants in plain words, and hand off to a person the moment the thread stops being simple. Deciding whether it belongs in your mix at all is the subject of our channel strategy entry and the step-by-step version in our channel selection guide.

  • RCS messaging — the carrier standard succeeding SMS, which restores the buttons and media this channel lacks.
  • Channel strategy — the framework for deciding whether SMS belongs in your mix at all.
  • WhatsApp Business API — the opt-in app channel SMS is most often weighed against.
  • Chatbot broadcast — the outbound format most SMS automation actually is.
  • Omnichannel chatbot — what has to be true for an SMS thread and a web chat to be one conversation.

FAQ

What is an SMS chatbot in simple terms?

Software that answers text messages automatically. A customer texts your business number and gets a reply within seconds, at any hour, without a person reading it. The common jobs are order status, appointment reminders and rescheduling, delivery updates, and simple qualification questions before a human takes over. What makes it different from a chatbot on your website is that there is nothing to tap, so everything the bot offers has to be said in words the customer types back.

Do I need to register before sending automated texts in the US?

Yes, if you are sending to US numbers from a standard 10-digit number. A2P 10DLC registration covers a brand and a campaign, and unregistered traffic is blocked or filtered and surcharged rather than merely deprioritized. Published timelines vary widely by how much vetting the brand needs, from minutes for an automated brand check to a documented range of one to four weeks for campaign review, and longer when the queue is backed up. Toll-free numbers use a separate verification path documented at three business days, which is often the faster route for a pilot, and sole proprietors without an EIN have their own narrower registration track. Start the registration before you build, not after.

How much does an SMS chatbot cost to run?

Two meters run at once, and only one of them is on the chatbot vendor's pricing page. The platform charges you for the bot, usually per contact or per conversation, along the lines our pricing models guide describes. Separately, the carrier charges per message segment, and a segment is 160 characters of standard text or 70 if the message contains any emoji or non-standard character. Long replies and chatty confirmations cost real money at list scale, which is why terse bot copy is a budget decision on this channel and a style decision everywhere else.

Can an SMS chatbot use AI, or is it just keywords?

It can use anything. A generative or retrieval-grounded bot runs on SMS the same way it runs on a widget, because the channel carries text and text is what those models consume. The channel argues for more capable understanding rather than less, since a menu-free interface exposes the bot to every phrasing a person can produce. What the channel does not forgive is a long, hesitant, or verbose reply, so whatever model sits behind it needs an instruction to answer in one or two sentences.

Is SMS still worth using when WhatsApp and RCS exist?

In the US, yes, and mostly for reach. WhatsApp adoption there is a minority habit, and the text inbox is where American customers receive business messages, so SMS reaches lists that no app-based channel can. Outside the US the calculation usually flips, because WhatsApp is the default way people text in Brazil, India, Mexico and much of Southeast Asia. RCS is the direct upgrade to the same inbox and falls back to SMS automatically, so it is complementary rather than competing. Our RCS versus WhatsApp guide works through the campaign-lane version of that decision.

What should an SMS chatbot never be used for?

Anything that needs a form, a document, a signature, or more than about four exchanges. Also anything sensitive: SMS is not an encrypted channel, so account numbers, health details, and identity documents do not belong in a text thread, a constraint our PII handling guide covers in general terms. The healthy pattern is a bot that resolves the short thing in two messages and sends a link for everything else.

How do I handle opt-outs correctly?

Treat the standard keywords as the floor rather than the specification. Providers auto-handle STOP and its variants on long codes, and the first message you send has to tell recipients how to unsubscribe. Above that sits the FCC's revocation rule, which recognizes opt-outs made "in any reasonable manner" rather than only through a designated word, and requires them to be honored within ten business days. Practically, that means your bot needs to recognize a plainly worded "please stop texting me" as an opt-out, not just the literal word STOP, and route it to the same suppression list.

Sources