Koppelingen van fietsverhuursoftware: betalingen, kassa, boekhouding en API

Koppelingen lossen problemen op; ze veroorzaken er ook

Een verhuurbedrijf draait op meerdere systemen: boekingstool, betaalprovider, boekhouding, misschien een kassa in de winkel, e-mail, website, een slot of gps-tracker. Ze koppelen lijkt een voor de hand liggende winst, en dat is het vaak ook. Maar elke koppeling is ook een nieuwe manier waarop twee systemen elkaar kunnen tegenspreken, en een verschil tussen boekingssysteem en boekhouding is een slechte manier om een terugbetaling te ontdekken.

Dit artikel laat zien welke koppelingen de moeite waard zijn, hoe u bepaalt welk systeem de bron van waarheid is voor welk gegeven, wat er misgaat en hoe u beloften van leveranciers beoordeelt.

De gangbare koppelingen

Bepaal eerst de bron van waarheid

Voor elk soort informatie moet één systeem leidend zijn. De andere lezen eruit of krijgen een kopie, maar bewerken het niet.

Als twee systemen de klant claimen, ontstaan dubbelen. Als beide een boeking kunnen wijzigen, ontstaat overboeking. Eerst bepalen, dan koppelen.

Betalingen

De koppeling met betalingen is die welke de meeste zaken niet kunnen vermijden. Waar u op moet letten:

• Welke betaalproviders worden ondersteund en kunt u uw eigen account gebruiken? Op de prijzenpagina van bikerental staat dat de betalingsverwerking op uw eigen Stripe-account blijft.
• Wie houdt het geld vast en hoe snel komen uitbetalingen binnen?
• Worden creditcardreserveringen voor borg ondersteund en hoe worden vervaltermijnen afgehandeld? Zie borg en creditcardreservering in de fietsverhuur.
• Worden terugbetalingen en gedeeltelijke terugbetalingen vanuit het boekingssysteem gedaan en zichtbaar in de boeking?
• Worden transactiekosten apart getoond van softwarekosten?

Boekhouding

U wilt omzet niet twee keer intypen. Zoek een manier om omzet, betalingen en terugbetalingen, samengevat of gespecificeerd, naar uw boekhoudprogramma of uw boekhouder te sturen, met duidelijke regels voor btw en voor borg, die meestal geen omzet is. Is er geen directe koppeling, dan kan een regelmatige gestructureerde export volstaan. De vraag is of de cijfers sluiten, niet of er een logo op een pagina staat.

Kassasysteem in de winkel

Verkoopt en repareert u ook fietsen, dan draait er misschien een kassa naast het verhuursysteem. Bepaal wat wordt gedeeld — meestal de klanten, soms voorraad en betalingen — en wat niet. Een uitgebreidere behandeling staat in kassasysteem of verhuursoftware voor de fietsenwinkel.

Uw website

Een boekingswidget of gehoste pagina op uw domein moet de beschikbaarheid live uit het boekingssysteem lezen, nooit een kopie. Test het: doe een boeking en controleer of de beschikbaarheid binnen seconden verandert. Controleer op de telefoon snelheid en afrekenen. Zie de checklist voor boekingssystemen.

Sloten, gps en telematica

Voor e-bikevloten worden apparaten die locatie, accu of status doorgeven steeds aantrekkelijker. De vraag is waar hun gegevens heen gaan en of ze veranderen wat u kunt doen. Ze zijn nuttig als ze de fietsdossiers voeden, u op problemen wijzen en geen extra dashboard toevoegen dat niemand opent. Het datamodel van bikerental heeft al een plek voor kilometerteller, accu en apparaatidentiteit, zodat u later apparaten kunt toevoegen zonder het vlootdossier te herontwerpen.

API en webhooks

Met een API leest en schrijft u gegevens vanuit uw eigen tools; webhooks sturen gebeurtenissen, zoals een nieuwe boeking of een teruggebrachte fiets, naar andere systemen. Ze zijn krachtig en een verplichting: iemand moet bouwen en onderhouden wat ervan afhangt. Gebruik ze voor een concrete behoefte, zoals een eigen rapport of een automatisering, niet omdat ze bestaan. Bij bikerental maken API en webhooks deel uit van het Growth-abonnement en hoger; zie de prijzen.

Wat er misgaat

• Dubbele klanten, als twee systemen dossiers voor dezelfde persoon aanmaken.
• Verouderde beschikbaarheid, als een widget of kanaal een vertraagde kopie leest.
• Afwijkende terugbetalingen, als een terugbetaling in het ene systeem wordt gedaan en in het andere niet wordt vastgelegd.
• Synchronisatielussen, waarin twee systemen elkaar overschrijven.
• Stille uitval, waarbij een koppeling stopt en niemand het merkt tot de maandafsluiting.

Vraag u bij elke koppeling af: wat gebeurt er als hij uitvalt en hoe merk ik dat?

Vragen voor leveranciers

1. Is de koppeling ingebouwd of een connector van een derde?
2. Is hij eenrichtings of tweerichtings en wat start een synchronisatie?
3. Wat gebeurt er als een synchronisatie mislukt? Krijg ik een melding?
4. Welke velden worden gedeeld en welk systeem wint bij een conflict?
5. Zijn er extra kosten?
6. Kunt u me laten zien dat het werkt?

Vergelijkt u producten, dan kunt u de koppelingsregels uit de koopgids en de vergelijking van de beste software aan uw scorekaart toevoegen.