What steps make up a reliable booking process?
A reliable booking flow has seven stages, and each stage advances only after the required data is available. A caller can provide several fields in one answer; the system keeps each valid value and does not repeat completed questions.
- 1
Establishing a goal
The agent must decide whether the customer wants a new booking, change, cancellation or information.
- 2
service
Specialties and services are related to the actual catalog, not a free guess of the model.
- 3
specialist
A first name, last name, or descriptive selection will be converted to a physician or employee in the directory.
- 4
Date and time
The Georgian phrase is normalized to the exact Tbilisi time interval and the minimum advance time is checked.
- 5
Availability
A busy slot is never confirmed. The system offers the nearest real alternatives from the same calendar.
- 6
Patient data
Name and contact number are collected only when the service and time are already known.
- 7
final confirmation
After a concise summary, one clear confirmation creates the booking. Success is announced only after the booking service returns a successful result.
What should happen when a user says several details together?
If the user says "Friday at two o'clock with Irakli Tsatsdeladze", the process must fill in the doctor, day and time in one answer. The following question should only address unknown data or actual calendar conflicts.
For this, LLM outputs structured candidates, while a rule-based validator checks each field's type, current stage, and catalog match. The uncertainty of one field should not invalidate the rest of the correctly received data.
If the two answers conflict, the change is only allowed if the previous value already exists and the user's new phrase truly represents the change. Adding an empty field is not a change.
How should busy time and alternatives work?
The agent offers times only from the calendar’s latest response. If a slot is taken before confirmation, the system checks again and offers the nearest two or three real alternatives for the same specialist.
- Never offer availability from memory or an outdated list.
- All dates are evaluated in a single, documented time zone.
- The proposed option should have an identifier so that "first" and "second" can be handled correctly.
- Availability will be re-checked before the booking is made.
What proof must be left after a successful booking?
After a successful call, four entries must match: the agent's voice confirmation, the calendar entry, the process completion event, and the session result. The phrase "booked" alone does not prove success.
| layer | What does it prove? | An example of an error |
|---|---|---|
| calendar | Time was actually created | API rejected but agent said success |
| A process event | The correct last step has been completed | The confirmation was repeated and the second request was issued |
| session result | The panel shows the correct result | The booking exists, but the interface reports an error |
| Audio and transcript | What the customer and the agent said | Later it cannot be determined which time was confirmed |
Official sources and further reading
Technical definitions are verified with primary sources. Links are opened in the official documentation of the corresponding project.
- Pipecat Flows — Pipecat Documentation
A formal description of organizing conversations into graphs, state management, and transitions between nodes.
- SIP APIs — LiveKit Documentation
Official API overview for managing SIP channels, allocation rules, and participants.