We gaan dus verder op PadelOS School v3.8 met uitsluitend Code.gs + Index.html als actieve applicatiebestanden.
De huidige v3.8-architectuur is herkenbaar en bruikbaar als basis. Code.gs gebruikt de hoofd-Sheet PadelOS v02092026 en bevat één centrale backend met Sheet-tabellen voor accounts, rollen, sessies, spelers, trainers, locaties, banen, aanvragen, lessen, observaties, gesprekken en finance.
De browserverbinding is al verbeterd ten opzichte van de eerdere fout “google is not defined”: de frontend wacht expliciet tot google.script.run beschikbaar is en gebruikt daarna slechts één vaste serverbridge p351Call(). De backend accepteert alleen expliciet toegestane functies.
Login bevat al e-mailcode, wachtwoordlogin, registratie, sessies, logout en wachtwoord instellen/wijzigen. De sessie wordt gehasht opgeslagen en verloopt na 24 uur.
Rollen zijn server-side gekoppeld aan drie applicatiemodi: PLAYER, TRAINER en ADMIN. Een gebruiker kan meerdere rollen hebben en de beschikbare modi worden uit GEBRUIKER_ROLLEN berekend.
De echte hoofd-Sheet bestaat en is dezelfde Sheet-ID die Code.gs gebruikt. De Sheet bevat onder andere GEBRUIKERS, GEBRUIKER_ROLLEN, SESSIES, LOGIN_CODES, PROFIELEN, SPELERS, TRAINERS, LOCATIES, BANEN, LESAANVRAGEN, LESSEN, DEELNAMES, LESVOORBEREIDINGEN, OBSERVATIES, SPELER_LEERDOELEN, FACTUREN, BETALINGEN, BERICHTEN, URENREGISTRATIE, LES_FINANCIEEL, CLUBBETALINGEN en TRAINER_BETALINGEN.
Ook de belangrijkste operationele functies bestaan al: speler maakt aanvraag, trainer doet aanbod, admin plant trainer/locatie/baan, PlanPlay wordt opgeslagen, trainer kan observeren/coachen, speler kan reflecteren, facturen en betalingen bestaan en trainer-/clubbetalingen kunnen ontstaan nadat spelerfacturen betaald zijn.
Login + rollen stabiliseren wordt nu de fundering van PadelOS1/2/3/School/4/5.
De identiteit moet voortaan conceptueel los staan van de schoolrol:
ACCOUNT → PROFILE → ROLE ASSIGNMENTS → APP ACCESS
Daarmee wordt PadelOS3 de gedeelde accountlaag. PadelOS School vraagt alleen:
heeft account X PLAYER / TRAINER / SCHOOLADMIN-rechten?
en maakt geen eigen tweede identiteit.
Ook leggen we één canonieke rolset vast:
SUPERADMIN
SCHOOLADMIN
TRAINER
TRAINER_IO
PADELCOACH
SPELER
PLANNER en FINANCE worden later permissies/subrollen in plaats van vierde/vijfde hoofdapp.
De huidige v3.8-flow moet nog tot één echte state-machine worden gemaakt:
NIEUW → TRAINER_VOORSTEL → ADMIN_TE_PLANNEN → GEPLAND → LES_GESTART → LES_UITGEVOERD → COACHING_GEREED → FACTUUR_OPEN → BETALING_GEMELD → BETAALD → AFGEROND
Daarbij krijgt een trainer-aanbod echte velden voor voorgestelde datum, starttijd, eindtijd, locatie, baan en bericht. In v3.8 is het trainer-aanbod nu hoofdzakelijk een chatbericht.
Ook moet LES UITGEVOERD een expliciete stap worden. Nu kan na planning direct PlanPlay/coaching worden gebruikt en wordt tijdens het plannen tevens de financiële flow aangemaakt.
Voor de uiteindelijke School-keten wil ik finance daarom splitsen:
planning → prijsreservering
les uitgevoerd → definitieve leskosten
coaching afgerond → factureerbaar
factuur gemaakt/verzonden → betaling
alle spelerfacturen betaald → trainer/club betaalbaar
Dat voorkomt dat een geannuleerde of nooit uitgevoerde les al financieel als voltooide les wordt behandeld.
Niet geblokkeerd door de Sheet of door ontbrekende v3.8-bestanden.
Wel kan ik op basis van broncode + Sheetstructuur niet beweren dat ieder onderdeel runtime-bewezen werkt in de momenteel gedeployde /exec-versie. Daarvoor moet uiteindelijk de echte webapp end-to-end worden getest met minimaal:
testspeler → testtrainer → testadmin.
Ook is de gedeelde identiteit met PadelOS4 en PadelOS5 nog geen bewezen cross-app SSO. De School-code heeft wel een goede accountbasis, maar die moet als canonieke PadelOS3-authlaag door die andere apps worden gebruikt.
De beste volgende actie is nu één complete PadelOS School release bovenop v3.8 maken, zonder losse patches:
PadelOS School v3.9 — Complete School Chain
Daarin blijven slechts:
Code.gs
Index.html
en bouwen we de canonieke keten:
Speler
→ les aanvragen
→ datum/tijd/locatie voorstellen
Trainer
→ aanvraag ontvangen
→ concreet trainer-aanbod maken
Admin
→ aanbod kiezen
→ trainer + locatie + baan vastleggen
→ les plannen
Trainer
→ PlanPlay
→ les uitvoeren
→ aanwezigheid
→ NBF/HSS/GRAS/Freeze/Socratisch
→ observatie
→ leerdoel
→ coaching afronden
Finance
→ les definitief maken
→ spelerfactuur
→ betaling melden
→ admin bevestigt
→ betaald
→ trainervergoeding
→ clubbetaling
→ keten afgerond.
En PadelOS1/2/3 worden daarbij geen losse duplicaten, maar gedeelde diensten:
PadelOS1 = Help / Handleiding
PadelOS2 = Support / FAQ / Helpdesk
PadelOS3 = Account / Login / Profiel / Settings / Rollen / Rechten
Dat is vanaf nu de canonieke architectuur voor PadelOS School.
Ja. Ik heb hier nu een werkende PadelOS CURRENT v3.8 van gemaakt, voortbouwend op de login die bij jou nu daadwerkelijk werkt.
De kern blijft:
1 · Speler → 2 · Trainer → 3 · Admin → 4 · PadelOS Totaal
maar daar zit nu ook de club-, baan- en geldstroom tussen.
Code.gs — PadelOS CURRENT v3.8
Index.html — PadelOS CURRENT v3.8
Complete PadelOS v3.8 ZIP
Ik heb beide JavaScriptdelen opnieuw syntactisch gecontroleerd.
De ZIP bevat ook:
NL padelclub referentieprijzen CSV
Club beschikbaarheid CSV-template
JSON-template
TXT-template
Demo lesprijzen
System 1 · Speler krijgt naast les aanvragen nu ook Boekbare momenten. Een speler ziet bijvoorbeeld:
The Padellers / Baan 2
10 september
18:00–19:00
€32
Gebruik als lesvoorstel
Daarmee worden locatie, datum en tijd meegenomen naar de lesaanvraag. De speler kan kiezen voor privéles, duoles, groepsles of clinic.
System 2 · Trainer ziet lesverzoeken én baanmomenten. Daarna blijft de lijn zoals we al hadden: aanbod doen → toegewezen les → PlanPlay → observatie → GRAS / Freeze / NBF / HSS / spelbedoeling / Socratische vragen → uren.
System 3 · Admin heeft nu Clubs & banen. Daar kun je rechtstreeks een bestand uploaden:
CSV, JSON of TXT.
PadelOS leest het bestand in en kan automatisch ontbrekende:
LOCATIES → BANEN → CLUB_BESCHIKBAARHEID
aanmaken.
De minimale clubimport is heel eenvoudig:
club,plaats,datum,start,eind,prijs,baan
Padelclub Alkmaar,Alkmaar,2026-09-10,18:00,19:00,32.00,Baan 1
TXT kan zelfs:
Padelclub Alkmaar|Alkmaar|2026-09-10|18:00|19:00|32.00|Baan 1|Lesbaan
Dat is meteen onze eerste koppellaag met clubapps: wanneer een club of reserveringssysteem CSV/JSON kan exporteren, kan PadelOS dat nu verwerken. Een rechtstreekse Playtomic/API-koppeling kan later bovenop exact dezelfde gegevenslaag.
Ik heb ook actuele openbare tarieven opgezocht en als referentiedataset ingebouwd. Dit is nadrukkelijk geen complete lijst van iedere Nederlandse padelbaan; het is een bruikbare startdataset met actuele openbare prijsvoorbeelden.
Bij Padelclub Nederland zie je bijvoorbeeld op meerdere locaties voor een double court ongeveer €25 per uur dal en €32 per uur piek. Ze vermelden ook dat via Playtomic nog een boekingsfee van 4% kan gelden.
De prijzen verschillen behoorlijk per locatie. The Padellers publiceert bijvoorbeeld:
Stadskanaal indoor: vanaf ongeveer €16 dal / €24 piek per uur.
Amsterdam-West: ongeveer €24 dal / €30 piek per uur.
Hoorn/Zwaag: ongeveer €16 dal / €24 piek per uur.
Kapelle: ongeveer €25 dal / €34 piek per uur.
Amstelpark buiten: ongeveer €20 dal / €24 piek per uur.
Daarom gebruik ik in de PadelOS demo-calculator €32 per baanuur als redelijke piek-/planningsreferentie. Dat is geen verplichte prijs; admin kan hem per les aanpassen.
Ook de fictieve lesprijs van ongeveer €30 p.p. voor een groep van vier is verdedigbaar als prototype: The Padellers noemt groepslessen vanaf €22,50 p.p. per 60 minuten inclusief trainer, baan en materiaal, terwijl Plaza Padel losse trainingen vanaf €25 p.p. per uur noemt.
Ik heb de demo bewust eenvoudig gemaakt.
Voor een groepsles van vier spelers van één uur rekent PadelOS standaard ongeveer:
Omzet
4 × €30 = €120
Kosten
baan: €32
trainer les: €45
voorbereiding 15 min: €11,25
nabespreking/evaluatie 15 min: €11,25
materiaal: €2,50
planning/admin: €7,50
Totale kosten: €109,50
Demo marge: €10,50
De trainervergoeding is dus in dit voorbeeld €67,50 voor:
voorbereiding + 60 minuten les + nabespreking/evaluatie.
Dat vind ik belangrijk voor PadelStudy: coaching en leerdoelen worden daarmee niet behandeld als gratis werk ná de training.
Voor clinics zit een apart fictief voorbeeld in het meegeleverde bestand.
Wanneer Admin nu een aanvraag omzet in een echte les, maakt PadelOS:
lesgroep
→ deelnemer
→ lessenreeks
→ les
→ gesprek
→ baanboeking
→ LES_FINANCIEEL
→ spelerfactuur.
De bestaande financiële Sheet-tabbladen worden daarvoor gebruikt. We voegen dus niet alles dubbel toe.
Wanneer de speler zijn betaling meldt en Admin die bevestigt:
spelersbetaling
→ factuur betaald
→ PadelOS controleert of de bekende spelerfacturen van die les betaald zijn
→ clubbedrag krijgt status KLAAR_VOOR_BETALING
→ trainerbedrag krijgt status KLAAR_VOOR_BETALING.
Belangrijk: PadelOS maakt nog geen echte bankoverschrijving.
Zonder Mollie, Stripe, bank-API of betaalprovider zou ik dat niet als “betaald” mogen voorstellen. V3.8 maakt dus correct de financiële verplichting en uitbetalingsopdracht aan; de daadwerkelijke betaalprovider wordt een volgende laag.
Een club hoeft dus nog geen volledig PadelOS-account te hebben.
De eerste praktische werkwijze kan gewoon zijn:
clubbeheerder
→ exporteert beschikbare banen uit eigen systeem
→ CSV / JSON / TXT
→ Admin importeert bestand
→ PadelOS toont beschikbare banen
→ spelers stellen lesmomenten voor
→ trainer reageert
→ admin plant
→ baanboeking wordt geregistreerd
→ baankosten worden meegenomen in de lesprijs.
Later kunnen we daar een beperkte CLUBBEHEERDER-rechtenlaag boven zetten zonder een vijfde hoofdsysteem te maken. Die clubbeheerder zit dan functioneel binnen System 3, maar ziet alleen zijn eigen locatie, banen, beschikbaarheid, boekingen, afspraken en betalingen.
V3.8 maakt bij eerste gebruik automatisch slechts twee nieuwe tabbladen wanneer die nog niet bestaan:
CLUB_BESCHIKBAARHEID
en
NL_PADEL_REFERENTIES
De bestaande tabbladen blijven de echte operationele laag voor:
CLUBAFSPRAKEN
BAANBOEKINGEN
CLUBBETALINGEN
TRAINER_BETALINGEN
LES_FINANCIEEL
Dat sluit mooi aan op de bestaande PadelOS-architectuur: de frontend blijft licht en de Sheet blijft de bewerkbare bron.
NEXT: vervang nu alleen weer de bestaande Code.gs en Index.html door deze v3.8, deploy een nieuwe versie en test daarna eerst één complete keten:
Speler → Boekbaar moment → Lesvoorstel → Admin → Planning → kosten €120/€109,50 → spelerfactuur → betaling melden → admin bevestigen → club + trainer KLAAR_VOOR_BETALING.
Als die ene keten werkt, hebben we een echte operationele basis voor een padelschool in plaats van alleen losse schermen.