AI Inbox

Designing a bot flow

A bot is not a personality, it is a set of decisions: what it asks first, when it goes and looks something up, when it is allowed to act, and — the one that matters most — when it stops and brings in a person. This is where those decisions get made, and tested before a customer meets them.

  • Define what the bot asks, looks up and does
  • Set the point where it stops and hands over
  • Run a conversation through the flow before it ships
  • Owned by the people who run it, not only who built it

Watch the full tour

Verify your work email once and every research paper, case study and product tour on ascendo.ai opens, right here, without leaving the page.

  • Takes about 30 seconds
  • Work email only, no spam

Bots fail on the boundaries, not in the middle

Almost every bot handles the case it was designed for. What decides whether customers tolerate it is everything else: the request nearly but not quite in scope, the customer who answers a question with something unexpected.

Those are design decisions and they usually go undesigned, because the happy path is what gets demonstrated. The other half is ownership: the flow is built during a project by people who move on, and the team who live with it cannot change what it does.

Three cards: the happy path specified carefully because it is what gets demonstrated, the boundary cases left to whatever the model does, and a flow nobody on the team afterwards can change.
The middle card is where customers actually meet the bot, and it is the one nobody wrote a specification for.

What a flow actually specifies

Four decisions. The last one is the one customers judge you on.

  1. Step 1

    What it asks first

    The opening question shapes everything after it. Asking for the wrong thing first is how a conversation turns into an interrogation.

  2. Step 2

    When it looks something up

    The point at which the bot goes to the knowledge base or the customer record, instead of asking for things the system already knows.

  3. Step 3

    When it is allowed to act

    What the bot can do on its own as distinct from what it can answer, set per issue type the same way autonomy is set everywhere else.

  4. Step 4

    When it stops

    The condition that hands the conversation to a person, and what travels with it. The most important line in the flow, and the least specified.

Four decisions a bot flow specifies: what it asks first, when it looks something up instead of asking, when it is allowed to act rather than answer, and the condition on which it stops.
Only the last of these four fires when things are going badly, which is why it is the one customers experience.

Three things that separate a designed bot from a deployed one

All three are about what happens outside the path somebody demonstrated.

The handover is the design

A bot that answers well and hands over badly is worse than no bot, because it has spent the customer’s patience and then made them start over.

Behaviour is configured, not coded

The people who should own bot behaviour are the ones reading the conversations, and they are usually not the ones able to change it.

Test it before customers do

A flow can be run against a conversation before it reaches a customer, which is the only responsible way to find the edges. The alternative is finding them by upsetting somebody.

A bot flow configuration listing the opening question, lookup points, permitted actions and the stopping condition, alongside a test run showing what the flow does on an out-of-scope conversation.
The last row is a test run against a request that is nearly in scope — the case a demonstration never includes.

Why the usual approaches fall short

Too rigid, too loose, or nobody can change it afterwards.

A decision tree

Deterministic and rigid. It falls over on anything phrased outside the branches somebody predicted.

A bot with no defined flow at all

Fluent, unpredictable and impossible to reason about. You cannot tell anyone what it will do.

Escalating on a keyword

Uses “speak to a human” as the only exit, and misses every customer who is stuck but polite.

Configuring it once at launch

Fits the products and the queue as they were on day one, and nobody afterwards can move it.

Two columns comparing a decision tree, a bot with no defined flow, escalating on a keyword and configuring once at launch with a flow whose boundaries are specified and changeable.
Escalating on “speak to a human” misses every customer who is stuck but polite, and those are the ones you never hear from again.

What things are called

Containment in particular is worth defining carefully before anyone reports on it.

Flow
The path a bot follows: what it asks, what it looks up, what it does, when it stops.
Handover condition
The rule that ends the bot conversation and brings a person in.
Containment
The share of conversations resolved without a person — only meaningful if the customer actually got their answer.
Fallback
What happens when the bot cannot proceed, which should be a handover rather than a loop.
Autonomy level
Whether the bot answers, drafts for approval, or acts — set per issue type.

Frequently Asked Questions

The team who read the conversations after launch, not only the people who built it during the project. Bot behaviour needs to change as products and queues move, and that is impractical if every change is a development request.

Where this fits

Multiple AI bots tour

Running several bots with different behaviour over one shared knowledge foundation.

Bot to human handoff

The stopping condition in practice, and exactly what carries across to the agent.

Levels of autonomy

How much a bot is permitted to do, set per issue type rather than once for everything.

More AI Inbox tours

All tours

AI Inbox

Design the exit before the entrance

Bring us the conversations your current bot gets wrong. The handover is usually where the problem is, and it is normally the fastest thing to fix.

Talk to us