CHATBOT SCENARIOS
Answer in the window, hand off to a person
A scenario is a drawing, not a script. You place the blocks, connect them, and the engine walks them one inbound message at a time — inside four bounds that are the difference between an automatic answer and an automatic invoice.
Most of what a business is asked on WhatsApp is asked over and over: where are you, what does it cost, is it still available, can somebody call me. A scenario answers those in the seconds after they are asked, and steps aside the moment the question is a real one.
The blocks you draw with
Six of them, and each one does a single thing.
Send a message
One message, with the values you typed or the ones the conversation has already collected. It is metered like any other outbound message.
Ask a question
Sends a question and then parks. The scenario does not resume until the customer answers, so it cannot spin while nobody is talking. The answer is stored in a variable you name.
Branch on the answer
Conditions read a variable and take the first matching branch. Keywords match whole words rather than substrings, so an answer of no does not match a message containing nothing.
Wait
Pauses for a stated time before the next block. It is for pacing across minutes, never for a natural typing pause, and it is bounded so it can never park a conversation past the point where a free-text reply is still allowed.
Set a value
Writes a variable from another variable or a fixed string, so a later message can greet somebody by the name they just gave you.
Hand off to a person
Ends the scenario on that conversation and leaves it to whoever is in the inbox. A handed-off thread is never re-entered by the bot, which is the whole point of the block.
The four bounds
A drawn loop is a bill, not a hang, so each one is a real limit in the engine.
Four sends in one turn
One inbound message can produce at most four outbound messages. Without it a badly drawn branch answers a single hello with a monologue, and every line of it is charged.
Twenty-four steps in one turn
Conditions and connections are free, so this is the bound on a loop that sends nothing. It stops a scenario spinning inside a single turn.
Forty sends in one run
A cycle through a drawn graph is legitimate — a menu that returns to itself is a cycle. This is the bound on how far one conversation can take it.
A six-hour ceiling on a wait
A wait that outlived the window would park a conversation whose next message the transport refuses, which reads to a customer as the scenario simply stopping.
Why a crash cannot send twice
The order of two database writes is the whole answer.
Charging for a message is not an action that can be undone, and a scenario runs on a server that is replaced on every deploy. So the engine moves the cursor off a block before that block sends, and the move is a claim rather than a write: it only succeeds if the cursor is still where this run believes it is.
The consequence is chosen rather than tolerated. If the process dies between the claim and the send, the message is lost. If it died the other way round, the customer would get the same message twice and be charged for it twice. Silence is the safe direction; a duplicate is not.
Two runs cannot start on one conversation either. A run holds a short lease, and a second run arriving while that lease is live is refused rather than queued — which matters because the transport delivers a batch of messages in one webhook and retries land on whichever server answers first.
A scenario is checked before it can go live
A bound that fires has already sent forty messages.
Draw it
Saving is always allowed, on every plan, so a half-finished scenario is never lost. Nothing is live until you switch it on.
It is validated on the way in
A scenario is refused activation if it has no start, more than one, a connection pointing at a block that is gone, a question with nothing after it, a condition with no branches, or a loop that sends without ever waiting for a person. A question with nothing connected after it is the shape somebody draws by accident: the customer is asked something, answers, and the business has stopped talking mid-sentence.
Watch what it actually did
Every run writes a transcript — which branch a condition took, which variable was empty, why a block declined. That is the only place those facts exist: a customer reading their own WhatsApp thread cannot see them, and neither can you without it.
What it will not do
Said here rather than discovered later.
- It does not write with a language model. The AI block was withdrawn from the toolbox and the engine refuses it, so no scenario can put generated words in front of your customers today.
- It does not reach a customer first. A scenario answers inbound messages. Reaching somebody who has not written to you is a template send, which is a different page and a different approval.
- It is not a reason to stop reading your inbox. Every scenario has a hand-off block for exactly that reason, and the inbox shows which messages the bot sent so a colleague is never guessing.
Where it sits
Team inbox
Where a handed-off conversation lands, and who it lands with.
Message templates
What a scenario can send once the free-text window has closed.
Pricing
One subscription per connected number. The bot is part of a plan, not a seat.