August is not the month to change your booking system
For a seasonal business, when a new system goes live matters as much as what it does. Why I push back on mid-season launches, and what a sensible calendar for a software project looks like.
It is the beginning of July, the season is running, and something breaks. The calendar double-books a boat. A booking form swallows three enquiries. The spreadsheet everyone shares gets overwritten. The owner, understandably, wants it fixed properly, and wants it now.
This is the moment I am most likely to say something a client does not want to hear: not now.
Why mid-season launches go badly
Changing how a business takes bookings is not a software event. It is a people event. Staff have to learn where things are, trust what the screen says, and stop keeping a private backup "just in case". That takes a few weeks of normal days.
In August there are no normal days. What happens instead:
- Nobody has time to learn. New screens get used the old way, or not at all, and the paper backup becomes the real system again.
- Every teething problem is expensive. A small bug in March is a conversation. The same bug on 14 August is forty angry guests.
- Old and new overlap. Half the season's bookings are in the old system and half in the new one, which is worse than either.
- The people who know the problems best are too busy to explain them. And their explanation is exactly what a good system is built from.
What to do in July instead
Fix what you must, with the smallest possible change — a patched form, a shared calendar tidied up, a rule everyone agrees to follow until September. Then do the most useful thing for the next project, which costs nothing: write down what goes wrong, as it goes wrong.
"Tuesday: hotel called about a booking we had no record of." "Friday: two staff sold the last two places at the same time." That list, kept for a month, is worth more than any requirements meeting in October.
A calendar that works
For a summer business, a project tends to fit something like this:
- September–October: talk it through, while the season is fresh and the list is long.
- November–January: build it.
- February–March: staff use it on real bookings for the early season, when mistakes are cheap.
- April onwards: it is simply how things are done.
For a winter business — a ski shop, a mountain event — shift everything by six months. The work for Sports&Ski's rental system revolved around the ski season in the same way: kit tracked by serial number, boots and poles, deposits and balances all had to be ready before the shop was full of people wanting skis.
The dive centre reservation system we built for Mykonos Diving Center was delivered in October, after the season, with the whole winter ahead for the team to get used to it. By the following summer it was not new any more.
Mykonos Diving CenterReservations, payments and partner commissions in one system
The honest version
Sometimes you cannot wait. If the current system is losing bookings every day and there is a small, contained fix, we will do it in August and plan the proper version for autumn. What I try hard to avoid is a big switch in the middle of the busiest weeks, because the odds are stacked against it.
If this season is teaching you what your next system needs, keep the list. Send it to us in September.