Bewijs de werkende week van één trainer voordat je vindbaarheid, uitbetalingen en ondersteuning voor meerdere trainers toevoegt.
Case · Boekingsproduct · Opdrachtgever Ruud
Padel Next Level
Een gericht lesboekingsproduct voor één echte trainer en zijn leerlingen: één gedeelde boekingswaarheid in plaats van afstemming via WhatsApp, zonder marktplaatscomplexiteit voordat de kernweek werkt.
Voor wie
Ruud is de trainer, beheerder en tester namens de opdrachtgever. Zijn leerlingen moeten een agenda kunnen openen, zien wanneer hij beschikbaar is en daar boeken — zonder op chat te wachten. Ruud heeft één plek nodig voor beschikbaarheid en boekingen zodat hij niet steeds “wanneer kun je?” hoeft te appen of zijn planning opnieuw hoeft te sturen.
Mijn rol
Product- en technisch eigenaarschap: V1-kader, rolflows, productregels, discipline in opleveren/reviewen en acceptatiestappen die Ruud kan lezen en testen. De beperking was bewust: laat de echte coachweek van één trainer werken voordat je een sportmarktplaats ontwerpt.
Probleem
Elke les begint als een afstemmingsprobleem. Leerlingen hebben een geschikt moment nodig zonder WhatsApp-verkeer. Ruud moet beschikbaarheid publiceren, losse en wekelijkse lessen plannen, en weten wie er meedoet — zonder de week opnieuw uit chatthreads te reconstrueren. Vóór het product betekende dat voortdurend heen-en-weer: “wanneer kun je?”, “ben je donderdag vrij?”, steeds opnieuw de beschikbaarheid sturen.
Ontwerpvraag: wat is het kleinste betrouwbare systeem voor de echte coachweek van één trainer, vóór enige marktplaatscomplexiteit?
Inzicht
Marktplaatsfuncties voordat de week van één trainer werkt, brengen vindbaarheid-, support- en operationele schuld mee. Het product is geen “meer manieren om padel te vinden”; het is één boekingswaarheid met twee rolgebonden interfaces. Leerlingen hebben zekerheid nodig over een les. Ruud heeft een operationeel overzicht van morgen nodig. Beide steunen op dezelfde beschermde lesdata.
Opties
- A · Marktplaats-V1 met meerdere trainers — bredere ambitie, maar rollen, vindbaarheid, uitbetalingen en ondersteuning vóór de primaire workflow is bewezen.
- B · WhatsApp plus spreadsheet — vertrouwd, maar elke boeking vraagt handmatige afstemming en de waarheid van de agenda blijft verspreid.
- C · Gericht boekingsproduct alleen voor Ruud — gekozen: één trainer, één boekingsmodel en aparte schermen voor leerling en trainer.
Koerswijziging
We schrapten betalingen, wachtlijst, gamification, Google-login en informeel slepen-en-neerzetten uit V1. Die functies kunnen later nuttig zijn, maar maken de eerste betrouwbare boekingslus lastiger om te bouwen en testen. Het product scheidt nu een rustige boekingsflow voor leerlingen van een werkruimte voor de trainer — twee interfaces, één datamodel.
Kernflow met twee kanten
Leerling
Kies dag → bekijk aanbod → kies vorm/tijd → boek → vind het onder Mijn lessen.
Mobiel-eerst boeken houdt traineradministratie buiten de beslissing van de leerling.
Trainer
Stel beschikbaarheid in → maak losse les of wekelijkse reeks → beheer capaciteit en spelers → houd de agenda als operationele waarheid.
Ruud krijgt een beheerscherm, geen consumentenapp met achteraf toegevoegde beheerdersknoppen.
Eén boeking, beide kanten
De leerling heeft zekerheid nodig. De trainer heeft een operationeel overzicht van morgen nodig.
Bewijs van leerling
“Geboekt” is een status, geen toastmelding
De aangeleverde screenshot uit producttesten houdt de komende les zichtbaar met datum, starttijd, duur, vorm en huidige groepsgrootte. Een leerling kan later terugkomen en de afspraak nog steeds begrijpen.
Getoond als een eerdere productstatus, niet als de huidige live-UI.
Productregels achter de interface
Eén boekingswaarheid: capaciteit en geboekte status komen uit hetzelfde beschermde datamodel.
Reeksen zonder geschiedenis te verliezen: wekelijkse lessen kunnen stoppen terwijl eerdere exemplaren begrijpelijk blijven.
Niveau is nuttige context: leerlingen hebben een niveau; de trainer kan dit corrigeren wanneer de coachpraktijk afwijkt.
De trainerbeelden gebruiken de echte applicatie-UI met een geïsoleerde lokale backend en duidelijk fictieve deelnemers. Er zijn geen productieaccounts of leerlingdata gebruikt.
Leerlingen boeken vanuit een rustige mobiele flow. Ruud beheert agenda, reeksen, beschikbaarheid, spelers en niveaus in een trainerwerkruimte.
Geen betalingen, wachtlijst, gamification, Google-login of informeel slepen-en-neerzetten in V1. Betrouwbaarheid wint van een lang functiemenu.
Resultaat & eerlijkheid over bewijs
Het product is live op padelnextlevel.nl met publieke registratie, aparte rollen voor leerling/trainer, boekingsschermen, profielbeheer, terugkerende lessen en productie-uitrol.
Wat veranderde voor Ruud: hij hoeft leerlingen niet meer voortdurend te appen over wanneer hij wel of niet les kan geven, of steeds zijn beschikbaarheid rond te sturen. Leerlingen openen de agenda, zien vrije momenten en boeken daar — één gedeelde boekingswaarheid in plaats van chatgesprekken.
Gebruik (live Supabase, aug 2026): gebruikt door 151 leerlingen + Ruud als trainer · 70 leerlingen met minstens één boeking · 361 boekingen · 148 lessen.
De beelden van leerlinghome/profiel zijn vastgelegd in het live product met een tijdelijke portfolio-testleerling; het test-e-mailadres en telefoonnummer zijn weggelaten. De aangeleverde geboekte status is gelabeld als een eerdere productstatus. Trainerbeelden komen uit de echte UI met een geïsoleerde lokale backend met fictieve deelnemers. Er is geen echte les geboekt en er worden geen productiegegevens van leerlingen getoond.
Hierna
Observeer eerst hoe Ruud en leerlingen de boekingslus herhaaldelijk gebruiken met minder handmatige afstemming. Vereenvoudig daarna randgevallen in trainerreeksen en maak het no-showbeleid voor leerlingen begrijpelijk. Betalingen komen pas nadat de kernboekingswaarheid vertrouwd wordt.