QZee: turning a no-show insight into a live booking platform
I co-founded QZee and led product design through a market pivot into a connected booking platform for service businesses.
Visit QZee live- Role
- Co-founder & Product Design Lead
- Team
- Co-founder · Engineering · Operations
- Year
- 2019 to 2025
- Platform
- SaaS · Web · Mobile
- active businesses
- 170
- unique customers
- 10,000
- raised in 2021
- £75k
- Google x Tramshed Academy
- Winner
Evidence note: The 2022 pitch shows the original hospitality concept; figures are owner-confirmed product outcomes, not claims that interface design alone caused them, and screen data is illustrative.
The problem
Venues could appear fully booked while reserved tables sat empty, but booking systems could not return that capacity to customers after a no-show. The larger challenge was finding a market where QZee could reach decision-makers, onboard businesses and learn quickly.
The work
A no-show became a two-sided product
During Eat Out to Help Out, my friends and I spent weeks trying to book somewhere to eat. When we went into town, the contradiction was visible: venues that appeared fully booked still had empty reserved tables. Staff told us those tables had bookings against them, so they could not simply release them.
Capacity existed, but the booking model could not recover it once a customer failed to arrive. I framed QZee as a two-sided product: venues could release last-minute capacity and manage bookings, while customers could find and claim that availability without adding deposit friction to every reservation.
In 2021, I helped pitch and raise £75,000 from private investors in South Africa, Japan, and Canada. The following year I took QZee through the 12-week Google x Tramshed Tech Startup Academy, pitched the product, and won the programme. The recording below captures the original hospitality proposition at that point in QZee's development. It is origin evidence, not a representation of later scale.
Pivoting into a market where we could learn faster
The hospitality thesis was credible, but the market made it difficult for an early startup to learn. Restaurant capacity is combinatorial: tables move, groups can fit multiple configurations, and a spare chair can change what is possible. The person who could approve a new system was also difficult to reach, while larger chains expected a level of established reliability we had not yet earned.
Service businesses offered an adjacent route. Staff schedules behave like capacity, but the staff-and-time model is clearer than mutable table allocation. Owners were more accessible, businesses could onboard faster, and real usage could expose the product's failure modes sooner.
Original market
Hospitality
- Capacity model
- Mutable tables and group sizes
- Buyer access
- Decision-makers were difficult to reach
- Adoption barrier
- Established tools felt reliable enough
Selected market
Service businesses
- Capacity model
- Staff availability and time slots
- Buyer access
- More direct access to operators
- Adoption path
- Faster onboarding into real use
Preserve the thesis · change the conditions for learning
This was not a reset. The job remained matching demand to live capacity. The pivot changed the operational constraints around that job so QZee could acquire evidence at startup speed.
That decision also changed how we worked. Engineering joined at wireframe stage so feasibility could alter the model before polish; live-user tests, A/B tests and pulse feedback then directed each iteration after release.
Building one product model for both sides
The owner console and customer booking experience could not behave like disconnected products. A service defined by a business needed to carry its category, duration, price, add-ons, availability, and terms into every place a customer might book it. The same booking then needed to appear correctly in the owner's calendar, customer record, communications, and payment state.
A guided setup experience helped owners move from an empty account to a bookable business, while the live calendar made availability and booking states actionable. This reduced the conceptual distance between configuring a service and seeing a real customer book it.
QZee One carried that shared model across the web products, email, payments and three further mobile products; the third mobile product remains confidential. Its architecture, accessibility evidence and guarded AI workflows are covered in the QZee One design-system case study.
A live platform serving businesses and their customers
QZee grew to support businesses ranging from gyms and multi-chain operators to AU Vodka, with the owner and customer experiences running from the same service, availability, booking and payment model.
I led product design across that ecosystem while working with my co-founder, engineering and the businesses using it; the company outcomes belong to that combined effort.
The pivot increased the rate at which we could learn
The most important decision was recognising that a valid customer problem sat inside a market that made evidence too expensive to acquire. Changing the market preserved the product thesis while making onboarding, testing and iteration faster.