Chatbot Workflow: Map Questions, Actions, and Human Handoffs

A chatbot workflow is the map of how a user's message travels through your system: from intent detection through actions, fallbacks, and escalation to a human. Getting the map right before you build saves significant rework. Tools like fenbs keep the approved flow decisions, unresolved edge cases, and follow-up improvements together — outside any one conversation or session.

Most chatbot failures happen at the edges: the question the bot cannot answer, the action that half-completes, or the moment the user expects a human and gets another automated response. Designing the handoff first, then working backwards to the automated steps, produces a more reliable result.

What a chatbot workflow covers

A chatbot workflow has four main components: intents (what the user might want), entities (the specific details in the message), actions (what the bot does in response), and escalation paths (what happens when the bot cannot handle the request). Every bot needs all four, even a simple one.

A fifth component matters more than it often gets: the handoff to a human. A bot that fails silently or loops the user through the same unhelpful response destroys trust faster than a bot that says "I can't help with that, let me connect you to someone who can." Design the handoff before designing the happy path.

How to map the conversation flow

Start with the three to five most common requests your users actually make — not the ones you expect. If you have an existing support channel, look at the last hundred tickets or chats and group them by topic. Those groups become your initial intents.

1. List each intent and give it a plain-English label: "check order status", "request a refund", "ask about shipping times".
2. For each intent, list the entities you need: for "check order status", you need an order number and possibly an email address.
3. Define the action: what does the bot actually do? Query a database, send an email, look up an FAQ, or say "I don't know"?
4. Define the success case and the failure case. What does the user see when the action works? What happens when it does not?
5. For the failure case, decide whether the bot tries again, asks for clarification, or hands off to a human. Write that decision down before you build it.

Defining actions and integrations

Actions are where most chatbots become more complex than expected. Looking up an order status requires an API call to your order management system, authentication, error handling, and a clear response format. Each integration point is a dependency that can fail independently.

For each action, document: the system it calls, the data it sends, the response it expects, and how it handles errors. A bot that shows a raw API error message to a user has a workflow design problem, not an API problem. The multi-agent workflow guide covers how to structure more complex action chains.

Human handoff design

A human handoff happens when the bot cannot or should not handle the request. The most common triggers are: the intent is not recognized after two attempts, the request involves sensitive personal data, the user explicitly asks for a human, or the action produces an error that the bot cannot resolve.

When designing a handoff, define: where the user goes (live chat, email, a ticketing system), what context travels with them (the conversation history, any entities already collected), and what the human receives so they do not ask the user to repeat everything. A handoff that makes the user start over is nearly as frustrating as a bot that never transfers at all.

fenbs keeps the approved handoff rules as Decisions and rules. If your team decides that any request involving a payment dispute must go to a human, recording that rule means every assistant and every developer building the next version of the bot starts from the same policy.

Testing the flow end to end

Test each intent with real user phrasing, not the phrasing you used when training the model. Users ask for the same thing in dozens of different ways. Test the failure cases deliberately: send an unrecognized intent, provide malformed input, and trigger the handoff path intentionally.

Log every conversation in development and review the failures together. Failures cluster around two problems: missing intents and broken actions. Missing intents are fixed by expanding training data. Broken actions are fixed by improving integration error handling or simplifying the action.

Recording decisions and follow-up improvements

Chatbot design produces a stream of decisions: which intents to cover first, which actions to build, what the handoff threshold is, which edge cases to punt to a human indefinitely. Those decisions tend to live in a design doc that goes stale or a series of meeting notes that are hard to find.

When a decision changes — say, you add a new intent after launch — it is worth recording what changed and why. The next developer who inherits the bot needs to understand why the flow is the way it is, not just what it does. See workflow automation tools for a broader look at the tools that connect chatbots to the rest of your stack.

How to manage chatbot workflow decisions with fenbs

1. Create a free account and add a project for the chatbot you are designing.
2. Add the approved intents and their definitions as tasks. Put the action description and success criteria in the plan field.
3. Record handoff thresholds, tone rules, and integration constraints as Decisions and rules.
4. Connect your AI assistant over MCP from Integrations. Ask it to read the project rules before suggesting changes to the flow.
5. After launch, add follow-up improvements as Enhancement tasks. Record the reason each change was made so the history is available for the next review.

For a broader look at how AI assistants fit into business conversations, see AI chatbot for business. For iterative workflow improvement, see agentic workflows.