Every bot project we touch starts the same way: a founder with a Figma file, a Slack thread, and three competing opinions about what the bot should say first. The chatbot flow diagram is the document that ends that argument. Once it exists, scope stops drifting and engineers can build.
This guide covers the node types we use, the mistakes we see on most drafts, and a template our US team pastes into every new project. By the end you will have a chatbot flow diagram that survives a real launch, not a pretty picture that rots in a shared drive.

What a chatbot flow diagram actually is

A chatbot flow diagram maps the paths a user can take inside a conversation. Each box is a state: a bot message, a user input, a system action, or a handoff. Each arrow is a rule that moves the conversation from one state to the next. Miro, Lucidchart, FigJam, Whimsical, and Botmock all work; the tool matters less than the discipline.
A good chatbot flow diagram answers three questions at a glance: where does the conversation start, what happens when the user goes off-script, and when does a human take over. If the diagram cannot answer those three, it is a mood board, not a spec.

The six node types you actually need

1. Entry node — greeting, channel-aware (SMS vs web widget)
2. Intent node — the user said something; the bot classifies it
3. Bot message node — what the bot says back, including buttons or quick replies
4. System action node — API call, CRM lookup, payment step
5. Decision node — a branch based on a slot value or a flag
6. Handoff node — escalates to a human with full transcript attached

Most chatbot flow diagram drafts we inherit have 15 node types. That is a sign the author was thinking in tool icons, not behavior. Collapse everything to the six above and the diagram gets readable.

How to structure the diagram itself

Top to bottom, not left to right

Conversations scroll vertically on a phone. Your diagram should too. Top-to-bottom flow lets a product manager read it the way a user experiences it.

One happy path in bold

Highlight the shortest successful path from entry to outcome. Everything else is an edge case. On a finished chatbot flow diagram, the happy path should be visible from five feet away.

Global fallbacks on the side

Do not redraw “I didn’t understand, try again” under every node. Draw it once on the right margin with a dashed arrow pointing back to the current state. Keeps the canvas clean.

Color code by system vs conversation

We use navy for bot messages, orange for API or system actions, and light grey for user utterances. QA loves it because they can scan for missing API calls in one pass.

Five mistakes we see on every first draft

• No explicit handoff. The bot says “I’ll connect you” and the diagram just ends. Where does the ticket go?
• No fallback budget. Real users mistype and rage-click. The diagram should say how many retries before handoff. Usually two is right.
• Buttons and free-text mixed without rules. Either the node is buttons-only or the node is free-text with NLU. Picking both creates silent bugs.
• Zero error branches for API calls. Stripe went down. Now what? Draw it.
• Tone drift. The first node says “Hey!” and node 47 says “We apologize for the inconvenience.” Pin a voice rule to the diagram header.

The template we paste into every new project

Our default chatbot flow diagram has four swim lanes: User, Bot, System, Human Agent. The entry node sits at the top of the Bot lane. The happy path drops straight down. Escalations jump right into the Human Agent lane. API calls jump left into the System lane. Fallback loops stay pinned to the far right as a single shared state.
With that scaffolding, the first pass of any new chatbot flow diagram takes 90 minutes. We review it with the client on a Zoom call, mark every branch that triggers a payment or a legal disclaimer, and sign it before a single line of code is written. That signature is the contract.

From diagram to shipped product

A chatbot flow diagram is not the end product. It is the brief. Once signed, it maps one-to-one to Dialogflow intents, Voiceflow blocks, or a custom stack on Node and OpenAI. We version the diagram in the same repo as the code so a senior reviewer can trace a bug from a user transcript back to the node that owns it.
If your team is still sketching on a whiteboard, take the six node types, the four swim lanes, and the vertical layout above, and you will save yourself a round of scope creep. A good chatbot flow diagram is boring. That is the point.