Hoe schrijf je een TMS RFP: onze ervaringen [+ 5 gratis sjablonen]

We beantwoorden wekelijks transportmanagementsysteem-RFP's (Request for Proposal). Sommige zijn een plezier om doorheen te werken. Andere zijn een les in wat je vooral niet moet doen.

Dit artikel is wat ik zou bouwen als ik vandaag een TMS-selectieproces van de grond af zou opzetten. Het is gebaseerd op de RFP's die we hebben beantwoord, op patronen die steeds terugkeren bij verschillende bedrijven en sectoren, op wat de meeste ervan bevatten en op de fouten die we keer op keer zien.

Ben je een inkoopspecialist, dan zal veel hiervan vertrouwd aanvoelen. Hopelijk bespaart het je in elk geval één onnodige verduidelijkingsronde.

Wat is een TMS RFP?

Een TMS RFP (Request for Proposal) is een gestructureerd document dat je verstuurt naar aanbieders van transportmanagementsystemen. Het beschrijft je logistieke operatie en vraagt elke leverancier om op basis van dezelfde eisen voor te stellen hoe hun systeem daarmee omgaat. Het hele punt is vergelijkbaarheid: dezelfde vragen, hetzelfde format, dezelfde context — zodat wat je terugkrijgt naast elkaar gelegd kan worden in plaats van gelezen als vijf afzonderlijke verkooppraatjes.

Je hebt er niet altijd een nodig. Een RFP verdient zijn bestaan wanneer de beslissing complex is, of wanneer je die intern moet kunnen verantwoorden. Als je logistieke operatie eenvoudig is, volstaan een productdemo en een gesprek met een paar leveranciers.

Heb je echt een TMS RFP-aanbesteding nodig?

Dit verkeerd inschatten is de duurste fout in het hele TMS-selectieproces. Beslis dit vóór alles.

Het draait om hoe complex je logistiek is, niet om hoe groot je bedrijf is.

Voer een gestructureerde TMS RFP-aanbesteding uit als je vanuit meerdere locaties verzendt, gebruikmaakt van verschillende transportmodi en het systeem moet koppelen aan je ERP. Dan heb je alle leveranciers naast elkaar nodig, zodat niets belangrijks door de mazen glipt. Vervoerders worden op heel verschillende manieren aangesloten. De ene noemt het "native", de andere routeert het stilletjes via een derde partij. In een losser proces merk je dat pas nadat je hebt getekend — en dan is het te laat.

Sla de formele RFP-aanbesteding over als je één locatie hebt met een handvol vervoerders en al weet wat je nodig hebt. Waarom? Omdat je jezelf op het moment dat je een RFP uitschrijft meteen in de enterprise-prijscategorie plaatst. 2 à 3 goede demo's met gerichte vragen leveren je vaak een beter systeem op, goedkoper en sneller. Vertel die 2 à 3 leveranciers wat je verzendt en welk probleem je wilt oplossen, en vraag ze dat te laten zien in hun live systeem. Binnen een uur weet je genoeg. En als je voornamelijk pakketten verstuurt in plaats van pallets of vracht, heb je misschien helemaal geen volledige TMS nodig — software voor verzending via meerdere vervoerders is een andere, lichtere categorie die daar specifiek voor is gebouwd.

Wees dus eerlijk over welke aanpak bij jou past voordat je begint. Een RFP uitvoeren die je niet nodig had, is de langzaamste en duurste manier om een TMS aan te schaffen.

Een RFP uitvoeren die je niet nodig had, is de langzaamste en duurste manier om een TMS aan te schaffen.

Nog een waarschuwing als je toch de volledige RFP-route kiest. Een proces vol governance-taal, methodologische kaders en eisen voor vaste prijzen kost weken om op te reageren, en de leveranciers die die overhead kunnen absorberen zijn doorgaans de grote, gevestigde partijen. Als een slankere, modernere oplossing je eigenlijk beter zou bedienen, kan een te bureaucratisch proces die leveranciers stilletjes uitfilteren voordat je ook maar een demo hebt gezien.

Het doel is de juiste oplossing voor jou te vinden. Ontwerp het proces daaromheen, niet om het proces zelf te managen.

Het TMS RFP-proces in 9 stappen

Een TMS-selectie hoeft niet ingewikkeld te zijn. Maar het heeft wel een duidelijke volgorde nodig. Sla stappen over en je betaalt daar later de prijs voor — meestal tijdens de implementatie, wanneer aannames die eerder verduidelijkt hadden moeten worden uitgroeien tot kostbare verrassingen.

Goed uitgevoerd duurt het hele traject 8 tot 12 weken. Minder voor een eenvoudige scope, en het heeft zelden meer nodig.

Dit is de volgorde die werkt:

1. Marktverkenning. Voordat je ook maar één eis opschrijft, besteed je tijd aan het begrijpen van wat er beschikbaar is. De TMS-markt is de afgelopen vijf jaar sterk veranderd: er zijn goede enterprise-platforms, goede midmarket-platforms en echt capabele moderne SaaS-transportmanagementsoftware die vijf jaar geleden nog niet bestond. Stel een longlist op van 5 tot 8 TMS-leveranciers die het waard zijn om te benaderen.
2. NDA. Stuur die vroeg op. Je deelt operationele gegevens zoals volumes, namen van vervoerders en interne systeemdetails — een ondertekende NDA vóórdat de RFP uitgaat is standaardpraktijk en beschermt beide partijen.
3. RFI (optioneel). Een korte Request for Information is zinvol als je longlist breed is en je wilt filteren voordat je investeert in een volledig RFP-proces. Houd het bij één pagina: bedrijfsachtergrond, kernmogelijkheden, globale prijsrange. Genoeg om een shortlist te maken zonder leveranciers essays te laten schrijven.
4. RFP. Het kerndocument. Het geeft elke leverancier wat hij nodig heeft om een nauwkeurig voorstel te doen. Meer hierover in het volgende hoofdstuk.
5. Q&A-venster. Neem dit altijd op. Leveranciers hebben vragen, en de antwoorden verbeteren vaak elk voorstel dat je ontvangt. Voer het schriftelijk uit en deel alle vragen en antwoorden tegelijkertijd met alle leveranciers. Dat houdt het proces transparant en vergelijkbaar.
6. Shortlist en presentaties. Beoordeel de schriftelijke voorstellen en nodig vervolgens 2 à 3 leveranciers uit voor een presentatie. Een presentatie moet een live demonstratie van het systeem bevatten op basis van jouw werkelijke gebruiksscenario's, niet een generieke demo. Als een leverancier jouw scenario niet in zijn systeem kan laten zien, is dat op zichzelf al waardevolle informatie.
7. Tweede ronde (indien nodig). Voor een complexe beslissing is een diepgaandere sessie gericht op specifieke openstaande punten — zoals beveiliging, integratie en commerciële voorwaarden — de moeite waard. Plan hem alleen als je nog echte vragen hebt.
8. Beslissing en contract. Zorg voor interne afstemming voordat je gaat onderhandelen. Ken je must-haves, je aanvaardbare compromissen en je breekpunten.
9. Onboarding. Dit eindigt niet bij de handtekening. De beste RFP-uitkomsten hebben een onboardingplan dat vóór het tekenen van het contract is overeengekomen.

TMS RFP-tijdlijn die je kunt kopiëren

Globale doorlooptijd per scope:

• Enkele, eenvoudige locatie: 6 tot 8 weken (een volledige RFP is mogelijk niet nodig).
• Meerdere locaties + ERP-integratie: 8 tot 12 weken.
• Wereldwijd, multi-entiteit, complexe integratie: 12 tot 20 weken, waarschijnlijk met twee presentatierondes.

Download het RFP-tijdlijnsjabloon (.docx)

Wat er in je TMS RFP-document moet staan

Het RFP-document is je belangrijkste instrument in dit proces. Een goed RFP-document doet het grootste deel van het evaluatiewerk voor je — houd het dus gefocust. Een strak document van 10 pagina's is beter dan een van 30 pagina's dat alles probeert te omvatten.

1. Begeleidende brief en doelstelling

Één pagina. Wie je bent, wat je zoekt, waarom nu. Houd het feitelijk. Leveranciers hebben geen visiedocument nodig — ze moeten simpelweg jouw operationele probleem begrijpen.

2. Tijdlijn

Een duidelijk schema met echte datums: uitgifte van de RFP, deadline voor Q&A, indiening, presentatievenster, beslissing. Leveranciers plannen hun responsinspanning hierop. Vage tijdlijnen leveren vage voorstellen op.

3. Bedrijfs- en operationele achtergrond

Hier schieten de meeste RFP's tekort, en dit is het verschil tussen vergelijkbare voorstellen en een verduidelijkingsronde. Beschrijf niet alleen je bedrijf, maar beschrijf je logistieke operatie. Hoeveel locaties. Hoeveel juridische entiteiten. Welke transportmodi (pakket, LTL, FTL, lucht, zee, rail). Welke regio's. Globale volumes. Huidige systemen. Wat "goed" betekent verschilt ook per sector — de eisen voor fabrikanten van elektronica, machines, chemicaliën of drukwerk en verpakkingen zijn niet hetzelfde. Dit is de context die leveranciers nodig hebben om hun voorstel nauwkeurig te kunnen opstellen. Geef je hier onvoldoende detail, dan ben je twee weken kwijt aan het beantwoorden van verduidelijkingsvragen die volledig vermijdbaar waren. Dit onderdeel krijgt een eigen sectie verderop, in het volgende hoofdstuk.

4. Functionele eisen

Een tabel met wat het systeem moet kunnen, geprioriteerd naar belang: must-have / should-have / nice-to-have (Excel volstaat). Vraag leveranciers om op elke eis te reageren met hun dekkingsniveau: a) native, b) third-party, c) maatwerk, of d) niet ondersteund. Dit is wat voorstellen vergelijkbaar maakt. Verderop meer over hoe je deze lijst opbouwt.

5. Evaluatiecriteria

Vertel leveranciers hoe je de beslissing neemt: functionaliteit, prijs, implementatieaanpak, referenties, beveiliging, team. Deel de weging als je daartoe bereid bent. Hoe transparanter je bent, hoe beter de voorstellen.

6. Prijsmodel

Vraag om een volledige uitsplitsing: abonnement, implementatie, transactiekosten, support en alles wat er verder bij komt. Vraag indien mogelijk om een voorbeeldfactuur. Prijsstructuren verschillen sterk per leverancier, en verborgen kosten hebben de neiging laat op te duiken. Probeer die vroeg boven tafel te krijgen.

7. Antwoordformat

Vertel leveranciers precies hoe je het voorstel wilt opgebouwd zien, en als je sjablonen aanlevert, verplicht dan het gebruik ervan. Vergelijkbare voorstellen besparen je dagen tijdens de evaluatie, en het format ligt volledig in jouw handen.

Download het RFP-documentsjabloon om te starten met de volledige structuur hierboven:

Download het RFP-documentsjabloon (.docx)

De operationele informatie die de meeste TMS RFP's weglaten — en waarom dat het belangrijkste onderdeel is

Dit is het hoofdstuk dat ik elke TMS RFP-schrijver als eerste zou laten lezen.

We reageren op veel TMS-aanbestedingen. Bijna elk voorstel dat we schrijven vereist een verduidelijkingsronde — en dat komt zelden doordat de eisen onduidelijk waren. Het komt doordat de operationele context ontbrak: volumes, locatiestructuur, vervoerderslandschap, huidige systemen.

De RFP's die een volledige verduidelijkingsronde vereisten, hebben bijna altijd één ding gemeen:

We hebben bedrijven weken zien besteden aan het opstellen van evaluatiecriteria en eisenlijsten, om vervolgens een RFP te sturen die niet vermeldt hoeveel zendingen ze per maand verwerken.

Zonder die informatie gaan leveranciers gissen. En als ze gissen, komen de voorstellen te algemeen terug, zijn de prijzen niet definitief en is er niets concreets om te vergelijken.

Een wereldwijde fabrikant met 10 magazijnen en SAP heeft een volledig ander voorstel nodig dan een distributeur op één locatie die zijn logistiek in spreadsheets bijhoudt. Als een leverancier niet kan zien welke van de twee jij bent, dekt hij zich in — en krijg je voorstellen die nergens aan vastzitten.

De oplossing kost een middag. Beantwoord deze tien vragen in de RFP voordat die de deur uitgaat.

1. Organisatie en scope. Hoeveel juridische entiteiten en locaties vallen binnen de scope? Is de uitrol parallel of gefaseerd? Hoe zelfstandig opereren de locaties — aparte vervoerderscontracten, aparte teams?
2. Zendingsvolumes. Maandelijkse en dagelijkse aantallen zendingen per locatie, gemiddeld en piekwaarden. Eventuele seizoensgebondenheid. Verhouding inkomend versus uitgaand.
3. Verdeling per transportmodus. Welk aandeel is pakket, LTL, FTL, lucht, zee? Welke modi groeien? Welke zijn operationeel het meest kritisch?
4. Vervoerderslandschap. Hoeveel vervoerders per locatie en per modus? Gedeeld over locaties of lokaal beheerd? Zijn er strategische vervoerders die prioriteit moeten krijgen, of door de klant aangewezen vervoerders die je niet kunt wijzigen?
5. Geografie en handelsroutes. Welke regio's vallen binnen de scope? Welke routes zijn het belangrijkst: binnenlands, grensoverschrijdend, intercontinentaal? Belangrijke havens of logistieke knooppunten?
6. Huidige situatie. Hoe worden zendingen vandaag gepland, geboekt en gevolgd? In ERP, spreadsheets, vervoerdersportalen, e-mail? Wat zijn de voornaamste knelpunten in het huidige proces?
7. Financiële opzet. Wie betaalt voor transport — één entiteit of meerdere? Zijn er rekeningnummers van derden of klanten? Hoe worden transportkosten vandaag vastgelegd en gevalideerd?
8. Bedrijfsmodel. B2B, B2C? Bij een mix: de verhouding. De operationele en systeemeisen verschillen aanzienlijk.
9. Integratielandschap. Welke systemen moeten worden gekoppeld aan de TMS: ERP, WMS, CRM? Zijn er bestaande vervoerdersintegraties die behouden moeten blijven? Hoe geautomatiseerd moet het zijn vanaf dag één?
10. Tijdlijn en beperkingen. Is er een go-live-datum? Zijn er interne mijlpalen — zoals het einde van het boekjaar, het hoogseizoen of systeemmigraties — die de planning beïnvloeden?

Niets hiervan is moeilijk op te schrijven. Maar het verandert alles aan wat je terugkrijgt.

Download de checklist voor operationele informatie om deze tien vragen om te zetten in een invultabel die je direct in je RFP kunt opnemen:

Download de checklist voor operationele informatie (.docx)

Hoe schrijf je functionele TMS-eisen

Functionele eisen zijn het hart van de RFP. Doe je het goed, dan krijg je een helder, vergelijkbaar beeld van wat elke leverancier wel en niet kan. Doe je het verkeerd, dan ben je weken kwijt aan het ontcijferen van antwoorden die allemaal "ja" zeggen.

Het doel is niet de langste lijst. Het is de eerlijkste.

Prioriteer meedogenloos: must-have, should-have, nice-to-have

Niet alles wat je wilt is even belangrijk. Gebruik drie categorieën en houd je eraan:

1. Must-have (M): niet onderhandelbaar. Een leverancier die hieraan niet voldoet, valt af — wat hij verder ook te bieden heeft.
2. Should-have (S): belangrijk, maar je kunt leven met een tijdelijke oplossing of een belofte op de korte termijn roadmap.
3. Nice-to-have (N): goed om van te weten, maar staat achter alles hierboven.

De meeste lijsten hebben veel te veel must-haves. Als alles kritiek is, is niets dat. Wees eerlijk over wat het systeem werkelijk onbruikbaar zou maken voor jou, en markeer alleen dát als must-have.

Vraag leveranciers om functionaliteitsdekking te classificeren: native / third-party / maatwerk

Laat ze voor elke eis antwoorden met één van de volgende opties:

Deze kolom is waar voorstellen je vertrouwen verdienen of verliezen. Een leverancier die eerlijk antwoordt en niet ondersteund schrijft waar dat van toepassing is, laat zien hoe hij zich als partner zal gedragen. Een leverancier die overal native antwoordt, vertelt je ook iets belangrijks.

Wees specifiek in de vraagstelling

"Ondersteunt het systeem vervoerdersprijzen?" levert je een nutteloos "ja" op. "Kan het systeem de vrachtprijs berekenen voor elke vervoerder — ook voor vervoerders zonder een pricing-API — en die per zending naast elkaar tonen?" levert je iets op dat je daadwerkelijk kunt evalueren.

Waar eindigt het ERP en waar begint de TMS?

Een van de meest voorkomende bronnen van verwarring bij de evaluatie van transportmanagementsystemen is waar de TMS ophoudt en het ERP begint.

Financiële processen zoals grootboekcodering, landed cost en vrachtaudit worden vaak aan de ERP-kant afgehandeld, waarbij de TMS de gegevens aan het ERP aanlevert. Dat is normaal en vaak de juiste opzet. Maar het moet expliciet worden vastgelegd. Wanneer een leverancier op een van je must-haves antwoordt met "afgehandeld via ERP-integratie", ga dan precies na wat dat betekent voor jouw implementatie — en wie dat bouwt.

Beschrijf het doel, niet de technische oplossing

Beschrijf wat je wilt bereiken, niet hoe het systeem dat technisch moet doen. Te gedetailleerde technische eisen sluiten goede oplossingen om de verkeerde redenen uit. Geef leveranciers de ruimte om je een betere aanpak te laten zien dan de aanpak die jij voor ogen had, want soms hebben ze die.

Een eerlijke, geprioriteerde lijst van 30 eisen vertelt je meer dan een spreadsheet van 150 regels waarbij alles kritiek is en elke leverancier elk vakje heeft aangevinkt.

Een startset van TMS-eisen om aan te passen

De meeste eerste kopers willen een vliegende start met de lijst zelf, dus hier is een voorbeeldset op basis van onze ervaring, al gecategoriseerd, die je kunt aanpassen aan jouw operatie. De volledige lijst is te downloaden in het scoreblad hieronder — dit geeft voldoende inzicht in de opzet.

Download het scoreblad voor functionele eisen, al opgebouwd met prioriteiten en een dekkingskolom per leverancier:

Download het scoreblad voor functionele eisen (.docx)

Hoe vergelijk je TMS-kosten (en bouw je een driejaarsmodel)

"Wat kost een TMS?" is de vraag die kopers het liefst beantwoord zien en die leveranciers graag ontwijken. Maar het abonnementstarief is zelden je uiteindelijke kostenpost. Voor een middelgrote, multi-locatie verlader kunnen implementatie en integratie de driejaarskosten zelfs meer bepalen dan de maandelijkse vergoeding — en dat is precies de post waarover leveranciers het vaagst blijven. De kunst is dus om de vraag zo te structureren dat de antwoorden vergelijkbaar terugkomen en de werkelijke kosten zichtbaar worden.

Als globale oriëntatie: midmarket cloudgebaseerde transportmanagementsoftware kost doorgaans enkele honderden tot enkele duizenden euro's per maand, terwijl traditionele enterprise-systemen lopen van tienduizenden tot meer dan een miljoen euro per jaar, met een implementatie die kan oplopen tot zes of zeven cijfers. Dat is een enorme bandbreedte — precies waarom een vergelijkend model belangrijker is dan welk enkel getal dan ook. Voor een indruk van wat echte TMS-aanbieders rekenen, zie ons onderzoek naar de beste TMS-aanbieders.

Prijscomponenten van een TMS

Vrijwel elke TMS-offerte bestaat uit een combinatie van het volgende:

Bouw een driejaarsmodel voordat je vergelijkt

Een TMS-leverancier die goedkoop lijkt op abonnement kan de duurste blijken zodra implementatie, transactiekosten en vervoerdersonboarding erbij komen. Zet elke leverancier door hetzelfde model:

Driejaarskosten = implementatie + (jaarlijks abonnement × 3) + (kosten per zending × jaarvolume × 3) + support + verwachte vervoerders- en integratie-add-ons.

Gebruik je werkelijke volumes, niet het nette voorbeeldscenario van een leverancier. Die ene tabel herschikt de shortlist regelmatig.

Let op de verschillende prijscomponenten, niet alleen het basistarief

Sommige leveranciers prijzen laag op abonnement en verdienen dat terug via transactiekosten of kosten per vervoerder. Dat is niet per se slecht, maar het verandert wie het goedkoopst is naarmate je groeit. Als je volume stijgt, kan een model per zending een vast tarief snel inhalen. Vraag om een voorbeeldfactuur en de abonnementsvoorwaarden, zodat je vergelijkt wat je werkelijk betaalt en niet een toptarief.

Een vraag die elke leverancier waard is: zijn nieuwe vervoerdersintegraties inbegrepen, of worden ze elke keer apart gefactureerd? Sommige TMS-platforms rekenen €5.000 tot €10.000 per nieuwe vervoerdersintegratie en hebben daar maanden voor nodig, terwijl anderen nieuwe vervoerdersintegraties zonder meerkosten bouwen. Voor een middelgrote verlader die door de jaren heen vervoerders toevoegt, kan dat ene antwoord de driejaarskosten meer beïnvloeden dan de abonnementsregel ooit zal doen.

Hoe evalueer je TMS-voorstellen verder dan prijs

De voorstellen zijn binnen. Ze zien er allemaal redelijk uit, de meeste zeggen ja op je eisen en de prijzen liggen in een vergelijkbare range. En nu?

Dit is het punt waarop teams stilletjes terugvallen op prijs, omdat al het andere moeilijker te vergelijken lijkt. Doe dat niet. Dit is wat ze werkelijk van elkaar onderscheidt.

1. Vervoerdersconnectiviteit.

Voor een TMS is vervoerdersconnectiviteit het fundament. Hoe maakt de leverancier daadwerkelijk verbinding met vervoerders — via directe API/EDI-integraties, aggregators van derden, of helemaal niet (e-mail en pdf-orders ongeacht de IT-mogelijkheden van de vervoerder)? Wat gebeurt er als je een vervoerder nodig hebt die ze nog niet ondersteunen, hoe lang duurt dat en wat kost het?

Een leverancier met diepe, directe vervoerdersconnectiviteit is een heel ander verhaal dan een leverancier die alles via een middleware-laag routeert. Je merkt het verschil in de betrouwbaarheid van boekingen, in de kwaliteit van tracking en in de vraag of je een vervoerder kunt toevoegen zonder elke keer een nieuwe commerciële onderhandeling te openen.

2. Harmonisatie van vervoerdersniveaus — dit punt telt zwaarder dan de meeste mensen beseffen.

Vervoerders zijn niet gelijk in hun digitale mogelijkheden. Sommige hebben geavanceerde API's die realtime prijzen, ETA-voorspelling, adresvalidatie, labelgeneratie en gedetailleerde trackingevents ondersteunen. Andere sturen je een boekingsbevestiging per e-mail en daarmee is het gesprek voorbij. De meeste vervoerdersnetwerken bevatten beide soorten tegelijk.

Dat wordt jouw probleem op het moment dat je je ERP of WMS koppelt aan de TMS. Als je integratie van elke vervoerder een volledige dataset verwacht — boekingsbevestiging, trackinglink, label, kostenraming — maar sommige vervoerders kunnen dat niet leveren, krijg je uitzonderingen, handmatige omwegen en gaten in je data. Één zwakke vervoerder breekt de consistentie van de hele workflow.

Er zijn twee manieren waarop verschillende aanbieders van transportmanagementsoftware hiermee omgaan, en het is de moeite waard om te beslissen welke je wilt voordat je ook maar één voorstel leest:

• Een slankere TMS geeft door wat elke vervoerder aanlevert, en het is jouw probleem om de gaten op te vangen in je ERP of via handmatig werk. Eenvoudigere integratie, maar meer uitzonderingen om zelf af te handelen.
• Een TMS die de data normaliseert en de gaten zelf opvult: berekent vrachtkosten op basis van je geüploade tarieflijst wanneer er geen pricing-API is; schat de levertijd in wanneer de vervoerder geen ETA levert; genereert verzendetiketten wanneer de vervoerder dat niet kan; laat vervoerders trackingmijlpalen handmatig invoeren wanneer ze geen tracking hebben, en meer. De software vult de technische tekortkomingen van je vervoerders op, en je ERP ziet één consistente structuur.

Vraag leveranciers bij de evaluatie van voorstellen direct: hoe gaan jullie om met vervoerders met beperkte digitale mogelijkheden? Het antwoord zegt veel over hoe volwassen hun platform werkelijk is.

3. Eerlijkheid over integratie.

Let goed op hoe leveranciers de integratiescope beschrijven (wie doet wat). Een voorstel dat klip en klaar stelt "ERP-zijdige ontwikkeling is voor jou, dit is wat wij leveren en hoe we dat ondersteunen" is betrouwbaarder dan een voorstel dat "naadloze integratie" suggereert zonder uit te leggen welke partij welk deel van de integratie voor zijn rekening neemt. IntegratieVerrassingen zijn een van de meest voorkomende redenen waarom TMS-projecten tijd en budget overschrijden.

4. Implementatieaanpak.

Een gefaseerde aanpak — eerst handmatige operationele validatie, daarna automatisering — brengt doorgaans minder risico met zich mee dan een big-bang-lancering. Je kunt bevestigen dat het systeem werkt voor je werkelijke processen voordat je er je hele operatie op leunt. Van onze kant: de leveranciers die dit voorstellen zonder dat ernaar gevraagd wordt, hebben doorgaans al een rommelige go-live meegemaakt. Degenen die volledige automatisering vanaf dag één aanprijzen, vaak niet.

5. Referenties

Vraag om referenties van bedrijven met vergelijkbare operaties, niet alleen vergelijkbare omvang of personeelsaantal. Een referentie van een distributeur op één locatie is weinig nuttig als je een multi-locatie productieomgeving met SAP-integratie beheert. En stel de gerichte vragen: "Hoe verliep de vervoerdersonboarding?" "Hoe verliep het integratieproces?" "Wat gebeurde er wanneer iets niet werkte zoals verwacht?"

6. Het voorstel zelf.

Hoe een TMS-leverancier op je RFP reageert, is een voorproefje van hoe hij zich als partner zal gedragen. Beantwoordde hij je vragen direct, of omhulde hij alles met voorbehouden? Gaf hij de gaten eerlijk aan, of claimde hij volledige dekking op elke eis? Liet hij zien dat hij je operatie begreep, of stuurde hij je een licht aangepaste versie van zijn standaardpresentatie?

Een voorstel dat op twee punten niet ondersteund toegeeft en uitlegt waarom, is meer waard dan een voorstel dat overal ja op zegt. De waarheid komt er hoe dan ook uit. Beter tijdens de evaluatie dan bij de go-live.

Download de leveranciersevaluatiematrix om leveranciers te beoordelen op gewogen criteria:

Download de leveranciersevaluatiematrix (.docx)

De presentatieronde met TMS-leveranciers

Schriftelijke voorstellen vertellen je wat een leverancier beweert. Presentaties laten zien of hij dat ook kan waarmaken.

In deze fase zou je een shortlist van 2 à 3 leveranciers moeten hebben. Het doel van de presentatieronde is het voorstel onder echte druk te zetten en te zien of het systeem werkt aan de hand van jouw werkelijke scenario's.

Vraag om een live demonstratie, geen standaarddemo

Een standaarddemo is een ingestudeerde reeks die het systeem op zijn best laat zien. Een live demonstratie is jij die zegt: "Laat me zien hoe je deze zending afhandelt, vanuit ons magazijn in Nederland, met onze vervoerder, tegen ons overeengekomen tarief" — en dan kijken wat er werkelijk gebeurt.

Bereid 2 à 3 echte scenario's uit je eigen operatie voor vóór de vergadering: een standaard uitgaande boeking, een zending waarvoor een spoedofferte nodig is, en iets lastigs zoals een vertraagde zending of een vervoerder die geen tracking levert. Wanneer een leverancier steeds terugkeert naar de gepolijste demo in plaats van jouw scenario uit te voeren, heb je daarmee je antwoord.

Daag de zwakke punten uit

Elk TMS-voorstel heeft ze. Ga direct naar de onderdelen waar een leverancier gedeeltelijk heeft geantwoord of waar je twijfels hebt, en blijf daar. Laat ze niet terugschuiven naar iets wat vlekkeloos werkt. Hoe werkt dit precies? Wie doet wat? Wat gebeurt er als het niet werkt zoals verwacht?

Zorg voor de juiste mensen in de vergadering

Aan de kant van de TMS-leverancier moeten de mensen die presenteren degenen zijn die daadwerkelijk aan je implementatie zullen werken — niet alleen het verkoopteam. Vraag dat expliciet. Aan jouw kant: breng iemand van IT mee (als integratie in scope is) en ten minste één persoon die het systeem dagelijks zal gebruiken. Die stelt andere vragen dan inkoop, en je wilt beide sets vragen gesteld hebben.

Tweede ronde, alleen als dat nodig is

Voor een complexe beslissing is een tweede sessie gericht op specifieke onderwerpen de moeite waard. Voorbeeldonderwerpen:

• Beveiliging en gegevensbescherming — vraag om een pentest-rapport of beveiligingsdocumentatie als je IT- of informatiebeveiligingsteam dat vereist
• Integratiearchitectuur — een technische sessie tussen je IT-team en dat van de leverancier
• Commerciële voorwaarden — loop het contract, de SOW en de aannames regel voor regel door voordat je formele onderhandelingen ingaat

Plan hem niet alleen om de eerste vergadering met meer mensen in de zaal te herhalen. Hij moet specifieke openstaande vragen beantwoorden, anders heeft hij geen bestaansrecht.

Leg toezeggingen schriftelijk vast

Alles wat een leverancier in de vergadering toezegt maar niet in het schriftelijke voorstel staat, moet schriftelijk worden bevestigd voordat je verdergaat. Mondelinge toezeggingen overleven contractonderhandelingen niet. Als een TMS-leverancier "ja, dat kunnen we" zegt over iets belangrijks, stuur dan nog dezelfde dag een e-mail en vraag om bevestiging.

TMS-contract en SOW (Statement of Work): wat je moet controleren vóór ondertekening

Je hebt je leverancier gekozen. De meeste teams ademen op dit punt uit. Ik raad je aan dat niet te doen, want dit is waar de details die tijdens de evaluatie werden overgeslagen stilletjes jouw probleem worden.

Stem intern af voordat je gaat onderhandelen

Ken je must-haves, je aanvaardbare compromissen en je breekpunten voordat het gesprek begint. Eisen halverwege de onderhandeling wijzigen kost tijd, beschadigt vertrouwen en zorgt er soms voor dat je de TMS-leverancier verliest die je eigenlijk wilde. Regel het intern eerst, en onderhandel daarna.

Begrijp wat je koopt: SaaS, geen licentie

Moderne TMS-platforms zijn SaaS-abonnementen, geen softwarelicenties. Je abonneert je op een dienst die de leverancier host, onderhoudt en bijwerkt — je koopt geen systeem outright. Dat verschuift wat het contract moet dekken: abonnementsvoorwaarden, beëindiging, eigendom van data en exportrechten, uptime-verplichtingen, responstijden voor support. Standaard inkoopsjablonen zijn niet voor dit model geschreven, dus zorg dat het jouwe is bijgewerkt.

De SOW is even belangrijk als het contract

De Statement of Work legt vast wat er wordt geleverd, door wie en wanneer: accountconfiguratie, vervoerdersonboarding, integratieondersteuning, training en de acceptatiecriteria die aangeven dat de implementatie daadwerkelijk is afgerond. Als het niet in de SOW staat, is het niet inbegrepen — ongeacht wat er in een vergadering of e-mail is gezegd. Lees de sectie aannames extra zorgvuldig. Daar wordt de scope voorwaardelijk gedefinieerd. Als je vervoerderslijst groter blijkt dan vermeld, of je ERP een niet-standaard integratieformaat vereist, bepaalt de aannamensectie of dat een kort gesprek is of een geprijsd wijzigingsverzoek.

Wees expliciet over wat buiten scope valt

Maatwerkontwikkeling, training op locatie, datamigatie, integratiewerk aan jouw systemen, wijzigingen aan vervoerderszijde. Deze worden doorgaans apart geprijsd. Dit op papier zetten vóór ondertekening elimineert de meest voorkomende — en meest vermijdbare — bron van implementatiewrijving: twee partijen die elk iets anders veronderstelden dat inbegrepen was.

Spreek het onboardingplan af vóór ondertekening

Niet erna. Vervoedersprioriteiten, configuratietijdlijn, integratiemijlpalen, go-live-criteria — regel dit allemaal terwijl je nog onderhandelingsruimte hebt. Een leverancier die je op contractstadium geen duidelijk onboardingplan kan geven, vertelt je iets wat je wilt weten voordat je je vastlegt.

Na ondertekening: TMS-implementatie en onboarding

Het grootste deel van het echte risico ligt na de handtekening. Drie dingen bepalen hoe het verloopt.

1. Datamigatie

Vervoerderscontracten, tarieflijsten, adresboeken, historische zendingen. Beslis vroeg wat je moet migreren, wat eerst wordt opgeschoond en wie het werk doet. Rommelige brondata is de meest voorkomende reden dat de go-live-datum steeds verder wordt uitgesteld. Schoon het op voordat je migreert, niet terwijl je aan het migreren bent.

2. Volgorde van vervoerdersonboarding

Je sluit niet alle vervoerders op dag één aan. Prioriteer op volume en kritikaliteit, zet de belangrijkste live en valideer ze, en breid daarna uit. Dit is precies waar de gefaseerde aanpak die je tijdens de evaluatie hebt bevraagd zijn waarde bewijst.

3. Gebruikersadoptie

De mensen die dagelijks zendingen boeken, moeten het nieuwe systeem willen gebruiken. Betrek ten minste één van hen al vanaf de RFP-fase, train ze goed tijdens de hypercare-periode (onboarding) en zorg ervoor dat de dagelijkse workflow echt sneller is dan wat ze daarvoor deden. Een technisch vlekkeloze uitrol die het team gewoon niet gebruikt, is nog steeds een mislukte uitrol.

10 veelgemaakte fouten bij een TMS RFP

De patronen die we het vaakst zien, allemaal op één plek:

• Geen operationele context. De grote fout. Geen volumes, geen locatiestructuur, geen vervoerderslandschap verstrekt aan de leveranciers. Een verduidelijkingsronde en generieke prijzen zijn gegarandeerd.
• Alles is een must-have. Als elke eis kritiek is, is de prioriteitenkolom dode ballast en kun je een dealbreaker niet onderscheiden van een nice-to-have.
• Vage tijdlijn. Geen datums betekent dat leveranciers hun inspanning niet kunnen inschatten, waardoor de voorstellen even vaag terugkomen.
• Te gedetailleerde technische specificaties. De technische implementatie voorschrijven in plaats van het operationele resultaat sluit goede oplossingen om de verkeerde redenen uit.
• De ERP/TMS-grens negeren. Ervan uitgaan dat de TMS financiële processen beheert die het ERP eigenlijk beheert, en dat halverwege de implementatie ontdekken.
• Terugvallen op prijs. Kiezen op het abonnementstarief zonder driejaarsmodel, of zonder vervoerdersconnectiviteit en integratie-eerlijkheid mee te wegen.
• Een standaarddemo in plaats van een live demonstratie. De gepolijste reeks van de leverancier bekijken in plaats van het systeem je werkelijke scenario's te laten testen.
• Referenties die niet bij je operatie passen. Kijken naar indrukwekkende logo's, terwijl die bedrijven een logistieke operatie kunnen hebben die totaal anders is dan de jouwe. Vraag om referenties die op jou lijken, en vraag ze hoe onboarding en integratie werkelijk verliepen.
• Onboarding uitstellen tot na ondertekening. Het plan dat je onderhandelt met onderhandelingsruimte is beter dan het plan dat je onderhandelt zonder.
• Een proces dat te zwaar is voor de juiste leverancier. Bureaucratische overhead die de moderne platforms die je het beste hadden gediend, mogelijk uitfiltert.

Gratis TMS RFP-sjablonen

We hebben vijf sjablonen gebouwd op basis van de RFP's die we beantwoorden, zodat je niet met een leeg vel hoeft te beginnen:

1. RFP-documentsjabloon. De volledige structuur uit deze gids.
2. Scoreblad voor functionele eisen. Geprioriteerd, met een dekkingskolom per leverancier.
3. Checklist voor operationele informatie. De tien vragen als invultabel.
4. Leveranciersevaluatiematrix. Gewogen scores voor meerdere leveranciers.
5. RFP-tijdlijnsjabloon. Activiteiten, datums, verantwoordelijken.

Download het pakket — alle vijf, gratis, zonder e-mailadres. Neem wat nuttig is, laat de rest:

Download het volledige TMS RFP-sjablonenpakket (.zip)

Cargoson is een transportmanagementsysteem dat wordt gebruikt door middelgrote fabrikanten en groothandelaren in Europa en Noord-Amerika. We beantwoorden RFP's zoals die jij straks schrijft aan de lopende band — dus als je liever je eisen eerst bespreekt voordat je begint met schrijven, helpen we je graag om het door te denken, geheel vrijblijvend.

Plan hier een gratis consultatie van 30 minuten

Voer het proces goed uit en het is elk uur waard.