EV-oplader APIs voor parkeersoftware

Eén waarheid over beschikbaarheid

Beschikbaarheid is wat bestuurders zien, dus dat mag niet verkeerd zijn. Het kan ook niet uit een van beide systemen afzonderlijk worden afgeleid.

• Alleen de opladerstatus mist een baai die fysiek wordt geblokkeerd door een auto die niet is aangesloten
• Alleen al de bewoner mist een oplader die defect is, gereserveerd is of buiten gebruik is
• De eerlijke staat is de combinatie, en één systeem moet de eigen publicatie ervan hebben
• Wie het ook bezit, beiden moeten het voeden, en de oudheid moet zichtbaar zijn in plaats van aangenomen

Onze aanbeveling is dat het parkeersysteem de beschikbaarheid publiceert, omdat het al over bewegwijzering beschikt en de bestuurder er al naar kijkt, en dat het opladen de laderstatus en foutstatus doorgeeft.

Reserveringen tegen een fysieke baai

Bij reservering lopen de aannames van de twee systemen het scherpst uiteen, omdat een reservering een belofte is over een fysieke ruimte die geen van beide systemen controleert.

1. 1

   Bepaal wat er gereserveerd wordt

   De bay, de oplader of beide. Als iemand in de parkeerplaats kan parkeren zonder op te laden, belooft het reserveren van de oplader alleen niets.

2. 2

   Bepaal wie handhaaft

   Een voorbehoud dat niemand afdwingt is een suggestie. Dit is meestal een parkeermogelijkheid in plaats van een oplaadmogelijkheid.

3. 3

   Behandel de no-show

   Hoe lang de baai wordt vastgehouden en wat er met de reservering en het geld gebeurt als er niemand arriveert.

4. 4

   Behandel de kraker

   Er bevindt zich iemand in het gereserveerde vak als de houder arriveert. Dit zal gebeuren, en het proces daarvoor is een zakelijke beslissing, geen technische beslissing.

Eén betaling of twee

Beide zijn werkbaar en hebben verschillende consequenties, dus het zou een beslissing moeten zijn en niet wat de integratie ook maar heeft opgeleverd.

• Eén gecombineerde betaling is beter voor de chauffeur en vereist dat de ene partij het int en afrekent met de andere, wat een commerciële afspraak en een verzoeningsplicht is
• Twee afzonderlijke betalingen zijn eenvoudiger te bouwen en slechter voor de chauffeur, die twee keer betaalt voor één stop en dit zal vermelden
• Hoe dan ook moeten beide gegevens in overeenstemming zijn met hetzelfde verblijf, anders kan een geschil niet worden opgelost
• Als parkeren wordt verzameld voor opladen, moeten de laadgegevens nog steeds een factuur ondersteunen, inclusief fiscale behandeling

Overstay, inactiviteit en handhaving

De meest voorkomende klacht in een faciliteit met opladen gaat niet over opladen. Het gaat over een baai die wordt ingenomen door een auto die uren geleden klaar is.

• Opladen weet wanneer een sessie is voltooid. Parkeren weet wanneer het voertuig is vertrokken. Geen van beiden kan als enige een overschrijding van de toegestane verblijfsduur vaststellen
• Voor een nutteloze vergoeding zijn beide nodig, plus een uitstelperiode die iemand heeft besloten in plaats van in gebreke te blijven
• Kennisgeving voordat er kosten in rekening worden gebracht, maakt de polis verdedigbaar en wordt vaak achterwege gelaten
• Handhaving is een parkeermogelijkheid. Opladen kan het gedrag beprijzen; het kan de auto niet verplaatsen

Wie is eigenaar van de klant

De moeite waard om vroeg te regelen, omdat het de vorm van de integratie bepaalt en het een commerciële kwestie is die technische kleding draagt.

Als de bestuurder een relatie heeft met de parkeerexploitant, is het opladen een kenmerk van parkeren en zou het onzichtbaar moeten zijn: geen aparte app, geen apart account, het opladen verschijnt als een lijn op de parkeerrekening. Als de relatie met een laadnetwerk is, is parkeren een locatie en heeft de bestuurder twee relaties, ongeacht of iemand dat zo bedoeld heeft. Beide zijn levensvatbaar. Wat niet werkt is dat geen van beide partijen beslist, wat twee apps, twee accounts en een chauffeur oplevert die geen van beide gebruikt.