An app can look ready while its copy of tomorrow’s bookings is already out of date. A cancellation arrives after the snapshot. Someone changes a time. A walk-in asks for a slot. Before changing which system staff use, decide where each of those changes belongs and how you will prove it survived.
This Part 2 planning exercise produces a booking register, a numbered change journal and a go/hold decision. You can carry those rules into a booking prototype in Overskill, then test the prototype before considering any real switch. The example is fictional. It does not import bookings, synchronize systems or demonstrate a working rollback.
Download the booking cutover worksheet. It includes the filled example, the complete answer key and a blank planning section. All real-system test results start as Not tested.
Give one place authority at a time
Lin is the only operator allowed to accept changes in this example. The labels below describe a proposed operating policy; they do not prove a particular app can enforce it.
Scroll horizontally to compare all columns.
| Phase | Where Lin may accept a booking change | What other places do |
|---|---|---|
| OLD | The existing register, with every accepted change entered in its journal | The candidate is a copy to reconcile |
| FROZEN | Nowhere, during the short fictional review interval | Both copies stay read-only; requests remain unconfirmed |
| NEW | The reconciled candidate after explicit approval | OLD stays read-only |
| PAUSED | Nowhere | Keep the last accepted state and one owned HOLD queue for unconfirmed requests |
For a real business, identify a workable way to receive requests without promising an unverified time. If you cannot safely keep one writer, preserve late changes or operate an owned fallback, hold the plan. Do not disable the only process that is keeping bookings safe.
Start with six identifiable bookings
The snapshot is taken at 08:00 UTC on November 3, 2026. All appointment times in this exercise use UTC. Each booking occupies 45 minutes, with the end excluded. Customer aliases C01–C06 are fictional; there are no contact details or payments to move.
Ada has B01 at 09:00, B02 at 10:00 and B03 at 11:00. Mo has B04 at 09:00, B05 at 10:00 and B06 at 11:00. All six are confirmed at revision 1. Keep these IDs through the exercise: a reschedule changes the original booking, and a cancellation stays in the register as cancelled.
This guide starts after the fields and IDs have been chosen. Use the spreadsheet mapping guide for that earlier decision, and the booking-day exercise for availability rules. Here, the problem is keeping accepted changes accounted for while authority moves.
Apply the journal, not just the snapshot
Give each event a stable ID, sequence, time, operator, source and payload. An identical replay of the same event changes nothing. Reusing its ID for different content is a conflict, even if the new content looks plausible.
Scroll horizontally to compare all columns.
| Event | Fictional instruction | Expected effect |
|---|---|---|
| J001 | Cancel B02 after the snapshot | Keep B02, mark it cancelled, revision 2 |
| J002 | Move B04 from 09:00 to 12:00 | Same ID, revision 2; preserve 09:00 in history |
| J003 | Record an in-person request accepted for Ada at noon | Create B07 once; this is a noon appointment, not service at intake time |
| J004 | Find B05 at 10:00 in OLD but 10:30 on a stray candidate sheet | Record conflict K01; accept neither an automatic reschedule nor a second booking |
| J005 | Lin resolves K01 using the authoritative row and journal | Keep B05 at 10:00; revision 2 records the resolution, not a time change |
After J003 there are seven records: six confirmed and one cancelled. J004 leaves those counts unchanged, so counts alone would conceal the conflict. The decision is Hold until Lin records the evidence and reason for J005. A later timestamp on a stray sheet does not make it authoritative.
The worksheet gives every event’s exact time, the final register and the preserved history. Check IDs and times as well as totals. Missing a sequence, replaying changed content or accepting a stale booking revision fails the local reference check without changing its state. That check is a planning aid, not a server concurrency guarantee.
Make “go” depend on a named checkpoint
J006 freezes OLD. The proposed candidate must reconcile through J005: seven records, six confirmed, one cancelled, B04 at noon and no open conflict. J007 records a fictional approval to make NEW authoritative only after all eight worksheet checks are explicitly passed.
Those checks cover identity, cancellations, staff/times, revisions/history, the journal watermark, conflicts/requests, one-writer authority and rehearsed access/availability/recovery. Unknown, missing or failed evidence means Hold. The example declares its checks passed to show the decision; it is not evidence that Bookslot or any generated app passed them.
In your own plan, replace each declared result with an observed result, an evidence reference and a named owner. Use the launch checklist and interruption tests to plan the separate app checks. Do not treat a checked worksheet as a migration test.
Preserve the changes accepted after handoff
NEW accepts B08 for Mo at 13:00 in J008, then cancels B03 in J009. The register now has eight records: six confirmed and two cancelled. J010 pauses acceptance while Lin inspects a recovery problem in the fictional rehearsal.
During that pause, J011 records a request to move B08 to 13:30. It goes into HOLD as unconfirmed, owned by Lin. B08 stays confirmed at 13:00. Do not put 13:30 into the accepted register because someone asked for it.
Returning to the OLD copy from before handoff would lose B08 and show B03 as confirmed again. It would also omit the unconfirmed J011 request. Switching a website address or restoring earlier code does not reconcile those facts.
Decide what must happen before a return
The default decision after the pause is Hold. A proposed return-to-old needs a separately prepared fallback that retains every accepted change through J009 and preserves J011 separately. Compare exact IDs, statuses, times, revisions and history. Then verify the one-writer plan, actual access/availability/recovery behavior, named approval and communication plan.
The worksheet calls a fully matching fictional fallback eligible for review. It never calls a real rollback executed or safe. If your old system cannot represent a late booking, a cancellation or its history, the matching test has failed even if a total looks right.
Bring the policy into a small Overskill prototype
Overskill can be your place to build and test the proposed workflow. Start with a fictional register and a visible phase, rather than copying live customer bookings into an untested app. The service-booking guide gives broader booking requirements; the Bookslot catalog page is a candidate to inspect for a suitable starting point. Neither this exercise nor that link establishes import, journal, freeze, synchronization or recovery behavior.
If the plan is worth prototyping, open the app brief builder. Edit its audience, outcome and records inputs, then review the generated brief before choosing Start build. Describe one operator, stable booking/event IDs, cancelled rows, expected revisions, conflict resolution and a separate unconfirmed-request queue. Keep records restricted to authorized staff and test copied links and unauthorized reads/writes as separate requirements. The link does not attach the worksheet or move any booking; supply the fictional setup and expected answers separately.
If the existing process still meets the need, or the authority and recovery questions are unresolved, keep the current safe process and record the next test. The spreadsheet-or-app decision guide can help make that stop decision explicit.