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

A multi-stage WhatsApp conversation flow must hold state, accept answers in any order, allow earlier answers to change, and survive abandonment. Teams usually draw a flow as a line: ask the first thing, get the answer, ask the second thing. Real people answer three questions at once, change the second answer while answering the fourth, and disappear for a day.

A messaging conversation is not a form. It has no submit button, no fixed order, no guarantee that the same person is typing, and no end. Designing for those facts is most of the difference between a flow that works and one that leaves stuck conversations nobody watches.

What we'll cover

• Why a chat is not a form
• What state has to hold
• People answer out of order
• Changing an earlier answer
• Building it with CodeWords
• Abandonment is the normal ending
• Coming back, hours or days later
• Timeouts, and what should expire
• Telling people where they are
• Keeping flows working
• Limits worth knowing about
• What to build first
• Frequently asked questions

Key takeaways

• A flow must be resumable at every point, because a conversation is always partly complete.
• Extract every answer present in each message, and never ask for something the customer already gave.
• When a customer changes an earlier answer, revise the field, recompute what depends on it, and confirm the change.
• Abandonment is a normal ending: keep the partial enquiry, find where people stop, and follow up once.
• Give held slots, quoted prices and the conversation thread different expiry times.

Why a chat is not a form

A chat differs from a form in four ways, and each difference has consequences.

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

No fixed order. The customer may have answered the question you asked third 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 can belong to a different person, especially on a household handset.

The flow therefore has to be resumable at every point, tolerant of answers that arrive early, and willing to end without completing.

What state has to hold

Flow state has to hold more than the answers. The extra items 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 the customer explicitly confirmed.
• What you told the customer. This matters when somebody returns and you must not contradict yourself.
• Anything already acted on, such as a provisionally held slot, an ordered part or a notified person. These are the expensive items.
• Whether a person is involved, so nothing automated sends over the top of them.

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

People answer out of order

People answer questions in any order, so the flow must extract every answer in each message. Suppose somebody messages "hi can you fix a Bosch dishwasher, I'm in Leeds, any time Thursday". That message answers three of your six questions before the flow starts.

Follow two rules. First, extract everything present in each message, not only the field you are currently asking about. Second, never ask for something you already have. Re-asking is the most common complaint about automated flows and the easiest to avoid.

Customers also answer questions you have not asked yet, or supply details unprompted halfway through. Store the detail, acknowledge it briefly, and skip that step when you reach it. Aim for a checklist filled from any direction, not a queue worked through in order.

Changing an earlier answer

A good flow lets a customer change an earlier answer, such as "Actually, make it Friday." This happens constantly, and linear flows handle it worst. The flow needs three abilities:

1. Revise a captured field without restarting.
2. Recompute what depends on the field. Changing a date can invalidate an offered slot.
3. Confirm the change explicitly. This is where misunderstanding becomes a wasted visit.

Be careful with anything already acted on. If the flow held a slot, changing the date means releasing it. If someone ordered a part, the change is no longer a flow decision and needs a person. Decide before you build which changes are free and which have consequences.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations (CodeWords pricing page, 2026), and you make each connection once and reuse it. To build a multi-stage flow:

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 answer valid, what happens when somebody changes an earlier answer, and what ends the flow.
3. Authorize the connections to your calendar, wherever you record jobs or enquiries, and your WhatsApp Business Platform account.
4. Describe the exceptions: an abandoned conversation, a person taking over, a customer answering several questions at once, and a request the flow does not cover.
5. Test the partial paths instead of the complete one. The flow that runs straight through is the one case that always works.

You describe the outcome, and Cody builds it, connects it and deploys it. The Free plan costs $0, Pro costs $39 per month and Business costs $100 per month (CodeWords pricing page, 2026). Details are on the pricing page.

Abandonment is the normal ending

Abandonment is the normal ending for a share of conversations. People stop partway, and that is not a malfunction. Make use of the stop in four ways:

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

Notice where people 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, and reference what they said. Generic nudges perform badly. "You mentioned a Bosch dishwasher in Leeds, shall I find you a slot?" performs well.

Then stop. Send one follow-up, or occasionally two. A third message goes to somebody who has already decided.

Coming back, hours or days later

When a customer returns after days and says "yes", the flow must restate what it had and confirm before proceeding. Handle this explicitly. For example: "Picking this back up: a Bosch dishwasher in Leeds, not draining, and you wanted Thursday. Is that still right?" That one line removes the class of error where the flow resumes a stale conversation against changed facts.

Two supporting decisions apply. First, let anything time-sensitive expire, particularly prices and held slots. Second, default to starting again, gracefully, after a long gap, instead of resuming a conversation whose context has gone.

Timeouts, and what should expire

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

Item	How long it should last
Held slot	Release quickly, because holding capacity for somebody who has gone costs real money
Quoted price	Expire on a stated timescale, which you say when you quote
Collected details	Keep much longer, because a postcode does not go stale
Conversational thread	Lapse within hours, so a new message starts fresh

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.

Telling people where they are

For any flow with more than a few steps, tell people where they are. You do not need a progress bar. A line of orientation is enough, such as "two more things and we are done".

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

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

Keeping flows working

Flows keep working when you store partials, confirm on resumption and fix questions instead of flows.

Store partials, and make them visible to a person.

Never re-ask what you already have.

Confirm on resumption, every time.

Expire slots and prices, and say when you do.

Watch the drop-off point for each flow, and fix the question instead of the flow.

Limits worth knowing about

Multi-stage flows have five limits.

People will not follow a designed path. A flow that requires them to fails.

Long flows lose more people, so the number of questions is a design decision, not a wish list.

A phone number is not a person. The person who resumes may be a different human.

Some conversations need a person early. Detecting that beats completing the flow.

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

What to build first

Build resumption first. 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 improves on that. Without resumption, every interruption becomes a lost enquiry or a wrong assumption.

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

Frequently asked questions

Why do linear flows break?

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, so a fixed line of questions fails.

What does the flow need to remember?

The flow needs to remember what was asked and answered, kept separately, when each answer arrived, how confident each answer 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 the answer, acknowledge it briefly, and skip that step when you reach it. Never ask for something you already have, because re-asking is the most common complaint about automated flows.

How should a changed answer be handled?

Revise the field without restarting, recompute anything that depends on it, and confirm the change explicitly. If the flow already acted on the old answer, for example by ordering a part, a person needs to handle the change.

Is abandonment a failure?

No. Abandonment is the normal ending for a share of conversations. Keep the partial enquiry, notice where people stop, distinguish stalled from declined, and follow up once with a reference to what the customer said.

What happens when somebody comes back days later?

Restate what you had and confirm before proceeding. Anything time-sensitive should have expired, and after a very long gap the flow should start again gracefully.

What should expire, and when?

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

Should customers be told where they are in a flow?

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

How many questions are too many?

The right number is the one that does not raise drop-off. Watch where people stop, and treat the question at that point as the problem, not the flow.

What should I test?

Test the partial and resumed paths. The clean run 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