Start with the outcome
Write the smallest outcome in operational terms: “a confirmed appointment with a named staff member and a recoverable record.” Then list what must be true for that outcome to hold:
- the right person can book or change it;
- the calendar reflects actual conflicts;
- the correct staff member and location are allocated;
- payment or deposits follow an owner-approved rule;
- confirmation, reminder, cancellation, and reschedule paths are visible;
- customer data is retained and accessed deliberately; and
- someone can support, recover, and retire the workflow.
If the outcome is only “a form sent to the team,” a custom portal may be a larger system than the business needs.
Check configured alternatives before custom code
Current provider documentation shows that existing scheduling products expose parts of this surface. Google Calendar appointment schedules provide a booking page and can block times based on calendar availability. Microsoft Bookings documents a customer-facing booking page and scheduling policy options. Square documents booking pages, embedded flows, staff and location choices, calendar sync, and optional prepayment features.
Those are documented capabilities, not a recommendation. Plan, region, configuration, permissions, and current product behavior still need a real trial. Treat each provider as a candidate to test, not as proof that the workflow fits.
Apply the hard stops
| Boundary | Question | Stop and investigate when |
|---|---|---|
| Identity | Who can view, create, change, cancel, or export a booking? | Roles are ambiguous or access is inferred from the UI |
| Calendar | Which calendars and conflicts control availability? | A double-booking cannot be detected or recovered |
| Allocation | Who, where, and what resource is booked? | Staff or location rules exceed the stated scope |
| Money | Is payment or a deposit part of the booking? | Money movement has no accountable owner |
| Communication | What confirms, reminds, changes, and cancels? | A missed notice has no recovery path |
| Data | What customer and service data is retained? | Sensitive data is required without a reviewed boundary |
| Accessibility | Can customers complete and recover the booking flow with the access methods they use? | Completion evidence or qualified review is absent |
| Operation | Who supports, recovers, and retires the system? | No named owner can operate it |
OWASP distinguishes authentication from authorization and recommends checking authorization on every request. A visible “cancel” or “staff” control is not proof that the server enforces the right relationship.
Run the same test twice
In two configured schedulers and one manual assisted path, use separate synthetic customer A, customer B, staff, and owner identities that the operator controls. Test normal booking, conflict, reassignment, cancellation, reschedule, export, confirmation, and support handoff. Attempt allowed and denied view/change/cancel/export actions; a visible control is not a denial result.
Record retention, deletion, and export behavior. In a test environment, disable or simulate failure of calendar sync and notifications, activate the manual fallback, and reconcile the records afterward. Do not disrupt a real provider or use real customer data. Use payment sandbox or test mode if available; otherwise mark deposits, refunds, and reconciliation unresolved. Record customer accessibility as untested until observed completion evidence or a qualified review exists; do not imply compliance.
Copy one row per alternative and hard stop:
| Alternative | Boundary and action | Expected result | Observed result | Evidence | State | Owner | Unresolved question |
|---|---|---|---|---|---|---|---|
| Provider A, Provider B, or assisted path | Example: customer B attempts to change customer A booking | Denied without exposing booking data | Leave blank until run | Redacted test record | unresolved | Named operator | Replace with remaining question |
Use only pass, fail, or unresolved for the state. Record plan or edition,
date, configuration, failure, and operator effort with each alternative.
Do not turn a successful booking into a product recommendation. Decide whether the remaining gap is acceptable, can be narrowed around an existing system of record, or creates a hard stop.
Choose the smallest credible outcome
Use configure when an existing path handles the tested outcome. Use narrow
when only a low-privilege presentation or handoff layer is missing. Use
investigate when a real trial is incomplete. Use do-not-build when payment,
sensitive records, multi-location allocation, authorization, or operational
ownership cannot be controlled.
Copy the booking decision record
| Gate | Representative state | Evidence still required | Hard stop |
|---|---|---|---|
| Outcome | Confirmed appointment with named staff and recoverable record | Ten recent requests and completion rules | Outcome is not defined |
| Existing path | No alternative exercised | Two provider trials plus assisted path | No alternative is exercised |
| Calendar and allocation | One location and two staff are representative only | Conflict, capacity, reassignment, and cancellation tests | Conflicts cannot be detected or recovered |
| Identity and authorization | Roles are representative only | Allowed and denied action matrix | Roles or server enforcement are unresolved |
| Money | Deposits are present but untested | System of record, owner, cancellation, refund, and reconciliation test | Payment workflow or owner is unresolved |
| Communication | Email is representative only | Delivery failure, fallback, and reconciliation test | Missed notice has no recovery owner |
| Data | Minimum contact and appointment data are representative only | Retention, deletion, export, and access results | Sensitive data lacks reviewed controls |
| Accessibility | Untested | Observed completion evidence or qualified review | Customer completion evidence is absent |
| Operation | No real owner observed | Support, outage, restore, retirement, and handoff exercise | No operational owner exists |
| Final decision field | Current record |
|---|---|
| Outcome | investigate — do not build now |
| Triggered stops | No alternative trial; authorization, payment, data, recovery, accessibility, and ownership unresolved |
| Evidence references | Representative record only; no provider result |
| Owner | Unassigned until a real operator participates |
| Reviewer | Security-conscious technical advisor pending |
| Date | 2026-08-05 |
Compare this record with the custom client-portal decision, the workflow-layer boundary, and the operational-owner hard stop.
This record does not choose a vendor or recommend custom code. Its current answer is to investigate and avoid building until the missing evidence exists.