Chatbot Script Examples You Can Copy Today

The welcome message formula

The opening message is the only script every chatbot needs and the one most often written badly. It has four jobs and about twenty-five words to do them in.

The four parts

• Identify as a bot in the first clause. Not "virtual assistant", not "powered by AI". The word "bot" sets expectations correctly and costs you nothing, and in several jurisdictions disclosing automation is a legal requirement rather than a courtesy.
• State the scope in one line. Naming three things you are good at is more useful than any adjective, and it quietly tells the visitor what not to bother asking.
• Offer two or three quick replies, phrased the way a customer would phrase them. "Where is my order?" beats "Order management". Two or three, never six, because the point is to make the first turn effortless rather than to publish a menu.
• Name the exit. One short sentence telling people how to reach a human removes the anxiety that they are trapped, and it reduces the number of people who type "agent" in frustration on turn one.

Hi, I'm the [Brand] bot. I can help with [thing 1],
[thing 2] and [thing 3].

[Quick reply 1]  [Quick reply 2]  [Quick reply 3]

Type "human" any time and I'll pass you to the team.

That is the whole formula. The discipline is length: on a phone, the widget opens to roughly the height of a business card, and every line of brand copy you add pushes the quick replies below the fold where nobody sees them.

Three rules that survive contact with real users

• Do not ask an open question in the opening message. "How can I help?" hands the visitor a blank page, and a meaningful share of them will type something outside your scope, producing a failure on the very first turn.
• Do not ask for an email before you have answered anything. You have given the visitor nothing yet, so the request reads as a toll gate. Ask after the bot has been useful, and give a reason.
• Write the scope line from your actual inbox, not from your sitemap. The three things you name should be the three questions your team answers most often this month.

10 chatbot welcome message examples by industry

Same formula, ten different scopes. The brand names are placeholders. What varies between these is not tone, it is what the bot admits it cannot do, which is usually the line that makes the script honest.

1. Ecommerce store

Hi, I'm the Northwind bot. I can check order status,
explain returns and help with sizing.

[Where is my order?]  [Start a return]  [Sizing help]

Order status is the highest-volume question in retail by a distance, so it goes first and gets its own button. Note that the bot promises to "check" status, which is a promise you can only make if it is genuinely wired to your order data. If it is not, say "explain how tracking works" instead.

2. SaaS product

Hi, I'm the Lattice docs bot. I answer from our
documentation and pricing pages and link the source
for every answer.

[How does pricing work?]  [Set up SSO]  [API rate limits]

For account-specific issues, type "support".

Technical audiences trust a bot more when it tells them where the answer came from, and less when it claims to know things it cannot. Splitting "documentation" from "account-specific" up front prevents the most common SaaS bot failure, which is confidently guessing about one customer's particular configuration.

3. Professional services firm

Hi, I'm the assistant for Hale & Cross. I can explain
our services, how we charge, and how to book an intro
call. I can't advise on your specific situation.

[What do you charge?]  [Book a 20-minute call]  [Areas we cover]

For a law, accounting or consulting firm the disclaimer is the most important sentence in the script, and it belongs in the welcome message rather than buried in a footer. It also does commercial work: it makes the intro call the obvious next step.

4. Real estate

Hi, I'm the bot for the Vance Property team. I can answer
questions on current listings, viewings and the buying
process in [area].

[Book a viewing]  [What's available under [price]?]  [Talk to an agent]

Naming the geography stops the bot fielding questions about markets you do not cover. Property enquiries are time sensitive, so the agent handoff earns a button rather than a footnote. There is more on this flow in the real estate chatbot guide.

5. Healthcare clinic, front desk only

Hi, I'm the Fern Street Clinic bot. I can help with
opening hours, booking, which insurers we accept and
prescription renewals. I can't give medical advice or
look at your records.

If this is an emergency, call your local emergency number now.

[Book an appointment]  [Opening hours]  [Insurance we accept]

The emergency line goes above the buttons, not below, because it is the only message on the screen that could matter urgently. Be careful here: a general chatbot platform, ours included, is not a place to handle patient records or protected health information. matram.ai does not sign a BAA and makes no HIPAA claim, so a script like this one is deliberately limited to logistics.

6. Home services, trades and repair

Hi, this is the Redwood Heating bot. I can tell you if we
cover your postcode, give a ballpark on common jobs and
book an engineer visit.

Emergency, no heat or a leak? Call [number], we answer 24/7.

[Do you cover my area?]  [Boiler service price]  [Book a visit]

Coverage area first, because an out-of-area visitor is not a lead and both of you save time finding out in one turn. Trades traffic skews toward genuine emergencies at 11pm, which is exactly when nobody is watching the chat, so the phone number is unconditional.

7. Education and course providers

Hi, I'm the course bot for Meridian College. I can answer
questions on entry requirements, fees, funding and
deadlines for [year] entry.

[Entry requirements]  [Fees and funding]  [Application deadline]

Pinning the intake year prevents the single most damaging error in this sector, which is answering a prospective student with last cycle's deadline. If your bot reads from your website, this is also a reminder to delete or date-stamp the old cycle's pages.

8. Restaurants and hospitality

Hi, I'm the bot for The Copper Kettle. I can help with
bookings, the menu, allergens and parking.

[Book a table]  [See the menu]  [Allergen info]

Groups of 10 or more, I'll put you through to the team.

Allergens deserve a button and a caution. Publish the allergen matrix as a page the bot can read verbatim and cite, and route anything phrased as a personal medical question to a human. This is a case where getting an answer approximately right is worse than not answering.

9. Insurance broker or agency

Hi, I'm the Ashby Insurance bot. I can explain what our
policies cover, what documents you'll need and how to
start a claim. I can't quote a price or change a policy,
an adviser does that.

[What's covered?]  [Start a claim]  [Speak to an adviser]

The two things a bot must never do in insurance are quote and bind, so the script says so in the greeting rather than discovering it three turns later. Claims get a button because someone starting a claim is having a bad day and should not have to hunt.

10. Nonprofit or membership organisation

Hi, I'm the bot for the Riverside Trust. I can answer
questions on membership, donations, volunteering and
what's on this month.

[Join or renew]  [Volunteer]  [What's on]

Membership renewals and volunteer sign-ups are the two highest-value actions and both are administrative, which makes them ideal bot work. Donations should link to your existing payment page rather than being handled in the chat.

Bad versus good chatbot script lines

Every line below is one we have read in a real widget. The pattern in all seven is the same: the weak version optimises for how the company wants to sound, and the strong version optimises for what the visitor has to do next.

Rather than trusting anyone's claimed uplift for lines like these, measure your own. The two numbers worth watching are the share of conversations that end on turn one and the share that reach a resolution or a handoff, both readable from your transcripts within a week. There is a fuller checklist in our chatbot best practices guide.

When the script is not what you are missing

Almost everybody who lands on a page like this believes the wording is the problem. Sometimes it is. More often the script is the last thing you should be touching, and these stages run from obvious to genuinely arguable.

Stage one: nobody is typing anything

The widget has been live for weeks and the whole transcript log fits on one screen. No amount of rewriting rescues this, because scripting is optimisation and you have nothing yet to optimise. Check whether the widget is genuinely visible on the pages people land on, and whether those pages get any traffic worth speaking of. Both of those are layout and marketing problems wearing a copywriting costume. Come back to the wording when there is something to read.

Stage two: the script is fine and the content behind it is thin

People are typing, the greeting does its job, and the bot still fails. So read where it fails. If the failures cluster on questions your team can answer in a sentence but your site has never stated in writing, the fix is a page rather than a paragraph in a settings screen. This is the most common misdiagnosis on the whole topic. You can rewrite the welcome message every week and it still won't make the bot know your delivery cut-offs.

Stage three: you are writing answers into a tool that generates them

Here the work is not merely unnecessary, it is actively costly. Somebody opens the help centre and starts pasting canned answers into an AI chatbot, one question at a time. It works, briefly. Then a policy changes, and now there are two versions of it, one on your site and one buried in a vendor's configuration, and only one of them ever gets updated. Every hour spent that way is an hour of permanent maintenance you have quietly signed up for. The last section of this page covers what to write instead, and it is a far shorter list.

Stage four: genuinely borderline, and it depends on the sentence

But some wording really does have to be fixed word for word, and that is where this stops being simple. A regulated disclosure. A consent line. An insurance exclusion, or the exact phrasing somebody in compliance signed off. None of that should be composed fresh for each visitor, however good the model is. So a lot of real deployments end up mixed: generated answers for the open questions, immovable text for the few moments where the wording is the product. Nobody can draw that line for you. What you can do is list the sentences that would cause a problem if they came out slightly different, and treat that list as the only genuinely non-negotiable part of your script.

Lead qualification script examples

A qualification script is an interrogation unless you earn it first. The order that works is answer, then ask, then explain why you are asking. Three or four questions is the ceiling, one at a time, buttons wherever the answer set is fixed.

B2B software, demo request

Visitor: I'd like a demo.

Bot: Happy to set that up. Three quick questions so the
     right person calls you, takes about 20 seconds.

Bot: What are you trying to fix right now?
     (free text)

Bot: Roughly how many people would use it?
     [1-10]  [11-50]  [51-200]  [200+]

Bot: When would you want this live?
     [This month]  [This quarter]  [Just researching]

Bot: Thanks. What's the best email for the invite?

Bot: Booked. You'll get a calendar link within a minute.
     If nothing arrives, check spam or reply here.

Only the first question is free text, because it is the only one whose answer you cannot enumerate. "Just researching" is an explicit option on purpose: a visitor who tells you the truth about timing is more useful than one who picks the nearest lie and then ghosts your sales team.

Home services, quote request

Bot: I can get you a quote. Four things and I'll pass it
     to the team.

Bot: What's the job?
     [Boiler repair]  [New install]  [Annual service]  [Something else]

Bot: What's your postcode?
     (free text)

Bot: How soon do you need someone?
     [Today]  [This week]  [Flexible]

Bot: Best number to text the quote to?

Bot: Got it. [Name] covers your area and will text you
     before [time]. If it's urgent, call [number].

Phone number rather than email, because this audience converts on a text message. Note that the confirmation names a person and a deadline. A commitment you can actually keep is worth more than any amount of enthusiasm in the preceding lines.

Ecommerce, high-value or considered purchase

Visitor: Which model should I get?

Bot: Depends on two things. What are you using it for
     mostly?
     [Home]  [Studio]  [Touring]

Bot: And what's your budget?
     [Under 500]  [500-1200]  [1200+]

Bot: For studio use in that range, most people go with
     the [model]. Here's the spec page: [link]

Bot: Want me to send a side-by-side with the [alternative]?
     I'll need an email for that.

The email request arrives last, attached to something the visitor actually wants, and it is optional. That is the difference between lead capture and a wall. More on the flow in the lead generation chatbot guide and the ecommerce chatbot page.

The rules under all three

• Answer something useful before you ask for anything. Qualification is the second half of a conversation, not the first.
• One question per message. Two questions in one bubble reliably gets one answer.
• Buttons for anything with a fixed answer set, free text only where the answer is genuinely open.
• Say why you are asking, in five words. "So the right person calls you" is enough.
• Confirm with a specific commitment: who, by when, and what happens if it does not arrive.

Customer service and FAQ chatbot script examples

Service scripts are judged on the bad turns, not the good ones. Anyone can write the reply for a question the bot can answer. The four below are the ones that decide whether people come back.

Order status, when the bot has data

Visitor: where's my order

Bot: I can look that up. What's your order number?
     It's in your confirmation email, starts with #.

Visitor: #48213

Bot: Order #48213 shipped on 17 July and is due
     [date]. Tracking: [link]

Bot: Anything look wrong there?
     [It's late]  [Wrong address]  [All good, thanks]

The follow-up buttons matter. "It's late" is the point at which a service conversation becomes a retention conversation, and you want that path to exist rather than making an unhappy customer start again.

A policy question, answered from your content

Visitor: can I return something I bought on sale

Bot: Yes. Sale items can be returned within 14 days if
     unworn and tagged, though they're refunded as store
     credit rather than to your card.

     Source: Returns policy [link]

Bot: Want me to start a return?
     [Start a return]  [No thanks]

Two things make this work. The answer leads with yes or no before the conditions, and it links the page it came from so the customer can check rather than argue. If your bot cannot cite a source, that is worth fixing before you worry about tone.

The bot does not know

Bot: I couldn't find an answer to that in our help centre,
     and I'd rather say so than guess.

     I can send this to the team, or I can help with
     [topic A] or [topic B].

     [Send to the team]  [Ask something else]

Saying "I'd rather say so than guess" reads as competence rather than failure, and it is also true of any well-configured retrieval bot. What you must not do is fire this message twice in a row. The second consecutive failure should escalate automatically instead of asking again.

An angry message

Visitor: this is the third time I've asked. useless.

Bot: That's a fair reason to be annoyed, and I'm not the
     right thing to fix it. I'm putting you with a person
     now and sending them this conversation so you don't
     repeat yourself.

Bot: [Name] will reply here. If you'd rather not wait,
     leave an email and they'll come back to you.

No apology template, no "I understand your frustration", no attempt to answer. One acknowledgement, an immediate handoff, and an explicit promise that the transcript travels with them. Repeating themselves is the specific thing that makes an escalated customer angrier.

Escalation script examples and handoff rules

Escalation is two things: the rule that fires it and the sentence the visitor sees. Most teams write the sentence and never write the rule, which is why so many bots only hand off when somebody types the word "human".

Triggers worth configuring

• Any explicit request. "Human", "agent", "person", "representative", "speak to someone". No confirmation step, no "are you sure?".
• Two consecutive turns where the bot could not answer. One is a gap in your content, two is a bad experience.
• Money and account keywords: refund, cancel, chargeback, invoice, close my account, delete my data.
• Complaint and risk language: complaint, legal, lawyer, ombudsman, discrimination, injury, unsafe.
• Anything the bot is forbidden to do by policy, such as quoting, binding, prescribing or giving advice.
• Clear anger or repeated frustration, whether you detect it by sentiment or by a keyword list.

Handoff, agents available

Bot: Passing you to the team now. [Name] is on and
     usually replies within a few minutes. They can see
     everything above, so no need to repeat yourself.

Handoff, nobody is on

Bot: The team is offline right now. They're back at
     [time] on [day].

     Leave an email and I'll send them this conversation,
     or I can keep trying to answer here.

     [Leave my email]  [Keep going]

Handoff after the bot failed twice

Bot: I've missed that twice, so I'll stop guessing and
     get a person. Sending this over now, including what
     you already told me.

Handoff the bot has to refuse

Bot: I can't [cancel a policy / issue a refund / give
     medical advice], that has to be a person. I'm putting
     you through and flagging it as [reason] so it goes to
     the right desk.

Three rules govern all four. Never promise a response time you cannot hold, because a missed "within 5 minutes" damages more trust than an honest "within a day". Never make the visitor re-explain, which means the transcript has to travel with the handoff. And never make escalation a hidden feature: put the exit in the welcome message so the option is visible before anyone needs it.

On matram.ai the handoff lands in a shared team inbox with the conversation attached, and the transcripts feed the analytics and the daily email summary, so the questions that keep triggering escalation show up as a list rather than as a feeling. If your team lives in Slack, the Slack chatbot integration puts the same handoff in a channel.

What a bad script actually costs you

The sticker price of a bad script is nothing at all. It is words in a text box. Everything it costs you happens somewhere else.

Start with the part you never see. A visitor who gets told twice that the bot did not understand them does not complain, does not fill in a survey and does not email anybody. They close the tab. Maybe they call, maybe they go to a competitor, maybe they just stop being a customer quietly. There is no ticket for any of that. Your dashboard shows a conversation that ended, which looks identical to a conversation that ended well, and the only way to tell those two apart is to read the transcripts yourself. Most teams never do, which is why bad scripts survive for years.

Then it costs you the room. Support stops pointing people at the widget, because they know how it goes. Sales quietly drops it from the demo. Before long the chatbot is a thing that exists on the website and nobody owns, still billing, still answering badly, and nobody wants to be the person who reopens it. That's worse than never having launched. The next person who proposes automation in that company has to argue against a live example of it not working, and the example is sitting in the corner of every page.

And there is the work you did instead. A week spent building branches for questions nobody asks is a week not spent writing the handful of pages your team keeps retyping by hand. Those pages would have served your customers and your search traffic as well as the bot. So before you spend another day on wording, work out which of the two failures you are actually looking at: people not understanding your bot, or your bot having nothing worth saying. The second one is a content problem, and no script fixes it. Which brings us to the awkward part.

On an AI chatbot, you do not script the answers

This is the part that reframes everything above, and it is the genuine insight for anyone who arrived here searching for scripts.

A script is a predefined path. Anthropic's engineering write-up on building effective agents draws exactly this line between systems where "LLMs and tools are orchestrated through predefined code paths" and systems where the model directs its own process. A rule-based chatbot is entirely the former: every sentence it can say exists in its configuration before anyone opens the widget, which is why writing those sentences is the whole build.

A retrieval-based AI chatbot works the other way. It searches your content for passages relevant to the question, hands them to a language model, and the model composes an answer that did not exist until somebody asked. There is no branch to write, no keyword list, no fallback tree. If you spend a week writing five hundred FAQ answers into a tool like that, you have done the wrong work, and worse, you now maintain those answers in two places. The rule-based versus AI chatbot comparison goes deeper on the architectural difference.

What replaces scripting

Curating the source material. The bot's answer quality is a direct function of what it can read, so the work moves from writing dialogue to auditing content. Practically: find the questions your team answers repeatedly, check whether the answer exists anywhere the bot can reach, and write the page where it does not. That page then serves your customers, your search traffic and your bot at the same time, which is a better return than a decision tree nobody outside the widget will ever read.

What you still write, and it matters more than before

• The welcome message. The formula at the top of this page applies unchanged, because the opening is fixed text on every platform. It is also the only place you can set expectations about scope.
• The starter prompts. Two or three suggested questions that steer people toward what your content actually covers, which is the cheapest way to reduce failed first turns.
• Tone and boundary instructions. Not answers, but rules: how formal to be, what to never claim, when to say "I don't know", whether to answer at all outside your source material.
• The escalation rules from the section above. Handoff is a business decision and no model should be inventing it.
• Lead capture fields and the qualifying questions, which stay deterministic because you need consistent data out the other end.
• The fallback line for genuine gaps, which you will rewrite once you have read a week of real transcripts.

That is a short list, and getting it right takes an afternoon rather than a month. On matram.ai you write the welcome message, point the bot at your site, sitemap, documents or connected sources such as Notion, Google Drive or Zendesk, decide whether strict mode confines it to that material, and set when it hands off. Answers are cited to the page they came from, so when one is wrong you fix a page rather than hunt for a branch.

One honest caveat about cost. Scripted bots are cheap to run and expensive to maintain, while AI answers are generated per conversation and priced accordingly across the market. Fin, for example, publishes $0.99 per resolution with a fifty-outcome monthly minimum, which is a usage model rather than a licence. Flat monthly pricing like ours trades that variability for a message cap, and which suits you depends on volume rather than on anything either of us can tell you in the abstract.

Frequently asked questions

Sources

• Anthropic, "Building effective agents" (19 December 2024) - The definition of a workflow as a system where "LLMs and tools are orchestrated through predefined code paths", used to frame what a chatbot script actually is and why generated answers are not scripted.
• Fin pricing page (read 20 July 2026) - Per-outcome pricing of $0.99 per resolution with a 50-outcome monthly minimum, cited as an example of usage-based AI answer pricing versus flat monthly plans.