How a customer confirms or reschedules

Three actions on a reply

Action 1: confirm (the most common)

Mr. Tan taps Confirm. The link opens a tiny page — nothing to install, no login — that says “Thanks, you’re confirmed for Thursday 9:00am.” Behind it, a Function URL Lambda does three small things, in order. First, it writes a confirmed row to the ar-replies DynamoDB table for this appointment. Second, it updates the status column in the list sheet via the Sheets API so the front desk sees a green check next to his name. Third, it writes a confirmed row to ar-audit with the time, the appointment, and the channel he replied on.

From that point on, the “already confirmed?” check from Part 3 short-circuits the appointment to scheduled on every tick. Mr. Tan won’t get the 2-hour text, because he already said he’s coming. The system only nudges people who haven’t replied — confirming is how you opt out of the rest of the chain.

Action 2: reschedule (the save)

Sometimes the day no longer works. Mr. Tan has a meeting that ran long, or a school pickup landed on the same hour. Without a reminder, he’d just not show up. With one, he taps Reschedule two days ahead — while there’s still time to fill his old slot.

Reschedule opens a short page showing the open slots for his service over the next couple of weeks (read from the same list, filtered to free times). He picks one. On submit, the Function URL Lambda updates the list sheet with the new date and time, copies the old appointment’s chain rows from ar-sends to ar-sends-archive with a chain id, and clears the live chain so a fresh set of reminders starts against the new time. It writes a rescheduled row to ar-audit with the old time and the new time. And it frees his original slot, so a gap alert can offer it to someone else.

The next tick reads the new time, sees it’s more than the first window away, and lands at scheduled. The reminder chain begins again against the new appointment — same service, same schedule, clean state.

Action 3: cancel (the honest no)

Sometimes the customer just can’t make it and isn’t ready to pick a new time. That’s fine — a clean cancel two days out is far better than a no-show, because it gives you the slot back while it’s still sellable.

Cancel opens a one-line confirmation page. On confirm, the Function URL Lambda marks the appointment cancelled in the list, frees the slot, and posts a gap alert to the front-desk Slack: “Cancelled — Mr. Tan, cleaning, Thursday 9:00am. Slot now open.” A cancelled row goes to ar-audit. The reminders stop, of course — there’s nothing left to remind about. The waitlist, if you keep one, is where the front desk goes next.

If a cancelled customer later books again through any of the three intake lanes from Part 2, that’s simply a new appointment with a new row and a new chain. The cancelled one stays in the list, marked, so the history is intact.

Every action is logged, every action is reversible

The ar-audit table records every confirm, reschedule, and cancel with the time, the appointment, the channel, and a snapshot of the row before and after. If a customer rescheduled to the wrong slot, or tapped Cancel by mistake, the front desk can run an “undo last action” through a small admin command that reads the previous-state snapshot and restores the row. The undo is itself an audit row, so the trail of edits stays clean.

This kind of reversibility matters because the reply links are out in the world, on customers’ phones, tapped by people in a hurry. A misclick shouldn’t cost anyone an appointment. The audit trail is what lets the desk fix a wrong tap in seconds, and it’s the same trail the weekly summary in Part 6 reads to tell you how many no-shows you actually prevented.

Next post: the cost breakdown. The whole pipeline above runs in coffee-money territory at SMB volume; Part 6 explains exactly where the dollars go and why the text messages are the only line that really moves.

All posts