Case study
Zippy Booking
My own cloud booking platform for rental, activity and service businesses — built, hosted, supported and improved by me.
- Sector
- Rental, activity and service businesses
- My role
- Product owner, developer and operator
- Status
- Live and in active development
The problem
Businesses that sell time, equipment or people run into the same wall. A booking isn't really a slot in a calendar — it's a claim on a specific resource, for a specific window, subject to staff availability, turnaround time and payment.
Generic booking tools model the calendar and leave the rest to you. So the operator ends up double-checking every online booking against a stock sheet, holding a mental map of what's actually free, and handling deposits, reminders and cancellations by hand. It works at low volume and quietly fails as things grow.
The knock-on effects are consistent across the businesses I spoke to: double bookings during peak weeks, deposits chased late or not at all, staff unsure of the day's schedule, and no reliable view of what capacity was actually used.
What I built
Zippy Booking is a cloud platform covering the whole booking operation rather than just the point of sale.
Online bookings
Customers book directly from your site, with the same availability the counter and phone see.
Real availability
Availability calculated from actual resources, staff and turnaround rather than an open calendar.
Payments and deposits
Deposits, balances and refunds handled as part of the booking rather than as a separate task.
Calendars and scheduling
A live operational view of what's booked, by whom and against what.
Staff management
Who's working, what they're assigned to, and what the day looks like — visible without a phone call.
Equipment management
Items tracked individually so stock, condition and servicing are part of availability, not a separate sheet.
Customer records
History, contact details and past bookings in one place instead of across an inbox.
Automated emails
Confirmations, reminders and follow-ups sent automatically at the right point in the journey.
Mobile-friendly management
Designed to be run from a phone, because most of these businesses aren't run from a desk.
Why it matters
The operational effect is that a booking stops generating work. Payment, confirmation, resource allocation, staff notification and reminders all happen as consequences of the booking rather than as tasks afterwards.
The second effect is trust in availability. When availability is calculated from real resources, staff can answer 'can you do Saturday?' immediately and correctly, which removes both the double-booking risk and the habit of holding capacity back 'just in case'.
The third is visibility. Because everything runs through one system, operators can finally see what capacity was actually used rather than inferring it from bank statements at the end of a season.
What it means for my consultancy work
Zippy Booking isn't a portfolio piece. I host it, support it, handle its incidents and ship changes to it continuously. That's a different discipline from delivering a project and moving on.
It's the reason I'm careful about maintenance budgets, sceptical of clever solutions that will be hard to support, and blunt about the fact that most of a system's cost arrives after launch. Those aren't consultancy opinions; they're operational scar tissue.
On results
I've deliberately not published customer numbers, revenue figures or time-saving percentages for Zippy Booking, because I won't publish metrics I can't evidence. If you'd like verified figures or a named customer reference added to this case study, send me what you're happy to have public and I'll include it.