Een enquête uit 2025 bij meer dan 200 Britse laadpaaloperators, uitgevoerd door Monta, vond dat slechts 3,9% van de snelladers (50 kW en hoger) daadwerkelijk de wettelijke 99%-uptime-norm van het land haalt. Driekwart van de operators rapporteert een uptime boven 95%, en een flink deel claimt in de 97-98,4%-band te zitten. Bijna niemand haalt de norm die er echt toe doet.
Dat verschil tussen het cijfer op het dashboard en het cijfer dat een chauffeur werkelijk ervaart, is geen typisch Brits fenomeen. Het duikt overal op waar betrouwbaarheid grondig gemeten wordt: netwerken die een uptime in de hoge negentig procent rapporteren, terwijl een aanzienlijk deel van de echte laadpogingen nog steeds niet netjes van start gaat. Een uitsplitsing van sessiefalingen door laderfabrikant Kempower, geciteerd in Zest's betrouwbaarheidsanalyse van 2026, vond dat het merendeel van de incidenten aan de kant van de gebruiker ligt (een mislukte authenticatie, een kabel die nooit vergrendelde), maar een reëel deel, ongeveer een vijfde, zijn echte technische defecten aan de lader zelf. Hoe dan ook, de ervaring van de chauffeur is dezelfde: die steekt de stekker in, en er gebeurt niets.
Waarom dit een prijsprobleem is, niet enkel een ops-probleem
Dynamic-pricing-modellen, het onze inbegrepen, behandelen vraag als functie van tijd, locatie en hoe druk een station nu is. Wat bijna geen enkel model als input meeneemt, is beschikbaarheid, van jezelf of van iemand anders in de buurt.
Denk aan wat er gebeurt als een lader twee straten verderop een middag uitvalt. De vraag naar jouw plek verandert niet omdat jij iets deed. Ze verandert omdat de capaciteit in de buurt net kleiner werd. Chauffeurs die daar hadden geladen, komen nu bij jouw connector terecht, tegen precies de prijs die je al had ingesteld voor een normale dag. Als je model puur prijst op je eigen historische vraagcurve, laat je marge liggen precies in het venster waarin je de meeste hefboom had om ze te vangen, omdat die verschuiving in vraag onzichtbaar was tot de sessies binnenkwamen.
Dezelfde logica werkt ook omgekeerd, en dat kost meer. Als je eigen lader uitvalt, ziet een op vraag gebaseerd pricing-model helemaal niets. Er staat geen mislukte sessie in je CDR, want de sessie is nooit gestart. De bezetting daalt, maar niets in een omzet-per-sessie-weergave vertelt je waarom, en als je model die connector al als weinig gevraagd behandelde door het gat in de historiek, blijft het zo prijzen alsof er niets aan de hand is zodra de lader weer online is.
Betrouwbaarheid is nu het door de sector zelf genoemde topprobleem, wat dit actueler maakt
Operatorenquêtes van dit jaar plaatsen laderbetrouwbaarheid en -stabiliteit boven energie- en netbeperkingen als grootste uitdaging voor netwerkoperators, volgens een rapport over de operatorenquête van dit jaar, voor het eerst sinds dit soort rapporten dit bijhoudt. Dat is een signaal dat de sector zelf verschuift van "hoe snel kunnen we uitbreiden" naar "hoeveel van wat we gebouwd hebben, werkt ook echt wanneer iemand het nodig heeft". Prijsstrategie heeft die verschuiving grotendeels nog niet ingehaald. De meeste gesprekken over dynamic pricing gaan nog altijd over tijdstip-curves en beursprijzen, niet over het feit dat de echte, actuele concurrerende capaciteit rond een station hard kan schommelen in beide richtingen door een storingsticket drie kilometer verderop.
Wat dit in de praktijk betekent
We stellen niet voor dat je zou moeten prijzen op basis van de live status van een concurrent. Op de meeste markten heb je die niet, en zelfs als je die wel had, roept een piek prijzen op basis van iemands slechte dag terechte vragen op die je liever niet aan een regulator of een chauffeur beantwoordt. De nuttigere conclusie ligt dichter bij huis: je eigen downtime en je eigen eerste-poging-faalpercentage zijn vraagsignalen waar je pricing-model momenteel blind voor is. Een connector met een hoog faalpercentage is niet enkel een ops-metriek, hij onderdrukt actief de vraag die je pricing-engine denkt te observeren, wat betekent dat elk model dat puur op afgeronde sessies traint, werkt met een dataset die zijn eigen slechtste dagen al uitsluit.
Als je dynamic pricing draait, of erover nadenkt, is dit het waard om als eerste te checken: weet je vraagmodel het verschil tussen "niemand wilde hier laden" en "iemand probeerde het en de lader liet hem in de steek"? Voor veel operators is het eerlijke antwoord vandaag nee.
Wij runnen zelf een laadnetwerk en bouwen daar de pricing voor, en daar worden dit soort blinde vlekken al snel op de harde manier duidelijk. Waar leeft je eigen betrouwbaarheidsdata vandaag eigenlijk, in je CPMS, je CDR's, een support-mailbox, en koppelt iemand dat terug naar hoe je prijst?
Veelgestelde vragen
Waarom beïnvloedt de downtime van een concurrent mijn eigen prijzen?
Omdat de vraag op een publieke laadlocatie niet enkel door jouw eigen lader bepaald wordt, maar door de werkende capaciteit in de buurt op dat moment. Als een lader vlakbij uitvalt, komen de chauffeurs die daar hadden geladen bij jouw connector terecht. Je prijs was ingesteld voor een normale dag en houdt geen rekening met het feit dat de lokale capaciteit net kleiner werd.
Waarom laat mijn eigen downtime zich niet zien in een omzetgedreven pricing-model?
Omdat een model dat traint op afgeronde sessies enkel sessies ziet die er ook echt waren. Een mislukte laadpoging genereert geen sessie en dus ook geen data. Het model registreert niet 'een chauffeur probeerde het en het lukte niet', het registreert enkel lagere bezetting op die connector, en kan een storingsgevoelige connector uiteindelijk behandelen als permanent weinig gevraagd in plaats van onbetrouwbaar.
Hoe groot is het echte verschil tussen gerapporteerde uptime en werkelijke beschikbaarheid?
In het VK vond een enquête uit 2025 bij meer dan 200 laadpaaloperators (via Monta) dat slechts 3,9% van de snelladers de wettelijke 99%-uptime-norm haalt, terwijl 74% van de operators zelf een uptime boven 95% rapporteert. Het gerapporteerde cijfer is een netwerkgemiddelde over een lang venster, het zegt weinig over of de specifieke lader waar een chauffeur op een bepaalde dag voor staat, ook echt werkt.
Wat kan een operator hier concreet mee doen?
Begin met je eigen eerste-poging-faalpercentage te behandelen als een vraagsignaal, niet enkel als een ops-metriek. Volg het per connector, niet enkel netwerkbreed, en check of periodes met een hoog faalpercentage samenvallen met dalingen in bezetting die je pricing-model mogelijk verkeerd interpreteert als lage vraag in plaats van onderdrukte vraag.