How it works

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.

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, or confirm. 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 under custom_fields.

branch_on

Captured value to next position, with a default_next_position so 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.