AI Chatbot Conversation Design

Updated September 15, 2026 · AI-assisted guide. Sources and illustrative examples are identified below.

TL;DR: Good chatbot conversation design helps a visitor understand an answer, complete a task, or reach a person. Use a clear bot identity, short relevant replies, focused questions, honest uncertainty, and accurate action confirmations. Evaluate the complete interaction, including mistakes and exits.

---

Editorial update: This guide replaces unsupported claims about human-sounding chat increasing trust and sales. Sample dialogue below is illustrative. It does not describe a customer conversation or a measured DOYJO project.

Start with the visitor’s task

Choose a real reason someone would open the chat. They may want to know whether you serve their area, whether a product fits their needs, or how to contact the right team. Write the outcome in the visitor’s words before defining the assistant’s personality.

For an illustrative local service business, the job could be: “Find out whether this company handles my type of project and how to request an estimate.” The conversation should answer that job with as little unnecessary work as possible. Requiring a name and email before answering a published service question may obstruct it.

Map a short successful path and the likely detours. What if the location is unclear? What if the requested service is unavailable? What if the visitor changes their mind or asks for a person? These branches are part of the design, not rare exceptions to leave until after launch.

Introduce the assistant accurately

An opening message should identify the assistant and describe a useful scope. “I’m the website’s AI assistant. I can help with published services, pricing information, and contact options” sets a clear expectation. Add an accessible route to staff when the business provides one.

Avoid giving the bot a job title that suggests a licensed professional or a human employee. A friendly name can be appropriate when the interface still makes the AI identity clear. The visitor should not have to infer that identity from a footer after sharing information.

Match the opening to actual capabilities. If there is no live transfer, do not offer “Chat with our team now.” If the bot can link to a calendar but cannot inspect it, say it can help find the booking page. This consistency between words and behavior is more useful than an elaborate persona.

Answer first, then ask the next useful question

For a direct question, start with the relevant answer. Give the qualification or source the visitor needs, then offer one practical next step. A pricing question should not trigger several paragraphs about the benefits of AI before revealing the published starting price.

Ask a follow-up only when the answer changes what you can do next. “Is this for a new website or an existing website?” can help route an implementation inquiry. Asking about company size, annual revenue, phone number, budget, and deadlines all at once makes a simple exchange feel like a long form.

Use the vocabulary your customers use. Explain a technical term when it affects their choice. A visitor asking about a missed appointment usually needs a clear contact route, not an explanation of the integration architecture.

Build a complete conversation example

The following hypothetical exchange shows a modest assistant helping with an estimate request. The service policy is invented solely to illustrate the design; it is not a statement about AI Curdy or DOYJO’s services.

Visitor: Do you repair old windows?
Assistant: The published service list includes window repair. The team needs to review the condition before confirming a repair. Is this for a home or a commercial building?

Visitor: A house. Can you give me a price?
Assistant: There is no fixed window-repair price on the service page. You can request an estimate and describe the damage. Would you like the estimate request link?

Visitor: Yes.
Assistant: Open the estimate request page to send the details. This chat has not submitted a request.

The assistant answers the initial question, narrows the request once, preserves the uncertainty around suitability and price, and states what happens next. It does not invent a quote or imply that the office has received anything.

Now test a variation: the visitor says “Actually, it is a storefront.” The assistant should update that detail and explain the relevant route. It should not force the visitor to restart simply because they corrected an earlier answer.

Use confirmations where they prevent meaningful errors

A helpful confirmation makes important information visible. It should also distinguish a proposed action from a completed one. “Send this request to the service team?” and “The service team received your request” refer to different states.

Google’s conversation-design guidance distinguishes confirming understood details from explicitly approving consequential actions. It also encourages allowing corrections within the conversation. See its guidance on confirmations. These are design principles; the page is not a recommendation to adopt the retired Conversational Actions product.

For a booking, show the service, date, time zone, location or meeting format, and any relevant conditions before asking for approval. After submission, report the actual result from the booking system. If the system cannot establish the result, state that uncertainty and give the next step.

Do not confirm every harmless detail. If a visitor chooses to read the services page, opening the correct link may provide enough feedback. Save explicit confirmation for the places where misunderstanding would create meaningful inconvenience or an unwanted commitment.

Make mistakes recoverable

Write recovery responses for different causes. Missing source information, an ambiguous question, and an unavailable external service require different answers. A universal “Sorry, I didn’t understand” conceals the problem and often sends the visitor into another unsuccessful attempt.

When information is missing, say what cannot be confirmed. When a request is ambiguous, ask one focused question. When a system is unavailable, explain the alternative route. Avoid claiming that a technical failure means the visitor entered something wrong.

If the same exchange fails repeatedly, offer an exit or human route. A person should not need to discover a special phrase to escape the bot. Preserve relevant details only when the receiving process actually supports them, and avoid claiming a handoff has occurred until it has.

Use a calm, direct tone for frustration. A brief acknowledgment followed by a useful option is often sufficient. Repeated apologies, jokes, or declarations that the bot understands someone’s feelings can distract from the unresolved task.

Personalize with context the visitor understands

Start with information the visitor deliberately provided in the current conversation. If they said they need help with an existing order, keep the next response on that task. Do not immediately pivot to an unrelated sales offer.

Page context can also be useful: an assistant opened on a specific service page can offer to explain that service. Keep assumptions visible and easy to correct. Someone reading a commercial-services page may be researching for another person or comparing options.

Persistent personalization needs deliberate choices about identity, access, storage, and visitor controls. A chatbot should not reveal a previous conversation or account detail merely because a browser appears familiar. Avoid manufactured scarcity, invented popularity statistics, or progress percentages that do not reflect a real process.

Design the controls alongside the words

Test opening, reading, typing, sending, following links, correcting details, and closing the chat with a keyboard. Check focus visibility, readable text, and the layout with zoom and a narrow screen. Offer descriptive link labels so visitors know where each next step leads.

If the widget is a modal dialog, W3C’s modal dialog pattern describes focus movement, keyboard navigation, closing behavior, and returning focus. A nonmodal panel needs behavior appropriate to its own design. Do not apply a modal label to a panel that behaves differently.

New messages should remain understandable to people using assistive technology. Test real conversations rather than checking only the empty widget. A well-written reply has limited value when the user cannot find it, reach its link, or dismiss the interface.

Evaluate the conversation as a whole

Review complete sessions against the intended task: Was the answer accurate? Did the assistant request unnecessary information? Could the visitor correct a misunderstanding? Was the handoff honest and usable? Record failures and unknown outcomes alongside successes.

Compare wording changes on representative tasks and include staff who understand the policies. If you measure conversion, keep visitor intent and traffic differences in mind; people who choose chat may already be more interested. More messages are not automatically better service.

For a Sheboygan business or a nationwide service company, DOYJO can help connect conversation design to the actual website and operating process through AI Curdy’s integration services. Bring a few recurring customer questions and the answers your team is comfortable standing behind.

Keep exploring

• Plan and test a useful chatbot
• Separate conversation activity from resolution
• Browse the practical AI guide collection

Have a conversation problem this guide should address? Send it to AI Curdy, with private customer details removed.