Put a controlled transaction service between the agent and the operational system. The agent may request an action; the backend should decide whether the action is permitted and report its verified result.
The following tool names are illustrative interfaces to design, not vendor endpoints:
| Proposed tool | Purpose | Important restriction |
|---|---|---|
check_eligibility |
Validate location, service area and task type | Return approved categories, not an open-ended decision |
get_available_slots |
Obtain current eligible capacity | Apply provider, duration, location and resource rules |
create_booking |
Commit the selected booking | Require validated fields and a stable operation identifier |
get_booking_status |
Verify the committed record | Return the authoritative record ID and relevant details |
create_callback_request |
Record an unresolved task | Mark it pending; never imply a confirmed appointment |
request_handoff |
Route to an approved destination | Use a server-controlled destination list |
What is the safe transaction sequence?
Use this proposed sequence:
- Establish the required customer identity or booking context.
- Validate eligibility and permitted action.
- Retrieve current availability.
- Read back the selected location, date, time and task.
- Obtain the caller’s confirmation.
- Submit the booking with a stable idempotency identifier.
- Verify the resulting record.
- Speak a confirmation only after the verified result.
- Log the operational record ID against the task.
Idempotency means that retrying the same intended operation should not create another booking. Establish the identifier outside the model and reuse it when the same operation is retried. Add business-level duplicate checks for repeat contacts where appropriate.
Retell’s custom-function documentation explicitly warns that enabled retries repeat requests and can cause the endpoint to process them more than once; it advises enabling retries only for idempotent endpoints. (docs.retellai.com)
What happens when the booking request times out?
A timeout must not automatically become either “booked” or “not booked”. Use an explicit intermediate state:
CONFIRMED
REJECTED
PENDING_VERIFICATION
For PENDING_VERIFICATION, query the backend using the stable operation identifier or other approved reconciliation method. If the result remains unknown, create a human-owned reconciliation task and tell the caller that confirmation is pending. Do not submit a fresh booking blindly.
Implement provider-specific protections against two callers taking the same capacity. A separate availability read followed by a write is not your proof of a safe reservation; test the actual system’s conflict handling.
What should ServiceTitan buyers check?
ServiceTitan’s API guide requires appropriate administrator-enabled permissions and documents the app-key, client-credential and access-token flow. Importantly, it says an integration environment for an existing production customer is a clone of the production system and production data. Do not assume that environment is anonymised or appropriate for unrestricted contractor access. (help.servicetitan.com)
Ask the system owner to demonstrate the distinction between a booking request and a job or appointment that has actually been scheduled. ServiceTitan’s Scheduling Pro documentation describes jobs appearing on the Dispatch Board and booking requests appearing separately for review. (developer.servicetitan.io)
What should dental buyers check?
Open Dental documents separate operations for slot searches, appointment creation, planned appointments and updates. Its appointment-creation interface includes patient, operatory and appointment-time requirements, and the documentation exposes provider, clinic and other scheduling fields. A generic calendar event is not equivalent to a correctly configured dental appointment. (opendental.com)
Have the practice validate appointment type, duration, clinician, operatory, location, new-patient rules, identity handling and any procedure requirements. Where those policies are unknown, the agent should request clarification or hand off—not invent them.
Deliverable: an integration contract, field mapping, permission inventory and evidence of successful, failed, duplicated and ambiguous transactions.