TMS-statusflow bouwen: van boordcomputer-event naar klant-ETA en escalatie

Je klant belt niet omdat een webhook ontbreekt. Hij belt omdat jouw systeem om 10.00 uur nog zegt dat de chauffeur om 10.15 uur komt, terwijl de boordcomputer al een uur niets meer heeft gemeld. Een statusflow die alleen de laatste status doorzet, maakt van die onzekerheid een klantbelofte.

De oplossing is een kleine, strenge keten: bepaal welke bron eigenaar is, leg ieder event onveranderd vast, match het aan de juiste rit en stop, lees de actuele ETA terug en stuur pas daarna een klantmelding. Ontbreekt de bron, is de melding te oud of spreken twee bronnen elkaar tegen, dan gaat het dossier naar een eigenaar. Niet naar een stille retry.

De productdetails en prijzen hieronder zijn gecontroleerd op 21 oktober 2026. RFC 3339 komt uit juli 2002 en is later aangevuld door RFC 9557. RFC 9110 is uit juni 2022. De genoemde freshness-grenzen zijn voorbeeldbeleid voor een implementatie, geen wettelijke norm.

Een TMS-statusflow is een verwerkingsketen die een bron-event aan één rit en stop koppelt, de tijdigheid en volgorde controleert, een actuele ETA uit de bron leest en alleen op basis van een geldig besluit een klantstatus publiceert. Het systeem bewaart het event, de berekening, de melding en iedere menselijke correctie, zodat je achteraf weet wat er gebeurde en waarom.

De route die je bouwt

Je gaat van event naar klantupdate via zes poorten: ontvangst, authenticiteit, matching, bronversheid, ETA-read-back en melding. Een event dat bij de verkeerde stop hoort of ouder is dan de huidige status mag wel in de tijdlijn komen, maar mag de klantstatus niet terugzetten.

Routeplanning, tachograafretentie en factuurvrijgave vallen buiten deze gids. Voor het bredere ritdossier blijft één rit-ID de sleutel tussen order, POD, tachograafverwijzing en factuur. Hier gaat het om de klantbelofte tijdens de rit: is de volgende status betrouwbaar genoeg om te publiceren?

Wat je nodig hebt vóór de eerste webhook

Begin met je contract en je eigenaarschap. Een API-token is pas nuttig wanneer je weet welke bron je gelooft, welke stop je ermee bedoelt en welke actie mag volgen.

1. Een canoniek rit- en stopmodel

Maak één record voor de rit en één record per stop. Gebruik een eigen sleutel, bijvoorbeeld RIT-2026-1021-0084 en RIT-2026-1021-0084-S03. Bewaar de order-ID, klantreferentie, bron-ID’s, voertuig of onderaannemer, geplande aankomsttijd, tijdvenster, actuele status, laatste geldige ETA, laatste eventtijd en eigenaar van een uitzondering.

Voor de betrouwbaarheid van de write is bronversie, idempotentie en read-back tegen stale writes de juiste basis. De eventtijdlijn is append-only. Voeg ieder ontvangen event toe met source_system, source_event_id, source_entity_id, event_type, event_time, received_at, payload_hash en de ruwe payload of een onveranderlijke verwijzing ernaar. Een delivery-ID voor de aflevering is iets anders dan een event-ID voor de gebeurtenis. Bewaar beide.

2. Een duidelijke bronhouder per gegeven

Maak vóór de bouw een tabel met veld, bronhouder, sleutel, versheidsgrens en toegestane schrijfactie. Een eigen voertuigstatus kan uit Samsara komen. De order en stopvolgorde blijven eigendom van je TMS. Een onderaannemer mag de status en ETA van zijn stop leveren, maar niet stilletjes de klantreferentie of de stopvolgorde veranderen. Je klantcommunicatie heeft weer een eigen geschiedenis: verstuurd, afgeleverd, mislukt of onderdrukt.

Samsara beschrijft twee webhookfamilies, Alert Webhooks en Event Subscriptions. De documentatie noemt voor Webhooks 2.0 meer detail in de JSON en geeft aan dat versie 1.0 geen nieuwe mogelijkheden meer krijgt. Gebruik voor een nieuwe koppeling dus de actuele eventvorm die jouw account ondersteunt en leg de eventversie vast in je broncontract.

3. Tijdstempels die niet kunnen ontsporen

Bewaar drie tijden: event_time, het moment waarop de bron de gebeurtenis zegt te hebben gezien; received_at, het moment waarop jouw endpoint hem ontving; en processed_at, het moment waarop jouw systeem hem beoordeelde. Sla ze op als RFC 3339 definieert een protocolformaat voor datum en tijd met offset of als UTC plus het oorspronkelijke offset. 2026-10-21T09:15:00+02:00 en 2026-10-21T07:15:00Z verwijzen naar hetzelfde moment. 21-10-2026 09:15 doet dat niet controleerbaar.

Qargo vereist in zijn externe subcontractor-webhook een tijdzone-offset in event_time, eta_start en eta_end. Dat is een nuttige ondergrens, ook wanneer jouw eigen API een naamloze lokale tijd accepteert. Zet de lokale tijd voor de planner in de schermlaag, niet in je eventcontract.

4. Een queue met eigenaar en deadline

Een herstelqueue is geen lijst met foutmeldingen. Elk item krijgt een reden, rit-ID, stop-ID, bron, laatste geldige toestand, nieuw ontvangen toestand, deadline, eigenaar, toegestane acties en sluitbewijs. Gebruik vaste redenen zoals event_duplicate, stop_unmatched, source_stale, eta_conflict, source_auth_failed, notification_failed en read_back_mismatch.

Wijs de rol toe, niet alleen een mailbox. De planner behandelt een niet-gematchte stop. Klantenservice behandelt een klantmelding die niet kan worden bevestigd. De integratie-eigenaar behandelt een reeks 401-, 429- of 5xx-fouten. De operationeel manager krijgt alleen escalaties die na de afgesproken termijn openstaan.

5. Toegang tot bron, doel en klantkanaal

Je hebt API- of webhooktoegang tot het TMS, de boordcomputer of het telematicaplatform, de onderaannemer en je klantkanaal. Voor een eigen vloot kan Samsara de bron zijn. Voor een onderaannemer kan Qargo een inbound status-update aanbieden. Voor sms kan Twilio Messaging de afzender zijn; e-mail of een klantportaal past beter wanneer je een langere uitleg of een link naar documenten nodig hebt.

Maak de webhookhandler snel. Samsara verwacht een 2xx-respons na succesvolle ontvangst en adviseert langere verwerking asynchroon te doen. De actuele Samsara-documentatie vermeldt vijf afleverpogingen met exponentiële back-off wanneer de endpoint geen 2xx teruggeeft. Sla daarom eerst op, antwoord snel en verwerk daarna. Een timeout mag nooit direct tot een tweede klantmelding leiden.

Concrete stappen: van event naar klantupdate

Een betrouwbare klant-ETA ontstaat pas wanneer eventmatching, bronversheid en read-back alle drie slagen. Een binnengekomen bericht is een aanleiding om de bron te controleren, geen toestemming om de klant meteen te informeren. De scheiding tussen event, bewijs en menselijke actie sluit aan bij een herstelbare carrierflow met aparte klantoplossing en carrieractie. Loop de stappen in deze volgorde door.

1. Registreer de ruwe aflevering

Maak aan het begin van je webhookhandler een ontvangstrecord. Schrijf minimaal source_system, delivery_id, source_event_id, received_at, de ruwe body, de handtekening of authenticatie-uitkomst en een payloadhash. Verifieer een Samsara-signature of Qargo-credential vóór je het event naar de bedrijfslogica stuurt. Bewaar ook de HTTP-status die je teruggeeft.

Geef iedere nieuwe aflevering een accepted, rejected of duplicate-uitkomst. Bij een duplicate sla je niets weg als nieuwe bedrijfsstatus, maar je bewaart de aflevering wel in het ontvangstlog. Zo kun je later aantonen dat de bron drie keer leverde zonder drie klantupdates te sturen.

2. Normaliseer het event naar je eigen contract

Laat Samsara, Qargo en een losse onderaannemer niet rechtstreeks je klantstatus schrijven. Vertaal hun berichten naar een intern model met vaste waarden, bijvoorbeeld planned, departed, en_route, at_stop, delivered, delayed, exception en unknown. Bewaar de oorspronkelijke waarde ook. AT_STOP uit Qargo en arrived uit een ander TMS kunnen dezelfde interne status krijgen, maar hun bronnamen mogen niet verdwijnen.

Gebruik een statusvolgorde met expliciete uitzonderingen. Een late en_route-melding mag een actuele at_stop-status niet terugzetten. Een echte correctie door een bevoegde planner mag dat wel, maar alleen met actor, reden en tijdstip. De statusmachine moet dus zowel bronstatus als eventtijd en beslisactor meenemen.

3. Match eerst de stop, en pas daarna de ETA

De veiligste match is een eigen stop-ID die je bij het uitzetten van de rit ook in de bron hebt gezet. Gebruik bij Qargo het stop-UUID wanneer je dat hebt. De Qargo-documentatie geeft matching op orderreferentie, consignmentreferentie, stopreferentie en stoptype als alternatief, maar de combinatie moet precies één stop opleveren. Nul of meerdere matches horen in de herstelqueue.

Bij Samsara kun je in de RouteStopEtaUpdated-payload onder meer een eventId, eventTime, route-ID, route-externe ID en stop-ID terugvinden. De beta-eventvorm werkt voor routes die aan een voertuig of bestuurder zijn toegewezen en bevat per stop onder meer eta, enRouteTime, afspraakvensters en externe ID’s. Sla de externe route- en stop-ID op naast je eigen sleutel.

Een klantreferentie alleen is te zwak. Dezelfde referentie kan op een retour, een deellevering of twee stops voorkomen. Match minimaal op rit of route, stop, bronhouder en stoptype.

4. Leg freshness vast vóór je een ETA gebruikt

Freshness is de leeftijd die je maximaal accepteert voor een besluit. Maak hem afhankelijk van de bronfrequentie en de klantbelofte. Een bruikbaar startbeleid voor een binnenlandse rit kan zijn: een event jonger dan 20 minuten is groen tijdens normaal rijden; tussen 20 en 45 minuten is het oranje en vraag je een nieuwe bronlezing; na 45 minuten is het stale en escaleer je. Voor een bron die maar elk uur rapporteert, zijn die grenzen onzin. Gebruik dan minstens de broncadans plus een afgesproken marge.

Bereken naast event_age ook eta_age, want een event kan nieuw zijn terwijl het een oude ETA bevat. Maak een ETA ongeldig wanneer de peiltijd ouder is dan je grens, het tijdvenster ontbreekt, de stop al afgerond is of de ETA vóór de laatst bevestigde aankomst ligt. Publiceer in dat geval geen verzonnen alternatief.

5. Lees de bron terug vóór je publiceert

Gebruik een webhook als trigger en haal de actuele route, stop of ETA op bij de bron. Bij Samsara is de RouteStopEtaUpdated-melding een concreet startpunt, niet het eindbewijs. Bij een subcontractor-event vraag je de actuele status op wanneer de bron dat ondersteunt. Bij een bron zonder read-endpoint zet je de onzekerheid expliciet op het dossier en geef je alleen een melding die die onzekerheid eerlijk weergeeft.

Bewaar de read-back met read_at, bronversie of laatst bekende event-ID, ETA, status, stop-ID en payloadhash. Vergelijk hem met de ontvangen melding. Een verschil is geen technisch detail. Als het event en_route zegt en de bron inmiddels at_stop zegt, telt de read-back voor de huidige toestand, terwijl het oorspronkelijke event in de tijdlijn blijft staan.

Wanneer een bron een ETag of versie ondersteunt, gebruik je een voorwaardelijke write voor iedere terugschrijfactie. RFC 9110 beschrijft If-Match als bescherming tegen ongewenste overschrijvingen en noemt 412 als mogelijke respons wanneer de representatie niet meer overeenkomt. Niet iedere TMS- of telematica-API biedt die poort. Dan zijn broncheck, idempotentie en read-back samen je herstelgrens.

6. Bepaal of een klantupdate iets nieuws zegt

Stuur niet iedere GPS-ping naar een klant. Maak een publicatieregel met drie voorwaarden: de status of ETA is inhoudelijk veranderd, de bron is vers genoeg en de wijziging raakt de klantbelofte. Een verschuiving van 10.18 naar 10.21 is geen bericht. Een verschuiving van 10.18 naar 10.42, een overschreden tijdvenster of een overgang naar delayed wel.

Maak de publieke boodschap los van de interne status. Intern kun je source_stale gebruiken. Extern schrijf je: Ik kan de aankomsttijd op dit moment niet betrouwbaar bevestigen. Je krijgt uiterlijk om 11.15 uur een nieuwe update. Publiceer nooit de ruwe voertuigpositie wanneer een klant alleen een aankomstvenster nodig heeft.

Voor een sms-kanaal kun je Twilio gebruiken. De actuele Nederlandse prijs, aangegeven als oktober 2026, is $0,1143 per uitgaand sms-segment naar een internationaal nummer of alfanumerieke afzender-ID en $0,0075 voor inkomende sms naar een internationaal nummer. Er kunnen carrierkosten bijkomen en een bericht wordt per segment afgerekend. Zet daarom een maximumlengte en een link naar een webpagina in je bericht.

7. Maak de melding idempotent

Gebruik een sleutel als customer-update:RIT-2026-1021-0084-S03:delayed:eta-v4. Dezelfde sleutel mag maar één verzendopdracht maken. Bewaar queued, sent, delivered, failed en superseded als aparte toestanden. Een 202-respons van je berichtenleverancier is geen bewijs van aflevering.

Bij een time-out zoek je eerst op de idempotentiesleutel en lees je de afleverstatus terug. Maak geen nieuwe sms omdat je de eerste respons niet zag. Als de melding nog niet is verstuurd, mag je opnieuw proberen met dezelfde sleutel. Als de klant al een oude ETA heeft gekregen en er komt een nieuwe geldige ETA, markeer je de oude publicatie als superseded en stuur je alleen de inhoudelijk relevante correctie.

8. Maak de herstelqueue uitvoerbaar

Maak van elke afwijking één taak met één eerste actie. Voor stop_unmatched is dat de order en stopreferentie controleren. Voor source_stale is dat de bron opnieuw lezen. Voor eta_conflict is dat beide event-ID’s naast elkaar leggen en de bronhouder raadplegen. Voor notification_failed is dat de kanaalstatus lezen, niet blind opnieuw verzenden.

Zet per taak een deadline. Als een stop over 25 minuten in het klantvenster valt, kan een stale event sneller escaleren dan dezelfde stale event bij een rit die pas morgen wordt gelost. Geef de planner de laatste betrouwbare ETA, de afspraak, het verschil en de voorgestelde klanttekst. Een queue-item zonder context wordt alsnog een telefoontje.

9. Reconcileer en meet na iedere dag

Vergelijk dagelijks de ritten die in je TMS als onderweg staan met ritten die in de bron een event kregen. Zoek stops zonder event, events zonder stop, dubbele event-ID’s, ETA’s buiten het afspraakvenster en klantmeldingen zonder geldige bronlezing. Bewaar een telling per bron en per onderaannemer.

Meet minimaal event-latentie, percentage events zonder match, leeftijd van de oudste queue-taak, percentage klantupdates met read-back, dubbele meldingen per 1.000 stops en tijd tot menselijke oplossing. Een gemiddelde zegt weinig als één onderaannemer de helft van de stale events veroorzaakt.

Valkuilen: waar statusflows hun betrouwbaarheid verliezen

Je gebruikt received_at als gebeurtenistijd

Een event dat om 11.00 uur aankomt, kan om 10.10 uur bij de bron zijn ontstaan. Sorteer op event_time voor de inhoudelijke tijdlijn en gebruik received_at voor netwerkvertraging. Als een bron geen betrouwbare gebeurtenistijd levert, zet je de bronkwaliteit lager en laat je de status niet automatisch een eerdere bevestiging overschrijven.

Je maakt de laatste status tot de waarheid

Een laatste status is een samenvatting, geen bronbewijs. Bewaar alle events en laat een state machine bepalen wat nu geldig is. Een late en_route na delivered blijft zichtbaar in de tijdlijn, maar maakt de levering niet ongedaan.

Je gebruikt één ID voor alles

Een rit-ID, bron-event-ID, webhook-delivery-ID, klantmelding-ID en queue-ID hebben verschillende functies. Meng je ze, dan kun je een dubbele aflevering niet onderscheiden van een nieuwe gebeurtenis. Leg de relaties expliciet vast.

Je matcht op klantreferentie alleen

Een referentie kan op meerdere stops of documenten voorkomen. Qargo accepteert samengestelde matchcriteria en verwacht bij zo’n match precies één stop. Neem die regel over: nul of meerdere treffers zijn een hersteltaak, geen gok.

Je behandelt ETA als een belofte zonder vervaldatum

Een ETA zonder peiltijd en freshness-grens is een getal met schijnzekerheid. Toon in je interne scherm hoe oud de bron is en blokkeer automatische klantupdates wanneer die grens is verstreken.

Je meldt een conflict als vertraging

Een stale bron en een tegenstrijdige bron zijn twee verschillende problemen. Bij stale vraag je nieuwe data op. Bij conflict onderzoek je bronhouder, eventtijd, statusvolgorde en eventuele handmatige correctie. De klanttekst moet niet doen alsof je de oorzaak al kent.

Je stuurt live GPS naar de klant

Een klant heeft meestal een aankomstvenster nodig, geen exacte positie van een voertuig of bestuurder. Beperk de publieke data tot status, ETA en een door jou beheerde contactroute. Houd de ruwe telematica in de operationele omgeving en leg de privacy- en toegangsregels vooraf vast.

Je vertrouwt op de retry van de leverancier

Samsara stopt na vijf pogingen wanneer je geen 2xx teruggeeft. Dat is een aflevermechanisme, geen herstelstrategie. Bouw een eigen backfill of periodieke reconciliatie, zodat een korte storing niet tot een onzichtbaar gat in je statuslijn leidt.

Je laat n8n of Make het dossier zijn

Een uitvoeringslog is handig om een workflow te debuggen. Hij is geen statusregister met retentie, eigenaarschap, bronversie, klantmelding en sluitbewijs. Bewaar de zakelijke tijdlijn in een eigen datalaag en gebruik de workflowtool als orkestratie.

Beslis-kader: welke route past bij jouw statusflow?

Kies kant-en-klaar wanneer één TMS de order, stop, subcontractor, ETA en klantportal al bijeenhoudt en je uitzonderingen door mensen laat behandelen. Kies een workflowlaag wanneer de bronnen API’s hebben, de statuslogica beperkt blijft en je zelf een duurzame queue kunt beheren. Kies maatwerk wanneer meerdere bronnen eigenaar zijn van verschillende delen van de belofte, events tegenstrijdig kunnen zijn en de klantmelding bedrijfskritisch is.

Kant-en-klaar TMS

Qargo is een concreet voorbeeld. De actuele prijspagina noemt geen prijs per gebruiker, maar een licentie die wordt afgestemd op transportomzet. Gebruikers, functies, een sandbox, onboarding en support zijn volgens de pagina inbegrepen; de productopsomming noemt ook een subcontractor portal, customer portal, mobile driver app en meer dan 100 standaardintegraties. De externe status-webhook kan stopstatus, ETA en data van een subcontractor ontvangen.

Dit past als je proces dicht bij het TMS-model blijft. Het breekpunt komt wanneer een klantbelofte uit Samsara, een subcontractor-feed, een eigen orderbron en een apart sms-kanaal tegelijk moeten worden vergeleken. Dan is een eigen statuslaag nuttiger dan nog een instelling in het TMS.

Workflowlaag met n8n of Make

n8n Cloud rekent volgens de actuele prijspagina per workflowuitvoering, ongeacht de complexiteit. Starter kost €20 per maand bij jaarlijkse betaling voor 2.500 uitvoeringen met onbeperkte stappen. Pro kost €50 voor 10.000 uitvoeringen. Dat is aantrekkelijk voor webhook, normalisatie, opslag en queue-orkestratie, maar de bronversies, statusmachine en read-back moet je zelf ontwerpen.

Make rekent sinds 27 augustus met credits als eenheid. Iedere moduleactie, zoals lezen, zoeken, maken, bijwerken of transformeren, kan credits kosten. Het gratis plan bevat 1.000 credits per maand. Een statusflow met twee bronlezingen, een match, een queue-write en een sms-actie kan dus veel meer verbruiken dan één inkomende webhook doet vermoeden. De prijs is niet de enige grens. De zichtbaarheid van de foutpaden is minstens zo belangrijk.

Maatwerkstatusservice

Maatwerk past wanneer je meerdere TMS’en, Samsara, Qargo of andere subcontractors, eigen klantafspraken en verschillende escalatierollen moet verenigen. Bouw dan een kleine statusservice met een append-only event store, een normalisatielaag, een state machine, een ETA-service, een publicatielaag en een herstelqueue. n8n of Make kan de adapters en meldingen aanroepen, maar de beslissingen blijven in een model dat je kunt testen.

Een maatwerkflow is overkill als één TMS de hele keten al beheert en je per dag maar enkele afwijkingen hebt. Koop eerst de discipline die je nodig hebt. Bouw pas wanneer de uitzonderingen structureel duurder zijn dan het beheer van een eigen statuslaag.

De keuzehulp geeft dezelfde uitkomsten als het geschreven kader. Hij vervangt de beoordeling van bronhouderschap, freshness en eigenaarschap niet.

Uitgewerkt voorbeeld: Noordland, Samsara en een subcontractor

Onderstaand is een fictief implementatievoorbeeld met echte productnamen en illustratieve IDs. Het is geen klantcasus. De getallen laten zien hoe je regels toepast.

Noordland Distributie heeft acht eigen vrachtwagens en werkt voor regionale ritten met twee vaste onderaannemers. Order ORD-88421 bevat drie stops. Stop S03 heeft een afgesproken venster van 10.30 tot 11.00 uur. De rit krijgt RIT-2026-1021-0084. De eigen truck gebruikt Samsara; de subcontractor meldt zijn stop vanuit Qargo.

De normale route

Om 08.05 uur ontvangt Noordland een Samsara RouteStopEtaUpdated-event voor route-externe ID RIT-2026-1021-0084. De ETA voor S03 is 10.42 uur. De eventtijd is 2026-10-21T08:05:00+02:00 en de ontvangsttijd 08.05.004. De match lukt op route-externe ID en stop-externe ID. De bron is jong, de ETA valt binnen het afgesproken venster en de publicatieregel verandert de klantbelofte niet. Er gaat dus geen sms uit.

Om 08.38 uur komt een nieuwe ETA van 11.18 uur. De stop dreigt buiten het venster te vallen. De statusservice leest de route opnieuw uit, bevestigt ETA 11.18, maakt publicatieversie eta-v2 en zet één klantmelding klaar. De tekst is: Je levering staat later gepland. Nieuwe verwachte aankomst: 11.18 uur. Je krijgt een nieuwe update zodra de chauffeur bij de stop is. De melding bevat geen ruwe GPS-positie.

Twilio behandelt sms per segment. De statusservice bewaart de bericht-ID en wacht op de afleverstatus. Een time-out na het verzenden leidt tot een read-back op customer-update:RIT-2026-1021-0084-S03:delayed:eta-v2, niet tot een tweede bericht.

Een stale event

Om 09.25 uur komt nog een Samsara-event binnen met event_time 08.38 uur en ETA 11.18 uur. De event-ID is nieuw, maar de broninhoud is ouder dan de laatst verwerkte bronversie. De service bewaart hem als late_event, laat de actuele status op delayed staan en leest Samsara opnieuw. De nieuwe read-back geeft ETA 11.24 uur. Omdat de klant al 11.18 uur heeft ontvangen en 11.24 geen nieuwe publicatiedrempel overschrijdt, blijft de eerdere melding staan.

Een subcontractor-conflict

Voor stop S02 meldt de subcontractor om 09.40 uur via Qargo AT_STOP met event_time 09.40 en eta_end 09.45. De eigen TMS-status staat nog op en_route en de laatste ETA was 10.05. De match op de Qargo-stop-ID lukt, maar de twee bronnen verschillen in toestand. De statusservice maakt geen klantmelding. Hij zet eta_conflict in de queue met de twee event-ID’s, de bronhouders en de laatste klantmelding.

De planner controleert het TMS en belt de subcontractor. De chauffeur staat inderdaad aan de losplaats, maar de Qargo-update had de verkeerde stopreferentie gebruikt. De planner markeert het event als misrouted, corrigeert S02 met actor en reden en laat de service de bron opnieuw lezen. S03 blijft ongewijzigd. Geen klant heeft een foutieve aankomsttijd gekregen.

Een ontbrekende bron

Om 10.15 uur heeft S03 nog steeds geen nieuw event. De policy zegt dat een ETA ouder dan 45 minuten stale is. De queue wijst de taak toe aan de planner met deadline 10.20 uur. De planner ziet de laatste betrouwbare ETA, 11.24 uur, maar mag die niet als actuele zekerheid tonen. Hij vraagt de chauffeur om een status en vindt in Samsara een korte netwerkonderbreking.

De planner bevestigt handmatig vertraging, nieuwe ETA volgt en laat de klantmelding uitgaan met de nieuwe eigenaar en het volgende update-moment. Wanneer Samsara om 10.21 uur weer een geldige ETA 11.31 uur levert, wordt de handmatige melding vervangen door de feitelijke ETA-update. Beide besluiten blijven in de tijdlijn staan.

Wat je aan het einde kunt aantonen

Bij één rit kun je terugvinden: de oorspronkelijke route, ieder bron-event, de match op stop, de bronversie, de ETA-read-back, de publicatieversie, de afleversstatus van het bericht, de stale-regel, de queue-eigenaar en de handmatige correctie. Dat is het verschil tussen een dashboard dat groen kleurt en een klantbelofte die je kunt uitleggen.

Vergelijkingstabel: kant-en-klaar, workflowlaag of maatwerk

De productdetails en prijzen in deze tabel zijn gecontroleerd op 21 oktober 2026. Sms-tarieven kunnen wijzigen en carrierkosten komen bovenop de genoemde Twilio-prijs. Qargo werkt met een gepersonaliseerde prijs op basis van transportomzet.

Voor de meeste transportbedrijven is een TMS met goede bron-ID’s en een menselijke herstelqueue de beste start. Voeg n8n of Make toe wanneer je enkele API’s moet verbinden en de queue klein blijft. Bouw een eigen statusservice wanneer de klantbelofte niet uit één bron komt en een foutieve ETA duurder is dan het onderhoud van een controlelaag.

Een goede statusflow probeert niet elke afwijking automatisch weg te werken. Hij maakt zichtbaar welke bron sprak, hoe vers die bron was, waarom de ETA geldig leek, wanneer de klant is bijgepraat en wie ingreep toen de data niet meer klopte. Zodra je dat kunt aantonen, is een stale event geen verborgen storing meer maar een beheersbare taak.