Transportsoftware kiezen: 7 praktijksituaties om tijdens een demo te testen

Laat bij het kiezen van transportsoftware niet alleen functies aanwijzen. Vraag je leverancier om één proefrit van order tot factuurvoorbereiding door te lopen en onderweg bewust uitzonderingen toe te voegen. Kijk samen met planning, chauffeurs en administratie waar informatie terechtkomt en wie een probleem moet oplossen. Dat geeft je een concretere vergelijking dan een lijst met vinkjes.

Bereid één proefrit en drie rollen voor

Vraag om een testomgeving waarin je wijzigingen en fouten kunt uitproberen zonder echte ritten, facturen of berichten te versturen. Maak proeforder TEST-RIT-001: vier pallets van testlocatie A naar testlocatie B, een afgesproken tijdvenster en een fictieve opdrachtgever. Gebruik aparte testrollen voor planner, chauffeur en administratie. Begin iedere test met een verse kopie van de rit, zodat de ene uitzondering de volgende niet verstoort.

Schrijf vooraf op wat voor jouw bedrijf noodzakelijk is. Moet een chauffeur zonder verbinding kunnen registreren? Mag de administratie factureren als een afleverdocument ontbreekt? Kies zelf de regels; de onderstaande acceptatiecriteria zijn voorstellen om met je team en leverancier aan te scherpen.

1. Een normale rit: van invoer naar factuurvoorbereiding

Laat de planner de order invoeren en toewijzen. Laat de chauffeur de opdracht openen en de afgesproken aflevergegevens registreren. Vraag daarna de administratie om de rit terug te vinden en een factuurconcept klaar te zetten. Laat ook zien welke gegevens eventueel naar het boekhoudpakket gaan.

• Let op: blijft dezelfde orderreferentie herkenbaar in planning, chauffeursapp en administratie? Welke gegevens worden opnieuw overgetypt?
• Voorstel voor akkoord: de vier pallets, opdrachtgever en afgesproken ritgegevens blijven herleidbaar. Afwijkingen en handmatige stappen zijn benoemd. De factuur blijft een testconcept; er gaat niets naar een echte klant.

2. Het tijdvenster verandert na de toewijzing

Verander het lostijdvenster nadat de chauffeur de oorspronkelijke opdracht heeft geopend. Laat vervolgens zowel het scherm van de planner als dat van de chauffeur zien. Vraag wat er gebeurt wanneer de chauffeur de wijziging nog niet heeft bekeken of bevestigd.

• Let op: is duidelijk welke instructie actueel is, wie deze wijzigde en of de chauffeur de nieuwe informatie heeft ontvangen? Ontvangen en gelezen zijn verschillende dingen.
• Voorstel voor akkoord: de nieuwste instructie is herkenbaar en de planner ziet welke opvolging nodig is. Een niet-bevestigde wijziging verdwijnt niet stilzwijgend uit beeld. Spreek af wanneer iemand alsnog moet bellen.

3. De opdrachtgever annuleert vóór vertrek

Annuleer een toegewezen proefrit. Controleer de planning, chauffeursapp en factuurvoorbereiding afzonderlijk. Laat de leverancier ook zoeken op de oorspronkelijke orderreferentie: je wilt kunnen achterhalen wat er is gebeurd.

• Let op: krijgt de chauffeur de annulering mee? Blijft de reden zichtbaar? Komt de rit nog ten onrechte in de lijst met uit te voeren opdrachten?
• Voorstel voor akkoord: de annulering is overal herkenbaar. De normale rit wordt niet ongemerkt gefactureerd. Eventuele annuleringskosten volgen de afgesproken commerciële regels of gaan eerst naar een medewerker voor beoordeling.

4. De chauffeur heeft tijdelijk geen verbinding

Spreek met de leverancier een veilige test af: open de opdracht op een testtoestel, verbreek de verbinding en probeer een afleverregistratie vast te leggen. Sluit en heropen de app als offline bewaren onderdeel van het aanbod is. Herstel daarna de verbinding en vergelijk de registratie met de planning.

• Let op: maakt de app onderscheid tussen lokaal opgeslagen en daadwerkelijk doorgestuurd? Wat gebeurt er als de planner intussen dezelfde rit heeft gewijzigd?
• Voorstel voor akkoord: er is geen onterechte melding dat gegevens zijn doorgestuurd. Een bewaarde registratie komt na herstel één keer aan, of een medewerker krijgt een duidelijke herstelactie. Ondersteunt het pakket geen offline invoer, leg dan de praktische noodwerkwijze vast en beoordeel of die voor jouw ritten acceptabel is.

5. Een deel van de lading of afleverinformatie ontbreekt

Laat bij de proefrit drie van de vier pallets als afgeleverd registreren. Laat daarnaast één document weg dat in jouw eigen proces vereist is. Dat hoeft niet altijd een foto of handtekening te zijn: kies de gegevens die je daadwerkelijk nodig hebt voor deze opdracht.

• Let op: ziet de administratie het verschil tussen gedeeltelijk afgeleverd, compleet afgeleverd en nog te beoordelen? Wie krijgt de uitzondering toegewezen?
• Voorstel voor akkoord: het ontbrekende deel en de reden blijven zichtbaar. De afgesproken controle vóór facturatie wordt uitgevoerd. Laat daarna het ontbrekende gegeven toevoegen en toon wie de uitzondering afsluit, zonder de oorspronkelijke registratie onzichtbaar te overschrijven.

6. Een koppeling stuurt dezelfde opdracht opnieuw

Vraag de leverancier in de testomgeving dezelfde order tweemaal aan te bieden met dezelfde externe referentie. Herhaal, als factuuruitwisseling onderdeel van de oplossing is, ook een overdracht waarvan de ontvangstbevestiging uitblijft. Dit test je samen met de leverancier; verstuur geen proefverzoeken naar een live administratie.

• Let op: ontstaat er een tweede order of factuur? Kan iemand zien dat het om een herhaling gaat? Welke toepassing bepaalt of de verwerking al is gelukt?
• Voorstel voor akkoord: de afgesproken controle voorkomt dubbele zakelijke verwerking of zet de herhaling zichtbaar klaar voor beoordeling. Een fout kan worden hersteld zonder blind nog een keer te verzenden.

Een API alleen bewijst dit niet. MDN beschrijft idempotentie als hetzelfde bedoelde effect bij herhaalde identieke verzoeken; dat is niet voor iedere HTTP-methode gegarandeerd. Vraag daarom om een demonstratie van de werkelijke order- en factuurkoppeling, niet alleen om de mededeling dat er een API beschikbaar is.

7. Planner, chauffeur en administratie hebben andere rechten

Wissel tijdens de demo echt tussen de drie testaccounts. Laat de chauffeur een eigen opdracht openen en probeer vervolgens een niet-toegewezen proefrit te bekijken. Laat de administratie financiële gegevens aanpassen en controleer of die mogelijkheid ook bij de chauffeur verschijnt.

• Let op: passen zichtbare gegevens en bewerkrechten bij de afgesproken taak? Gebruik geen gedeeld beheerdersaccount om alle rollen na te bootsen.
• Voorstel voor akkoord: iedere rol kan de benodigde handelingen uitvoeren en krijgt ongeoorloofde gegevens of wijzigingen niet beschikbaar. Laat een geweigerde handeling daadwerkelijk testen; een verborgen knop alleen is geen bewijs dat toegang is afgeschermd. Dit is een functionele roltest, geen volledige beveiligingsaudit.

Maak van de demo een korte beslislijst

Noteer per test: getoond en passend, extra inrichting nodig, niet beschikbaar of nog niet bewezen. Een belofte op de roadmap is geen getoonde functie. Leg bij iedere open vraag vast wie het uitzoekt, wanneer je bewijs krijgt en welke extra kosten of licenties nodig zijn. Gebruik deze compacte lijst tijdens het gesprek.

Technische documentatie helpt bij de voorbereiding. Het MendriX Developer Portal beschrijft bijvoorbeeld afzonderlijke interfaces voor TMS-, chauffeurs- en track-and-tracegegevens. Welke functies je kunt gebruiken, hangt af van het concrete pakket, de inrichting en de afspraken met de leverancier. Deze checklist beoordeelt geen merk en veronderstelt geen samenwerking met een leverancier.