bron → scan → wijziging → Sheet → historie → nieuws → RSS → e-mail → voorspeller.
Als die keten goed draait, zou ik daarna niet meteen nóg meer interface bouwen. Dan is de slimste stap om de landelijke bronnenmachine verder te ontwikkelen: clubsites + KNLTB/Meet & Play + Playtomic + Peakz + Plaza + The Padellers + gemeenten/bouwplannen + padelnieuwsbronnen, zodat PadelOS4 werkelijk steeds meer van Nederland zelf leert kennen.
Ik voeg in de nieuwe PadelOS4-Sheet
nu drie zichtbare lagen toe die naast de technische monitor blijven staan:
PAD4_NEWS_FEED — alleen bevestigde/publiceerbare wijzigingen met bronlink;
PAD4_NOTIFICATION_LOG — welke wijzigingsmail wanneer naar padelstijn@gmail.com is gestuurd;
PAD4_PREDICTIONS — trend-/voorspellingssignalen, met expliciete betrouwbaarheid en bewijs zodat een voorspelling nooit als feit wordt gepresenteerd.
De RSS-feed leest straks rechtstreeks uit PAD4_NEWS_FEED.
SIGNAL_ONLY
Een statistische trend mag nooit worden weergegeven alsof we weten dat een club volgende maand werkelijk €XX,xx gaat vragen.
Dit kunnen we uiteindelijk veel verder trekken dan prijzen:
prijsontwikkeling → aantal banen → nieuwe clubs → indoor/outdoor groei → regionale groei → beschikbaarheid → populariteit → evenementen → trainingen → trainers → lesprijzen → nieuwe bouwplannen.
SIGNAL_ONLY is alleen goed voor een voorspelling. Voor actuele prijzen moeten we een veel sterker model gebruiken:
PUBLIC → LIVE_BOOKING → AUTHENTICATED → VERIFIED → HISTORY → NEWS → PREDICTION
De huidige PadelOS4 doet nu alleen publieke monitoring en vermeldt expliciet dat private/authenticated data niet wordt gescrapet en bookingintegraties alleen links/deeplinks zijn. Dat is veilig als basis, maar te beperkt voor wat jij wilt.
Voor Playtomic is er inmiddels wél een officiële route: de Playtomic Club API. Die is bedoeld voor clubs die hun eigen boekingsgegevens met externe systemen willen koppelen, ondersteunt real-time/historische bookings en authenticatie via officiële credentials. Playtomic waarschuwt bovendien expliciet tegen ongeautoriseerde automatiseringen en stuurt externe integraties richting Playtomic Connect.
Dus ik zou PadelOS4 slimmer maken met vier bronklassen:
PUBLIC_PAGE
Clubsite, tarievenpagina, sitemap, KNLTB, nieuws.
OFFICIAL_API
Bijvoorbeeld Playtomic Club API wanneer een club PadelOS toestemming geeft.
AUTHORIZED_BROWSER
Een test-/monitoraccount dat wij of een club zelf beheren, uitsluitend voor sites waar dit toegestaan is. Daarmee kan een browser daadwerkelijk door datum → tijd → baan → checkout lopen om de werkelijke getoonde prijs te controleren.
MANUAL/IMPORT
CSV/JSON/XML/API-feed van clubs die liever zelf data aanleveren.
Een testlogin zou ik niet als wachtwoord in de Sheet opslaan. Voor Playtomic horen officiële API-credentials buiten de Sheet, bijvoorbeeld in Apps Script PropertiesService, en de API-token is tijdelijk; Playtomic documenteert een tokenlevensduur van één uur.
Voor KNLTB geldt een iets andere wereld. ClubApp ondersteunt actuele baanbezetting en reservering voor leden, terwijl Meet & Play juist bedoeld is om ook losse banen en activiteiten te vinden en boeken. In 2024 waren al 533 aanbieders op Meet & Play actief, dus dit is voor Nederland een zeer belangrijke bron.
Bij iedere live prijscheck slaan we niet alleen €28 op, maar bijvoorbeeld:
CLUB_ID
PLATFORM = PLAYTOMIC
SOURCE_MODE = AUTHORIZED_API
CHECKED_AT = 2026-09-03T19:03
BOOKING_DATE = 2026-09-10
START = 19:00
DURATION = 60
COURT = Baan 3
COURT_TYPE = DOUBLE
PLAYER_TYPE = PUBLIC
BASE_PRICE = €32,00
SERVICE_FEE = €1,28
TOTAL_PRICE = €33,28
AVAILABLE = TRUE
SOURCE_URL
SOURCE_ID
VERIFICATION = LIVE
Dat is veel waardevoller dan alleen:
Piekprijs = €32.
Want zo kan PadelOS later ontdekken:
dinsdag 19:00 €32
vrijdag 19:00 €36
zondag 10:00 €25
volgende week €34
zelfde club maar indoor €39
lid €20
niet-lid €32.
Playtomic rekent bovendien een eigen servicevergoeding die per land/transactie kan variëren, dus ik zou baanprijs en platform/servicefee afzonderlijk bewaren.
Dat kan onderdeel worden van het systeem, maar alleen als het account door ons/de club is aangemaakt en expliciet voor monitoring gebruikt mag worden.
Dus niet:
AI maakt willekeurig accounts bij 780 clubs en probeert beveiligingen te omzeilen.
Wel:
PadelOS Monitor Account
club/API geeft toestemming
browser logt in
kiest representatieve momenten
leest prijs en beschikbaarheid
slaat bewijs en timestamp op
logt uit.
Voor MFA, captcha of nieuwe voorwaarden stopt de automatisering en komt:
HUMAN_ACTION_REQUIRED
Dat is veel betrouwbaarder dan proberen beveiligingsmechanismen te omzeilen.
Voor elke club hoeven we ook niet iedere beschikbare minuut te testen.
PadelOS kan bijvoorbeeld dagelijks een vaste benchmarkmatrix controleren:
moment
doel
ma 10:00
weekday dal
di 19:00
weekday piek
vr 20:00
vrijdag piek
za 10:00
weekend ochtend
za 19:00
weekend avond
zo 14:00
weekend middag
en voor:
+1 dag · +7 dagen · +14 dagen · +30 dagen
Dat levert maximaal 24 meetpunten per club per dag op.
Voor 780 clubs zijn dat theoretisch:
18.720 prijsmetingen per dag.
Daarom moeten we dit verdelen:
API-bronnen → frequent;
publieke statische prijzen → 1× per dag/week;
authenticated browser → kleine slimme sample;
stabiele clubs → minder vaak;
recent gewijzigde clubs → vaker.
Een voorspelling mag dan bijvoorbeeld zeggen:
LIVE FACT
Peakz locatie X vraagt op 10 september 19:00 €34.
HISTORY
Zelfde benchmark was 3 september €32.
CHANGE
+€2 / +6,25%.
PATTERN
5 van de laatste 7 avondmetingen waren hoger dan vorige maand.
FORECAST / SIGNAL_ONLY
Kans op structurele prijsstijging: 72%.
Dat is een echte voorspeller, omdat hij gebaseerd is op werkelijke observaties.
Dezelfde meetlaag kan straks ook meten:
AVAILABLE_SLOTS = 12
TOTAL_SLOTS_CHECKED = 20
OCCUPANCY_PROXY = 40%
Daaruit kunnen we trends bouwen zoals:
Alkmaar dinsdagavond vrijwel vol
Maastricht daluren veel beschikbaar
Den Haag indoor sterkste bezettingsgroei
Amsterdam piekprijs stijgt terwijl beschikbaarheid daalt.
Dan wordt PadelOS4 uiteindelijk een soort Padel Market Intelligence Nederland.
En dat kan PadelOS weer gebruiken:
speler zoekt les
trainer beschikbaar
PadelOS4 vindt baan
vergelijkt werkelijke bookingprijs
berekent lesprijs
admin boekt via officiële route.
De volgende Code.gs-versie zou ik daarom niet meer scraper noemen, maar een Connector Engine met:
PUBLIC_FETCH
PLAYTOMIC_API
MEETPLAY_LINK
KNLTB_CLUBAPP
AUTHORIZED_BROWSER
CLUB_API
IMPORT_FEED
waarbij elke waarneming altijd krijgt:
bron + methode + tijd + zekerheid + bewijs + toegestaan/authorized-status.
Dat is de stap van een simpele monitor naar een serieus PadelOS4-dataplatform.
Vervang in het nieuwe Apps Script-project alleen Code.gs en Index.html.
Voer eenmalig pad4Setup() uit.
Voer pad4InstallTriggers() uit.
Deploy als Web App (nieuwe versie).
Open /exec.
wijzigingsmail naar padelstijn@gmail.com alleen bij wijzigingen/review/nieuwe kandidaten;
bron-URL in change log, mail en nieuwsfeed;
PAD4_NEWS_FEED voor bevestigde publieke updates;
RSS: voeg ?format=rss toe aan de gedeployde /exec URL;
JSON nieuwsfeed: ?format=json;
PAD4_NOTIFICATION_LOG voor verzonden meldingen;
PAD4_PREDICTIONS voor transparante trendsignalen;
dagelijkse voorspeller-trigger na de update.
Een voorspelling is altijd SIGNAL_ONLY: nooit een feitelijke toekomstige prijs.