Returns, membership changes, damage claims — jobs that don't end with one answer but walk step by step. You describe the procedure once: the agent collects the details, picks its path by condition, checks your systems when needed, and hands the sensitive moment to your team.
7 step types
instruction · conditional branch · system lookup · human handover · finish · note · tag — complex work is built from these seven
When — and when not
every procedure defines the phrases that start it AND the situations it must stay out of, separately
Drafted for you
when a recurring process is spotted, a procedure draft is proposed; nothing goes live unread and unapproved
describe
A procedure is a set of steps in plain sentences: "ask for the order number first", "if the date is past 14 days, take this path", "hand over to the team at this point". No code, no diagrams — you write the process the way you'd explain it.
Steps in plain sentences
Each step is an instruction; anyone can read, edit and update it — no technical skill needed.
Branch on a condition
"If past 14 days", "if the membership is active" — the process takes a different path by condition; you write both paths.
When it engages
Exceptions are defined alongside the trigger phrases: you can say "a shipping question does NOT start the return procedure".
Every procedure carries a "when to use" definition and "stay out of these situations" exceptions, written separately.
execute
The procedure doesn't stay on paper. The agent asks the customer for missing details, checks your systems when needed — order date, membership status, stock — and states the result in the customer's language. Along the way it leaves notes and tags on the conversation; when your team looks later, what happened is plain.
Collects the details
Whatever a step needs, it asks for: order number, date, preference — in order, patiently.
Checks your systems
The system-lookup step also calls the endpoints you define in the panel — shipping, membership, stock, orders.
Leaves a record
Note and tag steps mark the conversation; which procedure, which step, what was decided — traceable.
The system-lookup step uses the same endpoints described on the Developer API page — no separate setup.
control
Every process has a moment that needs a human: approving a refund, changing a contract, granting an exception. You write that moment into the procedure as a handover step; when the agent reaches it, it delivers the job to your team with the full history. The agent's general brakes hold inside procedures too.
The handover step
You choose the handover point; the agent stops there and passes the conversation on with its summary and history.
Brakes intact
Forbidden topics, the source requirement, approval on money matters — no procedure can override these rules.
Review first
A draft procedure passes review before anything else; the publish decision is always yours.
The system also proposes procedure drafts from recurring processes — no draft ever goes live without human approval.
You set the handover point when writing the procedure; the agent never goes past it.
No. Steps are plain sentences; conditions and handover points are added by selection. In your setup week we write your first procedures together.
Every procedure defines exception phrases alongside its triggers — you can say "stay out of this situation". Pre-publish review is the second gate against wrong triggering.
No. Moments that move money are handover steps in the procedure: the agent collects the details, prepares the case, and leaves the decision to your team.
Yes: recurring processes and your team's replies are observed, and procedure drafts are proposed from them. A draft never goes live unread and unapproved.
We handle the setup in your first week; we turn your most frequent processes into procedures together.