Skip to content
Chatbotscape
Editorial flat-vector illustration for Chatbot Scripts: Writing for a Box With a Character Limit (2026)
19 min read

Chatbot Scripts

Writing for a Box With a Character Limit (2026)

Quick answer: A chatbot script is not a document. It is a set of short strings that get dropped into fields, and several of those fields have caps published by the channel rather than by your platform. On WhatsApp, a reply button label is capped at 20 characters and a list row title at 24, which is shorter than most of the button copy in circulation. This guide covers the seven blocks every working script needs, the character budgets you are writing into, three scripts you can adapt today, and the failure ladder that separates a bot people finish from a bot people abandon. What decides which line fires is a separate layer, covered in dialogue management; what shape the branches take is covered in our conversation flow guide.

A script is seven blocks, not a wall of text

Every script that survives contact with customers contains the same seven blocks. Most published examples contain three of them, which is why they read well and perform badly.

  1. The opener. What the bot is for, in one line, plus the first choice. Covered in depth in our welcome message guide.
  2. The menu. Two or three options that cover most of why people arrive. Not a list of your departments, and three is also where WhatsApp reply buttons cap out.
  3. The collection turns. One ask per message. Never two questions in one bubble, because customers answer the second and you lose the first.
  4. The read-back. Repeat the specifics before anything irreversible happens. Our confirmation design guide covers what to echo.
  5. The failure ladder. What the bot says on the first miss, the second, and the third. Three different lines, not one line three times.
  6. The exit. How a person gets to a human, available from any turn and not buried at the end.
  7. The close. What happens next, with a reference the customer can keep.

Write those seven and you have a script. Skip the fifth and sixth and you have a demo.

The character budgets nobody writes to

This is the part that gets discovered during implementation, usually after the copy has been approved. Meta publishes exact caps for WhatsApp interactive messages, and they are tighter than the copy most guides suggest.

FieldReply-button messageList message
Body text1,024 characters4,096 characters
Headeroptional; text, image, document or video, with no character cap publishedoptional; text only, 60 characters
Footer text60 characters60 characters
Button label20 characters, up to 3 buttons20 characters, exactly 1 button
Section titlenot applicable24 characters, up to 10 sections
Row titlenot applicable24 characters
Row descriptionnot applicable72 characters
Row capnot applicable10 rows across all sections combined

Three things fall out of that table and each one changes how you write.

The body cap is four times larger on lists than on buttons. Same channel, same interactive message family, 1,024 against 4,096. If your script needs a paragraph of context before the ask, the list message is the one that allows it. Nobody chooses list versus buttons on that basis, and they should.

Sections do not buy you more options. You may define up to 10 sections, but the row limit is 10 across all of them combined. Sections group; they do not expand. A service menu with four categories of five services each does not fit, and finding that out after you have written twenty row titles is a bad afternoon.

Twenty characters is short. "Book an appointment" is 19 and fits. "Yes, book me an appointment" is 27 and does not. Write your button labels first, count them, and let the body text carry the meaning that will not fit on the button. The constraint is not unique to WhatsApp, and at least one builder surfaces it for you: our Tidio walkthrough on 28 May 2026 found the Flows editor showing an inline warning that Facebook Messenger "displays shorter buttons; unique ones are truncated to 20 characters" while you write the node. That is the exception rather than the rule: on the other builders we have reviewed, nothing warns you in the editor.

Two more rules from the same documentation are worth knowing before you write. Meta specifies that a button label "Must be unique if using multiple buttons," so two buttons cannot both say "More info." And a list message supports exactly one button, whose label is also capped at 20 characters, which means the word that opens your menu is doing more work than any other word in the script.

Three scripts you can adapt today

These are written to the constraints above. Counts are given for every button label, section title, row title and row description, plus the opening message body, since those are the fields where the budget actually runs out. The remaining message bodies all sit far inside their 1,024-character ceiling and are not counted individually. Adapt the nouns; keep the structure.

1. Service booking, WhatsApp

Opener (body, 104 characters): "Hi! This is Northside Barbers. I can book you in, move an existing appointment, or pass you to the team."

Buttons: Book a time (11) · Change booking (14) · Talk to a person (16)

Service menu (list message). Button: View services (13). Section title: Cuts and beards (15).

Row titleCharsRow descriptionChars
Haircut (45 min)16$32. Wash, cut and finish.26
Beard trim (20 min)19$18. Shape, line-up and hot towel.34
Cut and beard (60 min)22$45. Both services in one visit.32

Collection turn: "Which day suits you best?" One ask. Offer tappable days rather than free text, for the reason set out in slot filling: a question that invites an answer you then have to reject is the worst pattern available.

Read-back: "Booking a haircut with Sam, Thursday, August 20 at 3:00 PM, 45 minutes, $32. Shall I confirm?" Buttons: Confirm (7) · Change (6).

Close: "Booked. You will get a reminder the day before. Reply CHANGE any time to move it."

2. Order status, website widget

Opener: "Hi, I can look up an order, start a return, or get you to the team."

Buttons: Track my order (14) · Start a return (14) · Talk to a person (16)

Collection turn: "What is your order number? It starts with NS and has six digits, like NS204817."

Showing the format is the whole trick. It cuts malformed entries without adding a turn, and it gives the failure ladder something specific to say.

Read-back: "Order NS204817, placed August 6, two items, shipping to the address on 4th Street. Is that the one?"

Close: "Out for delivery today, tracking 1Z999AA10123456784. Anything else?"

3. Lead qualification, Instagram DM

Opener: "Thanks for reaching out. Two quick questions and I will get you to the right person, or say 'human' any time."

Collection turn 1: "What are you looking to have done?" Options: Kitchen (7) · Bathroom (8) · Something else (14).

Collection turn 2: "Roughly when do you need it finished?" Options: Next month (10) · 2-3 months (10) · Just planning (13).

Instagram and Messenger cap quick-reply titles as well. We have not verified those two numbers against Meta's documentation in this pass, so treat the WhatsApp caps in the table above as the verified ones, keep every label inside 20 characters, and check your own channel before you ship.

Close: "Got it. Priya handles kitchen work and will message you here before 5 PM tomorrow. Anything you want me to pass on?"

Note what is not in that script: a budget question. Our editorial position, and it is a position rather than a measurement, is that asking for budget in the second turn of a first conversation costs you more conversations than it qualifies, and that the answer you extract that way is unreliable anyway. Two questions, then a named human with a time. The rest of the routing logic belongs in your escalation playbook.

The failure ladder is the part everyone skips

A bot that says the same thing twice has told the customer that nothing they do will change the outcome. We read that as the reason people leave at the second failure rather than the first, though we have not measured it. Write three distinct rungs.

First miss. Restate the ask more narrowly, and add the format. "I did not catch that. Your order number starts with NS and has six digits, like NS204817."

Second miss. Change the mechanism. Stop asking for typed input and offer buttons, or offer a different route to the same goal. "No problem. Want me to look it up by the email you ordered with instead?"

Third miss. Stop. Offer the human and carry the transcript across. "Let me get someone. Sending you to the team now with everything from this chat."

Engines differ in how much of the ladder they hand you, which is worth checking before you write three rungs you cannot deploy. Dialogflow CX exposes numbered sys.no-match-1 through sys.no-match-6 events, which makes distinct copy per attempt a configuration step. Rasa's CALM ships a single named fallback pattern rather than a numbered ladder; the per-attempt variation is yours to build inside it. Flow builders vary, and none of our fifteen reviews records a numbered retry primitive, so assume you will be counting attempts by hand and budget the nodes. The mechanism underneath is covered in dialogue management. What belongs here is the copy.

Two things to keep out of the ladder. Do not apologize three times; one apology reads as courtesy and three reads as a broken machine. And do not let the ladder run without an end, which is what happens when no third rung exists. Where it should end is a policy decision, set out in our escalation playbook and defined in fallback intent.

What changes when the bot is generative

All seven blocks survive. What changes is how you store them, and the change is not uniform across the seven.

On a rules-based bot the script is the output: the string in the field is what the customer sees. On a generative bot the script becomes a specification. You are no longer writing the sentence, you are writing the constraint on the sentence, plus the examples that pin down tone. That is prompt work rather than copywriting, and our prompt engineering guide covers the mechanics.

The menu and the collection turns loosen most, since a model can rephrase a question without changing what it asks for. What does not loosen at all is the fixed text. Confirmations, prices, legal lines, cancellation terms and anything you would have to correct in writing should stay as literal strings the model cannot rephrase. A model that paraphrases "your card will be charged $45 today" into something friendlier has changed a commitment. Keep the read-back deterministic and let the model handle the parts where variation is harmless. This split, deterministic where it matters and generative where it does not, is the same tradeoff we set out in generative versus rule-based chatbots.

Version it, or you will rewrite it

Scripts rot in a specific way: someone edits a line in the builder to fix a complaint, nobody records why, and six months later the tone is inconsistent and nobody can explain any individual sentence. Three habits prevent it, and none of them need a tool.

Keep the master copy outside the builder, in a document with one row per string. The builder is a deployment target, not a source of truth, and you should not assume its edit history will tell you who changed what. Date every change yourself and write the reason in five words. Then re-read the whole script out loud once a quarter, because inconsistency is inaudible line by line and obvious in sequence.

If your bot serves more than one language, treat translation as authoring rather than conversion. The character caps apply per language, and the languages that run long will breach a 20-character button that was comfortable in English. Our multilingual guide covers what else changes. When you are turning existing material into bot copy, the email-to-script converter does the first pass, and the conversation flow simulator lets you walk the branches before you build them.

Then test it as a script rather than as a feature. Our QA testing protocol turns the seven blocks into a regression set, and the check that catches the most problems is the cheapest: run every capped field through a character counter before it ships.

What not to script

Anything you cannot deliver. A bot that offers same-day callbacks on a Friday night has written a promise your team will break.

Small talk you have not budgeted for. Answering "how are you" is fine. Building a personality module is a project, and it is rarely why anyone opened the chat.

The agent's side of a live conversation. Saved replies a human picks from are a different artifact with different rules, covered in canned responses. Do not manage both in one document.

Regulated wording, without review. If a sentence has compliance implications, it belongs in the fixed-string set and it belongs in front of whoever signs off on your other customer-facing copy.

What is a chatbot script?

The written text a chatbot uses, organized by the turn it belongs to. In practice it is a set of short strings dropped into named fields in a builder, not a document read top to bottom, which is why length caps and one-ask-per-message discipline matter more than prose quality. A complete script covers the opener, the menu, the collection turns, the read-back, the failure ladder, the human exit and the close.

How long should a chatbot message be?

Short enough to read without scrolling on a phone, and inside whatever your channel caps. WhatsApp publishes 1,024 characters for the body of a reply-button message and 4,096 for a list message, so the ceiling is generous and the practical limit is attention rather than the API. One ask per message is the rule that matters most: two questions in a single bubble reliably produce one answer.

How many buttons should a chatbot offer?

On WhatsApp reply buttons the choice is made for you: up to three, labels capped at 20 characters, and each label must be unique. Where a platform allows more, three is still the number we would write to, because a menu long enough to need scanning is a menu people skip. Our conversation flow guide makes the same call on the top-level menu. If you need more options than that, a list message is the correct format and it caps at 10 rows across all sections combined.

Do I still need a script if my chatbot uses AI?

Yes, for a narrower set of text. The parts you stop writing are the conversational connective tissue, which the model handles. The parts you must keep as fixed strings are anything that constitutes a commitment: prices, confirmations, cancellation terms, legal lines. A model that rephrases a charge confirmation into friendlier language has altered a promise, and the customer is entitled to rely on the words they were shown.

What should a chatbot say when it does not understand?

Something different each time, up to three times, then hand off. First miss: restate the ask more narrowly and show the expected format. Second miss: change the mechanism, typically from typed input to tappable options, or offer a different route to the same goal. Third miss: stop and route to a person, carrying the transcript. Repeating one line tells the customer that nothing they do will change the outcome, which is our reasoning rather than a measured finding, and it is enough of a known problem that Dialogflow CX exposes six numbered no-match events so you do not have to.

Where should I store my chatbot scripts?

Outside the builder, in a document with one row per string, a date, and a five-word reason for each change. Builders are deployment targets and their edit histories are usually thin or absent. Keeping the master copy separate is also what makes a platform migration survivable, since the text is the asset and the canvas is not.

What is the difference between a chatbot script and a conversation flow?

The script is what gets said; the flow is the shape of the branches; and the engine choosing which branch to take is a third thing again. You can have flawless copy on a flow that never reaches the customer, and a clean flow whose wording loses them at the second turn. Our conversation flow guide covers the topology and dialogue management covers the decision layer underneath both.

Sources

  • Meta. Interactive reply buttons messages, WhatsApp Business Platform documentation (page stamped "Updated: May 21, 2026" when read) — the maximum of three predefined reply buttons per message, body text capped at 1,024 characters with URLs auto-linked, button label text capped at 20 characters with the requirement that labels be unique when several are used, button ID capped at 256 characters, footer text capped at 60 characters, the optional header supporting document, image, text and video types, and the button_reply webhook payload carrying the tapped button's ID and title. Read in a live browser session on 12 August 2026. developers.facebook.com
  • Meta. Interactive list messages, WhatsApp Business Platform documentation (English page stamped "Updated: Jul 2, 2026" when read; a localized rendering of the same URL carried a different stamp, which is why we record the English one) — support for up to 10 sections containing up to 10 rows in total across all sections, body text capped at 4,096 characters, text-only header capped at 60 characters, footer capped at 60 characters, a single action button capped at 20 characters, section title capped at 24 characters, row title capped at 24 characters, row description capped at 72 characters, row ID capped at 200 characters, and the list_reply webhook payload identifying the selected row. Read in a live browser session on 12 August 2026. developers.facebook.com
  • Google. State handlers, Dialogflow CX documentation — the sys.no-match-default built-in event and the numbered sys.no-match-[1-6] events, with the statement that when handlers are provided for the numbered events they are invoked instead of the default and in order. Read in a live browser session on 12 August 2026. docs.cloud.google.com
  • Rasa. Conversation Patterns, Rasa Documentation concepts (page stamped "Last updated on Aug 12, 2026" when read) — conversation patterns as reusable system flows provided by CALM, including the cannot-handle fallback pattern referenced in the failure-ladder section. rasa.com
  • Chatbotscape. Tidio review — the one hands-on platform observation on this page: a Flows-editor session on 28 May 2026 captured the inline warning that Facebook Messenger "displays shorter buttons; unique ones are truncated to 20 characters," surfaced in the Decision node as the copy is written. That session measured build times, not script performance, and this page publishes no completion or conversion figures for any platform.
  • Chatbotscape platform reviews, all fifteen, searched 12 August 2026 — the basis for the catalog-wide statement in the failure-ladder section. A case-insensitive search of every published review, excluding process notes and backups, for a numbered no-match event, a retry ladder, a numbered retry or a reprompt handler returned no match in any of the fifteen, which is why the page tells you to assume you will be counting attempts by hand. The reviews of Manychat, Landbot, Wati and SendPulse are linked for navigation from this cluster and are cited for no individual claim here.
  • Chatbotscape. Dialogue management /glossary/dialogue-management, Chatbot conversation flow /academy/chatbot-conversation-flow and Chatbot welcome message design /academy/chatbot-welcome-message-design — the decision layer, the branch topology and the opener, which this page deliberately does not restate.
  • Ahrefs Keywords Explorer, US, 12 August 2026 — the search-demand figures in this page's keyword note.
  • Chatbotscape evaluation methodology. /methodology (continuously updated).

About this guide

Chatbotscape launched in 2026 as an independent review site for chatbot platforms. This guide is part of our SMB chatbot Academy. It covers the script as a written, versioned artifact: what blocks it needs, what character budgets it ships into, and what changes when a model is generating the words. The decision layer that chooses between scripted turns is in the companion glossary entry, and branch topology is in our conversation flow guide. If a channel limit has changed since we verified it, or your production experience contradicts something here, we want to know: editorial@chatbotscape.com.

Methodology

The character limits in the table and throughout the worked scripts were read directly from Meta's live WhatsApp interactive message documentation on 12 August 2026, in a live browser session rather than a cached fetch, and each figure is attributed in Sources. Both pages carried their own update stamps, recorded above. During verification the list-messages page returned one stamp in its English rendering and a different one in a localized rendering of the same URL; we record the English stamp and flag the discrepancy rather than quietly picking one. The numbered no-match behavior attributed to Dialogflow CX was read from Google's State handlers page the same day, and the Rasa fallback-pattern comparison from Rasa's Conversation Patterns page.

Character counts given for the worked scripts were computed programmatically from the strings as published on this page, not estimated. The scripts themselves are editorial constructions written to the documented constraints. They are not copy we have deployed or tested, and this page publishes no completion rates, abandonment rates or conversion figures.

Two passages carry their hedge in the body where you meet them: the position against a budget question in early qualification, and the reasoning about why a repeated line loses people. The rest of this page's editorial judgment is not individually flagged in situ, so it is enumerated here instead: the seven-block structure, the three-rung failure ladder and the copy in each rung, the guidance on which strings to keep deterministic on a generative bot, the three versioning habits, the recommendation to cap a menu at three options, and the four items under what not to script. None of those is a documented vendor rule. Everything in the character-limit table and every engine behavior attributed to Dialogflow CX or Rasa is. See our methodology for how platform facts are verified.

Last updated

13 August 2026 — Initial publication aligned to methodology v3.12.1. Next scheduled refresh: 13 November 2026.