Vora
Define success before the prompt.
Describe the intended outcome in terms someone can inspect: the booking with the correct client and timezone, the customer record with the right status, or the staff task with enough context to continue.
Identify the system that owns that result. Write down the normal case and the result expected when information is missing, a slot conflicts or a provider fails.
Use synthetic or appropriately consented data. Keep expected behavior separate from the transcript and records you actually observe. This makes a failed case useful instead of allowing a pleasant conversation to overwrite the requirement.
Keep the action states distinct.
| Observed situation | What it establishes | Next check |
|---|---|---|
| A preferred time was collected | A customer request exists | Was a booking action required, attempted and completed? |
| The authoritative system reports a created booking | A booking result exists there | Read back its ID, client, time and status |
| The slot conflicts | The requested slot was not confirmed | Check alternatives or the agreed staff route |
| The action failed | That attempt did not establish success | Inspect the error and the recovery owner |
| The action timed out with an uncertain result | Completion remains unknown | Reconcile downstream state before retrying |
| A handoff summary was generated | Context was prepared | Confirm receipt at the intended destination |
Use the actual provider's status meaning. These are evaluation categories, not a substitute for its contract or a promise about a particular tool.
Never turn “I would like Tuesday” into “Tuesday is booked” without the required booking evidence.
Read back the result through the right view.
Compare the transcript and action response with the authoritative booking or other downstream record. Check the identifier, client scope, timezone, status and any linked customer record.
Then reopen the result through the staff view that will use it. A screen shown during the conversation may not establish that a record persisted or that the next actor can access it.
Inspect failed cases too. A conflict should not leave a duplicate booking or an inaccurate customer status. An incomplete action needs a visible next owner rather than a success label.
Include repeats, interruptions and uncertain results.
Repeat a request using the recovery rule agreed for the configuration. Check whether it produces another action or resolves to the same intended result. Do not assume a second click or call is harmless.
Include an interruption during an action and a downstream timeout. If a response is uncertain, inspect the authoritative state before retrying. Record what the customer was told and who handles the unresolved item.
For a handoff, check the client, conversation context, reason and action status received by the agreed person or queue. Where acknowledgement is required, capture it. A generated summary and a notification icon are not the same as staff receipt.
Set answer and handoff boundaries before reviewing those cases.
Review the failure pattern, then change one thing.
Keep a case record with its configuration/version, expected result, observed result and evidence references. Mark an unrun case as unrun and an uncertain case as inconclusive.
Group the failures by cause: unsupported knowledge, wrong status, missing persistence, duplicate action or incomplete handoff. Name the owner of the change. Replay the affected cases after the correction using the same success definition.
Use those results when deciding whether to expand the client service or move more of the existing stack. Do not treat one successful call as evidence for every provider, language or client workflow.
Questions about post-call results.
Did the system return a created appointment, a conflict or an error?
Inspect the actual action response and authoritative record. Keep those results separate and use the corresponding customer message. If the attempt remains uncertain, reconcile it before describing it as complete.
What proves a booking is confirmed?
The authoritative system must contain the intended booking with the correct identifiers, client, time and status. Compare it with the conversation and check the associated customer record.
What should happen when the downstream API times out?
Treat the result as uncertain until its state is reconciled. Check whether the action committed before retrying, and use the agreed recovery and ownership rules.
How do I verify the right person received the handoff?
Inspect the intended destination and its client context. Check the unresolved task, conversation information and action state, then record staff acknowledgement where required.
Inspect a hypothetical test plan.
A hypothetical workshop uses after-hours callback intake. Booking stays with reception. The same example appears in the requirements, knowledge, migration and post-call resources, so each worksheet can be compared without inventing a different service.
| Case | Expected result | What the evaluator must inspect |
|---|---|---|
| Caller corrects their number | The final number ending 0102 reaches the right client queue | Saved fields and fresh reception view |
| Caller leaves a preferred appointment time | A request remains a request | No booked status or spoken confirmation without accepted booking |
| Destination response times out | Completion remains uncertain until reconciled | Original request identity and authoritative destination state |
| The same request arrives again | No unintended repeated business action | Actual duplicate/retry contract and retained action record |
| Customer asks for a policy exception | Only the authorized manager decides it | Handoff receipt, latest context and unresolved task |
| An unrelated client actor tries access | No unauthorized view or change | Denied operation and absence of leaked record data |
The filled worksheet records these expected checks with run state not_run. It contains no provider receipt, customer record or observed pass. Replace planning entries with your own controlled observations only after the test is authorized and actually runs.
For repeated actions and interrupted connections, review webhook identity and OAuth recovery. Reconnecting a provider does not prove interrupted work completed.
Label blank, worked, tested and real results.
Every file in this guide carries one evidence class. Keep the class when you copy, edit or share a sheet, so a plan is never read as a result.
| Class | What it is | What it does not show |
|---|---|---|
| Blank template | Empty fields and the states to fill in | Any test, result or claim |
| Hypothetical worked example | A fictional workshop filled in to show how to use the fields; every row stays not_run | An executed test, a customer or a supported integration |
| Controlled test | Your own authorized run with synthetic or consented data, a configuration version and evidence references | Behavior for other providers, languages or clients |
| Customer outcome | A result observed in a real client workflow, with the client's agreement to use it | A result for any other client |
Accepted evidence for a controlled test is the action response, the authoritative readback (identifier, client, time, status), the linked customer record and the staff receipt, recorded together with the reviewer. Missing any of these, mark the case inconclusive.
Use the five planning resources together.
Each blank resource keeps its existing public URL. The companion examples are hypothetical worked examples, and this guide is the owner page for all ten files. Each file names its class and this page.
- Requirements: blank matrix · filled planning example.
- Service cost: blank worksheet · hypothetical quote.
- Migration: blank checklist · filled planning example.
- Knowledge boundaries: blank worksheet · filled planning example.
- Post-call results: blank worksheet · filled planning example.
The service-cost example matches the pricing article's arithmetic: hypothetical monthly cost USD 400, service fee USD 1,200 and contribution USD 800 before other overhead, tax and acquisition. It is not Vora pricing, a market rate or a measured margin.
Evaluate the outcome your client needs.
Choose one conversation, its required stored result and the person who handles the unfinished path.