Multi-stage flows: people do not answer in order, and they walk away

Flows are usually drawn as a line. Ask the first thing, get the answer, ask the second thing. Drawn that way they look obviously correct, and then they meet people, who answer three questions at once, change their minds about the second one while answering the fourth, disappear for a day and come back mid-sentence.

A messaging conversation is not a form. It has no submit button, no fixed order, no guarantee the same person is typing, and no end. Designing for that rather than against it is most of the difference between a flow that works and one that produces a lot of stuck conversations nobody is watching.

What we'll cover

• Why a chat is not a form
• What state actually has to hold
• People answer out of order
• Changing an earlier answer
• Building it with CodeWords
• Abandonment, which is the normal ending
• Coming back, hours or days later
• Timeouts, and what should expire
• Knowing where somebody is
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

Why a chat is not a form

Four differences, each with consequences.

No submit. A form is either completed or not. A conversation is always partly complete, so partly complete has to be a state you can look at.

No fixed order. The question you asked third may already have been answered in the first message.

No captive attention. The customer is doing something else. Minutes or days pass between messages and nothing is wrong.

No guaranteed identity. The same number may be a different person, especially on a household handset.

The practical upshot is that the flow has to be resumable at every point, tolerant of answers arriving early, and willing to end without completing.

What state actually has to hold

More than the answers, and the extras are what make resumption possible.

What has been asked and what has been answered, kept separately so you know which questions are outstanding.

When each answer arrived. A price quoted a fortnight ago may no longer hold.

Confidence in each answer. Something inferred from an ambiguous message is not the same as something explicitly confirmed.

What has been told to the customer, which matters when somebody returns and you must not contradict yourself.

Anything already acted on. Whether a slot was provisionally held, a part ordered, a person notified. These are the expensive ones.

Whether a person is involved, so nothing automated sends over the top of them.

That last item prevents the single worst failure in this whole area: an automated flow continuing while a colleague is mid-conversation with the same customer.

People answer out of order

Somebody messages "hi can you fix a Bosch dishwasher, I'm in Leeds, any time Thursday". That is three of your six questions answered before the flow started.

Two rules. Extract everything present in each message rather than only the field currently being requested. And never ask for something you already have, which is the most common complaint about automated flows and the easiest to avoid.

Equally, somebody may answer a question you have not asked yet, or supply something unprompted halfway through. Store it, acknowledge it briefly, and skip that step when you reach it.

The end state to aim for is a checklist being filled from any direction rather than a queue being worked through in order.

Changing an earlier answer

"Actually, make it Friday." This will happen constantly and it is the thing linear flows handle worst.

Three requirements. The flow must be able to revise a field already captured without restarting. It must recompute what depends on it, since changing a date may invalidate an offered slot. And it must confirm the change explicitly, because this is exactly where misunderstanding becomes a wasted visit.

Be careful with anything already acted on. If a slot was held, changing the date means releasing it. If a part was ordered, that is no longer a flow decision and it needs a person. Knowing which changes are free and which have consequences is a design question worth answering before building.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: the things you need to know, what makes each one valid, what happens when somebody changes an earlier answer, and what ends the flow.
3. Authorize the connections to your calendar, wherever jobs or enquiries are recorded, and your WhatsApp Business Platform account.
4. Describe the exceptions: an abandoned conversation, a person taking over, a customer answering several questions at once, a request the flow does not cover.
5. Test the partial paths rather than the complete one, because the flow that runs straight through is the one case that always works.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Abandonment, which is the normal ending

A meaningful share of conversations stop partway. That is not a malfunction, it is what people do, and the question is what you make of it.

Keep the partial. Half an enquiry is still an enquiry, and it is frequently enough to follow up on properly.

Notice where they stop. A flow that loses people at the same question has a problem with that question, and the pattern is visible within a fortnight.

Distinguish stalled from declined. Somebody who stopped after being given a price has told you something different from somebody who stopped after being asked for a postcode.

Follow up once, referencing what they said. Generic nudges perform badly; "you mentioned a Bosch dishwasher in Leeds, shall I find you a slot?" performs well.

Then stop. One follow-up, occasionally two. A third is a message to somebody who has already decided.

Coming back, hours or days later

Somebody returns after three days and says "yes". Yes to what?

Handle it explicitly rather than hoping. Restate what you had, briefly, and confirm before proceeding. "Picking this back up: a Bosch dishwasher in Leeds, not draining, and you wanted Thursday. Is that still right?" That one line removes the whole class of error where a stale conversation is resumed against changed facts.

Two supporting decisions. Anything time-sensitive should expire rather than persist, particularly prices and held slots. And returning after a long gap should default to starting again, gracefully, rather than resuming a conversation whose context has gone.

Timeouts, and what should expire

Different things have different useful lives, and one global timeout gets all of them wrong.

A held slot should release quickly, because holding capacity for somebody who has gone costs real money.

A quoted price should expire on a stated timescale, which you should say when you quote it.

Collected details can persist much longer, since a postcode does not go stale.

The conversational thread should lapse within hours rather than days, so a new message starts fresh rather than continuing something half-remembered.

Say what expires and when, in the message. "This slot is held for two hours" is information a customer can act on, and it converts better than silence.

Knowing where somebody is

For anything with more than a few steps, tell people where they are. Not a progress bar, just orientation: "two more things and we are done".

It reduces abandonment because the main reason people stop is not knowing how much more there is. It also sets an expectation you then have to keep, so do not say two more things and ask six.

Say at the start what you need, roughly. "I need your postcode, the model, and when you can be in" lets somebody supply all three at once, which is faster for them and for you, and it is the single change that most improves completion.

Making it survive

Store partials, and make them visible to somebody.

Never re-ask what you already have.

Confirm on resumption, always.

Expire slots and prices, and say when you do.

Watch the drop-off point for each flow, and fix the question rather than the flow.

Limits worth knowing about

People will not follow a designed path, and a flow that requires them to is a flow that fails.

Long flows abandon more, so the number of questions is a design decision rather than a wish list.

A phone number is not a person, and resumption may be a different human.

Some conversations need a person early, and detecting that beats completing the flow.

Stored partials are personal data, with the same retention obligations as everything else.

What to build first

Resumption. Make every flow able to stop at any point, hold what it has, and pick up with a restatement and a confirmation. Everything else here is an improvement on top of that; without it, every interruption becomes either a lost enquiry or a wrong assumption.

Two habits make the difference. Extract everything from each message rather than only the field you asked for, because being asked for something you already gave is the fastest way to make automation feel stupid. And test the abandoned and resumed paths rather than the clean run, since the clean run always works and nobody's conversation looks like it.

Frequently asked questions

Why do linear flows break?

Because a conversation has no submit button, no fixed order, no captive attention and no guaranteed identity. People answer several questions at once, change earlier answers, and leave partway through.

What does the flow need to remember?

What was asked and answered separately, when each answer arrived, how confident each is, what the customer has been told, anything already acted on, and whether a person is involved.

What if someone answers a question I have not asked?

Store it, acknowledge it briefly, and skip that step when you reach it. Never ask for something you already have.

How should a changed answer be handled?

Revise the field without restarting, recompute anything that depends on it, and confirm the change explicitly. Where something was already acted on, such as an ordered part, that needs a person.

Is abandonment a failure?

No, it is the normal ending for a share of conversations. Keep the partial, notice where people stop, distinguish stalled from declined, and follow up once referencing what they actually said.

What happens when somebody comes back days later?

Restate what you had and confirm before proceeding. Anything time-sensitive should have expired, and a very long gap should default to starting again gracefully.

What should expire, and when?

Held slots quickly, quoted prices on a stated timescale, the conversational thread within hours. Collected details such as a postcode can persist. One global timeout gets all of them wrong.

Should customers be told where they are in a flow?

Yes, briefly. Saying what you need at the start lets people supply it all at once, and it is the single change that most improves completion.

How many questions is too many?

However many causes your drop-off. Watch where people stop, and treat the question as the problem rather than the flow.

What should be tested?

The partial and resumed paths. The clean run through always works, and no real conversation looks like it.

Related reading

• What a bot should remember
• The edge cases that actually matter
• Payments inside a conversation