Chatbot Flow Design

A senior growth practitioner's playbook for designing conversational flows for website chatbots and AI agents. Intent recognition architecture, branching logic, fallback handling, escalation to human, conversation analytics. The discipline of building a bot that knows what it knows and routes appropriately when it does not.

Most chatbots on the web fail in one of two ways. Scripted bots break the moment a user phrases something the script did not anticipate; the user gets pushed through a decision tree that does not fit their situation. LLM-powered bots without structure hallucinate; they confidently answer questions about pricing, policy, or capabilities and frequently make up answers, creating support burden and trust damage.

The chatbots that work do something different. They have an intent architecture that defines what the bot can and cannot handle. They ground their responses in a knowledge base so they do not invent facts. They have explicit fallback paths for unclear or out-of-scope intents. They escalate to humans cleanly when the bot's job is done. The audience trusts the bot because the bot is honest about its scope.

The voice is the senior growth practitioner who has watched chatbots become trusted brand surfaces and watched them become liability risks. Practical, opinionated about the architecture that distinguishes the two outcomes, willing to call out when a chatbot is the wrong investment or when an existing chatbot needs to be redesigned rather than tuned.

When to use this skill: scoping a chatbot for the first time, auditing a chatbot that hallucinates or fails edge cases, designing the intent architecture and fallback patterns, or deciding when to escalate to humans.

What this skill covers

This skill spans chatbot design as conversational flow architecture, not chatbot implementation. The growth-tooling distinctions:

• ai-content-collaboration covers AI in content workflows. This skill covers AI in customer-facing conversations.
• integration-orchestrator covers cross-team coordination for chatbot deployment. This skill is the conversational design itself.
• pm-spec-writing covers the spec for engineers building the bot. This skill is about WHAT the conversation should be; pm-spec-writing is about communicating it.
• discovery-research-synthesis covers customer research that informs intent architecture. Input to this skill, not part of it.
• chatbot-flow-design (this skill) is intent architecture, knowledge-base grounding, fallback patterns, and escalation discipline.

The audience: growth marketers and product marketers shipping chatbot growth tooling, in-house teams designing conversational flows for marketing or support contexts, agencies running chatbot work for clients.

Out of scope: AI in content workflows (covered by ai-content-collaboration); the engineering implementation of chatbots (handed off via pm-spec-writing); platform-specific bot configurations (those stay implementation-side); voice agents and IVR flows (different methodology though related principles apply).

The chatbot decision: when chatbots earn deployment

Before designing the chatbot, decide whether a chatbot is the right tool.

Chatbots earn deployment when:

• The audience asks the same questions repeatedly. FAQ-style support, product capability questions, qualification routing. The bot handles the volume; humans handle the exceptions.
• The audience is on the site at hours when humans cannot respond. Coverage gap that the bot fills meaningfully.
• The bot can ground its answers in real knowledge (documentation, product specs, pricing pages). Without grounding, the bot's answers are at best generic and at worst fabricated.
• The team can maintain the bot. Chatbots decay; intents drift; knowledge bases need updating. Without maintenance commitment, the bot becomes stale liability.

Chatbots do NOT earn deployment when:

• The audience expects human conversation. Sales conversations, complex troubleshooting, sensitive topics often warrant human-first.
• The team cannot ground the bot in real knowledge. A bot without grounding either hallucinates or stays so generic it adds no value.
• The bot would replace working human channels. Replacing a high-quality sales chat with a low-quality bot degrades the experience.
• The audience is small enough that direct human conversation is more efficient.
• The team cannot maintain the bot. Stale bots produce wrong answers.

The decision is not "should we have a chatbot"; it is "is the chatbot the right tool for this specific audience and conversation."

Detail in references/chatbot-decision-criteria.md.

Scripted-bot vs hallucinating-bot vs structured-guided-conversation

The keystone framing.

Scripted-bot. Rigid decision tree. "Press 1 for X, 2 for Y." Fails the moment a user phrases something the script did not anticipate. The chatbot equivalent of an automated phone tree. Cost: the user's actual question goes unanswered; the bot pushes the user through paths that do not fit; the audience leaves with a worse experience than no bot.

Hallucinating-bot. LLM-powered with no structure. Will confidently answer questions about pricing, policy, capabilities, and frequently make up answers. Liability risk; trust-eroding; support burden when wrong answers reach customers. Cost: the bot's confident wrong answers damage the brand more than no bot would; the team learns about the hallucinations through customer complaints.

Structured-guided-conversation. LLM-powered with intent architecture, knowledge-base grounding, defined fallback paths, and explicit escalation to humans. The bot knows what it knows, knows what it does not, and routes appropriately. Cost: the design effort upfront is significant; the maintenance is real; the audience trusts the bot because the bot is honest about its scope.

The litmus test. Ask the bot a question outside its intended scope. Does it confidently make up an answer (hallucinating), refuse rigidly (scripted), or honestly route the user to a human or alternative resource (structured-guided)? The third response is the goal.

Intent architecture

Defining what the bot can and cannot handle.

The principle. The bot has a defined set of intents it can handle. Each intent maps to a conversation pattern (questions to ask, knowledge to ground in, response to provide). Anything outside the intent set falls to fallback.

Intent design patterns.

• Named intents. "Pricing question," "feature comparison," "integration question," "support escalation," "demo request." Each intent is explicit.
• Intent hierarchy. Top-level categories with sub-intents. "Pricing question" includes sub-intents for "tier comparison," "discount inquiry," "billing question."
• Intent boundaries. Each intent has clear scope. Out-of-scope topics route to fallback.

Intent coverage. The bot's intents should cover 70-90 percent of expected conversations. The remaining percentage falls to fallback. Trying to cover 100 percent often produces bloated intent sets that the bot cannot handle reliably.

Intent maintenance. Intents drift as products evolve, audiences shift, and conversations change. Periodic review surfaces which intents are useful and which need refining.

Detail in references/intent-architecture-patterns.md.

Knowledge-base grounding

The bot's responses must come from real knowledge, not made-up confidence.

The principle. The bot's response generation should reference a structured knowledge base (documentation, product specs, pricing pages, support articles). The bot does not invent answers; it retrieves and presents.

Grounding patterns.

• Retrieval-augmented generation (RAG). The bot searches a knowledge base for relevant content before generating a response. The response is groun