Booking state
A confirmed, moved, cancelled, or refunded booking is visible to staff and the player without a second calendar.
How Lobby works
A player books. Staff sees it. The club gets paid.
Lobby keeps the public booking flow and the private club record connected from availability to payment and every change after it.
Explore the product- 01
Publish real availability
Courts, lanes, classes, prices, access rules, holds, and staff blocks define what a player can book.
- 02
The player books and pays
The club website shows the available option, collects the booking details, and sends card payment to Stripe.
- 03
Staff manages the change
A move, cancellation, refund, waitlist promotion, or attendance update changes the same club record.
- 04
The operator can trace it
Schedule, member, and payment context remain connected for support, reporting, and export.
The player side
Show what can actually be booked.
Players choose the activity, date, time, and available option on the club website. The price and access rules come from the same configuration staff manages.
Illustrative product flow
Now
Your club
Book tonight
TodayWedThuFri
Padel court 02
18:00 to 19:30
Open play
19:30 · 2 spots left
Tennis lesson
20:00 · Coach Mira
4 more slots after 21:00
HomeBookActivity
yourclub.com/admin/scheduleIllustrative demo data
Illustrative demo data
Padel · 4 courts
17:00 — 21:00
Open play
Court 01 · 4/4
Lesson
Court 02 · Coach SV
League
Court 03 · R4
Reservation
Court 04 · 2/4
Tennis · 2 courts
17:00 — 21:00
Reservation
Court T1 · Lefèvre +1
Holding · 90s
Court T2 · new booking
Swim · 6 lanes · 25 m
17:00 — 19:00
L1
4/4
L2
4/4
L3
Lesson
L4
3/4
L5
1/4
L6
Free
The staff side
Work from the same availability players see.
The front desk can add a reservation, hold time, move a booking, change capacity, or close a resource without reconciling a separate public calendar.
What stays connected
One action should not create three cleanup jobs.
The operational handoffs remain visible without pretending that Stripe, the schedule, and the member record are the same thing.
Capacity
Court availability, class spots, lane capacity, and waitlists update from the same action that changed them.
Payment context
Lobby keeps the operational reference while Stripe processes the card and settles funds to the club.
Changing systems
Migration is its own job, with its own checks.
Imports, staff verification, domain setup, and cutover belong in a separate switching plan, not inside the explanation of the everyday product.
Questions
The product loop, clearly.
Where do players book?
On the club’s branded booking website. Lobby is not a marketplace and does not place a marketplace profile between the club and its members.
Who processes the payment?
Stripe processes card payments for the club. Lobby connects the payment state to the booking but takes 0% of booking revenue.
What happens when staff moves or cancels a booking?
The schedule and booking record update together. The applicable refund, credit, capacity, and notification behavior follows the club’s configured rules.
Can we test this before members use it?
Yes. The 30-day Pilot is a private workspace for testing the real schedule and workflows. Publishing and live online payments require a paid plan.
How do we move from our current tool?
Migration is a separate, verified process covering the source export, dry run, staff review, and cutover. The migration page explains that path in detail.
Ready when you are
Test the full booking loop with your own club rules.
Start a 30-day Pilot, build the real schedule, and see what staff and players would use before anything goes public.
Book a demo