One possible lifecycle
A common flow is Requested → Confirmed → Checked In → Completed. Requested may instead be auto-confirmed for businesses that accept every valid booking. Confirmed can become Cancelled or No Show; the exact policy depends on how the business handles walk-ins, deposits, and late arrivals.
This is a general architecture guide and does not describe or promise BDS's exact internal status model.
- Requested: received but awaiting a decision
- Confirmed: capacity is reserved
- Checked In: customer arrived and service is starting
- Completed: service finished
- Cancelled: reservation ended before service
- No Show: customer did not attend under the published policy
Make transitions explicit
Represent allowed transitions as a small policy, not scattered UI conditionals. For each transition, specify permitted actors, required fields, whether capacity is released, whether the customer is notified, and whether the change can be reversed.
A status update should be atomic with any capacity effect. For example, cancelling a reservation and making the slot available must not leave the calendar in a half-updated state.
- Requested → Confirmed or Cancelled
- Confirmed → Checked In, Cancelled, or No Show
- Checked In → Completed; exceptional cancellation may require a reason
- Completed is usually terminal; corrections should create an auditable adjustment
Handle edge cases without hiding them
Rescheduling is often safer as one operation that reserves the new interval and releases the old one only after the new reservation succeeds. If a customer cancels while staff are checking them in, use optimistic concurrency or a version check so one update does not silently overwrite the other.
Late arrivals, partial service completion, staff cancellation, duplicate webhook delivery, refunds, and notification failures need explicit business rules. A no-show label should not be inferred only from a clock passing if grace periods or staff overrides exist.
Keep an event trail
A current-state column answers what is true now. An event history answers who changed it, when, from which state, and why. Keep actor and reason fields proportionate to the operational need, and restrict access because notes may contain personal information.
Notifications are side effects: enqueue them after a committed transition, make delivery retry-safe, and avoid sending twice when a worker replays an event.
Implementation checklist
Write a transition table, test permitted and rejected transitions, and cover concurrent changes, time-zone boundaries, rescheduling, and notification retries. Keep customer-facing cancellation rules aligned with the state logic and the business's published policy.
- Who can create, confirm, cancel, or mark attendance?
- When is capacity released?
- Can completed or cancelled records be restored?
- Which transitions notify customers or staff?
- What audit fields are necessary?