Facts become finished work in the seconds after a call ends. A task raised, an appointment booked, a payment link drafted. Not an overnight batch, and not a queue somebody drains in the morning.
7
actions you configure
5
wait for you by default
6
guard operators
Amber beats are drafted and held for approval. That is the shipped default for anything that reaches your customer.
The work a call creates is where deals quietly die.
The call goes well. Then the task is not raised, the quote is not sent, and the appointment is in somebody\u2019s head until Thursday. Nothing failed loudly enough for anyone to notice, and the deal is gone anyway.
Each one is switched on individually, with its own mode, its own confidence floor and its own conditions. The eighth is not on the list, because it is not optional.
| Action | What it does | Reaches caller | Default |
|---|---|---|---|
| create_task | Raises a follow-up task on the right board from what was actually discussed. | No | Automatic |
| set_appointment | Books the slot that was agreed on the call. | No | Automatic |
| send_email | A follow-up email in your branded template. You control the copy, the branding stays yours. | Yes | Approval |
| payment_link | Reuses a link you already built, or issues a new one for an amount. | Yes | Approval |
| send_form | Emails a published form. An unpublished form is refused rather than sent as a dead link. | Yes | Approval |
| vault_share | Shares a vault document. The link always expires. There is no setting that makes it permanent. | Yes | Approval |
| request_review | Asks for a review a couple of hours later, re-checking eligibility at the moment it sends. | Yes | Approval |
Not on the list of switches, because it is not optional. Caller details are written to your CRM on every analysed call.
Everything that only touches your own records just happens. That split is the shipped default, and it is the reason a business can switch this on before it fully trusts it.
A business switching this on for the first time cannot accidentally email its whole customer base. The defaults prevent it, and they choose when to change them.
A guard is a condition tested against the call’s own analysis. Pick a field, an operator and a value, and see which of ten sample calls would have fired.
Per-action mode
Automatic or approval, set independently. Auto-create tasks while reviewing every outbound email.
Minimum confidence
Per action, so a weak read never triggers an outward message to a customer.
Six operators
equals, does not equal, exists, greater than, less than, contains. "Only ask for a review when sentiment was positive" is one line.
Sanitised parameters
Values suggested by the model are cleaned before use, so a caller cannot talk the system into acting on something it should not accept.
None of these is a feature anybody asks for in a demo. Together they are the section that persuades a careful buyer, because each one is a specific way this could have gone wrong and did not.
Vault links always expire
There is no configuration anywhere that mints a permanent public link to a client document. The expiry is not a default you can turn off.
Review requests re-check on send
The eligibility test runs again hours later, at the moment the message goes out, not only at the moment of the call.
Forms have to be published
Sending a dead link is treated as worse than sending nothing at all, so the action refuses rather than delivers.
Tasks land on a real board
A follow-up attached to no board would exist and appear on nobody’s list. The account’s board is resolved before anything is written.
They are what thinking about the failure modes looks like in practice. Each one is the answer to a specific way this goes wrong at three in the morning when nobody is watching, which is exactly when automation earns or loses its place.
Every attempt is logged whether it ran or not. When somebody asks what happened on a specific call, the reply is a record rather than a reconstruction from memory.
Every guard tests a value that came out of the call. That is why the two pages either side of this one matter to it.
The follow-up always happens
Done in the seconds after the call, not at the end of a day that got away from somebody.
Approval where it matters
Everything customer facing waits for a human until you decide otherwise. That is the shipped default.
Conditional by design
Guards fire an action on the right calls rather than on every call.
Fully auditable
Every attempt is logged whether it ran or not, with its reason, confidence and approver.
Seven actions you configure: raise a follow up task, book the appointment agreed on the call, send a follow up email, issue a payment link, send a published form, share a vault document, and ask for a review a couple of hours later. Writing the caller’s details into the CRM is not on that list because it is not optional, it happens on every analysed call. All of it runs in the seconds after hang up, not as an overnight batch.
A short demo on your own process. We will set up one guard together and show you the audit trail behind it.
Book a demo