Chatbot Conversation Examples: Scripts & System Prompts

Most articles about chatbot conversation examples show you screenshots of someone else’s finished bot and call it a day. That’s not what this is. This is a library of the actual copy you type into the box — the welcome line, the clarifying question, the refusal, the handoff — plus the design decisions that make those lines work together instead of fighting each other. Every script here is written for a self-hosted deployment, where you own the system prompt and the knowledge base instead of renting a black box. If you want finished bots rather than the copy inside them, the showcase of AI chatbot examples is the right page — this one is for the words underneath them.

Why Conversation Design Matters

A chatbot is not a feature. It is a script. Every line a visitor reads — the greeting, the question, the answer, the apology when it doesn’t know — is copy a human wrote, edited, or forgot to write and left on the default. Teams spend weeks on the widget’s accent color and two minutes on what it actually says. That’s backwards. Visitors remember whether the bot understood them on the first try, or looped them through three vague questions before admitting it couldn’t help.

Old decision-tree bots used a fixed menu of buttons and a hard wall the moment a visitor phrased something unexpected. Real questions don’t arrive pre-sorted into menu items. An LLM-backed bot can meet a question directly, but only if the copy behind it — persona, scope, tone, failure behavior — was deliberately written. An LLM with no conversation design is a decision tree with better small talk and worse predictability.

Self-hosting changes the economics here. In a vendor’s hosted config, you edit through their UI, inside their constraints, with no diff history. Because it’s a plain-text field in your own admin panel, you can draft it, put it in version control alongside the rest of your infrastructure, and roll back a bad edit in seconds. AI Chat Agent’s System Prompt field is exactly that: one free-text box, 10,000 characters, no template lock-in. The rest of this post is what to put in it.

Six Conversation-Design Principles

Before the scripts, the rules that make them work. All six collapse into paragraphs inside one system prompt — there’s no separate panel for “persona” or “scope.” You write them, or the bot improvises them, badly.

1. Multi-turn context. A visitor’s second message should be read in light of their first. “What about pricing” after a message about onboarding is a different question than the same words asked cold. Treat the conversation as a continuous thread, not isolated queries.

2. One question per turn. Bots that ask three clarifying questions at once overwhelm someone typing on a phone. Ask one thing, wait, then ask the next.

3. Clarify before answering. When a request is ambiguous, resist the pull toward a generic, hedge-everything answer. One specific question beats a paragraph that covers every interpretation and satisfies none.

4. Consistent persona. Decide once whether the bot is formal or casual, whether it uses the visitor’s name or emoji — and lock it into the prompt so it doesn’t drift mid-conversation depending on the last retrieved chunk.

5. Explicit scope. State what the bot is for, and what it isn’t. A support bot that improvises opinions on unrelated topics because nobody told it not to is a liability.

6. Graceful failure. The bot will hit questions it can’t answer. Plan for it — the principle most teams skip, covered below.

None of these live in separate toggles — they’re paragraphs. Write them as instructions to a competent new hire, not marketing copy: the model reads the prompt the same way every conversation, so vague guidance produces inconsistent behavior across hundreds of chats.

Welcome and Greeting Chatbot Conversation Script Examples

The welcome message is the one line every visitor sees, so it earns outsized attention relative to its length. It’s a single field capped at 500 characters, with “Hi! How can I help you?” as the default — functional, but generic enough to say nothing about what the bot is actually good at. Pair it with up to four suggested questions (quick replies), 200 characters each, rendered as clickable buttons under the bubble of your website chat widget. Clicking one sends it as if typed — the fastest way to show scope without making anyone type first.

Support widget:

Hi, I’m the [Product] support assistant. Ask me about setup, billing, or troubleshooting — I can also pull up your order status if you give me an order number.

Suggested questions: “How do I reset my password”, “Where is my order”, “How do I cancel my subscription”, “Talk to a person”

SaaS onboarding widget:

Welcome! I can walk you through setup, explain any feature, or connect you with the team if you’re stuck. What are you working on today?

E-commerce widget — one of the more common website chatbot examples, since order status drives most of the traffic:

Hey! Looking for a product, checking an order, or have a question about shipping and returns? I’ve got you.

Agency / white-label widget:

Hello — I’m here to answer questions about our services and pricing, or get you booked in for a call. What would you like to know?

Each of these bot message examples does two jobs at once: states scope and primes the first click. A welcome that just says “Hi! How can I help?” wastes the one guaranteed impression you get before a visitor decides whether typing is worth the effort.

Routing and Qualifying Chatbot Conversation Examples

This is the biggest gap in most other articles: nobody shows the actual back-and-forth. A single good message in isolation says nothing about whether a bot can hold a thread. Here’s a realistic exchange — vague opener, clarifying question, routed answer — the shape a well-designed system prompt produces on its own, without scripting each branch by hand.

Visitor: hey does this work for my business
Bot: Happy to check. What kind of business are you running, and what would you want the bot to handle?
Visitor: online store, mostly people asking where their order is
Bot: That’s a common use case. The bot can look up order status if you connect your order data, and answer shipping questions from your FAQ pages. Do you already have a shipping policy page I could point it at?
Visitor: yeah we have one
Bot: Good — add that page as a knowledge source and I’ll answer from it directly, with a link back. Want me to walk you through adding a source, or do you have a different question first?

One question per turn, each answer narrowing the next, and the final message routes toward a concrete action instead of “let me know if you need anything else.” That’s a chatbot questions examples pattern worth stealing directly into your own prompt: if the request is ambiguous, ask one clarifying question before answering.

Visitor: it’s not working
Bot: Sorry to hear that. Trouble logging in, or does something break after you’re signed in?
Visitor: cant log in
Bot: Got it. Do you see an error message, or does the page just not respond?
Visitor: says invalid password but im sure its right
Bot: That usually means a typo or a stale saved password in your browser. Try resetting from the login page — I can walk you through it, or connect you with a person about your account.

Both exchanges narrow from a vague signal to a specific answer in two or three turns — never more than one open question at a time, never a wall of possibilities dumped on the visitor at once.

Knowledge-Grounded Answer Script Examples

This is where a chat bot example usually gets vague, because most writeups don’t distinguish a generic LLM answer from a grounded one. Same question, two answers below. Without a knowledge base, a general-purpose LLM answers from training-data patterns:

Most SaaS products offer a 14-day free trial, though some offer 30 days. I’d recommend checking the pricing page for exact details, as this can vary by plan.

That’s a hedge dressed up as an answer — not wrong, just not about your product. With a knowledge base behind it, the retrieval pipeline finds your actual pricing page, and the model answers from the retrieved chunk instead of a guess:

Trials are 14 days on all plans, no credit card required to start. Full details are on our [Pricing] page — I pulled this from there if you want to double-check.

The mechanics: a query rewrite cleans up the phrasing, hybrid search (dense embeddings plus lexical matching, merged by reciprocal rank fusion) pulls candidate chunks from your indexed pages, and an LLM reranker judges which candidates actually answer the question before the model sees them. Neighboring chunks get pulled in too, so an answer split across two paragraphs doesn’t cut off mid-thought. If your source content isn’t structured well for this, how to build a knowledge base for your chatbot covers page length, heading structure, and what to index.

Answers also carry per-page source attribution, so a visitor — or you, reviewing transcripts later — can see which page the bot pulled from. That traceability is most of what separates “grounded” from “plausible.” For why retrieval quality determines whether a customer service chatbot example is trustworthy, see how RAG grounds a support chatbot in your documentation.

Worth being precise: there’s no dial that makes the bot “more careful” here, no similarity-threshold slider. The gate is the reranker itself: it finds chunks worth answering from, or decides nothing is relevant — that refusal path is its own script, covered next.

What the Bot Says When It Does Not Know

This is the single most neglected script in every chatbot deployment, and the moment visitors remember longest, because it’s where trust is made or broken. Two ways to get it wrong, one way to get it right.

Bad refusal #1 — confident hallucination, because nothing told the model not to guess:

Sure! Most companies in your situation offer a 30-day money-back guarantee, so you should be covered.

Bad refusal #2 — the dead end, technically honest but useless:

I cannot help with that.

Good refusal — honest about the gap, and it still moves the visitor forward:

I don’t have information about that in what I’ve been given to work with. I don’t want to guess and give you something wrong — if you’d like, I can connect you with a person who’ll know for sure.

Here’s the part that’s genuinely underappreciated: there is no field in the admin panel where you type that refusal sentence. It isn’t configurable text. Greetings skip retrieval entirely — a “hello” never triggers a no-match notice — and for anything that does go through retrieval, two instructions get appended to your prompt at runtime: one when relevant chunks were found (answer from these, cite the source), one when the reranker decides nothing is relevant (say you don’t have that information, offer a human handoff if configured, don’t answer from general knowledge). The model writes the refusal itself, live, in the visitor’s language.

You can’t type the exact wording. What you can shape, through your own prompt, is tone and behavior: always offer a next step rather than a dead end, name the phrasing to avoid, and set how apologetic or brisk the tone should be. The three lines above are the target you’re writing toward, not literal strings you paste in.

Escalation and Human-Handoff Wording

Two escalation paths exist, and conflating them in your copy will confuse visitors. The prior question — when a human should take the conversation at all — is worth settling before you write either script.

The first is an operator taking over mid-chat — effectively invisible: no “you’re now talking to a human” banner, no operator name. Replies appear under the bot’s own name and avatar. Your persona has to survive the handoff seamlessly — if the bot has been warm and casual and an operator jumps in cold and clipped, visitors notice the shift even without a label announcing what happened. Write the persona with that in mind, and brief operators to match it. If nobody picks up, the widget falls back to a fixed line after 30 minutes: “Operator is unavailable. Please try again later.” That copy isn’t yours to edit.

The second path is the optional “Talk to a human” button, with its own configurable banner (200 characters). Clicking it opens a pre-filled email in the visitor’s own mail client — not a server-side notification. Write the banner honestly:

Prefer to talk to a person? Click below and it’ll open an email to our team — we typically reply within one business day.

Don’t write “connect you instantly” for this button — it opens a mail client, not a live channel. For higher-touch B2B support, operator chat for B2B support goes deeper into designing that flow well.

Lead-Capture Messaging

Lead capture is deliberately narrow: name, email, and phone — no custom fields, no dropdowns. Field labels come from the widget’s built-in i18n and aren’t yours to rewrite, but consent checkbox text is (500 characters, with a privacy-policy link), and timing is your call: pre-chat, before any conversation starts, or mid-chat, firing automatically after the fifth bot message.

That’s a real friction trade-off. Pre-chat gets more emails per visitor who starts typing, but a form in front of a question is a wall — some visitors never start. Mid-chat lets the visitor get value first, but by message five some have already gotten their answer and see no reason to hand over an email. There’s no universally right choice; it depends on whether the bot is your primary lead-gen surface or a support convenience. Tools built around gated lead playbooks, like Drift, push you toward pre-chat by default; owning the widget means the trade-off stays yours to make.

Pre-chat, framed as access rather than a form:

Quick intro before we start — who am I speaking with? This helps me follow up if we get disconnected.

Mid-chat, framed as a natural next step after the bot has already been useful:

Want me to send you a summary of this, or have someone from the team follow up? Just need your email.

Neither says “please fill out the form below” or leads with field labels. The copy earns the ask by stating what the visitor gets, not just what you want from them.

Closing, Feedback, and Rating Prompts

A rating prompt can be enabled to ask how the conversation went, and it auto-triggers when a visitor sends a thank-you-style message after at least two of their own turns — a natural closing signal, so the rating fires right then instead of an artificial “before you go” moment. Those scores are the cheapest signal you have on whether chat is actually improving satisfaction.

Glad that helped! Mind rating this conversation? It helps us improve.

For a conversation that ended in a refusal or an escalation rather than a resolved answer, don’t reuse the same cheerful line — among chatbot feedback examples, tone-deaf enthusiasm after a bad outcome is the fastest way to lose the rating entirely:

Sorry I couldn’t fully resolve this one. If a rating feels fair, I’d appreciate it — either way, someone from the team will follow up.

One practical cap worth designing around: the per-session message limit defaults to 15 (zero disables it). Hit it and the visitor sees a fixed “Message limit reached for this conversation” with the input disabled. If your use case is naturally chatty — multi-step troubleshooting, product walkthroughs — raise the limit or route faster, because that message isn’t one you can soften with better copy.

Assembling It Into One System Prompt

Every script above is a paragraph. Here’s how they fit into one sample chatbot system prompt — the payoff of this exercise. This is a complete, working example for a SaaS support bot; adapt the placeholders and trim what doesn’t apply. It fits comfortably inside the 10,000-character limit with room for product-specific detail. If you have not configured a bot before, the basic setup walkthrough covers where each field lives.

You are the support assistant for [Product Name], a [one-line description].

PERSONA
Warm, direct, professional tone. Plain sentences, no corporate jargon, no exclamation-point enthusiasm. Refer to the visitor as “you.” No emoji.

SCOPE
You help with: account setup, billing, troubleshooting, and general product questions. No legal, medical, or financial advice, and no detailed discussion of competitors. If asked about something outside this scope, say so plainly and redirect.

CONVERSATION STYLE
Treat the conversation as one continuous thread — use earlier messages to interpret later ones. Ask at most one clarifying question per turn. When a request is ambiguous, ask a specific question rather than giving a broad answer that hedges every interpretation. Keep answers to two or three sentences unless asked for more detail.

GROUNDING
When you have relevant information retrieved for a question, answer from it directly and mention which page it came from. Do not pad grounded answers with generic advice absent from the source.

WHEN YOU DON’T KNOW
If you can’t answer confidently, say so plainly. Do not guess or answer from general knowledge on topics specific to [Product Name]. Offer a human handoff instead of a dead end. Never say only “I cannot help with that” — pair a refusal with a next step.

ESCALATION
If a visitor asks to speak to a person, or you’ve been unable to help after a couple of exchanges, offer the handoff clearly and stop forcing an automated answer.

LEAD CAPTURE
If a visitor asks for a follow-up, ask for their email naturally as part of the conversation, not as an announced form.

BOUNDARIES
Never claim to have taken an action you can’t verify, such as “I’ve refunded that.” If a request needs account changes you can’t make, say so and offer the human handoff.

That’s the whole thing — one field, no branching UI. The server appends its own retrieval and lead-extraction instructions underneath automatically, so you’re only responsible for persona, scope, tone, and failure behavior. The welcome message and suggested questions from earlier live in separate, smaller fields — this prompt is the connective tissue that keeps them consistent.

Multi-Language Gotchas

The widget interface ships in English and Russian, roughly 22 strings, with language detection following a clear order: a data-lang attribute on the embed script, then the host page’s html lang attribute, then browser language, then English as the fallback.

The gotcha: anything you author yourself — welcome message, suggested questions, placeholder, consent text — always overrides the locale table. A Russian visitor on a page defaulting to Russian will still see your English welcome message unless you wrote a Russian one. The widget doesn’t auto-translate custom copy; a bilingual audience needs both versions configured explicitly. The system prompt itself doesn’t need duplication — “always respond in the visitor’s language” handles the model’s own replies, but it won’t touch your authored strings.

Testing and Versioning Your Scripts

Treat the system prompt like code, because it functionally is: a single text artifact that determines behavior across every conversation the bot has. Keep it in git, not pasted into the admin panel with no history.

Build a fixed set of ten to twenty test questions before touching the prompt — clear ones, ambiguous ones that should trigger a clarifying question, one your knowledge base can’t answer, one that should trigger escalation. Run that list every time you edit the prompt, and read the transcripts rather than skim them. Watch for the refusal turning into a hallucination after you tightened the persona wording, the bot asking two questions in one turn after a new instruction conflicts with “one question per turn,” or the tone drifting because a new paragraph contradicts an earlier one.

This is also where the more than 1,600 automated tests behind the platform help indirectly — the retrieval pipeline, lead extraction, and rendering are exercised by that suite, so when your test conversations go wrong, the fault is almost certainly your prompt wording, not the underlying mechanics.

Good chatbot examples aren’t found in a showcase — they’re written, tested, and versioned like anything else shipped to production. Whether you write this prompt into a vendor’s hosted config or into infrastructure you own matters more than it sounds: a prompt locked on someone else’s Intercom or Chatbase plan means editing through their UI, on their terms, with no history. More conversation-design breakdowns live on the getagent.chat blog. AI Chat Agent is self-hosted, €79 one-time with no monthly fees, full source code, and the system prompt is yours to write, diff, and roll back like any other file. Try the live demo to see these scripts running in a real widget, or go straight to the €79 one-time checkout if you’re ready to write your own.

Frequently Asked Questions