De productbeslissingen van een laderfabrikant stoppen niet bij de hardware. Zodra een lader de fabriek verlaat, moet iemand drie vragen beantwoorden: hoe configureert en monitort een installateur hem, hoe start de gebruiker een sessie en ziet wat die heeft gekost, en hoe praat hij met al het andere, een energiemanagementsysteem, een fleettool, een facturatieplatform. Kies de verkeerde backend en alle drie de antwoorden betekenen ofwel software bouwen die het bedrijf niet kan onderhouden, ofwel een platform kiezen dat het merk vastzet aan de roadmap van één leverancier.
De drie dingen die kopers echt vragen
In de praktijk heeft een OEM die een lader levert een CSMS nodig om hem te beheren, een app of portaal zodat gebruikers niet met een handleiding zitten, en een manier voor andere software om verbinding te maken. Plugchoice's OEM-programma bundelt precies dat: een gratis white-label CSMS, een app voor rijder en installateur die op OCPP draait in plaats van een eigen protocol, en een publieke REST API eronder, allemaal onder het merk van de OEM in plaats van dat van Plugchoice.
Het white-label deel is geen laagje verf. Het webportaal, de gebrande e-mails en de mobiele app dragen allemaal het logo, de kleuren en het domein van de OEM, ingesteld vanuit de teaminstellingen van het portaal zelf in plaats van via een project met het team van Plugchoice. Een white-label mobiele app is het enige onderdeel dat een aparte overeenkomst vereist; het portaal, de e-mails en één eigen domein niet.
Waarom "draait op OCPP" het deel is dat telt
Het verschil dat een OEM echt beschermt, is niet dat de app gebrand oogt, het is welk protocol eronder zit. Een app die tegen de eigen API van één backend is gebouwd, stopt met werken zodra die backend verandert, of dat nu is omdat de OEM van platform wisselt, een klant een andere backoffice wil draaien, of een reseller de lader op infrastructuur wil zetten die de OEM niet beheert. Een app die op OCPP is gebouwd, blijft de lader aansturen ongeacht welke backoffice erachter zit, want de OCPP-proxy van Plugchoice kan de berichten van een lader naar een bestaande backoffice routeren zonder die te vervangen. De bestaande opstelling van een klant blijft werken terwijl de eigen app en het portaal van de OEM ernaast draaien.
Wat er onder de motorkap meekomt
Voorbij de app en het portaal is de OEM-kant van het platform waar een fabrikant een vloot echt beheert over productlijnen heen: feature flags om functies per ladermodel aan of uit te zetten, virtuele producten zodat een nieuw ladermodel automatisch de juiste standaardconfiguratie overneemt, en tools voor de firmwarelevenscyclus, versiebeheer over de hele vloot, gefaseerde uitrol naar een testgroep voordat een bredere push volgt, en updates op afstand zonder locatiebezoek. Niets daarvan vereist dat het eigen engineeringteam van de OEM een device-managementbackend vanaf nul bouwt of onderhoudt.
Twee manieren om er geld aan te verdienen
Het OEM-programma van Plugchoice draait op twee verschillende commerciële modellen, en de keuze bepaalt wie de klantrelatie bezit. Onder het gratis model biedt de OEM Plugchoice zonder voorafgaande kosten aan zijn klanten aan, en verdient Plugchoice mee via een omzetaandeel zodra een klant een betaalde functie activeert, zoals Smart Charging. Onder het OEM-managed model houdt de OEM de volledige klantrelatie en prijscontrole zelf, en betaalt in plaats daarvan een terugkerend platformtarief per lader aan Plugchoice. White-labeling is beschikbaar onder beide modellen; alleen de gebrande mobiele app heeft, zoals hierboven, een eigen overeenkomst nodig. Geen van beide modellen vereist exclusiviteit: de OCPP-proxy zorgt ervoor dat een lader door de gebrande laag van de OEM kan draaien terwijl hij nog steeds verbonden is met welke backoffice de eindklant ook al gebruikt.
Erbovenop bouwen
Voor OEM's of hun integratiepartners die hun eigen tools willen aansluiten in plaats van te vertrouwen op alleen het portaal en de app, biedt hetzelfde systeem een publieke REST API: persoonlijke toegangstokens voor snelle integraties en interne tools, OAuth 2.0 voor productieapplicaties die afgebakende, gedelegeerde toegang nodig hebben. De API geeft altijd dezelfde genormaliseerde data terug, ongeacht ladermerk of firmware, laders, sessies, meterstanden, configuratie, zodat de eigen dashboards van een OEM of het energiemanagementsysteem van een klant geen aparte logica nodig hebben voor elke hardwarevariant in de vloot.
Welk model een OEM moet kiezen hangt af van hoeveel van de klantrelatie hij zelf wil bezitten en hoeveel platformrisico hij zelf wil dragen. Wat niet verandert over die keuze heen, is het protocol eronder: een app en backend gebouwd op OCPP is de ene keuze die niet steeds opnieuw hoeft te worden bekeken zodra een klant, een markt, of een backendeis verandert.
