Separate recovery from booking and reminders
This decision concerns the work after a missed-attendance report: verify the record, apply a named policy, make or record a capacity decision, coordinate staff work, and recover from an exception. It is different from deciding whether to build a booking portal or an appointment-reminder layer, though all three can touch the same appointment.
NIST's contingency-planning guide is used only for the general framing of named recovery ownership and testing. It does not establish an appropriate no-show policy, provider behavior, or custom-software outcome.
Check existing alternatives before custom work
Use this decision record to compare an existing booking process, a documented staff procedure, a configured system or integration, and a narrow custom layer. For each, record what it covers, what remains unknown or manual, and who verified the description. Then name one recovery requirement the non-custom alternatives fail, or record none. Do not assume a configured product has a feature until the responsible team has checked its current plan and workflow.
| Alternative | What it can cover | What remains unknown or manual | Owner who verified it |
|---|---|---|---|
| Existing booking process | __________ |
__________ |
__________ |
| Documented staff procedure | __________ |
__________ |
__________ |
| Configured system or integration | __________ |
__________ |
__________ |
| Narrow custom layer | __________ |
__________ |
__________ |
Name the unmet recovery requirement and the evidence for it: __________. If
the answer is none, the custom layer has not cleared the first decision gate.
Apply hard stops
Stop a custom build when any one of these remains unresolved:
| Hard stop | Why it blocks a custom layer |
|---|---|
| Attendance authority | A local label cannot decide whether a person attended. |
| Policy and exception owner | A workflow cannot choose a disputed classification on its own. |
| Capacity effect | A screen must not create availability by display. |
| Customer-contact boundary | Messages need a named policy and owner. |
| Operating ownership | A feature without access, support, and handoff ownership becomes another unmanaged dependency. |
| Safe recovery exercise | The team needs a bounded way to inspect a mismatch and escalation route. |
| Existing-alternative requirement test | A custom layer is not justified until a named requirement is unmet by documented or configured alternatives. |
If any hard stop fails, choose investigate, configure existing process, or do not build. Do not average hard stops into a score. If every row has named evidence and a named requirement remains unmet by the non-custom alternatives, the team may consider the smallest layer that preserves the existing booking authority and recovery ownership.
For the broader portal decision, see Should a Local Service Business Build a Custom Booking Portal?. For operational allocation, see Should a Service Business Build a Custom Dispatch Board?. For prevention before an attendance report exists, see Build a Custom Appointment-Reminder Layer?.
Does this decision record recommend a product or a no-show policy?
No. It makes unresolved authority, policy, capacity, and operating questions visible so the team can choose a smaller or non-custom option when appropriate.