Chatbot Script Generator

Three quarters of a working script is failure handling

Run the defaults above and the generator emits 24 states for a WhatsApp support bot. Six of them are the happy path: greet, offer a menu, collect one fact, read it back, close, ask whether it landed. Twelve are recovery, meaning the customer said something the bot could not use. Six are boundary states, meaning the conversation went somewhere the bot has to answer honestly rather than helpfully. Failure handling is 75% of the pack.

That figure moves with the setup, and the range is narrow. Across every combination the generator can produce, 300 of them, the packs run from 18 to 27 states and the failure share sits between 61.9% and 76.0%. Appointment booking is the lowest because a calendar adds happy-path states rather than recovery ones. Order status is the highest, because a reference number can be malformed, valid but unknown, or right but attached to nothing yet, and each of those needs different copy.

One thing that share is not: a claim about your traffic. Most conversations still take the happy path, and on a well-scoped bot most of them should. What is unevenly distributed is the writing. Six states carry the outcome and eighteen carry everything else, and a script review that spends its time on the greeting is spending it on a quarter of the problem.

What a complete script contains

Our guide to chatbot scripts sets out the seven blocks every script needs, and this tool is the executable version of that argument. The generator fills all seven, then adds the states that sit outside the blocks entirely: the ones about being a bot, about data, about abuse, and about what happens when a messaging window closes.

Eight of those 24 are marked as states a first draft usually contains. That marker is an editorial judgment drawn from reading published script templates and the flows we open during platform reviews, not a measurement of anybody's repository, and the tool labels it as a count rather than a benchmark. Treat it as a provocation: the sixteen you were not planning to write are the ones that decide whether the bot is tolerable at eleven at night.

The failure ladder, and why it has three rungs

The slider above sets how many times the bot tries again before it stops. Set it to three and you get three distinct rungs, which is the pattern to copy.

First miss. Restate the ask more narrowly and give the format. The customer usually knows the answer and does not know what shape you want it in.

Second miss. Change the mechanism rather than the wording. Stop asking for typed input, offer the menu, and let a tap do what a sentence could not. Our quick reply entry covers when a tap beats a text box, and quick reply versus button covers which control to reach for.

Third miss. Stop trying. Hand over, carry the transcript across, and say so. A ladder with no end is why people leave at the second failure rather than the first.

Set the slider lower and the generator does two things. It shortens the ladder, and it adds a terminal state so the bot still has somewhere to land, because a ladder without an end loops. It also raises a check telling you the ladder is short. The mechanism underneath all of this is dialogue management, and the miss counter is the part builders implement least consistently. What belongs in the script is the copy, and the copy has to differ per rung or the ladder does nothing.

The caps the copy is written to

Every line the generator produces is measured, and the character count sits next to it in the preview. This is the part that gets discovered during implementation, usually after the copy has been signed off. Change the channel and watch the numbers move.

Two of those rows need a footnote, and the tool prints both. The website widget has no vendor-imposed cap at all: 600 characters and six options are an editorial reading limit, because a widget that accepts a thousand characters will still lose the reader at four hundred. Telegram's 4,096 is a real platform limit; the button numbers in that row are ours.

The WhatsApp row deserves a second footnote because the same API publishes three different sets of numbers and picking the wrong one costs you a rewrite. A reply-button message caps the body at 1,024 with up to three buttons at 20 characters. A list message on the same API allows 4,096 in the body but caps at ten rows of 24 characters across all sections combined, so a menu that will not fit as buttons may still fit as a list. A message template, the kind you need to reopen a closed window, allows 25 characters on a quick-reply button. The generator lints against 20 because a script runs inside the session, where the tightest of the three applies. Meta also specifies that labels within one message must be unique, so two buttons cannot both read "More info", and the tool treats a repeat as a blocker rather than a style note. Our WhatsApp Business API entry covers the surfaces themselves.

The lint is not decorative. Writing this tool, the check caught three of our own generated labels over the 20-character limit before the page existed: a queue option at 23 characters, an out-of-hours option at 21, and a sales fallback at 22. All three read fine in a document and none of them would have rendered.

The states nobody drafts

Some of what the generator adds is obvious once it is on the page and invisible before. Four are worth calling out.

Format rejected is not the same as not understood. A malformed order number and an unparseable sentence need different copy, because in the first case the customer got the intent right and in the second they did not. Merging the two sends people back to retype input that was nearly correct. This is the state where slot filling gets its reputation.

In-hours unavailability needs its own line. The queue is empty at midnight and full at two in the afternoon, and both produce a customer who cannot reach anybody. Reusing the out-of-hours copy tells someone you are closed while your team is at their desks. Our handoff rules entry covers the thresholds that decide which one fires.

The session window is a state, not a setting. On WhatsApp, Messenger and Instagram the conversation closes after 24 hours of silence and reopening it takes an approved template rather than free text. That means the re-engagement line has to be written and submitted in advance. Our template approval predictor checks that line against the rejection triggers before you submit it, and session context covers what the bot should still remember when the window reopens.

Abuse should not route to a person by default. The reflex is to escalate anything hostile, which means the automation forwards abuse at an agent. The generated state ends the conversation and flags it, leaving a supervisor to decide. That is a policy position and you may hold a different one, which is why the copy is short and easy to replace.

Why we built it this way

The prompt came out of template libraries. Across the builders we open for Chatbotscape reviews, the shipped script templates are almost entirely happy path: a greeting, a menu, a capture, a close, and a single fallback line that says some version of "sorry, I did not get that" forever. The libraries are not wrong so much as incomplete, and they are incomplete in a way that flatters the demo. A happy-path script builds a bot that works in a walkthrough and disintegrates in week two.

The design decision that follows is why the copy here is deterministic rather than generated by a model. A script is a document a team argues with. If the tool produced different wording on every run you could not tell your edits from its variance, and the second draft would be a fresh negotiation rather than a diff. Fixed templates give you the same starting point every time, which makes the version-control habit our script guide recommends possible at all. That is also why one of the exports is a table with one row per string and its character count: a master copy outside the builder is the only thing that survives six months of small fixes.

Where this sits next to our other script tools

Three tools touch bot copy and they do different jobs. This one starts from nothing and gives you a full pack for a use case and a channel. The email to chatbot script converter starts from copy you already have, stripping email scaffolding out of a canned reply and re-cutting it into chat bubbles. The conversation flow simulator takes the branches you have written and lets you walk them, which is how you find out that two menu options match the same phrasing.

The order that works: generate the pack here, replace the parts that describe your business, run any customer-facing copy you inherited through the converter so it stops sounding like email, then walk the result in the simulator before you build a single node. Once it is live, the QA testing protocol turns the same states into a regression set.

What the generator will not do for you

It does not know your refund policy, your delivery estimates, or what your team can promise on a Friday night, and it does not pretend to. Three things need your attention before any of this ships.

The data-question state ships with wording that describes a common setup rather than yours, and the tool raises a check saying so on every run. It is the one line on this page you must not paste unchanged, because getting it wrong is a statement about your processing rather than a clumsy sentence.

The opening hours are a promise. Customers test it before they test anything else, and the always-open option raises a check for exactly that reason. If the rota does not cover the night, say the hours and let the out-of-hours state carry the real answer.

The tone control changes a handful of openers and apologies. It is not a personality, and it will not make a script sound like your brand. Small talk is deliberately absent for the same reason: answering "how are you" is fine, and building a personality module is a project that is rarely why anyone opened the chat.

Limitations worth stating

The channel caps are read from vendor documentation on the last-verified date at the top of this page, not probed against a live API. Platforms change limits, and a cap that moves between refreshes will be wrong here until the next one. Where a number decides something expensive, check it against the vendor docs on the day.

The copy is English and the caps are counted in characters, which means a translated script can breach a limit that was comfortable in the original. Twenty characters is generous in English and tight in German. Our multilingual guide covers what else changes, and the short version is that translation is authoring rather than conversion.

The failure share is a property of the generated pack, not a finding about scripts in general. We built the state list, so the 75% is a consequence of our editorial judgment about what a production bot needs. A team that disagrees about, say, whether abuse deserves its own state will get a different number, and that disagreement is worth having.

Nothing here is a compliance review. Bot disclosure requirements, data-handling wording and opt-out obligations vary by jurisdiction and by what you are actually doing with the transcript. Have someone qualified read the boundary states before launch.

Related Chatbotscape tools and resources

Some review links below go to platforms we may earn a commission from. That relationship does not affect scores, rankings, or what this generator produces. See our affiliate disclosure for how it works.

• Chatbot scripts guide — the seven blocks, the character budgets, and three worked scripts to adapt
• Welcome message design — the one state customers judge fastest
• Confirmation design — what the read-back should echo before anything irreversible
• Escalation playbook — where the failure ladder should end, as a policy rather than a line of copy
• Conversation flow design — the structure the script hangs on
• Generative versus rule-based — which strings stay literal when a model writes the rest
• Email to chatbot script converter — for copy you already have
• Conversation flow simulator — walk the branches before you build them
• Conversation design — the discipline the script belongs to
• Fallback intent — what fires when nothing matches
• Human handoff — the exit that has to be available from every state
• Greeting message — the opener, in more depth than a generator can give it
• Confirmation message — the read-back that stops the next contact
• Fallback rate — the metric that tells you which rung people are stuck on
• ManyChat review — template library depth and where its flows stop
• Landbot review — a builder whose editor exposes the script as text
• Tidio review — the one builder we have tested that warns about label truncation while you type

FAQ

What is a chatbot script?

The written copy a bot says, organized by the state it says it in. A script is not a flowchart and not a prompt. It is the set of strings a customer will read, with a note against each one saying when it fires and what happens next. On a rules-based bot the string is the output. On a generative bot most strings become a specification, though the read-back, the prices, and the legal lines stay literal. Our prompt engineering guide covers that translation.

How many states does a chatbot script need?

This generator emits between 18 and 27 depending on the combination you pick, and the count is driven by what your setup actually has rather than by a target. A channel with a session window adds a state. A bot with no route to a person loses three and gains one. Booking adds the two states a calendar needs. The number that matters is not the total but the split: on the default support script, 6 of 24 states are the happy path.

Why is most of the generated script about things going wrong?

Because the conversation has one way to succeed and many ways to stall. The default support pack is 75% recovery and boundary states. That is a share of the writing, not a share of your traffic: most conversations still take the happy path. It is the writing that is unevenly distributed, and it is the writing teams budget nothing for.

What should a chatbot say when it does not understand?

Three different things, in order. First miss: restate the ask more narrowly and give the format, so the customer knows what shape of answer works. Second miss: change the mechanism, usually by stopping the typed input and offering buttons. Third miss: stop, and hand over. Saying the same line three times tells the customer that nothing they do will change the outcome. Where the ladder should end is a policy question, covered in our escalation playbook.

How long can a WhatsApp chatbot message be?

1,024 characters in the body of a reply-button interactive message, which is the surface a session script uses most. A list message on the same API allows 4,096 in the body but caps at 10 rows of 24 characters each. Button labels are capped at 20 characters and must differ from each other within one message. The generator lints against the reply-button numbers because they are the tightest.

Does this tool use AI to write the copy?

No. Every line comes from a fixed template that varies by use case, channel, tone, and whether a person is reachable. That is deliberate: a generated script is meant to be read, edited, and argued with, and a deterministic one gives you the same starting point every time so you can tell what you changed.

Can I use the generated script as it is?

No, and one state will tell you so. The data-question copy describes a common setup rather than yours and has to be rewritten before launch. The opening hours have to be checked against the rota, because that is the promise customers test first. Everything else is a draft to argue with, not copy to paste.

Does the generator send my data anywhere?

No. Everything runs in your browser. Nothing you type is uploaded, stored, or logged, and reloading the page clears it.

Can I embed this generator on my site?

Yes, free. Copy the iframe snippet from the embed section above. The embed strips Chatbotscape navigation and keeps the generator plus attribution.

Sources and basis

• WhatsApp field caps.Body, button label, button count, list row and section limits are Meta's published values for Cloud API interactive messages, collected for our chatbot scripts guide and re-checked for this tool on 25 August 2026. The 24-hour customer service window and the template requirement for reopening it come from the same documentation set.
• Messenger and Instagram quick replies.The 20-character label and 13-reply limits are Meta's published send-API values. Checked 25 August 2026.
• Telegram message length. 4,096 characters is the documented Bot API message limit. The button numbers in that row are an editorial reading limit and the tool says so.
• Website widget numbers are ours. No vendor enforces a cap there. 600 characters and six options are an editorial reading limit derived from the same reasoning as the rest of the table, and the tool labels them as such rather than presenting them as a platform rule.
• The state list is editorial. Which states a production bot needs, and which of them a first draft usually contains, is our judgment from platform review work and published template libraries. It is not a survey, and the 75% figure is a property of that judgment rather than a finding about scripts in general.
• No customer deployment data. Every figure on this page is computed by the generator itself from its own output. Nothing here reports measured results from a live bot.
• Figures reproduced from the shipped engine. The 24-state default pack, the 6/12/6 split, the 18 to 27 range and the 61.9% to 76.0% failure-share range are printed by the same code that runs above, checked across all 300 input combinations before publication.