How it works
Four mechanisms do nearly all the work: a reply lane that bulk sending can't block, a qualification engine that stores your questions as data, a single door every outbound message leaves through, and a takeover rule that gets out of your way automatically.
One
The first reply gets its own lane
A lead arrives as a contact — posted by your website form, your CRM, an inbound text, or anything else that can make an HTTP request. If you ask for a conversation to start, the first reply is enqueued immediately and dispatched in the background, so the response time you see from the API never depends on how quickly the carrier accepts the message.
That job runs on a dedicated high-priority queue. Everything bulk — the nurture ladder, scheduled follow-ups, anything sweeping across many contacts at once — runs on the default queue instead. A thousand queued follow-ups therefore cannot end up in front of one new lead, which is the failure that quietly turns a 40-second product into a four-minute one.
Two
Your questions are rows, not code
A flow is an ordered list of steps. Each step names the template to send, the shape of answer it expects, the contact field to write the captured answer into, and optionally where to jump next based on what came back.
expects-
choice,number,boolean,freeform, orconfirm. The shape of the answer, never its meaning. choices- An ordered array of values with their synonyms. Order matters: texting “2” picks the second one, because that's how people answer a list over SMS.
writes_to-
Where the answer lands — a first-class field like
age, or anything undercustom_fields. branch_on-
Captured value to next position, with a
default_next_positionso branches can rejoin anywhere, not just at the following row.
Classification is rule-based rather than a model call, deliberately: a network hop, a rate limit, and somebody else's outage do not belong inside the one latency budget that matters most. Domain meaning comes from the synonyms you declare, which is how the same engine learns that “slab leak” is an emergency without Flywheel containing the word plumbing anywhere.
When a reply doesn't match, it re-asks once. If the second reply is also unclear it marks the thread as needing a human and stops talking, rather than rephrasing at somebody forever.
Three
Every message leaves through one door
There is exactly one class that sends automated messages, on every channel, for every account. Not for elegance — a second send path isn't a shortcut, it's an untested compliance surface. It applies these in this order:
-
1
Template resolution
Your override first, then a vertical default, then the generic one.
-
2
Idempotency
The send is claimed before any guard runs, so a retried job cannot slip a second message past a guard that has changed since.
-
3
Human takeover
Skipped only by transactional copy — a booking confirmation still goes out.
-
4
Opt-out and suppression
Per account, per address, checked against the person actually receiving it.
-
5
Consent
Promotional copy needs recorded consent. No consent, no send.
-
6
Template guards
Halt conditions declared next to the copy they protect — for example, stop the ladder the moment they reply.
-
7
Quiet hours
Last, so a message stopped for any other reason is never rescheduled to tomorrow morning.
Quiet hours are the recipient's, not yours, and a blocked message is requeued to the next open window rather than dropped. A minor is never the recipient: where a contact has a guardian, the guardian is who gets the message and whose consent and suppression state is checked.
Four
You take over by just typing
Sending a message into a thread pauses that thread's automation for 24 hours, as a side effect of the send rather than a separate switch. A person who has to remember to silence the bot will eventually forget, and the bot will talk over them in front of a customer.
Your message skips template lookup, flow logic, and quiet hours. It does not skip opt-out or suppression. Hand the thread back early with a single call when you're done.
Still to come
Booking, reminders, attendance and review requests are specified and are the next things being built. They are not in the product today, and you will not find endpoints for them in the API. When they ship, they ship the same way everything else did: as public endpoints first.