Transportmanagementsysteemvereisten: Gids 2026
Een praktische checklist met vereisten voor een transportmanagementsysteem voor vervoerders, met aandacht voor planning, POD, integraties, KPI's en RFP-vragen.
Het dispatchbord zit vol, het terminalslot schuift op en finance vraagt waarom de afgeronde jobs van vorige week nog steeds niet zijn gefactureerd. Een chauffeur heeft een afleverbon via een berichtenapp gestuurd, een andere POD ligt in een cabine, en niemand kan bevestigen of de free-timeklok van een container al is verlopen. Dat is de operationele realiteit achter vereisten voor een transportmanagementsysteem. Een lange functielijst lost dat niet op. Het juiste systeem moet planning, uitvoering, containerstatus, proof of delivery, facturatie, compliance en prestatiegegevens verbinden in één werkbare workflow.
De markt beweegt in die richting. Eén benchmark waardeert de wereldwijde markt voor transportmanagementsystemen op USD 18,50 miljard in 2025, met een prognose van USD 37,04 miljard in 2030, wat neerkomt op een cagr van 14,9% van 2025 tot 2030. Voor middelgrote vervoerders en containeroperators is dat groeicijfer minder van belang als marktkrantkop dan als koopsignaal. TMS-software wordt operationele infrastructuur, niet een mooier ogende dispatch-spreadsheet.
Inhoudsopgave
Waarom de meeste lijsten met TMS-vereisten het echte probleem van de koper missen
De meest voorkomende fout in de afbakening is een enterprise-checklist kopiëren naar een inkooptraject voor de middenmarkt. De lijst bevat multimodale optimalisatie, carrier procurement, control-tower-dashboards, voorspellende analyses en elke koppeling die de leverancier ooit heeft gebouwd. Ondertussen typen planners jobs nog steeds opnieuw over uit e-mail, missen chauffeurs toegangsinstructies en wacht finance op getekende POD's.
Een vereiste telt alleen als die een beslissing verandert of een knelpunt wegneemt. De nuttige vraag is niet: “Heeft het platform zichtbaarheid?” maar: “Kan de planner elke job identificeren die het terminalafspraakvenster dreigt te missen, zien wie de volgende actie bezit, en de klant waarschuwen voordat de fout een claim wordt?”
Begin met operationeel bewijs
Voer drie controles uit voordat u met leveranciers spreekt.
Audit de laatste 30 dagen aan uitzonderingen. Bekijk late ophalingen, gemiste aflevervensters, ontbrekende POD's, factuurgeschillen, dubbele jobs, fouten in voertuigbeschikbaarheid, detention-risico en handmatige klantupdates. Vertrouw niet op managementsamenvattingen. Vergelijk het dispatchbord, chauffeursberichten, afleverdocumenten en financiële records.
Koppel aan elke lacune een zakelijke consequentie. Een ontbrekende POD kan facturatie vertragen, een geschil veroorzaken of medewerkers dwingen de ontvanger na te bellen. Een gemist terminalslot kan wachttijd, herplanningswerk en ontevreden klanten veroorzaken. U hoeft geen verzonnen besparingsraming te maken. Wel moet u bepalen welke fout geld, capaciteit of managementaandacht kost.
Rangschik vereisten op impact op de cashcyclus. Zet POD-vastlegging, validatie van jobafronding, factuurgereedheid en afwikkelingscontroles hoog op de lijst als late documenten de inning vertragen. Zet geavanceerde optimalisatie lager als planners al werkbare routes kunnen maken maar jobs niet netjes kunnen afsluiten.
Praktische regel: Een vereiste hoort alleen in de RFP als de koper de operationele beslissing kan noemen die ermee verbetert, de gebruiker die het nodig heeft en het bewijs dat aantoont dat het gewerkt heeft.
Richtlijnen uit de sector bieden nog steeds een bruikbaar uitgangspunt. De TMS-criteria van Gartner omvatten planning, freight sourcing en procurement, zichtbaarheid, uitvoering en analytics, waaronder orderintake, consolidatie, keuze van modaliteit en route, carrierselectie, communicatie en KPI-meting. Gebruik die categorieën als ondergrens en voeg daar de cash- en containercontroles aan toe die generieke sjablonen vaak missen.
Vereisten zijn geen wensenlijst. Het zijn beslissingen over wat de operatie op een drukke dag betrouwbaar moet kunnen doen.
Kernfunctionele modules die een TMS voor de middenmarkt moet afdekken
Een planner ervaart een TMS als een reeks overdrachten. Een order komt binnen, het team valideert die, wijst een voertuig toe, geeft de chauffeur instructies, volgt de voortgang, verzamelt afleverbewijs en geeft de job vrij voor facturatie. Als één stap buiten het systeem valt, reconstrueren medewerkers dezelfde informatie elders.
De operationele volgorde
Orderintake moet gestructureerde gegevens uit e-mail, klantenportalen, API's of handmatige invoer accepteren zonder dubbele records te maken. Het systeem moet referenties, adressen, vereisten, tarieven, aflevervensters en documentbijlagen bewaren.
Planning heeft een visueel jobsraster nodig met filters op voertuig, chauffeur, klant, status, terminal en uitzondering. Een planner moet jobs kunnen herplannen, herverdelen en in bulk bewerken zonder elk record apart te openen. Werkt de demo alleen op één nette job, vraag dan de leverancier om een late auto, een geannuleerd slot en een wijziging die meerdere jobs raakt te tonen.
Chauffeursinstructies moeten de praktische aanwijzingen plaatsen waar de chauffeur ze kan gebruiken. Denk aan route-informatie, referenties voor ophaling en levering, toegangsbeperkingen, contactgegevens, timingvereisten en, waar relevant, container- of sealinformatie. Een chauffeur-app die zonder betrouwbare verbinding uitvalt, is een productie-risico, dus test offline gedrag in plaats van een mondelinge geruststelling te accepteren.
Uitvoeringstracking moet geplande versus werkelijke mijlpalen, huidige status, ETA, reden van vertraging en verantwoordelijke gebruiker tonen. Tracking is niet nuttig als het alleen een kaart oplevert zonder uitzonderingenqueue.
POD-vastlegging zit direct op het pad naar kasconversie. De chauffeur moet via de mobiele workflow een leesbaar document of digitale POD indienen, met tijdstempels en bijlagen gekoppeld aan de juiste job. Stel intern een norm op voor snelle indiening en meet die vervolgens. De koper moet geen genoegen nemen met “chauffeurs kunnen documenten uploaden” als volledig antwoord.
Facturatie moet afgeronde, door POD ondersteunde jobs identificeren en ontbrekende referenties, afwijkende aantallen, tariefverschillen of onopgeloste uitzonderingen signaleren voordat een factuur de klant bereikt. Afwikkeling moet verwachte en werkelijke kosten afstemmen, goedkeuringen ondersteunen en een audittrail bewaren.
| Module |
Minimaal acceptabel gedrag |
Foutmodus als die ontbreekt |
| Orderintake |
Structuurgegevens en bijlagen vastleggen zonder dubbele invoer |
Opnieuw invoeren, ontbrekende referenties, dubbele jobs |
| Planningbord |
Live jobs filteren, herverdelen, herplannen en in bulk bewerken |
Planners werken met verouderde spreadsheets |
| Chauffeursinstructies |
Route-, toegangs-, timing- en referentienotities op mobiel leveren |
Gemiste instructies en vermijdbare telefoontjes |
| Uitvoering |
Mijlpalen, ETA, vertragingen en eigenaars registreren |
Problemen komen pas aan het licht na een klacht |
| POD-vastlegging |
Afbeeldingen of digitale records aan de juiste voltooide job koppelen |
Facturatie wacht terwijl documenten worden nagetrokken |
| Facturatie |
Ondersteunde jobs vrijgeven en uitzonderingen markeren |
Onjuiste facturen en debiteurenconflicten |
| Afwikkeling |
Geplande kosten vergelijken met werkelijke kosten |
Margeverlies en handmatige reconciliatie |
Gebruik dit overzicht van transportmanagementsysteemmodules om te toetsen of de terminologie van een leverancier aansluit op echte workflows. Het belangrijke onderscheid is tussen een module die in het menu bestaat en een workflow die een moeilijke operationele dag overleeft.
Containerspecifieke vereisten naast generieke wegvervoerlogica
Een checklist voor palletladingen behandelt een beweging als oorsprong, bestemming, voertuig en aflevermoment. Containeroperators werken met een ander operationeel object. De job kan afhankelijk zijn van een boekingsreferentie, release order, terminalafspraak, containernummer, ISO-code, poortstatus en een free-time-deadline.
Een generiek TMS registreert de haven vaak als nog een stop. Dat is onvoldoende. Een terminalbezoek is een event met slotbeperking, en de gevolgen van vertraging kunnen doorlopen nadat de truck het terrein heeft verlaten. Het systeem moet een transportopdracht onderscheiden van een release order, de boekingsreferentie bewaren en exact tonen welke container bij de beweging hoort.
Minimaal containerdatamodel
Vereis op jobniveau velden voor:
- Boekingsnummer, zodat de beweging kan worden gekoppeld aan de klant of verschepingsinstructie.
- Containernummer en ISO-containercode, zodat de fysieke eenheid en het type eenduidig blijven.
- Terminal of kade, inclusief de relevante ophaal- of afleverlocatie.
- Verloop van free-time, met zichtbare status en eigenaarschap voor de volgende actie.
- Type release, zodat dispatch weet of de beweging afhangt van een release, boeking, interchange of andere autorisatie.
- Afspraakgegevens van het slot, inclusief geplande tijd, bevestigingsreferentie en wijzigingshistorie.
- Live ETA naar de terminal, zodat het team vóór het missen van een slot kan ingrijpen.
Tracking van demurrage en detention hoort niet in een notitieveld te verdwijnen. Het systeem moet de klok tonen, die koppelen aan container en job, en een uitzondering genereren wanneer de deadline nadert of operationele gegevens onvolledig zijn.
| Vereistegebied |
Generieke aanname voor wegvervoer |
Containerspecifieke behoefte |
| Jobidentiteit |
Klantorder en afleverreferentie |
Boeking, release, container- en transportreferenties |
| Voertuigbeweging |
Ophaal- en aflevermijlpalen |
Terminalslot, gate-event, interchange en kademelding |
| Vrachtgegevens |
Goederen, hoeveelheid, verpakking |
ISO-code, containernummer, seal en releasetype |
| Tijdcontrole |
Aflevervenster |
Verlopen free-time plus detention- en demurrage-risico |
| Zichtbaarheid |
Locatie van voertuig of zending |
ETA naar terminal en status over havengebeurtenissen |
| Uitzonderingsafhandeling |
Late ophaling of levering |
Gemist slot, onbeschikbare release, gate-afwijzing of klokrisico |
Een containeroperator moet elk platform afwijzen dat deze velden niet in het werkbeeld van de planner kan tonen. De gids over de architectuur van containervervoersoftware biedt nuttige context voor het evalueren van containerspecifieke workflows, maar de eindtoets is operationeel. Geef de leverancier een echte boeking, een gewijzigd terminalslot en een free-time-deadline. Vraag het team de uitzondering af te handelen zonder een aparte spreadsheet te maken.
Koppelingen en gegevensuitwisseling waarop operators echt vertrouwen
Discussies over integraties verzanden vaak in architectuurtoneel. Leveranciers praten over API's en connectiviteit terwijl de koper vergeet wie eigenaar is van de data, hoe vaak die beweegt en wat er gebeurt als de feed stopt.
Gebruik drie niveaus. Het eerste beschermt finance, het tweede beschermt dispatch en het derde beschermt de terminaluitvoering.
Niveau één beschermt de factuur
ERP- en boekhoudkoppelingen omvatten Sage, Xero, QuickBooks, SAP Business One en Microsoft Dynamics 365 Business Central. Finance bezit meestal de masterdata, waaronder klanten, belastinginstellingen, grootboekcodes, tarieven en debiteurenstatus. De koppeling moet gebruikmaken van een gedocumenteerde REST API, goedgekeurde connector of beveiligde bestandsuitwisseling, met geplande of gebeurtenisgestuurde updates.
Minimaal moeten klant- en jobreferenties, factuurregels, belastinggegevens, valuta waar van toepassing, kredietstatus, betalingsstatus en afwikkelingscorrecties worden uitgewisseld. Zonder deze koppeling voeren medewerkers facturen opnieuw in en heeft finance moeite om debiteurenbalansen af te stemmen.
Niveau twee beschermt de dagplanning
Telematica- en chauffeursystemen zoals Webfleet, Microlise, Trimble en Geotab leveren operationele data. Het operationele team bezit de werkinterpretatie, ook als de telematicaprovider het bronplatform beheert. Gebruik REST API's, webhooks of beveiligde bestanden, met frequentie die past bij het event. Minimale velden moeten voertuigidentiteit, chauffeuridentiteit, locatie, tijdstempel, contact- of bewegingsstatus, ETA-inputs en relevante chauffeur- of voertuigmeldingen bevatten.
Klant- en 3PL-portalen moeten ordercreatie, statusmijlpalen, ETA, reden van uitzondering, POD-beschikbaarheid en referentienummers uitwisselen via REST of SFTP. Als de feed uitvalt, moeten planners niet terugvallen op telefoontjes en verspreide berichten.
Niveau drie beschermt de terminaluitvoering
Port- en EDI-systemen kunnen Portbase, Cargo Community System, EDIFACT IFTMIN, PortNet en boekings-API's voor terminalafspraken omvatten. De externe haven of terminal is vaak eigenaar van de data. Vraag specifiek of het TMS het vereiste berichtformaat, de verwerking van bevestigingen, foutzichtbaarheid en updates van slotstatus ondersteunt.
| Niveau |
Integratiegroep |
Typische systemen |
Gegevenseigenaar |
Protocol / frequentie |
Foutmodus als die ontbreekt |
| Eén |
ERP en boekhouding |
Sage, Xero, QuickBooks, SAP Business One, Business Central |
Finance |
REST, connector of SFTP, gepland of gebeurtenisgestuurd |
Dubbel opnieuw invoeren en niet-afgestemde saldi |
| Twee |
Telematica en chauffeursapps |
Webfleet, Microlise, Trimble, Geotab |
Operatie en wagenpark |
REST of webhook, frequente eventupdates |
Dispatch valt terug op bellen |
| Twee |
Klant- en 3PL-portalen |
Klantplatforms en partnerportalen |
Operatie of klant |
REST of SFTP, order- en mijlpaalevents |
Handmatige statusupdates en documenten najagen |
| Drie |
Port- en EDI-systemen |
Portbase, Cargo Community System, PortNet, terminal-API's |
Externe terminal of haven |
EDI, API of beveiligde bestandsuitwisseling, eventgebaseerd |
Handmatig slot boeken en ondoorzichtige havenstatus |
De gevaarlijke lacune is een TMS dat wel met finance integreert maar geen praktische portconnectiviteit heeft. Voor een containeroperator kan daardoor juist het meest tijdkritische deel van de job buiten het systeem vallen.
Beveiliging, compliance en bewijs voor verkeersveiligheid
Een beveiligingsslide van een leverancier is geen bewijs. Inkoop heeft documenten, systeemtoegang en contractuele verplichtingen nodig die een klantenaudit of inspectie door een toezichthouder kunnen doorstaan.
Vereis een actueel ISO 27001-certificaat dat de specifieke TMS-dienst dekt, niet alleen het moederbedrijf van de leverancier. Vraag om een gepubliceerd SOC 2 Type II-rapport of gelijkwaardige assurance, GDPR-compatibele verwerkingsvoorwaarden, hostingdetails die relevant zijn voor uw organisatie en een duidelijk beleid voor gegevensretentie. Het contract moet ook subprocessors, meldplicht bij datalekken, data-export en verwijdering afdekken.
Bewijs dat de operatie kan opvragen
Op rol gebaseerde toegang moet dispatch, chauffeurs, finance, klanten, beheerders en subcontractors scheiden. MFA, encryptie tijdens overdracht en opslag, onveranderbare audittrails en gecontroleerde toegang voor beheerders zijn basiscontroles. Vraag te zien hoe het systeem wijzigingen in tarieven, POD's, afleverstatus, facturen en gebruikersrechten vastlegt.
Voor operators die te maken hebben met het EU Mobility Package: bevestig hoe tachograaf- en chauffeurstijdgegevens worden geïmporteerd, gedownload, opgeslagen en getoond tijdens een inspectie. Een TMS vervangt specialistische compliance-systemen niet automatisch. Het moet exact laten zien welke data het verwerkt en waar een ander systeem leidend blijft.
ISO 39001 beschrijft vereisten voor managementsystemen voor verkeersveiligheid en is een nuttige referentie voor herhaalbare, controleerbare veiligheidsprocessen. Een TMS kan dat bewijs ondersteunen via registraties van rijgedrag, incidentlogs, trainingsstatus, kwalificatie van subcontractors, voertuigcontroles en koppelingen tussen veiligheidsmaatregelen en uitgevoerd werk.
Een praktische bron over supply-chain compliance kan helpen om het bredere control framework op te zetten. Vraag tijdens de leveranciersevaluatie elke aanbieder om live te tonen hoe bewijs kan worden opgehaald. Als het genereren van een audittrail een supportticket vereist, is de controle operationeel niet volwassen.
Implementatie, onboarding en total cost of ownership
In 2026 moeten gebruiksgemak bij implementatie en transparantie in prijsstelling basisvereisten zijn, geen speciale toegevingen voor kleinere operators. Een middelgrote vervoerder moet geen lang verandertraject accepteren omdat de leverancier meer schermen biedt dan het bedrijf kan gebruiken.
Eis een benoemde onboardinglead, een schriftelijke scope en een vast go-liveplan voor de kern van planning tot facturatie. De leverancier moet een sandbox-tenant bieden voor parallel draaien, gedocumenteerde importsjablonen, rolgebaseerde training en een proces voor het afhandelen van fouten na livegang. Vraag wat de klant zelf moet aanleveren, want verborgen interne inzet hoort nog steeds bij de projectkosten.
Bouw het echte kostenmodel
Prijs het systeem over een horizon van drie jaar. Neem licenties, integratiewerk, datamigratie, training, interne projecttijd, supportniveaus, apparaat- of connectiviteitskosten waar van toepassing en de opportuniteitskosten van vertraagde facturatie mee.
| Kostenpost |
Jaar 1 |
Jaar 2 |
Jaar 3 |
Opmerkingen |
| Softwarelicentie |
Geoffreerd bedrag |
Verlenging volgens offerte |
Verlenging volgens offerte |
Geef aan of de prijs per voertuig, chauffeur, job of gebruiker geldt |
| Implementatie |
Eenmalig bedrag |
Geen of wijzigingsverzoeken |
Geen of wijzigingsverzoeken |
Vereis een vaste scope en een maximum |
| Integraties |
Bouw en inrichting |
Onderhoud |
Onderhoud |
Scheid standaardconnectoren van maatwerk |
| Training |
Eerste oplevering |
Opfrissing of training voor nieuwe gebruikers |
Opfrissing of training voor nieuwe gebruikers |
Geef aan wat inbegrepen is |
| Support |
Supportniveau |
Supportniveau |
Supportniveau |
Definieer reactietijden en escalatie |
| Interne tijd |
Personeelsinzet |
Verandermanagement |
Verandermanagement |
Inclusief werk rond finance en chauffeuradoptie |
| Exit en migratie |
Gecontracteerde dienst |
Gecontracteerde dienst |
Gecontracteerde dienst |
Definieer exportformaat en ondersteuning |
Rode vlaggen zijn onder meer minimumafnames langer dan 24 maanden, kosten per API-call en onboarding die per dag wordt gefactureerd zonder plafond. Leveranciers moeten elke variabele kost vóór ondertekening uitleggen. Een goedkope licentie met dure integratiewerkzaamheden is geen goedkoop TMS.
KPI's, SLA's en de performance-loop van POD naar factuur
Een dashboard vol metrics kan nog steeds de cashcyclus onzichtbaar laten. Definieer elke KPI als een operationele berekening met een eigenaar, bron, uitzonderingsregel en consequentie.
On-time delivery heeft een benoemd afspraakvenster nodig. “Op tijd” moet betekenen dat het werkelijke aankomst- of afrondingsmoment binnen het overeengekomen venster valt, en niet alleen dat de chauffeur zich in de buurt bevond.
POD-doorlooptijd moet de verstreken tijd meten van afronding van de levering tot scan of digitale upload. Gebruik het mediaan en niet alleen een selectief gerapporteerde beste score, en segmenteer het resultaat per chauffeur, klant, jobtype en subcontractor.
Invoice-to-cash moet de periode meten van geaccepteerde POD en vrijgave van de factuur tot betaling door de klant. Daarmee wordt het gedrag van dispatch gekoppeld aan financiële uitkomsten. Een POD die te laat binnenkomt is niet alleen een documentprobleem. Die vertraagt het moment waarop het bedrijf met vertrouwen kan factureren.
Een uitgewerkt operationeel voorbeeld kan bijvoorbeeld 95% on-time delivery binnen een venster van 60 minuten, POD-mediaan onder 4 uur en DSO onder 38 dagen hanteren. Die cijfers zijn voorbeelden van KPI-definities, geen universele benchmarks. Het TMS moet laten zien hoe elk resultaat wordt berekend, wie de data aanlevert en wat er gebeurt wanneer de dienst van de leverancier de afgesproken drempel mist.
| KPI |
Definitie |
Doel |
Databron |
SLA-respons |
| On-time delivery |
Afsluiting binnen het benoemde afspraakvenster |
95% binnen een venster van 60 minuten |
TMS-mijlpaal- en afspraakgegevens |
Root-cause review en servicecredit als de leveranciersdata niet beschikbaar is |
| POD-doorlooptijd |
Mediaan uren van afronding levering tot geüploade POD |
Onder 4 uur |
Chauffeursapp en POD-tijdstempel |
Escalatie bij falende mobiele workflow |
| Factuurgereedheid |
Afgeronde jobs met vereiste referenties en POD bijgevoegd |
Te definiëren tijdens contractering |
TMS-job-, POD- en facturatiegegevens |
Corrigerend plan voor workflowfouten |
| Invoice-to-cash |
Dagen van POD-accepteren en factuurvrijgave tot betaling |
DSO onder 38 dagen |
TMS- en boekhoudsysteem |
Financiële review van geschillen en integratiefouten |
Voor bredere wagenparkcontrole kunnen tips voor fleet safety en compliance uit 2025 de bovenstaande vereisten rond verkeersveiligheid aanvullen. Houd de meetloop gesloten: afleverevent, POD-accepteren, factuurvrijgave, geschilstatus en betalingsuitkomst moeten aan dezelfde job te herleiden zijn.
Voorbeeldtekst voor RFP's en vragen voor leveranciersevaluatie
Een goede RFP dwingt een leverancier om gedrag onder druk te beschrijven. Vervang “biedt realtime zichtbaarheid” door een toetsbare clausule: “De leverancier moet voor elke actieve job geplande en werkelijke mijlpalen, de huidige uitzonderingsstatus en de tijdstempel en bron van elke update tonen.”
Direct te gebruiken clausules
- Gegevenseigendom: “Alle operationele, klant-, job-, POD-, factuur-, audit- en configuratiegegevens die door de koper zijn aangemaakt, blijven eigendom van de koper en moeten exporteerbaar zijn in een gedocumenteerd, bruikbaar formaat.”
- Audittoegang: “De koper moet wijzigingen in gebruiker, status, tarief, POD, factuur en rechten kunnen opvragen met tijdstempels en actoridentiteit.”
- Serviceniveau voor integraties: “Kritieke koppelingen moeten een afgesproken beschikbaarheidsdoel, monitoring, meldingen bij incidenten en een herstelproces hebben.”
- POD-bewaring: “POD-afbeeldingen en bijbehorende metadata moeten gedurende de gecontracteerde bewaartermijn van de koper opvraagbaar blijven en bij beëindiging exporteerbaar zijn.”
- Hulp bij exit: “De leverancier moet gedocumenteerde export, ondersteuning bij overgang en redelijke medewerking aan een vervangende leverancier bieden.”
Dertig vragen die bruikbare antwoorden afdwingen
- Kan het systeem orders vastleggen uit onze vereiste kanalen?
- Kunnen planners het live jobsraster filteren op voertuig, chauffeur, klant, status en uitzondering?
- Kunnen gebruikers jobs in bulk bewerken of herverdelen?
- Kan het systeem een volledige wijzigingshistorie bewaren?
- Kunnen chauffeurs route-, toegangs- en referentie-instructies op mobiel ontvangen?
- Werkt de chauffeursworkflow ook wanneer er geen connectiviteit is?
- Kan het systeem geplande en werkelijke mijlpalen registreren?
- Kan het jobs signaleren die risico lopen voordat het afspraakvenster wordt gemist?
- Kunnen chauffeurs POD's rechtstreeks tegen de juiste job uploaden?
- Kan finance zien welke jobs factuurgereed zijn?
- Kan het systeem facturen blokkeren of markeren met ontbrekende POD's of referenties?
- Kan het verwachte en werkelijke transportkosten afstemmen?
- Kan het boekings-, release-, container-, terminal- en ISO-codegegevens vastleggen?
- Kan het het verlopen van free-time en risico op detention of demurrage tonen?
- Kan het terminalslotboekingen en wijzigingen registreren?
- Kan het live ETA naar de terminal berekenen of ontvangen?
- Welke ERP- en boekhoudsystemen hebben ondersteunde connectors?
- Welke REST-, webhook-, SFTP- of EDI-koppelingen zijn beschikbaar?
- Welke partij is eigenaar van elk uitgewisseld gegevenselement?
- Wat gebeurt er als een koppeling uitvalt?
- Kunnen gebruikers afgewezen berichten zien en opnieuw proberen?
- Kan het systeem POD- en statusdata uitwisselen met klantenportalen?
- Heeft de dienst ISO 27001-dekking voor de TMS-dienst zelf?
- Is een SOC 2 Type II-rapport of gelijkwaardig beschikbaar?
- Hoe zijn MFA, encryptie, rollen en auditlogs ingericht?
- Hoe worden chauffeurstijden en tachograafworkflows ondersteund?
- Kan de leverancier bewijsopvraging voor veiligheid en subcontractors tonen?
- Wie is eigenaar van onboarding en wat zit er in de vaste scope?
- Is er een sandbox voor parallel draaien en user acceptance testing?
- Wat zijn de kosten voor licentie, integratie, support, verlenging, API, exit en beëindiging?
Weeg de scorecard zwaarder op on-time performance, POD-doorlooptijd, factuurgereedheid, containerstatuscontrole en ERP-integratie. Nice-to-have analytics mogen niet boven de workflows staan die trucks in beweging houden en facturen verdedigbaar maken.
De vereisten koppelen aan Logivo als uitgewerkt voorbeeld
Een praktische evaluatie van Logivo moet starten met de gepubliceerde operationele scope, niet met een verkoopclaim. Het transportmanagementplatform dekt jobcreatie, toewijzing, uitvoeringstracking, chauffeursinstructies, digitale POD-vastlegging en facturatie in een verbonden workflow. Het bevat ook workflows voor containervervoer en praktische AI-ondersteuning voor document- en invoertaken.
| Vereistegebied |
Match |
Opmerkingen |
| Functionele modules |
Dekt de kernscope |
Controleer bulkbewerking, eigenaarschap van uitzonderingen en offline gedrag van chauffeurs |
| Containerspecifiek |
Relevante dekking |
Bevestig de exacte boekings-, release-, terminal- en free-timevelden die nodig zijn |
| Koppelingen |
Vraagt om validatie |
Bevestig native ERP-, telematica-, portal-, API-, SFTP- en portconnectiviteit |
| Beveiliging |
Contract- en bewijscontrole |
Vraag servicespecifieke certificeringen, auditcontroles, bewaartermijnen en verwerkingsvoorwaarden op |
| Implementatie |
Ontworpen voor lagere opstartlast |
Bevestig scope, tijdlijn, migratietaken, training en prijzen voor wijzigingsverzoeken |
| KPI's |
Configureerbaar startpunt |
Test de berekeningslogica voor mijlpalen, POD-doorlooptijd, factuurgereedheid en cashdata |
| RFP-gereedheid |
Geschikt voor gestructureerde evaluatie |
Vereis meetbare antwoorden en schriftelijke toezeggingen in plaats van functiebeschrijvingen |
Een middelgrote vervoerder moet nog steeds drie gebieden valideren vóór ondertekening: het exacte model voor containerstatus, het boekhoudintegratie- en reconciliatieproces, en het gedrag van de mobiele workflow bij slechte connectiviteit. Beschouw deze tabel als een startbeoordeling, niet als vervanging voor live procestesten.
Snelle checklist, verklarende woordenlijst en veelgestelde vragen
Geef deze checklist aan de operations manager, financieel directeur en planner. Elke vraag moet tijdens een leveranciersdemo een duidelijk ja of nee krijgen.
Koperschecklist
- Functionele kern: Kan het systeem jobs in één workflow creëren, plannen, toewijzen, briefen, volgen, afronden en factureren?
- Jobsraster: Kunnen gebruikers filteren, in bulk bewerken, herverdelen en uitzonderingen herkennen zonder elke job te openen?
- POD: Kunnen chauffeurs ondertekend of digitaal bewijs rechtstreeks tegen de job indienen?
- Factuurcontrole: Kan finance jobs die klaar zijn voor facturatie en ontbrekende documenten identificeren?
- Containercontrole: Kan het systeem boekingsnummer, containernummer, terminal, releasetype, slot en verloop van free-time opslaan?
- Terminalzichtbaarheid: Kan dispatch ETA en haven-gerelateerde uitzonderingen in hetzelfde operationele beeld zien?
- ERP-integratie: Kunnen klant-, tarief-, factuur-, btw-, betalings- en aanpassingsgegevens bewegen zonder dubbele herinvoer?
- Chauffeurs- en telematicadata: Kan het systeem voertuig-, chauffeur-, locatie-, tijdstempel- en mijlpaalgegevens ontvangen?
- Portuitwisseling: Kan het de vereiste API-, SFTP-, EDI- of afspraakworkflow ondersteunen?
- Beveiliging: Biedt de leverancier servicespecifieke certificering, MFA, encryptie, rolinstellingen en audittrails?
- Compliance: Kan het team chauffeur-, incident-, subcontractor- en documentbewijs opvragen?
- Implementatie: Is er een benoemde onboardinglead, vaste scope, sandbox, migratieplan en trainingsplan?
- Commercieel: Zijn licenties, integraties, support, API-gebruik, onboarding, verlenging en exitkosten uitgesplitst?
- KPI's: Zijn definities voor on-time delivery, POD-doorlooptijd, factuurgereedheid en invoice-to-cash schriftelijk vastgelegd?
- RFP-bescherming: Dekt het contract en de SLA gegevenseigendom, beschikbaarheid, audittoegang, bewaartermijnen en overgangsondersteuning?
Woordenlijst in gewone taal
TMS: Software die transportplanning, dispatch, uitvoering, zichtbaarheid, documenten, facturatie en afwikkeling beheert.
POD: Proof of delivery, zoals een getekende afleverbon, digitale bevestiging, tijdstempel of gekoppeld afleverrecord.
EDI 204 en 214: Veelgebruikte elektronische berichten om transportopdrachten en statusgebeurtenissen te communiceren. Bevestig welke berichtformaten uw klanten precies vereisen.
ISO 39001: Een norm voor managementsystemen voor verkeersveiligheid, nuttig voor gestructureerde veiligheidscontroles en controleerbaar bewijs.
SOC 2: Een onafhankelijk assurance-rapport over controles die relevant zijn voor beveiliging en daarmee samenhangende serviceverplichtingen.
Telematica: Gegevens van voertuig en chauffeur, waaronder locatie, beweging en geselecteerde operationele signalen.
Slot booking: Een geplande afspraak voor een voertuig om toegang te krijgen tot een terminal, depot, warehouse of andere begrensde locatie.
Detention: Een kost of exposure die samenhangt met het buiten de toegestane periode houden van materieel. Demurrage heeft meestal betrekking op materieel of cargo dat binnen een terminal blijft na de toegestane periode. Contractdefinities verschillen, dus configureer het systeem volgens de geldende voorwaarden.
Veelgestelde vragen
Hoe lang duurt een typische uitrol voor de middenmarkt?
Het antwoord hangt af van datakwaliteit, koppelingen, procesvariatie en gebruikersbereidheid. Voor de kern van planning tot factuur moet u de leverancier vragen een vast, onderbouwd go-liveplan voor te stellen in plaats van een open implementatie te accepteren.
Wat is de kleinste haalbare scope voor een vloot van 20 trucks?
Begin met orderintake, jobsraster, dispatch, chauffeursinstructies, uitvoeringmijlpalen, POD-vastlegging, factuurgereedheid en boekhoudintegratie. Voeg geavanceerde optimalisatie en bredere portaalconnectiviteit toe zodra de kernworkflow stabiel is.
Hoe voorkomen we scope creep tijdens onboarding?
Schrijf het minimum viable proces in de statement of work. Benoem de vereiste velden, koppelingen, gebruikers, rapporten, acceptatietests en trainingsoutput. Laat elk extra verzoek via een geprijsd change-controlproces lopen.
Wanneer is zelf bouwen versus kopen zinvol?
Bouw alleen als uw operationele model onderscheidend is en u langetermijnownership, support, beveiliging, koppelingen en upgrades kunt financieren. Koop wanneer het proces algemeen genoeg is om bewezen workflows te gebruiken, maar eis configuratie en gegevenstoegang in plaats van dure maatwerkontwikkeling.
Logivo biedt een geïntegreerde workflow voor vervoerders en containeroperators om jobs te plannen, chauffeurs te briefen, digitale POD's vast te leggen, containergerelateerd werk te beheren en afgeronde jobs te koppelen aan facturatie. Bezoek Logivo om de workflow te vergelijken met uw RFP en test vervolgens de drie gebieden die in uw operatie het belangrijkst zijn: POD-doorlooptijd, boekhoudintegratie en containerstatuscontrole.