A walkthrough of the four ways into the system (Admin, Coach, Parent and Mobile) and how a booking actually moves between them. Every page below is a basic, clickable wireframe, not a picture of one. It's built to show how the pieces fit together and work, not what the final product will look like.
The venue's own back office, where every booking gets approved, every court gets managed, and every day gets run and reported on.
Everything here reads and writes the one shared calendar every other portal looks at. Approving a coach's request is the single moment a booking becomes a real, live session. Nothing appears for a parent to book, and nothing can be paid against, until that happens here. Attendance and payments recorded on the floor roll straight into the same day's report, automatically.
Where a coach requests court time and keeps track of what's booked, without ever picking up the phone.
A request submitted here lands in the Admin Portal as awaiting approval. It doesn't touch the public timetable or become bookable by a parent until staff act on it. A recurring request is checked week by week against everything already on the calendar: one clashing date gets reported and skipped, the other nine weeks still go ahead. "Tentative" is a separate, independent flag from approval. A coach can request a soft hold either way, and staff can still adjust it after approving.
Where a parent books and pays for their children's sessions, and joins a waitlist when a class is full.
Only approved sessions with real availability ever show up here. Nothing pending or declined is visible. Paying online charges immediately and marks the booking paid; choosing "pay at venue" still confirms the booking straight away, just leaves it marked outstanding until staff take payment on the day, the same record the front desk sees in the Admin Portal. Joining a waitlist is a genuine queue: when a spot frees up, it's held exclusively for whoever's next in line for a limited window, rather than offered to everyone at once.
The Parent Portal again, reflowed for a phone screen. Not a second app to build or keep in sync.
Identical data, identical sign-in, identical bookings. Only the layout changes for a smaller screen. The check-in tab is a placeholder for the roadmap's later QR check-in phase, shown here so the shape of the app doesn't need to change when that phase gets built.
Four different front doors, but one shared record behind them. Here's what actually happens to a single booking as it moves through the system.
Each portal only ever shows what that person is allowed to see. A coach sees their own bookings, never another coach's. A parent sees their own children and bookings, never another family's. Staff see everything, because running the venue is the job.
Online payments run through Stripe, the same technology used by most modern booking systems. Card details are handled by Stripe directly and never touch our own servers.
Not required reading, but here for anyone curious how the plumbing behind the last four pages actually fits together.
The supplied roadmap doesn't mention integrating with PlayHQ so this build and project estimate will not include one. If Rout Courts does want PlayHQ data brought into the system anywhere, let me know and I'll scope it in.