Defined job and source
The owner’s brief is visible, and the incoming enquiry stays attached to the run instead of becoming anonymous prompt text.
Self-guided product walkthrough
See one AI employee handle an enquiry.
Follow one employee from the owner’s brief to sourced work, an exact held reply, a correction, and the next similar case. No scheduled call, no customer theatre, and no fake interactive controls.
Fictional sample, real product states
The names and enquiry words are illustrative. The Chat, source, evidence, Review, Training, and approval states are the real product journey—not a customer story or a live simulation.
What ends here
The walkthrough ends with held work. Nothing in the sample was sent, and it does not claim unattended dispatch or a result from a real customer.
One employee · one job · six visible states
The work is inspectable from start to correction.
Read straight down. Every step stays with the same employee, and every risky effect remains concrete enough for the owner to judge.
- 01Chat
Brief one ready employee
The owner describes one job, the facts to use, and the boundary for risky work in the same Chat where they will later correct it.
“Handle new service enquiries. Check our service area and opening rules, flag urgent work, and draft replies for me to approve.”
- One employee
- Owner-authored job
- Approval boundary named
- 02Incoming source
A real trigger brings the work
A forwarded email, webhook, or schedule can wake the employee. This walkthrough uses fictional enquiry text so no customer data is presented as proof.
“Could you help with an urgent repair near Bristol tomorrow? We need to know whether you cover our area.”
- Fictional sample
- Source attached to the run
- Urgency preserved
- 03Work evidence
It checks before it drafts
The employee applies the standing rules, keeps unknowns unknown, and records the evidence and run cost behind its decision instead of inventing an answer.
“Service area: matched · Urgency: high · Tomorrow's availability: not verified · Run cost: recorded · Next step: ask for postcode and callback number.”
- Facts checked
- Decision explained
- Run cost recorded
- Unknown not guessed
- 04Review
The exact reply waits
Review shows the proposed effect and why it stopped. The owner can inspect the concrete work before authorising anything.
“Thanks for getting in touch. We cover Bristol and I’ve marked this urgent. What postcode and callback number should we use? I haven’t promised a time yet.”
- Exact work visible
- Requires approval
- Nothing sent
- 05Correction
The owner sharpens the same employee
A correction in Chat becomes a visible rule or preference in Training. Every self-update stays visible in History, learned instructions remain editable or removable, and Undo appears only for a conflict-checked exact reversal.
“For urgent enquiries, ask for the postcode and best callback number before discussing availability.”
- Visible Training
- Every change in History
- Edit or remove
- 06Next similar case
The next run shows whether it stuck
Improvement is not a badge or a promise. The next comparable job is where the owner can see whether the correction changed the work.
“Rule applied: postcode and callback number requested; no availability promised; reply held with the new evidence visible.”
- Correction applied
- Next-run proof
- Still held for Review
What the owner can inspect and control
The checklist is not another promise. These are the fixed parts of the walkthrough it points to, plus the boundary that remains true when Require approval changes.
Exact held Action
With Require approval on, the concrete reply waits in Review. The owner sees the effect and can approve or deny that work; nothing in the sample was sent.
Reason, evidence, and cost
The run shows the facts checked, the unknown it refused to invent, why it held, and that the run cost was recorded without fabricating a number.
Correction and revocation
The correction remains visible and editable in Training. Connected access can be revoked, and the next similar run—not a badge—shows whether the rule improved the work.
Require approval is one control, not the whole safety system.
It decides whether the exact Action Vavio chose waits for an owner. It does not force the employee to act, bypass its Skills, or override independent platform floors. This walkthrough does not prove unattended sending or enterprise governance.
Proof beside its boundary
What Vavio has actually proved.
The walkthrough explains the shape. This company-owned production test is the harder evidence underneath it.
Company-owned Gmail test
On Vavio's company-owned, already-connected production Gmail account, two consecutive marked cycles read real mail, wrote a draft that Vavio verified at Gmail, held the reply, and delivered it only after explicit owner approval.
What that does not prove
That is Vavio's product test, not a customer result. A stranger connecting their own Gmail through Vavio's branded consent still awaits Google's restricted-scope verification; it does not guarantee a recurring inbox result for a new owner, and unattended sending remains unproved.
Evidence informs one clear owner decision
The employee’s Skills and the situation determine the Action it proposes. Run evidence helps the owner decide whether that Action should require approval. Current safety floors can still hold work, and this public proof makes no unattended-send claim.
Train this employee on your real job.
Start with one ready employee in Chat. Give it the job, the facts, and the boundaries—then inspect the work and correct the same employee.
Free trial · No card required · The demo sample is fictional; no customer data is shown and nothing in the walkthrough was sent.