A sports club in one system
A sports club with a padel school, a kids' programme, football and a barbecue area kept everything in informal records. We listened to its people, wrote down the club's rules and built one system where everyone sees their own part.
- Business
- Sports club and padel academy
- The problem
- They needed one reliable online system so the school and the kids' programme stop mixing, data does not leak across areas, and they stop relying on informal records.
The business and its problem
The club has two areas, padel and football, a padel school for adults, a programme for kids and a barbecue area that people book. Each part ran on its own: notebooks, messages and spreadsheets.
There was a first prototype, but it covered padel only, kept its data on a single computer and had two kinds of user. There was no football, no stock, no supply requests, no barbecue bookings and no reliable record of who did what. The club needed an online system, used from a phone or a computer, where everyone signs in with their role and one area’s data never mixes with another’s.
What there was and what was needed
| The earlier prototype | What the club needed |
|---|---|
| Padel only | Padel and football |
| Data kept on one computer | Online, on phone and computer |
| Two kinds of user | Six roles that combine |
| No stock, supplies or barbecue | Stock, supply requests and bookings |
| No history | A history that can't be erased |
How we analysed it
First, a survey of three groups at the club. Every question was answered from 1 to 5, to see where it hurt most.
With the answers I built the club's model: what exists (students, classes, areas, shifts), how it relates and which rules can't be broken. The rules were written in the club's own words, and a glossary fixes what each word means and which ones to avoid.
Then everything the system had to do was written as a concrete request, with its tests.
The survey
- Management
- Coaches
- Kids' programme families
The club's rules
- Every child in the kids' programme has at least one responsible guardian.
- A fee is either paid or pending: no partial payments.
- Any of a class's coaches can take attendance.
- Moving from the kids' programme to adults is decided by management only.
Glossary
- Operating area
- Padel or football: each with its notices, incidents, cleaning, stock and requests.
- Avoid: section, sector, module
- Shift
- The part of the day when an area's cleaning checklist is done.
- Avoid: schedule, slot
- Completion record
- The proof that a task was done, in which shift, by whom and at what time.
- Avoid: tick, check
What we built
One system with six roles, and a person can hold more than one, like a coach who also runs the padel area. To get in, everyone receives an invitation that expires after 24 hours.
Stock is worked out from every item in and out, and it warns when something is about to run out. Supply requests always follow the same steps, and the barbecue area never takes overlapping bookings.
Plan of the system, by part
Six roles that combine
Administrator, coach, padel manager, football manager, kids' programme manager and cleaning staff.
Classes
With one or more coaches, capacity and attendance, a technical score from 1 to 10 and a monthly note.
Padel and football areas
Notices, incidents and each shift's cleaning checklist.
Stock and requests
A balance worked out from every item in and out, with low-stock alerts, and supply requests.
Barbecue area
A calendar that never takes overlapping bookings.
Kids' programme
Each child with their guardians, and their monthly fee up to date or pending.
A supply request
- Pending
- Received
- In progress
- Done
Or it ends early:RejectedCancelled
The barbecue area, over a week
- Booked
- Third booking: rejected
Up to two bookings a day. A third is rejected, whatever the role.
How it is checked
The parts of the system were built with their own automatic tests, and they run on their own before publishing: if one fails, the change doesn't go out.
Each role's permissions are enforced inside the system, not just on screen: what a role can't see never reaches it.
And what matters stays in a history that can't be erased or edited: who changed what, and when.
Before publishing
- The tests run on their own before publishing
- If a test fails, nothing is published
- Each role's permissions, enforced inside
- Every change stays in the history
How it ended
On 17/09/2026 we showed the system to the club and the demo was approved. In the same meeting they asked for two changes: that the cleaning checklist resets every shift, to know what was done in each, and that the barbecue area takes at most two bookings a day.
That same day both changes were written into the specification, the glossary and a design decision. Court bookings stay in the system the club already used: they were left out on purpose.
The result
- The client demo on 17/09/2026 was approved.
- Both changes requested in the demo were added the same day.
That day's decision
Cleaning is recorded per shift.
Every task done leaves a record: which shift, by whom and at what time. That way each shift's history comes for free, and nothing depends on someone opening the system at the right moment.
Options set aside
- A tick that clears when the shift changes: it loses the history.
- Copying the whole checklist into every shift: it duplicates the tasks.
A closed shift can't be edited afterwards: what was done, stays.
Accepted on 17/09/2026
Does your business have something similar?
Tell me how you work today. I'll reply with questions to understand it and, if it's a fit, a written proposal.
Email me