Test the current boundary first

Start with one safely simulated appointment. Have an accountable owner identify the authoritative appointment record, approve one reminder, observe a reply or no-reply condition, and record what changes afterward. If an existing system is in scope, perform the same bounded exercise in an approved environment. Do not infer message, calendar, or reply behavior from a sales page.

The current small-business discovery signal records a request for confirmation-email cancellation and rescheduling actions. It establishes question demand only; it does not prove that reminders reduce missed bookings or that a custom system is needed.

Apply hard stops before building

Do not build when any answer is unknown:

  • Which record is authoritative for appointment state and message timing?
  • Who approves message content, consent handling, and policy exceptions?
  • How does a reply, cancellation, or reschedule reach an accountable owner?
  • What data may the layer read or write, and who owns access?
  • Who corrects an incorrect or incomplete message result?
  • Who supports the system when the builder is unavailable?

NIST's Secure Software Development Framework recommends defined organizational roles and responsibility for development activities and associated risks. That supports the general need for accountable roles here; it does not say a custom reminder system is required or secure.

Choose the smallest credible path

Use the appointment-reminder decision record in this draft's evidence packet to compare an assisted handoff, a configured path, and a narrow custom layer. No approved trial means investigate, not build. Build only when the existing paths fail the same stable requirement and the hard stops are resolved.

For an inbox boundary, see Should a Service Business Build a Client-Message Inbox?. For the broader booking decision, see Should a Local Service Business Build a Custom Booking Portal?.

Can a custom reminder layer sit beside the current booking system?

Only if its record authority, message policy, data access, support, and recovery boundaries remain explicit. A narrow layer may be appropriate, but it should not silently become the source of truth for appointment decisions.