Reschedule appointments by phone — and update the scheduling system.
A completed reschedule is more than collecting a preferred time. Truvoca must identify the correct appointment, read current availability and scheduling rules, present eligible options, receive explicit confirmation, commit the change in the connected source of truth, and verify the result.
This two-way workflow is launch-gated. It should not be presented as available until identity, authorization, availability freshness, holds or rechecks, rule validation, write-back, old-slot handling, confirmation, audit, concurrent changes, and recovery have passed end-to-end tests.
30 minutes over Google Meet. Times are shown in Eastern European Time (GMT+03:00). Scheduling runs on Google Calendar, so choosing a time takes you into Google’s service.
- Current appointment and authorization verified
- Eligible alternatives based on scheduling rules
- Explicit caller confirmation before the change
- Committed system update with safe failure recovery
Change only the appointment the caller is allowed to change
Define how Truvoca finds and authorizes the correct record.
The request may begin during an inbound call or as an approved branch of another workflow. Document the identity or lookup fields, authorization checks, eligible appointment statuses, change window, protected services or appointments, and the situations that require staff approval.
The conversation should reveal only the minimum information needed to locate and confirm the booking. If the record or authorization cannot be established, Truvoca should not expose alternatives or modify the schedule; it should use the approved staff route.
- Inbound or approved outbound trigger
- Identity, lookup, and authorization method
- Eligible appointment status and ownership
- Change deadline and policy window
- Protected services, providers, or appointment types
- Staff approval and fallback conditions
From change request to verified system response
Treat rescheduling as one controlled transaction.
The flow must protect the original appointment until a valid replacement and system response are confirmed.
- Identify and authorize the current appointment.
- Read its service, duration, provider, location, resource, policy, and status rules.
- Fetch eligible alternatives from the source of truth and apply freshness checks.
- Present a small set of clear options and repeat the selected date, time, and time zone.
- Hold or recheck the option, then receive explicit confirmation before committing.
- Write the change, verify the response, handle the old slot, and record the new confirmation.
- Notify the caller and team, or recover safely if any part of the transaction fails.
An open time is not automatically a valid appointment
Apply service, provider, location, resource, and policy rules to every option.
Availability must come from a verified source and be filtered through the rules that make a slot usable for this specific appointment. These can include service duration and buffers, provider skills or preferences, location, room or equipment, operating hours, recipient time zone, lead time, capacity, recurrence, and change policies.
The connector must define how fresh availability is, whether a slot can be held, and what happens when another user or process changes it. The site should not promise real-time availability or no double-booking before those mechanics are proven.
- Service duration, preparation, cleanup, and buffers
- Provider eligibility, skills, and allowed preferences
- Location, room, equipment, and other resources
- Operating hours, time zone, lead time, and capacity
- Recurring appointment and linked-record rules
- Unavailable, protected, or policy-restricted slots
Make the choice clear before changing the record
Present a limited set of valid options and confirm the selection explicitly.
The agent should offer a manageable number of alternatives and state the date, time, and time zone in language the caller can verify. If the provider, location, price, deposit, or cancellation policy changes, the workflow must disclose only the details that have been approved and supported.
Before writing anything, repeat the selected option and ask for explicit confirmation. If the response is ambiguous, preserve the original appointment and clarify or route to staff. Sensitive details should be minimized throughout the conversation.
- A small, relevant set of eligible alternatives
- Unambiguous date, time, and time zone
- Provider or location choice only within verified rules
- Reviewed policy change disclosure
- Explicit confirmation immediately before commit
- Clarification or staff route for ambiguous responses
The source-of-truth response defines completion
Commit the new appointment without leaving the schedule in a partial state.
For the exact integration, document the API or access method, objects, fields, permissions, validation, holds or locking, update order, idempotency, old-slot behavior, new confirmation identifier, custom fields, audit timestamps, and the source of truth.
Completion means the connected system confirms the new appointment and the old slot is handled according to verified rules. A request, callback task, calendar link, or local agent note is not a completed reschedule. If the response is uncertain, the workflow must avoid claiming success and move the record to reconciliation.
- Verified appointment object and fields
- Read and write permissions scoped to the workflow
- Hold, lock, or final availability recheck
- Idempotent update and duplicate-request protection
- Old-slot release or other documented handling
- New confirmation ID, audit timestamp, and source-of-truth response
Plan for the slot or connection to change mid-conversation
Recover safely from stale availability, partial writes, and duplicate requests.
Testing should cover another booking taking the slot, stale availability, timeout, a lost connection, duplicate caller requests, a successful write with a missing response, partial updates, and conflicting changes from staff or another channel.
For each case, define whether Truvoca rechecks, offers another option, rolls back, applies a compensating action, preserves the original appointment, creates a staff task, or blocks further automation. The caller should hear an accurate state, and the team should receive enough context to reconcile the record without creating another change.
- Slot becomes unavailable before commit
- Concurrent staff or customer change
- Timeout or unknown write result
- Partial update or old-slot release failure
- Duplicate request or repeated callback
- Rollback, compensating action, staff task, and reconciliation
Show the schedule before and after the call
A real rescheduling demo proves the committed change and the failure path.
Evidence should show the original appointment, the availability and rule evaluation, the options presented, the caller's confirmed choice, the system transaction, the new appointment, the handling of the old slot, and the final call outcome. Timestamps and identifiers should connect the conversation to the source-of-truth record.
The same review should include at least one concurrency or failed-write case and its caller message, staff task, audit trail, and reconciliation result. Use consented data and approved screens or recordings.
- Before record and verified authorization
- Availability response and applied rules
- Selected option and explicit confirmation
- Committed update and old-slot handling
- New confirmation and recorded call outcome
- Concurrency or failure test with recovery evidence
Launch only where the system transaction is dependable
Use automated rescheduling with stable rules and an accountable operations owner.
This workflow fits operations with a maintained two-way connector, clear authorization, reliable appointment objects, explicit scheduling and policy rules, tested concurrency handling, and a team that owns exceptions. It is not a fit when only a message can be captured, availability is stale, fees or policies are unresolved, or failed changes cannot be reconciled.
Keep the page gated until the connector-specific read, write, confirmation, recovery, security, and legal reviews are complete.
Good fit
- verified two-way scheduling connector
- explicit duration, resource, provider, and policy rules
- monitored exceptions and reconciliation owner
Exclude
- request capture without a committed change
- unverified payment, deposit, refund, or fee actions
- workflows without reliable failure recovery
Validate a complete reschedule before presenting it as automated.
Share the scheduling system, appointment object, identity and authorization method, service duration, provider, location, resource and policy rules, option strategy, update sequence, old-slot behavior, notifications, failure handling, and audit owner. We will identify which parts can be demonstrated and which require integration, operations, security, or legal validation.
Do not submit live customer or patient records, credentials, payment information, or confidential system documentation through the public form.
FAQ
FAQ
What counts as a completed reschedule?
The connected source-of-truth system confirms the new appointment, the old slot is handled according to verified rules, and the workflow records the result. A preferred time, callback task, or scheduling link is not a completed reschedule.
How does Truvoca find the correct appointment?
Each deployment defines and tests the lookup, identity, and authorization method for eligible appointments. The conversation should use the minimum necessary information and route to staff when the correct record cannot be established.
How are alternative times selected?
Options come from the verified scheduling source and are filtered by service duration, provider, location, resources, operating hours, time zone, lead time, capacity, and policy rules relevant to that appointment.
Can the caller choose another provider or location?
Only when provider or location preferences, eligibility, availability, service compatibility, and policy changes are documented and tested. Otherwise the workflow should keep the existing constraints or route the request.
What if the chosen slot becomes unavailable?
The tested workflow should recheck or hold the slot, avoid committing an invalid change, explain the accurate state, offer another eligible option when supported, and create a staff fallback when necessary.
What happens if the system update fails?
The workflow must not announce success. It should apply the verified rollback or compensating behavior, preserve or reconcile the original record, notify the caller accurately, and create an assigned staff task with audit context.
Can deposits or cancellation fees be changed?
Do not claim payment, refund, deposit, or fee changes until the provider, authorization, policy, legal, accounting, failure, and reconciliation behavior has been separately verified.
Which scheduling systems are supported?
Use the maintained connector registry and the verified scope for the exact appointment object and two-way rescheduling actions. Generic connectivity or a vendor logo does not prove that this workflow is supported.