Designing a Chatbot: The Complete 7-Step Method (2026)

“Designing a chatbot” and “building a chatbot” are two different jobs, and the second almost always fails when the first was rushed. Design is when you decide what your conversational assistant must achieve, for whom, on which channel, with what level of intelligence and under which limits. It is a job of framing, writing and arithmetic on your real demand, not a job of code.

The topic has never been more current: according to Insee, the French national statistics institute (TIC 2025 survey, Insee Première no. 2120, July 2026, published in French only), 18% of French companies with 10 or more employees used at least one artificial intelligence technology in 2025, up from 10% in 2024, and 43% of AI-using companies report using generative AI for text or speech. The chatbot is the most visible gateway to this adoption, and it is also the one where design mistakes show the most.

This guide is the complete method: the framing decisions, the three technical levels, the 7 design steps, a worked example from start to finish, a tool to decide your own framing, and the specification section by section. If you are looking for how to technically build the bot once it is designed, our how to develop a chatbot guide takes over where this one stops.

Designing a chatbot: what this stage actually covers

Concretely, design covers four families of decisions:

• the functional scope: which requests the bot handles, and above all which ones it does not;
• the conversational experience: the paths, the tone, the personality, the escalation formulas toward a human;
• the knowledge: where the answers come from (hand-written rules, your own content, free generation);
• the guardrails: transparency about the bot’s nature, personal data, forbidden topics, drift indicators.

The international standard ISO 9241-210:2019 (“Ergonomics of human-system interaction, Part 210: Human-centred design for interactive systems”, 2nd edition) sums up the spirit of the exercise: an interactive system is designed from an explicit understanding of the users, their tasks and their context, not from the capabilities of the technology. Applied to chatbots, this principle cuts short the market’s number one mistake: starting from “we want a bot with AI” and ending up with an assistant that impresses in the demo and solves nothing in production.

The 4 decisions that frame every chatbot design

Before drawing a single conversation path, four decisions commit everything else. Each one is made with a reference number, otherwise it will be made again later, at a higher cost.

A useful landmark for decision no. 1: Botnation’s FAQ product page describes the most frequent use case (making an FAQ conversational), which remains the best first chatbot project: bounded scope, content already written, fast ROI.

Three technical levels, three different designs

The technical level is not an implementation detail: it changes what you design. Here is what each level requires at design time.

In customer production, level 2 is where serious projects concentrate today: it combines the AI’s freedom of phrasing with grounding in your content. Our RAG chatbot article details how this architecture works, what it really costs and where it breaks. Level 3, for its part, must be designed with all the more guardrails as it can assert false statements with confidence: it is an experimentation choice, not a default choice.

The 7-step design method

Here is the method we apply on our own projects, from framing to the test set. Each step produces a written deliverable: that is what distinguishes a design from a brainstorm.

1. Frame the mission and its indicatorsOne mission sentence and two or three quantified indicators, set before everything else.
2. Map the real demandMine tickets, emails, FAQs and internal searches to prioritize what the bot must handle.
3. Draw the conversation pathsThe trees, the emergency exits and the route to a human.
4. Write the personality and toneA one-page editorial charter for the bot: form of address, length, humor, no-go areas.
5. Set the legal and safety guardrailsTransparency, personal data, forbidden topics, human validation.
6. Build the test set and testThe trap questions written in advance, the acceptance criteria.
7. Measure, feed, iterateThe knowledge base is a living organism, not a frozen deliverable.

Step 1: frame the mission and its success indicators

The mission is written in one sentence with an action verb and a beneficiary. Then you set at most two or three indicators, each with a starting value and a target: resolution rate without human intervention, average response time, share of demand absorbed, satisfaction score (CSAT) at the end of the conversation. The ISO 9241-210 standard quoted above applies here word for word: start from the users and their tasks, not from the technology.

Why indicators from step 1? Because a chatbot without success criteria can neither succeed nor fail: it will exist, consume credits and maintenance time, and nobody will be able to say whether it is useful. This is also what lets you cut the scope: any request that serves no indicator is out of version 1.

Step 2: map the real demand

Design feeds on data, not impressions. Before writing a single answer, capture the actual demand volume over three months from your existing sources: support tickets, shared mailboxes, chat transcripts if you have any, questions typed into the internal search engine, sales team requests.

Then classify each request by frequency (how many times per month) and by criticality (what happens if the answer is late or wrong). This crossing gives the bot’s prioritization matrix: frequent and simple requests go into version 1; rare and complex requests stay with humans, with a clean escalation; frequent but sensitive requests (complaints, health topics, legal matters) go into version 1 with an immediate route to a human.

Two symmetrical pitfalls to avoid: the “catalog” bot that tries to handle everything and handles nothing well, and the “showcase” bot that only handles three decorative questions. The demand map keeps both away, because it anchors every scenario in a real volume.

Step 3: draw the conversation paths

A conversation path is drawn like a flowchart: an entry intent (what the user wants), information collection steps, decision points, and endings. Two golden rules:

• limit the depth: beyond three or four menu levels, users drop off; if a path needs more, what it needs is a free-form information capture (one open question), not menus;
• every path has an exit: a complete answer, a transfer to a human, or a callback promise; never a dead end.

Escalation to a human is a path in its own right: design its trigger (keyword, repeated dissatisfaction, explicit request), its schedule (what happens at 10 p.m.?) and its waiting message. Our article on how chatbots work shows what happens between the message and the reply: understanding this mechanics prevents designing paths the engine will hold poorly.

To start faster, Botnation’s template gallery exposes more than 150 ready-to-use chatbot templates (real estate, restaurants, lead qualification…): picking a template does not replace design, but it provides proven paths to adapt rather than a blank page.

Step 4: write the personality and tone

The bot’s personality is a one-page document, not an intuition. It sets: the form of address, the target answer length (usually one to three sentences), the familiarity level (bot first name or not, humor yes/no/for which brands), the forbidden formulations (promises, medical or legal opinions, off-grid prices) and the apology and recovery formulas after a misunderstanding.

This charter matters even more with a generative AI bot: it feeds the system prompt and keeps the voice consistent between hand-written answers and the ones the model phrases. A bot that alternates between a notary’s tone and an influencer’s loses trust faster than a bot that makes a factual mistake.

Step 5: set the legal and safety guardrails

Three parts, to be designed before development:

• transparency: announce the automated nature of the chatbot and, when an answer is generated by AI, do not pass it off as a human text. Article 50 of Regulation (EU) 2024/1689, applicable since August 2, 2026, makes this an obligation for providers and deployers; the penalties provided by the Regulation show this is not a cosmetic detail;
• personal data: the chatbot will collect data (at minimum messages, often an email or an order number). CNIL, in its “Chatbots” sheet of February 19, 2021 (published in French only), recalls the applicable principles: defined purpose, data minimization, set retention period, informing individuals. Design what the bot does not ask for: it is the best GDPR there is;
• topic limits: black list of subjects where the bot apologizes and transfers (health, law, personal finance, serious complaints), and for an internal bot, vigilance over HR data.

For an internal chatbot, the works council must moreover be informed of the introduction of a new digital tool within the scope of its consultative duties: our article on the employee support chatbot details this step nobody mentions.

Step 6: build the test set and test

The test set is written from the step 2 mapping: the 30 to 60 most frequent real questions, declined into variants (typos, synonyms, casual phrasing, two-step questions). Add the trap questions: the out-of-scope question, the sensitive question, the malicious question, the question in a foreign language.

Acceptance testing happens in two rounds: internal testing (project members try to break the bot), then external testing with five to ten people who did not work on the design: they ask the questions nobody planned. For each attempt you note: the answer obtained, the path followed, the need for escalation, and you compare against the indicators set in step 1.

Step 7: measure, feed, iterate

An unattended chatbot degrades: content ages, new questions arrive, intents drift. Design must therefore plan its own maintenance from the start: a monthly review of unresolved conversations, a workflow to add a question-answer pair within minutes, a named owner (a person, not a committee).

This is also where the knowledge base becomes an asset: every unresolved question is information about your customers that nobody ever told you this clearly. The questions the bot fails to handle feed the next version of the specification.

A complete example: designing a customer service chatbot for an e-commerce retailer

Which design framing fits your project?

Five questions are enough to settle the dominant framing of your project. Check the situation closest to yours in each group: the verdict panel shows the framing to favor, with its design deliverables. In case of a tie, the tool keeps the lightest framing: it is always the right starting point.

The design specification, section by section

The specification is design’s final deliverable: once this document is signed, development or configuration can start, in-house or with a provider. Eight sections are enough, in this order:

1. Context and mission: the original quantified problem, the mission sentence, the explicit scope of requests handled and not handled in version 1.
2. Audience and channels: the personas (consumer customer, employee, prospect), the target channels with their format constraints.
3. Demand mapping: the frequency x criticality table from step 2, with the starting volumes.
4. Conversation paths: the trees or scripts of the selected paths, with their exits and the escalation path.
5. Knowledge and AI level: the sources that will feed the bot, their owner, their update frequency, and the target technical level (rules, content, generation).
6. Personality and tone: the bot’s editorial charter (one page).
7. Guardrails and compliance: disclosure of the automated nature, data collected and retention periods, forbidden topics, escalation and human validation workflow.
8. Indicators and acceptance: the step 1 targets, the test set, the production go-live criteria and the maintenance plan (monthly review, named owner).

Our how to develop a chatbot article offers an interactive specification generator that writes these sections from your answers: handy to get a first draft to rework.

Who designs the chatbot: in autonomy or accompanied?

Two routes exist, and they do not oppose each other. The autonomous route: your team designs and builds on a no-code platform, with the subscription grid as the only cost known in advance. The accompanied route: chatbot creation experts design and build the bot with you, typically within an accompanied offer like Entreprise, on quote.

Botnation holds both: the company publishes the no-code platform and builds custom chatbots for its clients through its Entreprise offer (on quote). The benefit of the second route is continuity: the team designing your bot is the one publishing the tool it runs on, so there is no middleman between the specification and the delivery; after delivery, the account, the scenarios and the knowledge base remain under your name in the editor. A third-party agency remains perfectly legitimate when a highly specialized craft, an on-site engagement or an integrator already in place calls for it: what matters is that the design specification stays written and signed on both sides.

Here is the platform’s public grid, captured on September 10, 2026 on the pricing page (prices shown in euros, excl. tax, when opened from the European Union):

AI credits consumed beyond the allowances are bought in packs: 1,000 credits at 25 €, 5,000 at 100 €, 15,000 at 250 €, 60,000 at 900 € (same September 10, 2026 figures, excl. tax), and a user beyond the plan’s quota costs 0.05 € per month. The cost of a custom accompanied build, for its part, is quoted only on request: any range circulating without commitment is not worth a signature.

The 5 design mistakes that cost the most

We devote a full article to chatbot creation mistakes; here are the ones that play out precisely at the design stage, where they are the most expensive to repair.

The common point of these five mistakes: they are invisible on launch day and get paid for during the first month of operation. This is why the method above puts indicators at step 1 and guardrails at step 5, before any development.

FAQ on designing a chatbot

Conclusion: designing means deciding before building

A successful chatbot is first a well-designed chatbot: a one-sentence mission, indicators set before the first answer, paths with exits, a written tone, guardrails laid before launch and a named maintenance plan. The technical part, for its own, has never been so accessible: the choice now plays out between autonomy on a no-code platform and a custom build accompanied by a team of experts, and the two routes can follow each other on the same project.