01
What a parallel week is and is not
During a parallel week, the old system stays live and players keep booking through it. Staff mirror every booking, cancellation, and payment into the new system by hand, within the day. Nobody outside the club sees the new system yet. The point is to find where the new setup differs from reality while the cost of a mistake is a staff member’s 10 minutes, not a player’s evening.
It is not a training week, and it is not a data migration. Training happens before it. Migration happens before it. The parallel week tests whether both were done right.
02
Set up the new system with the real week
Import the export first: courts, prices, members, future bookings, classes. Then walk the schedule for the coming week in the new system and compare it, court by court, with the old one. Every difference is a setup error to fix before the week starts, not during it.
- Courts with the same names and the same hour grid
- Price bands for every hour, including member rates
- Cancellation window set and shown at checkout
- Recurring bookings for regulars generating the right dates
- Class schedule with capacities and current rosters
- A test payment made and refunded with a real card
03
The staff routine, morning and evening
Each morning, one staff member opens both systems side by side and enters yesterday’s new bookings into the new one. Each evening, the same person cancels in the new system anything cancelled in the old one, and records any walk-in or phone booking. Keep it to one person per shift so that nothing is entered twice.
Ask that person to write down every moment they hesitated. A hesitation is a screen that is unclear, a field that is missing, or a rule that does not match how the desk works. That list is more useful than any feature comparison.
04
What to compare each evening
At the end of each day, compare 3 things: the number of bookings in each system for that day, the revenue total for the day, and the list of players with bookings tomorrow. The counts should match. If revenue differs, look for a price band set wrong or a member discount not applied. If the player list differs, a booking was missed in the mirroring or a recurring rule generated the wrong date.
- Booking count per court, old versus new
- Revenue total for the day, old versus new
- Tomorrow’s player list, old versus new
- Cancellations and refunds processed in both
- Any hesitation notes from the desk
05
The go or no-go checks
At the end of the week, go through the list. The new system should have matched the old one on every day’s count and revenue, or the differences should be explained and fixed. Staff should be able to book, cancel, refund, and move a booking without looking anything up. The test payment should have appeared in the payout report. If any of those fail, run a second week. A second week costs little. A broken launch costs regulars.
06
Then the soft launch
After a clean week, switch the order: the new system becomes the one players use, and the old one stays open, read-only, for lookup. Staff still check both for a week, this time to catch players who used an old link. Then the old system is closed. The message to players goes out at the start of the soft launch, not before, so that the link they receive is already the one that works.