Reserve the appointment with a temporary hold and an exact expiry. Issue a separate deposit request, then confirm only after authorised staff reconcile payment evidence and the booking process verifies the reservation. Tell the customer what is protected, until when, and what confirmation requires.
The proposed model below separates holding capacity, requesting payment and committing to an appointment. It is a practical starting point for workflow automation within an AI automation project.
Separate booking status from payment status
A hold protects specified capacity temporarily. A payment request supplies the deposit amount and reference. A confirmed reservation records the business's commitment after its agreed checks. None should silently imply the others.
Maintain independent booking and payment statuses. A booking might be held while payment evidence awaits review, or expired while a late transaction is investigated. Staff can then explain both facts without suggesting that payment automatically restores a released appointment.
Microsoft Graph documents calendar events and free/busy availability. It also distinguishes tentative meeting responses for user calendars from group calendar behaviour. Those capabilities do not establish a deposit policy or enforce your booking rules. A tentative response alone is insufficient as the business hold record. Source: Microsoft Graph calendar resource
Define the resources and deadline
Specify the service, appointment start and finish, staff member, room or equipment, and preparation time. Holding only the start time can leave essential capacity available to another booking. Use one booking reference across the hold, payment request and staff record, linked to the calendar entry.
Choose a deadline staff can explain and monitor. A hypothetical repair business might propose a two-hour hold during staffed hours. This is an example operating rule, not a universal recommendation. The business should consider appointment demand, payment methods and reviewer availability.
Give an actual date, time and time zone rather than “later today”. Decide whether timely payment means the transaction occurred before expiry or verified evidence reached the team before expiry. Communicate that rule before requesting payment, alongside applicable cancellation terms.
Control competing changes to the same slot
Checking availability is necessary, but two workers can both read the same free slot before either records a hold. Use one serialised resource-claim process: competing requests for overlapping staff, rooms and equipment are handled in order. Each change checks availability and the expected booking version before recording the outcome and increasing that version.
Route hold creation, confirmation, extension and expiry through this process. A stale attempt stops and reloads the current record. For example, an expiry task carrying an older version must not release a hold that staff have extended. A payment reviewer must not confirm a booking that another operation has expired.
Keep pending calendar changes visible in that process. If the calendar update fails, flag the booking for repair and keep its resource claim protected until staff resolve it. Verify the calendar result before promising success. This is a proposed integration design, not a claimed native calendar feature.
Reusable booking state model
Use this proposed runbook. Set deposit terms, expiry rules and reviewer responsibilities before use.
| Booking state | Capacity treatment | Payment handling | Next step |
|---|---|---|---|
| Requested | No capacity promised | No payment assumed | Claim available resources through the controlled process |
| Held | Protect specified resources until expiry | Track requested, awaiting review or accepted separately | Confirm, approve an extension or expire through the controlled process |
| Confirmed | Keep the verified resource reservation | Retain accepted payment evidence | Send confirmation and handle later changes separately |
| Expired | Release resources after the controlled expiry transition | Keep unresolved or late evidence for review | Offer availability afresh; refer financial decisions to authorised staff |
| Cancelled | Release the correct resources through the controlled process | Refer deposit treatment to authorised staff | Record the decision and notify the customer |
Required record: booking reference; booking version; customer contact; service; staff and resources; appointment start and finish; time zone; expiry; booking status; payment status; requested deposit and currency; payment-request reference; calendar event identifier and update status; review owner; last decision and reason.
Payment identity: record the stable transaction identifier and its source, such as the payment provider or bank record, separately from each evidence-item identifier. Record transaction time, evidence arrival time and review time where available. If transaction identity is missing or uncertain, keep payment review open.
Transition checklist:
- Serialise competing resource claims, including hold creation, confirmation, extension and expiry.
- Check the expected booking version and availability within that process; stop stale attempts and reload.
- Match payment to the booking reference, requested amount and currency; never use amount alone.
- Check the transaction identifier together with its source before counting another payment.
- Attach repeated evidence to the existing transaction; send uncertain identity for human review.
- Require authorised human approval for deposit acceptance, late-payment exceptions and refund decisions.
- At expiry, resolve evidence under the agreed timing rule; uncertainty needs a named reviewer and a bounded extension or explicit release decision.
- Verify the calendar outcome before sending confirmation; track message delivery separately.
Reconcile the transaction and its evidence
A customer's “paid” message or screenshot starts a check; it does not confirm the booking. Staff need evidence appropriate to the payment method, matched to the correct request. An upload identifier identifies a document, not necessarily the money movement it describes.
Two screenshots can show one transaction. One screenshot can be unclear about which transaction occurred. Where available, match the transaction identifier together with its provider or bank source. Do not count a newly uploaded document as a new deposit simply because its file identifier differs.
Keep evidence attached to its original request when appointments move. Record payment time separately from evidence arrival time so reviewers can apply the stated deadline rule. If timing or identity cannot be established, preserve the uncertainty and assign a reviewer. Any continued capacity protection needs an explicit deadline; review must not create an indefinite hold.
Work through ordinary and exception cases
All figures, references and times below are hypothetical; the handling rules are proposed.
Ordinary deposit: Hold H-204 protects a Wednesday consultation from 10:00 to 11:00 and expires on Monday at 14:00. The requested deposit is R300. At 13:20, staff match accepted payment evidence to H-204 and record its transaction source and identifier. Confirmation passes through the controlled process, checks the current version and verifies the calendar update. Expected outcome: one confirmed appointment with traceable payment evidence.
Missing or ambiguous reference: An upload shows R300 without a booking reference, while two customers owe that amount. Staff seek transaction details and contact the relevant customer rather than selecting the newest enquiry. Expected outcome: payment remains awaiting review; the hold follows its recorded deadline unless an extension is approved.
Duplicate evidence: Two uploads have different document identifiers but show the same transaction identifier from the same source. Staff attach both to one transaction and avoid repeating confirmation. If transaction identity is unavailable, they investigate rather than count two payments. Distinct transaction identifiers prompt an overpayment check, with any refund decided by authorised staff.
Late evidence and a taken slot: Evidence arrives at 14:10 after expiry, and another customer has the slot. Staff check transaction timing against the stated policy and offer alternatives. Expected outcome: no automatic restoration of the expired booking or displacement of the later reservation; an authorised person decides the financial outcome.
Give automation a checkable role
Explicit rules should control resource claims, expiry and transaction matching. AI can help extract appointment details, identify missing information or draft an explanation. Its interpretation should not settle uncertain payment evidence.
OpenAI's function-calling documentation describes models requesting tools and application code executing them. A requested action is therefore not evidence of a completed calendar update. Source: OpenAI function calling
n8n documents human approval or denial before selected AI tools execute. This offers a possible review mechanism; the business still defines approval authority and booking controls. Check current account, plan, region and integration eligibility before deployment. Source: n8n human review for AI tool calls
Compare AI agents versus automation when deciding whether language interpretation is needed. The custom AI agents workflow guide and custom AI agent definition provide related context.
FAQ: tentative appointments and deposits
What should the customer receive when the hold starts?
Send the service, appointment details, deposit amount, payment reference, exact expiry and confirmation condition. Say clearly that the slot is temporarily held and staff will send confirmation after verification. Include the agreed payment-timing rule.
Can staff extend a hold while payment is being checked?
Yes, under an approved exception rule. Record the approver, reason and new deadline through the controlled process. Increase the booking version, notify the customer and ensure older expiry attempts stop rather than release the extended hold.
What if confirmation succeeds but the message fails?
Keep the verified reservation confirmed and flag communication separately. Staff should retry or contact the customer through an agreed channel. A delivery failure should not release capacity already committed to that customer.
If your business needs help connecting appointment holds, deposit review and customer updates, get in touch to discuss the workflow and its exceptions.