Seth Godin: Separate an Appointment Request From a Confirmed Booking
Rehearse two competing requests, an approval and a cancellation before choosing a booking tool.
Choose, practice, reflectA practical lesson
The Lesson
A visitor asks for an appointment. Has a place been reserved, or has someone merely received a request? If the screen, the organizer’s notes and the visitor’s understanding give different answers, attractive design will not settle the disagreement.
In On writing a spec, Seth Godin recommends describing what a system receives and returns, including how earlier events change its current condition. He suggests simulating interactions before committing to an implementation. His official biography identifies his work as a writer and teacher. We can use that planning perspective to examine a small appointment flow before choosing software.
For this lesson, separate the request record from the slot record. A request can be awaiting review while the requested slot remains available. Later, an organizer may confirm it and reserve the slot. Those are different events, and a useful plan explains which one has happened.
Write the rule before drawing the page. In the fictional rehearsal below, submitting a request does not hold a slot. An organizer reviews requests in arrival order and confirms a request only if the slot is still available. This is one deliberately chosen practice rule, not a recommendation for every booking service. A different project might use temporary holds; that would need a different explanation and rehearsal.
Also decide what the visitor can be told. A receipt can acknowledge a request without saying an appointment is booked. A confirmation requires the organizer’s decision and an available slot. Write these messages beside the records they describe so the wording can be checked against the actual event.
The output is a paper process you can explain, not a functioning booking system. A future implementation would need its own review of simultaneous actions, permissions, privacy and other requirements. Completing this rehearsal does not establish that software handles those issues.
Reflection
- Which event should reserve a place: submission or approval?
- Who is allowed to make that decision?
- What should happen when two requests name the same slot?
- If a booking is cancelled, does another request move automatically, or need a fresh decision?
- Could a visitor mistake your receipt wording for a confirmation?
Practice
Original SelfGrowthVideos exercise: trace two requests through one appointment slot. The fictional rules, records and examples are ours, informed by Godin’s planning perspective. They are not his booking method or an endorsed software design. Use paper and request IDs, with no real contact details or messages.
- Make two small records. Draw a slot list with Slot A and Slot B, both available. Draw a request list with columns for ID, requested slot and current status. Put the practice rule above them: a request does not reserve a slot; an organizer must confirm it while the slot is available.
- Receive two requests. R1 asks for Slot A. R2 also asks for Slot A. Add both as awaiting review, in that order. Keep both slots available. Write a receipt such as, “Request R1 received for Slot A; awaiting review. This is not a confirmed appointment.” Give R2 its own receipt with the same distinction.
- Confirm the first request. The organizer reviews R1, checks that A is available, marks R1 confirmed and marks A reserved for R1. Record this as a separate event. Now a confirmation may say, “Request R1 is confirmed for Slot A.” Slot B remains available.
- Review the conflicting request. R2 still asks for A, but A is reserved. Mark R2 as needing an alternative. Do not confirm it or quietly change it to B. Your note can say that the requested slot is unavailable and another choice is needed. R1 remains confirmed; A still belongs to R1 in this rehearsal.
- Record a cancellation without inventing another decision. Suppose R1 cancels. Mark R1 cancelled and A available. R2 remains in the needs-alternative state until the organizer makes a new decision. The cancellation alone does not confirm R2. If you want to support automatic promotion in a future design, describe that as a proposed rule change and rehearse it separately.
- Reconcile records and wording. For each event, write the request status, slot status and permitted visitor message on one line. After cancellation, there should be no confirmed request and no reserved slot. Check that every confirmation in the event history corresponds to a confirmation decision, rather than merely to a submitted form.
Ask a willing peer to process the same events using only your written rule. Let them flag uncertainty rather than filling it with your spoken explanation. If they reserve A on receipt, find the sentence or label that led them there. Clarify it, reset both lists and repeat the sequence.
Review
Can you explain why two received requests did not create two bookings? Can another reader distinguish the old confirmation in the event history from the current cancelled status? Keep the history and the current records visibly separate; each answers a different question.
At the next check-in, add one proposed change, such as allowing an organizer to offer Slot B. Write who must accept that offer before it becomes a booking. Do not add a polished confirmation screen until you can explain the decision it represents. Your next useful step is the unresolved rule, not necessarily a new feature.