Booking HandbookPlan professional appointments.
First checks
- Name the current stage
Availability, request, review, confirmation, and the downstream professional record are related but not interchangeable.
- Separate the people
The client, booker, receptionist, provider, manager, administrator, referrer, and integration need attributable roles.
- Bound the intake
Collect only the operational information whose purpose, appointment, visibility, editor, and lifecycle you can explain.
- Reconcile every change
A provider, duration, time, cancellation, or portal edit must reach each dependent view without erasing history.
Do the request, people, intake, appointment, and handoffs still agree?
Choose one invented operational state. The checker identifies the first boundary that needs repair and points to the shared guide that owns the deeper rule.
Compare the dependent views
The core operational state may align, but dependent views are unlinked or unchecked. Reconcile the portal, reminder, calendar, API, export, and history before closing the change.
- Check next
- Professional-appointment cross-view reconciliation, then message, calendar, API, and export delivery
Request stage
rescheduled
Availability, request, review, confirmation, and closed states must remain distinguishable.
Client identity
stable
The request and appointment need one explicit current client relationship.
Intake snapshot
minimum current
Any intake needs a declared minimum, version, visibility, editor, and appointment link.
Role boundary
bounded
Each actor needs a bounded record scope and permitted action.
Provider allocation
eligible current
The current appointment points to the current eligible provider or releases the allocation.
Duration result
valid current
The appointment preserves the current shared duration and availability outcome.
Change attribution
attributable current
Each material change preserves an attributable actor, channel, old state, and new state.
Cross-view handoff
not checked
Dependent portal, message, calendar, API, export, and history views need a stable relationship.
Synthetic operational consistency only; no identity, permission, intake, professional-record, medical, legal, privacy, security, compliance, delivery, or named-product result was observed.
Understand the complete consistency rule
Map one operational appointment without making medical, legal, privacy, or compliance claims.
A professional appointment can begin as public availability, a qualification request, a referral, or a returning-client booking. Before comparing software, define the request stage, the people and roles involved, the minimum intake needed, and what must change together when the appointment moves.
The time can look correct while identity, intake, permissions, or history are wrong.
A request can exist before a durable client record. A receptionist may need to schedule without seeing every field. A provider change can leave an old name in a reminder or export. A portal cancellation can fail after the duration changes. These are record and handoff problems, not just calendar settings.
The consistency rule
Consistent professional appointment = declared request stage + stable client and appointment identities + bounded roles + versioned intake reference + current provider and duration results + attributable change + reconciled handoffs
The invented fixture below follows one adult's generic consultation request through review and confirmation, then changes the provider, duration, time, and cancellation state. The checker asks whether the operational records still agree; it never evaluates professional judgment or regulated suitability.
Follow the complete request-to-appointment workflow
- Declare the entry stage
State whether the person is only viewing availability, submitting a request, waiting for review, or receiving a confirmed appointment. Do not promise confirmation too early.
- Separate identities and roles
Record the client or patient, any separate booker, receptionist, provider role, assigned provider, manager, administrator, referrer, and integration identity independently.
- Define the minimum intake
For each field, write its operational purpose, applicable appointment type, visible roles, allowed editors, version, and current or superseded state before collecting an answer.
- Apply shared scheduling rules
Use the staff, location, resource, duration, buffer, availability, cancellation, form, and permission guides for their calculations. Keep only their current results and references here.
- Confirm one appointment
Give the appointment a stable identity and current client, provider, duration, time, delivery, intake, referral, policy, reminder, calendar, API, and export references.
- Change and reconcile
After every portal or staff change, record the actor, channel, old state, new state, and outcome, then compare all customer, staff, provider, message, calendar, API, export, and history views.
Compare the four appointment entry models
Availability only
Show possible times or working periods without accepting or confirming a booking.
Watch for
Do not let a visible opening imply that the provider, appointment type, intake, or request has been accepted.
Request and review
Collect a bounded scheduling request, route it to an eligible reviewer, and return an explicit accepted, declined, or needs-information result.
Watch for
A routing answer is an operational input, not proof of referral validity, urgency, suitability, or professional judgment.
Direct appointment
Confirm a standard appointment when identity, provider, duration, time, location, and policy results are already known.
Watch for
A fast booking path still needs attributable changes and current downstream references.
Established-client access
Offer selected appointment types or time windows to an existing client relationship while preserving separate permission and identity checks.
Watch for
A portal account or matching email is not, by itself, proof of authority, identity, or lawful access.
Review the eight connected operational records
Request
Owns the entry channel, requested service category, preferred time, current review state, and provisional identity reference.
Failure to test
The request is treated as a confirmed appointment or disappears when a durable client record is created.
Client identity
Owns the stable operational person reference and explicit links to a separate booker or provisional request identity.
Failure to test
A duplicate, missing, or silently merged identity sends the wrong appointment, history, or message to someone else.
Appointment
Owns the stable booking identity, lifecycle, current time, provider allocation, duration result, location or delivery mode, and linked references.
Failure to test
A reschedule creates an unrelated booking or leaves old provider and time data active elsewhere.
Provider role and allocation
Separates the kind of provider required from the eligible person currently assigned by the shared availability rules.
Failure to test
A generic staff label hides who is assigned, or a provider change updates only one calendar.
Intake snapshot
Owns the operational purpose, field version, answers reference, appointment link, visibility, editor, and superseded state.
Failure to test
Staff cannot tell which version was answered, who changed it, or which appointment it describes.
Referral reference
Preserves that a referral or introduction was supplied and its operational status without deciding its professional validity.
Failure to test
The scheduler treats a reference as verified authority, eligibility, urgency, or a completed professional record.
Permission decision
Points to the shared role-and-field calculation for the exact actor, record scope, and attempted action.
Failure to test
Every employee becomes an administrator, or denial exists only as a hidden interface convention.
Change and handoff history
Owns the attributable actor, channel, time, old state, new state, and reminder, calendar, API, export, and downstream outcomes.
Failure to test
The visible appointment is correct while messages, integrations, exports, or the change record remain stale or unattributed.
Inspect the complete invented appointment
This six-stage fixture uses invented adults and operational labels only. It contains no real client, patient, provider, health, legal, financial, identity, referral, or professional-record data.
Request
Not yet confirmed
REQUEST-1 records a generic 45-minute professional consultation request from invented adult CLIENT-1.
Roles
Scopes declared
RECEPTION-1 reviews the request; PROVIDER-A, PROVIDER-B, ADMIN-1, REFERRER-1, and INTEGRATION-1 keep separate operational roles.
Intake
Minimum reference
INTAKE-1 contains only synthetic scheduling preferences, a version, purpose, appointment link, visibility list, and editor state.
Appointment
Stable identity
APPOINTMENT-1 is confirmed with PROVIDER-A, a 45-minute shared duration result, and current time and delivery references.
Change
Old and new states kept
The provider becomes PROVIDER-B, duration becomes 60 minutes, and CLIENT-1 requests a new time through the synthetic portal.
Cancellation and reconciliation
No external write
The portal cancellation records its actor and outcome; every staff, provider, intake, message, calendar, API, export, and history view is compared.
Review appointment changes and demo warning signs
When the appointment changes
A request becomes an appointment
Link; do not overwrite
Preserve the request, explicit review outcome, client identity, and new stable appointment rather than treating a submitted form as instant confirmation.
A provider changes
Move the current allocation
Use the provider eligibility result, preserve the old assignment, and update portal, staff, provider, message, calendar, API, export, and attribution references.
The duration changes
Re-run shared rules
Use the shared duration and availability guides, then apply the resulting time and release states to the same appointment identity.
The client edits intake
Version the snapshot
Record the editor and current answers without erasing the previous appointment-linked snapshot or assuming that the content is appropriate.
The appointment moves or cancels
Record every outcome
Preserve actor, channel, policy reference, old and new state, released capacity, reminder, calendar, API, export, and failed-retry outcomes.
A handoff fails
Repair without duplication
Keep the request, client, appointment, intake, provider, and change identities stable while retrying or correcting only the dependent record.
Warning signs in a software demo
A submitted form means confirmed
The demo cannot separate visible availability, a request, manual review, and a confirmed appointment.
Everyone is an administrator
Reception, provider, manager, administrator, client, and integration roles have no bounded record or action scope.
Intake is an unlimited notes box
The product cannot explain purpose, applicable appointment, visibility, editor, version, correction, export, or disposal boundaries.
Provider means staff
The required provider role, eligible pool, assigned person, substitution history, and customer-facing identity cannot be separated.
A change edits only the calendar
Portal, reminder, intake, provider, API, export, or history views retain the old time, duration, person, or state.
Compliance is a marketing label
The demo substitutes a badge or generic feature claim for qualified review of the actual workflow, configuration, contracts, data, jurisdiction, and operating controls.
Prepare the next controlled rehearsal
One controlled operational rehearsalTest the handoffs before any sensitive or professional data enters the system.
Use one invented adult, request, receptionist, two providers, appointment, minimum intake snapshot, referral reference, provider change, duration change, reschedule, cancellation, and failed notification retry.
- Write the stage and record owner for availability, request, review, client identity, appointment, intake, referral reference, provider allocation, permission decision, and change history.
- Confirm the appointment, change provider and duration, edit one synthetic intake answer, reschedule, cancel, and retry one failed handoff while preserving every old and new state.
- Compare portal, receptionist, provider, administrator, intake, referral, reminder, calendar, API, export, and history views; record stale, missing, duplicate, excessive, or unattributed state.
Keep the rehearsal controlled
- Use invented adults, roles, requests, appointment types, scheduling preferences, referrals, messages, calendars, exports, and records only.
- Do not enter real health, legal, financial, identity, client, patient, provider, referral, payment, account, message, calendar, or professional-record data.
- Do not convert documentation or checker output into a compliance claim, professional judgment, product verdict, recommendation, purchase, affiliate route, or implementation approval.