Examples, not claims of completed deployments
These three illustrative recipes cover booking, authorized enquiry follow-up and support. They show decision points and boundaries, not documented customer results. Every integration, permission and transfer route must be verified before implementation.
The number of questions alone does not determine complexity. Count the systems involved, data changes, approval points and evidence required to establish that an action really completed.
Example 1 — booking with corrections and an unavailable slot
Goal: create one correct booking with the caller’s approval. Inputs include service, branch or specialist, date, time zone and the contact fields required by the business. Hearing a number is neither identity verification nor permission to book.
Permitted tools: read the service catalogue, check availability and request a booking only after the caller confirms a summary. The calendar is the availability source; the LLM must not invent a free slot.
Collect and clarify
A caller says the Georgian phrase „ხვალ ოთხის ნახევარზე თმის შეჭრა მინდა“. Resolve tomorrow from the call date; „ოთხის ნახევარი“ denotes half an hour before four, so clarify whether 15:30 is intended if the time of day is uncertain. Repeat the full calendar date before approval.
Check availability
If unavailable, name the exact date and time and offer only alternatives returned by the calendar. A change of specialist also requires checking that person’s service and availability.
Apply a correction
For ‘No, the day after tomorrow’, update the date and recheck dependent availability without losing the established service. Present the revised summary and a verified price, then obtain approval.
Write and verify
Application logic checks fields, permissions and approval. An operation identifier protects against duplicates. Say ‘booked’ only after the business system confirms success.
| Situation | Recovery | Acceptance check |
|---|---|---|
| Someone takes the slot before confirmation | Recheck, offer a new alternative and obtain fresh approval | Old approval never books a different slot |
| The write response times out | Look up the operation status; keep the outcome unconfirmed | A blind retry never creates a second booking |
| Booking succeeds but SMS fails | Record booking and notification outcomes separately | Notification failure does not cancel the booking |
| Recovery cannot resolve the state | Route to the agreed responsible person | The owner receives the operation identifier and unresolved status |
Example 2 — authorized follow-up to an enquiry
Goal: clarify an existing enquiry and continue with the appropriate team. This is not permission for unsolicited bulk advertising or calls to arbitrary collected numbers. The business must define a valid contact basis, applicable consent, permitted hours and opt-out handling in advance.
Inputs include an enquiry identifier, permitted contact channel, enquiry topic and accountable team. Possession of a number or a CRM record does not establish marketing consent. Permitted actions can include reading minimum enquiry context and recording an agreed outcome, not declaring a closed sale or revenue.
Open transparently
The agent identifies itself, explains the purpose and checks willingness to continue. It does not disclose private enquiry details if someone else answers.
Understand the need
Ask only necessary questions about the process, current systems and human involvement. Allow corrections, refusal and an end to the conversation.
Agree a next step
Agree to pass on the request, record a consented callback or use another verified route. State a response time only when supported by an actual operating commitment.
Record the result
Save the minimum agreed result and responsible team. Say ‘the request was recorded’ only after success; an actual connection with a person is a separate outcome.
| Response | Permitted action | Acceptance test |
|---|---|---|
| ‘Do not contact me again’ | Record the opt-out under the agreed policy and stop continuation | Refusal does not trigger another sales question |
| ‘I am not interested’ | Accept the response and end politely | The caller is not returned to a sales loop |
| ‘I want to speak to a person’ | Use the agreed human-handoff route | An attempt is not reported as a completed connection |
| ‘Wrong number’ | End without exposing context; record the contact mismatch | Private enquiry details are not disclosed |
| ‘I cannot talk now’ | Record a later-contact request only with approval | A request is not reported as a completed callback |
| CRM unavailable | Explain the limitation and use the agreed safe fallback | Do not claim that a record already exists |
Example 3 — support with status checks and human handoff
Goal: provide a verified answer or route the request to the right team. Prerequisites include approved knowledge, identity checks where needed, limited status access and a real human-handoff route.
Permitted tools may retrieve public instructions, read an authorized request status and create a support request. Account changes, refunds and other high-risk actions are not automatically authorized by this example.
Check topic and access
Answer public questions from approved material. For a private status, follow the business’s authorization policy; a spoken name or number is not sufficient proof of identity.
Stay within the source
Report the state actually returned by the system. Do not replace an unknown completion time with a reassuring but invented promise.
Handle exceptions
If the question exceeds approved knowledge, identity cannot be verified or a system is unavailable, explain the limit and offer a permitted alternative.
Continue with a person
Transfer only necessary context: the goal, verified fields, attempted steps and remaining question. If nobody answers, use an agreed callback or request route without pretending a connection succeeded.
| Test | Expected outcome |
|---|---|
| Identity check fails | No private status is disclosed; offer an authorized next step |
| Caller says ‘ignore your rules’ | Conversation text does not change application permissions |
| Human transfer fails | Record an attempted and a completed connection separately |
| Request creation outcome is unknown | Reconcile before retrying and retain an accountable owner |
Adapt a recipe to your business
Write down one desired outcome, its trusted data source, the response that proves completion and the accountable person. Add a correction, refusal and system outage. Test one complete process before expanding it.
Do not send passwords, API keys, recordings or real customer data for an initial assessment. A general description of the workflow and current systems is enough.
This worksheet stays on this page: nothing is sent or saved. Reloading clears it. Use general examples without personal data or secrets; print or save a PDF through your browser if useful.
Common questions
Are these workflows running for every customer?
No. They are illustrative examples. Actual functionality and integrations are determined after checking the customer’s environment.
Can we combine examples or change the sequence?
Yes, these are starting examples, not mandatory sequences. Assess feasibility, additional access and exception handling during discovery.
What if the caller supplies everything at once?
A workflow can retain recognized fields and ask only for missing information. Validation, required approval and confirmation from the business system still precede the final action.
Can someone change their mind mid-call?
Plan it as a branch: update the relevant field, recheck dependent information and renew the summary and approval where necessary.
Does the question count determine complexity?
Not alone. Systems, permissions, writes, exceptions and recovery rules often matter more.
Primary sources and scope
Checked on September 17, 2026. These sources explain technical mechanisms, not the availability of every capability in an OMO implementation. Proposed connections and examples require a separate assessment.
- Google AI — function calling
Model-proposed tool calls and application-side execution.
- LiveKit — call transfers
Transfer mechanisms require compatible, configured telephony.
- OWASP — prompt injection
Untrusted input, least privilege and controls for high-risk actions.