Start with the booking authority
Before evaluating any interface, name the authoritative answer to three questions:
- Which person, system, or calendar decides that a time is available?
- Who may change, cancel, or override a booking?
- Who corrects a double booking, missed notification, staff absence, or outage?
If the team cannot answer these, a custom portal will merely make the conflict arrive through a nicer form.
Test three paths with the same scenario
Use the evidence packet's booking decision record with one representative, non-sensitive appointment scenario.
| Path | What it tests |
|---|---|
| Assisted process | Can a person reliably record the request, check authoritative availability, confirm, and recover? |
| Configured booking link | Can one approved service and availability window produce a record, notification, and cancellation path? |
| Narrow custom layer | Does a remaining observed gap justify additional identity, access, recovery, and support obligations? |
Do not compare convenience using different services, policies, or customer types. The question is whether the same operational outcome survives each path.
Apply hard stops before convenience
A hard stop cannot be averaged away by a cleaner brand, a faster form, or a shorter click path.
Stop at do-not-build when no person owns availability or the authoritative calendar; the flow collects payments, health, identity, or other sensitive data without an approved boundary and reviewer; cancellation, double booking, staff absence, or provider outage has no recovery owner; or the proposal adds multi-location allocation without an observed workflow and accountable operator.
A booking link is not proof of payment handling, identity verification, or allocation correctness. A custom form is not proof of any of them either.
Preserve what happened
For the trial, retain the requested time, authority checked, confirmation, change or cancellation, notification route, and final outcome. Do not retain more personal data than coordination requires. The point is to inspect where the workflow breaks, not to create a shadow customer database.
Make a build decision only after a real gap remains
Consider a narrow build only if the assisted and configured paths both fail a specific documented requirement, and the team can name a stable owner, authoritative data source, recovery procedure, and ongoing support boundary. Otherwise configure the smallest workable path and measure real exceptions.
The decision record intentionally has no vendor score. Vendor comparison belongs elsewhere; this page asks whether a custom application should exist at all.