AI-agent voor logistieke uitzonderingen: van carrier-event naar claim en vervangzending

Je klant zegt dat het pakket niet is aangekomen, terwijl de vervoerder al ‘geleverd’ meldt. Of de doos komt aan met een scheur, maar de foto van de schade staat in een losse mail en de claimtermijn loopt al. Als je zulke uitzonderingen alleen doorzet naar een inbox, verlies je tijd én bewijs.

Deze gids is voor webshops en logistieke teams die zendingen met PostNL, DHL, UPS of een tussenlaag zoals Sendcloud willen afhandelen met een AI-agent. De agent leest carrier-events, vergelijkt ze met je leverbelofte, maakt een bewijsdossier en zet claim, vervangzending, terugbetaling of herplanning klaar. Een mens geeft de actie vrij.

Een logistieke uitzonderingsagent is software die een carrier-event aan een zending en leverbelofte koppelt, het event normaliseert, bewijs verzamelt en een volgende actie voorstelt. De agent mag classificeren en voorbereiden. Een claim, vervangzending, terugbetaling, adreswijziging of klantbericht wordt pas uitgevoerd na een controleerbare menselijke vrijgave.

De productdetails, prijzen en documentatie in deze gids zijn gecontroleerd op 11 oktober 2026. De actuele Sendcloud API-wijzigingen waar ik naar verwijs zijn gepubliceerd op 25 september en 9 oktober 2026. Shopify toont in de actuele documentatie API-versie 2026-10.

Wat je nodig hebt voordat je events automatiseert

Begin met de uitzonderingen die vandaag al geld kosten. Kies bijvoorbeeld vermiste zendingen, schade bij bezorging en een bezorgscan die de klant tegenspreekt. Laat vertragingen zonder klantimpact eerst alleen signaleren. Zo test je de keten zonder meteen iedere normale status door een taalmodel te sturen.

1. Eén zendingrecord als anker

De agent moet altijd kunnen terugvallen op één zendingrecord. Leg minimaal vast:

• order_id en order_line_ids uit Shopify, WooCommerce of je OMS;
• shipment_id, parcel_id, carrier en tracking_number;
• het verkoopkanaal, de klant en het afleveradres zoals dat bij verzending gold;
• de beloofde leverdatum en het type belofte, bijvoorbeeld ‘dinsdag 13 oktober’ of ‘vandaag besteld, morgen in huis’;
• de bronversie, event-ID, eventtijd, ontvangsttijd en hash van het ruwe event;
• de genormaliseerde fase, uitzonderingscode en huidige dossierstatus;
• POD-verwijzing, foto’s, klantmelding, orderwaarde, kostprijs en eventuele verzekerde waarde;
• claimdeadline, vervaltijd van het voorstel, eigenaar en goedkeurder.

Een ordernummer is niet hetzelfde als een pakketnummer. Bij een bestelling met drie colli kan één order drie verschillende claims en drie verschillende POD’s krijgen. Gebruik de zending en het pakket als aparte objecten, met een relatie naar de order.

Dezelfde sleuteldiscipline zie je bij een rit-ID die order, POD, tachograafbestanden en factuur aan één dossier koppelt. Voor pakketuitzonderingen vervang je de rit- en stopvelden door shipment- en parcel-ID’s, maar het principe blijft gelijk: bronbestanden blijven intact en de afwijking krijgt een eigen status.

2. Een bron voor events en een bron voor de leverbelofte

Je kunt rechtstreeks op de carrier-API aansluiten. Voor een webshop met meerdere vervoerders is Sendcloud vaak de praktische normalisatielaag. Sendcloud documenteert verbinding met meer dan 160 vervoerders en meer dan 100 koppelingen met webshops, WMS-systemen en marktplaatsen op zijn actuele API-portaal.

Sendcloud kan trackingwijzigingen naar je endpoint pushen. De helpdocumentatie beschrijft het webhooktype ‘Parcel Status Changed’, dat wordt verstuurd wanneer de pakketstatus verandert. Je richt dit in via Settings, Integrations, Configure, Webhook feedback enabled, waarna je de URL test en opslaat. De actuele Sendcloud-instructies beschrijven die webhookroute en het vereiste POST-endpoint.

De leverbelofte haal je niet uit de laatste trackingtekst. Die komt uit je order- of ATP-laag. De voorraadberekening per SKU, locatie, kanaal en datum maakt duidelijk welke voorraad werkelijk beloofd kon worden, met bronversie en vervaltijd. In deze gids gebruik je die belofte als referentiepunt: wanneer was de zending te laat, en wanneer is de klantactie al noodzakelijk?

3. Een bewijsdossier met deadlines

Maak voor iedere uitzondering een dossier dat een medewerker in één scherm kan beoordelen. Bewaar het ruwe event naast de vertaling. De agent mag een gebeurtenis samenvatten, maar nooit de oorspronkelijke carrierdata vervangen.

Voor een claimdossier heb je meestal nodig:

• het trackingnummer en de volledige relevante tijdlijn;
• label, verzenddatum, service, colli-aantal, gewicht en afmetingen;
• order- of verkoopfactuur met productwaarde en valuta;
• POD, handtekening, afleverfoto, GPS- of huisnummerinformatie als de carrier die levert;
• foto’s van doos, label, verpakking en beschadigde inhoud;
• de melding van de klant, inclusief datum en letterlijke omschrijving;
• verzekerde waarde of gekozen aanvullende aansprakelijkheid;
• claimkanaal, uiterste meldmoment en status van de claim.

De termijnen verschillen per dienst. PostNL meldt voor zakelijke schadeclaims dat je schade binnen zeven dagen na bezorging moet melden, met uitzondering van zon- en feestdagen, en vraagt een factuur plus foto’s van doos en label. Onverzekerde pakketten komen volgens dezelfde pagina niet voor schadevergoeding in aanmerking. PostNL beschrijft de termijn en vereiste bewijsstukken op de zakelijke schadepagina.

Voor een zakelijke PostNL-zending die niet is bezorgd, noemt PostNL eerst twee bezorgdagen als controlepunt. Daarna kun je in Mijn PostNL Zakelijk een case aanmaken en een factuur van de inhoud meesturen. Bij een internationale zending met de status ‘geleverd’ maar zonder ontvangst adviseert PostNL contact op te nemen, in ieder geval binnen dertig dagen. Dat zijn carrierregels, geen algemene claimwet. Sla de regel per carrier en dienst op.

DHL Express vraagt volgens de Nederlandse FAQ om een vermissing of schade schriftelijk binnen dertig dagen vanaf acceptatie van de zending te melden. UPS vraagt voor een claim in ieder geval het trackingnummer en een factuur die de waarde aantoont; bij schade moeten de inhoud en verpakking worden bewaard. UPS noemt een gebruikelijke oplossingstermijn van acht tot vijftien werkdagen als extra onderzoek niet nodig is. De Nederlandse UPS-claimroute noemt deze bewijsstukken en behandeltermijn.

4. Een proces met beperkte rechten

Je hebt een intake nodig, een staginglaag en een aparte vrijgave-uitvoerder. Dat kan met PostgreSQL of Supabase als dossierlaag, Sendcloud als verzendlaag, Shopify als orderbron en n8n of Make voor de meldingen en API-aanroepen. De formele goedkeuring hoort niet alleen in een Slack-bericht of in de uitvoeringshistorie van je workflowtool te staan.

Geef de agent deze acties:

• read_shipment: lees order, pakket, klantbelofte en carrierdata;
• normalize_event: zet een ruwe gebeurtenis om naar een vast schema;
• collect_evidence: haal POD, factuur, foto’s en klantmelding op;
• stage_decision: maak een voorstel met reden, bewijs en payload;
• request_approval: vraag een bevoegde medewerker om vrijgave.

Maak geen brede tool met refund_any_order of change_delivery_address. De uitvoerder moet zelf controleren welke order, bedrag, adres en actie in de goedgekeurde payload staan.

5. Mensen met een duidelijke rol

Wijs minimaal een eigenaar van de uitzonderingsqueue en een goedkeurder aan. De eerste verzamelt ontbrekende informatie. De tweede beslist over geld, voorraad, klantbelofte en carrieractie. Bij een klein team mogen die rollen tijdelijk bij één persoon liggen, maar de technische status en audittrail moeten nog steeds gescheiden blijven.

Meet vanaf het begin:

• aantal uitzonderingen per 1.000 pakketten;
• tijd van eerste carrier-event tot menselijke beslissing;
• percentage dossiers met compleet bewijs;
• claimherstel als bedrag en als percentage;
• tijd tot vervangzending of terugbetaling;
• dubbele writes, verlopen voorstellen en handmatig teruggedraaide acties.

Zonder deze basis bouw je geen uitzonderingsafhandeling. Je bouwt een nette samenvatting bovenop ontbrekende gegevens.

Concrete stappen: van carrier-event naar vrijgegeven oplossing

De veilige route heeft acht controlepunten. Een agent mag snel werken, maar iedere overgang blijft controleerbaar. De belangrijkste regel is eenvoudig: een event is een signaal, geen beslissing.

1. Ontvang, verifieer en dedupliceer het event

Laat je webhook-endpoint het event snel ontvangen en in een wachtrij zetten. Controleer providerhandtekening als de bron die meestuurt, valideer JSON en geef alleen bij succesvolle opslag een 2xx-antwoord. De Sendcloud-helptekst noemt POST, 2xx-antwoorden, correcte payloadvalidatie, signature verification waar van toepassing, retries en throttling als belangrijke foutpaden.

Gebruik event_id als eerste sleutel. Ontbreekt die, maak dan een deterministische sleutel uit carrier, trackingnummer, eventtijd, status en een hash van de payload. Een event dat drie keer wordt afgeleverd mag drie logregels opleveren, maar slechts één dossierovergang.

Bewaar bijvoorbeeld:

{
  "event_id": "sc-event-88421",
  "event_type": "carrier",
  "carrier": "postnl",
  "tracking_number": "3S-TEST-10482",
  "occurred_at": "2026-10-11T08:16:22Z",
  "received_at": "2026-10-11T08:16:25Z",
  "raw_payload_sha256": "sha256:...",
  "processing_status": "received"
}

Vertrouw niet op aankomstvolgorde. Een vertraagde webhook kan na een nieuwere scan binnenkomen. Sorteer op de eventtijd van de carrier, bewaar ontvangsttijd apart en laat een latere gebeurtenis een eerdere status niet overschrijven zonder reden.

2. Normaliseer de carrierstatus naar jouw eigen schema

Gebruik geen vrije tekst als interne beslislogica. Sendcloud documenteert voor tracking-events onder meer phase, exception, sub_status, description en status_type. In de changelog van 25 september 2026 werden oude statuscodevelden verwijderd en kwamen deze velden ervoor terug. Dezelfde wijziging onderscheidt success, warning en error als statuswaarden. De Sendcloud API-v3-changelog beschrijft de actuele trackingvelden en de verwijderde statuscodevelden.

Maak daar een beperkt intern contract van:

De status delivered is dus niet automatisch resolved. Een pakket kan volgens de carrier afgeleverd zijn en toch een misleveringsdossier openen. Een damaged-event bewijst ook niet vanzelf de waarde van de inhoud of de oorzaak. Normaliseren maakt de volgende vraag zichtbaar. Het beantwoordt die vraag niet alleen.

Let op recente API-wijzigingen. Sendcloud maakt sinds de wijziging van 9 oktober 2026 in parcels.event.created onderscheid tussen tracking-events met event_type=carrier of calculated en claim-events met event_type=claim. Een claim-event kan onder meer category, ticket_id, attachment_type, refund_price_eur en resolution bevatten. Zet zo’n claim-update in een aparte claimtijdlijn. Verwerk hem niet alsof het een nieuwe carrier-scan is.

3. Vergelijk event, leverbelofte en orderstatus

Haal de belofte op die gold toen de order werd aangenomen. Gebruik niet de huidige productpagina, want die kan intussen een andere voorraad of levertijd tonen. Vergelijk minstens:

1. beloofde datum en tijdvenster;
2. geplande en werkelijke overdracht aan de carrier;
3. laatste geldige carrier-event;
4. actuele verwachte bezorgdatum;
5. orderstatus, betaalstatus en eventuele annulering;
6. klantmelding en het moment waarop die binnenkwam.

Een vertraging is pas een klantuitzondering als de actuele verwachting de afgesproken belofte raakt of overschrijdt. Een pakket dat op vrijdag een delivery_delay krijgt maar nog vóór de beloofde maandag aankomt, hoeft geen refundvoorstel te krijgen. Een pakket dat op maandag 16:00 nog geen bezorgscan heeft terwijl de klant een ochtendvenster beloofd is, gaat wel naar de queue.

Bewaar de vergelijking als reden, niet alleen als kleur:

{
  "promise": {"date": "2026-10-11", "window": "08:00-18:00"},
  "carrier_estimate": {"date": "2026-10-13", "confidence": "low"},
  "decision_reason": "promise_breached",
  "checked_at": "2026-10-11T16:00:00+02:00"
}

4. Classificeer de echte uitzondering

Laat de agent maximaal één hoofdcategorie kiezen en eventueel één subcode. Zet twijfel naar needs_review. De vier meest voorkomende branches zijn:

Vermissing. Er is geen bruikbare scan na overdracht, de verwachte bezorgdatum is verstreken of de carrier meldt onderzoek. Een enkele vertraging is geen vermissing. Laat de agent de tijd sinds de laatste fysieke scan vergelijken met het carrierbeleid en de beloofde datum.

Schade. De carrier meldt schade of de klant meldt zichtbare of functionele schade met foto’s. Bewaar doos, label en inhoud. Vraag geen automatische vernietiging of retour aan voordat de claimroute duidelijk is.

Mislevering. De tracking zegt geleverd, maar de klant ontkent ontvangst. Vergelijk afleveradres, huisnummer of POD, eventuele handtekening, afleverfoto en klantverklaring. Houd dit apart van vermissing, want je onderzoekt een afleverhandeling die volgens de carrier al heeft plaatsgevonden.

Inhoud ontbreekt. De doos is ontvangen, maar één of meer artikelen ontbreken. Dat is een andere bewijsset dan een volledig verloren pakket. Koppel de pakbon, orderregels, colli-informatie en foto’s van de verpakking.

Laat de agent nooit op basis van sentiment in de klantmail besluiten dat een zending gestolen is. ‘Ik heb niets gekregen’ is een klantverklaring. Het is belangrijk bewijs, maar nog geen carrierfeit.

5. Bouw het bewijsdossier vóór je een claim indient

Maak een claimvoorstel met een vaste volgorde. Dat voorkomt dat een model een mooie samenvatting maakt waarin de factuur of foto ontbreekt:

1. Identiteit: order, zending, pakket, trackingnummer en carrier.
2. Gebeurtenis: raw event, genormaliseerde code, tijdlijn en laatste scan.
3. Waarde: verkoopfactuur, inkoopfactuur, kostprijs, valuta en verzekerde waarde.
4. Fysiek bewijs: POD, foto’s van doos, label en inhoud, gewicht en afmetingen.
5. Klantbewijs: datum, kanaal, verklaring en eventueel gewenste oplossing.
6. Termijn: carrierdienst, claimdeadline, resterende uren en claimkanaal.
7. Actie: claim, vervanging, refund of herplanning, elk met eigen goedkeuringsstatus.

Bereken claim_deadline_at één keer uit carrier, dienst en gebeurtenis. Toon ook de bron van de regel. Bij PostNL is ‘zeven dagen na bezorging’ iets anders dan ‘twee bezorgdagen na de verwachte levering’ voor een niet-bezorgde zending. Een agent die alleen een veld deadline=7d kent, maakt vroeg of laat de verkeerde claim.

6. Scheid klantactie van carrierherstel

De klant mag niet hoeven wachten op jouw claimonderzoek. Voor consumenten is de webwinkel in Nederland verantwoordelijk tot de consument het product ontvangt. De ACM noemt alleen uitzonderingen zoals een door de consument gekozen andere vervoerder of vooraf toegestane bezorging bij de buren. De ACM legt uit waar de verantwoordelijkheid voor verlies en beschadiging ligt. Europese consumentenregels leggen dezelfde hoofdlijn vast: de verkoper draagt het risico tot ontvangst; bij schade of een ondeugdelijk product kan de consument herstel, vervanging, prijsvermindering of terugbetaling vragen. Your Europe beschrijft die herstel- en terugbetalingsrechten.

Maak daarom twee parallelle voorstellen:

• customer_resolution: vervangzending, refund, herplanning, retour of aanvullende informatie;
• carrier_recovery: claim, onderzoek, bewijs aanvullen of niets doen.

De claim is jouw herstel bij de carrier. Hij is geen voorwaarde om de klant netjes te helpen. Voor B2B-klanten kunnen overeenkomst, aansprakelijkheidsbedingen en Incoterms de verdeling veranderen. Laat de agent zulke contractafwijkingen signaleren en zet de beslissing bij operations of legal.

7. Laat een mens de exacte payload vrijgeven

Een goedkeuringsscherm toont niet alleen ‘schade vermoed’. Het toont:

• de originele carriergebeurtenis en de vertaalde categorie;
• de order, trackinglijn en leverbelofte;
• de foto’s, factuur, POD en ontbrekende stukken;
• de carriertermijn en resterende tijd;
• het voorgestelde klantresultaat;
• het voorgestelde carrierresultaat;
• de exacte refundwaarde of vervangende orderregel;
• de payloadhash, snapshotversie en vervaltijd.

Laat de goedkeurder kiezen uit vaste acties: approve_replace, approve_refund, approve_reschedule, approve_claim_only, request_evidence of reject. Een vrije tekstknop ‘akkoord’ is te mager voor een financiële of logistieke write.

Na goedkeuring herlees je de order, voorraad en klantstatus. Controleer dat het voorstel niet is verlopen, dat de productvoorraad nog beschikbaar is en dat niemand de order intussen heeft terugbetaald. Schrijf de vervangzending met een eigen idempotentiesleutel, bijvoorbeeld replacement:{order_id}:{original_parcel_id}. Bij een time-out zoek je eerst op die sleutel. Je maakt geen tweede label omdat de eerste API-call misschien wel is aangekomen.

8. Sluit het dossier met read-back en meting

Lees na iedere actie het doel terug. Controleer bij een vervangzending het nieuwe order- en trackingnummer. Controleer bij een refund het werkelijk terugbetaalde bedrag en de betaalstatus. Controleer bij een claim het claim-ID, de ontvangen bijlagen en de deadline. Werk daarna klantcommunicatie en queue-status bij.

Gebruik statussen als new, evidence_needed, ready_for_review, approved, executing, awaiting_carrier, customer_resolved, reconciled en rejected. Een carrierclaim die is ingediend is nog geen herstelde omzet. Een klantbericht dat is verstuurd is nog geen bewijs dat de refund is gelukt.

De omvang zit dus niet in het lezen van één trackingregel. Ze zit in de verbinding tussen belofte, bewijs, aansprakelijkheid, voorraad, carrierherstel en een veilige write.

Valkuilen: waar een uitzonderingsagent stukloopt

Een generiek ‘exception’-label wordt de hele queue.

Waarom het misgaat: de medewerker ziet geen verschil tussen een vertraagde scan, een verdwenen pakket en een claim waarin nog een factuur ontbreekt.

Mitigatie: gebruik vaste hoofd- en subcodes, een eigenaar, een deadline en één concrete vervolgstap per item. delivery_delay, lost_suspected, damaged, misdelivered, contents_missing en evidence_missing zijn nuttiger dan confidence_low.

De laatste status overschrijft de tijdlijn.

Waarom het misgaat: events kunnen dubbel of buiten volgorde binnenkomen. Een late in_transit-scan maakt een eerdere delivered-scan dan onterecht ongedaan.

Mitigatie: bewaar alle events append-only, sorteer op carrier-eventtijd en laat statusovergangen door een expliciete state machine controleren.

POD wordt als bewijs van ontvangst behandeld zonder de inhoud te controleren.

Waarom het misgaat: een handtekening bewijst niet automatisch dat alle colli of alle artikelen zijn ontvangen. Een afleverfoto kan bij het verkeerde huisnummer horen.

Mitigatie: vergelijk POD met pakketnummer, adres, colli-aantal, pakbon en klantverklaring. Maak ‘afgeleverd maar betwist’ een eigen categorie.

De agent mist de claimdeadline.

Waarom het misgaat: deadlines staan in carriercontracten en verschillen per dienst, land en gebeurtenis.

Mitigatie: maak carrier, service, startmoment, deadlinebron en resterende tijd verplichte velden. Stuur een escalatie voordat de deadline verstrijkt.

Claim en klantoplossing worden één transactie.

Waarom het misgaat: de webshop wacht op de vervoerder, terwijl de klant al recht heeft op een passende oplossing of de vervangende voorraad intussen verdwijnt.

Mitigatie: maak customer_resolution en carrier_recovery apart. De klantactie krijgt een eigen goedkeuring en eigen read-back.

De agent stuurt het nieuwe pakket naar het oude, foutieve adres.

Waarom het misgaat: een adrescorrectie lijkt een klein tekstveld, maar verandert risico en leverbaarheid.

Mitigatie: laat een adreswijziging nooit uit de vrije klantmail komen. Vraag bevestiging, toon oud en nieuw adres en gebruik een aparte goedkeuringsactie.

Een time-out maakt een dubbele vervangzending.

Waarom het misgaat: de uitvoerder weet niet of de eerste call is gelukt en probeert opnieuw.

Mitigatie: sla vóór de write een idempotentiesleutel en payloadhash op. Zoek na een onbekende uitkomst eerst naar het bestaande order-, label- of refund-ID.

De workflowtool is het dossier.

Waarom het misgaat: een n8n- of Make-uitvoeringslog is geen duurzame claimadministratie. Retentie, zoekbaarheid, rechten en bijlagen zijn vaak niet afgestemd op je operationele proces.

Mitigatie: bewaar dossier, eventtijdlijn, bewijs en beslissingen in een eigen datalaag. Gebruik n8n of Make voor orkestratie, niet als enige bron van waarheid.

De agent maakt een claim op basis van een onbewezen oorzaak.

Waarom het misgaat: ‘verpakking beschadigd’ is niet hetzelfde als ‘carrier aansprakelijk’. Verpakking, gekozen service, verzekering, inhoudswaarde en contract kunnen de uitkomst veranderen.

Mitigatie: laat de agent feiten verzamelen en de claimroute kiezen. Laat een mens de aansprakelijkheidsclaim vrijgeven wanneer bewijs of contract niet eenduidig is.

Beslis-kader: wanneer koop je dit, wanneer bouw je het?

De beste start is meestal niet een autonome agent. Voor een eenvoudige flow met één carrier, één webshop en weinig beslisvarianten volstaat een verzendplatform met vaste regels en een helpdesk. De agentlaag verdient zich pas terug wanneer medewerkers veel tijd verliezen aan het lezen, vergelijken en samenstellen van dossiers.

Gebruik deze vijf criteria:

1. Aantal vervoerders. Eén carrier met een duidelijk portaal is eenvoudig. Meerdere carriers vragen een eigen statuscontract en deadline-adapter.
2. Aantal uitzonderingssoorten. Alleen vertraging is een regel. Vermissing, schade, mislevering, ontbrekende inhoud en retouren vormen samen een beslisproces.
3. Aantal writes. Alleen een melding naar een queue is laag risico. Claims, vervangorders, refunds en adreswijzigingen vragen staging, idempotentie en read-back.
4. Bewijscomplexiteit. Een trackingnummer is eenvoudig. POD, foto’s, facturen, verzekerde waarde, contractregels en klantverklaringen vragen een dossierlaag.
5. Beheerverantwoordelijkheid. Als niemand de queue en regels kan onderhouden, is maatwerk te vroeg. Als de uitzonderingsstroom bedrijfskritisch is, is een losse no-code flow te kwetsbaar.

Kant-en-klaar

Kies Sendcloud en je bestaande helpdesk wanneer je vooral tracking, meldingen, returns en een beperkte queue nodig hebt. De actuele Sendcloud-prijspagina toont een gratis plan tot 20 pakketten per maand. Het maandplan Lite staat op €28 per maand plus €0,10 per label, met drie gebruikers, drie integraties en maximaal 4.800 labels per jaar. Growth staat op €87 plus €0,09 per label en voegt onder meer vijf gebruikers, vijf integraties en een merkgebonden trackingpagina toe.

Dit is een goede start als de menselijke behandeling in het Sendcloud- of helpdeskproces mag blijven. Het wordt krap zodra je ATP-belofte, meerdere voorraadbronnen, claimbewijs en gecontroleerde writes in één besluit wilt tonen.

Workflowlaag met n8n of Make

Kies n8n wanneer je een eigen staginglaag, API-logica en een controleerbare queue wilt combineren met visuele workflows. De actuele n8n-prijspagina toont Cloud Starter voor €20 per maand bij jaarlijkse betaling met 2.500 workflowuitvoeringen en onbeperkte stappen. Pro staat op €50 per maand bij jaarlijkse betaling met 10.000 uitvoeringen. n8n rekent per volledige workflowuitvoering, niet per losse stap. De actuele n8n-prijspagina noemt deze bedragen, limieten en het uitvoeringsmodel.

Make past wanneer je vooral veel standaardkoppelingen en een visuele scenario-editor nodig hebt. De prijspagina toont Free met 1.000 credits per maand, Core voor $12 per maand bij 10.000 credits, Pro voor $21 en Teams voor $38. Elke moduleactie telt als credit; een event dat door veel zoek-, schrijf- en lusmodules gaat, verbruikt dus meer dan één credit. Make beschrijft de creditberekening en de actuele planprijzen.

In beide gevallen blijft de formele beslissing buiten de agentprompt staan. Staging, deadline, payloadhash en bevoegdheid horen in je eigen datamodel.

Maatwerkagent

Kies maatwerk wanneer meerdere vervoerders verschillende event- en claimregels hebben, je meerdere verkoopkanalen bedient, vervangorders direct voorraad reserveren, of claims en refunds in Exact Online, Shopify, een OMS en je helpdesk moeten worden afgestemd. Dan bouw je adapters voor carrier-events, één intern uitzonderingsmodel, een bewijsdossier, een vrijgave-interface en gecontroleerde uitvoerders.

Maatwerk is niet automatisch de beste keuze. Als de medewerker toch ieder dossier volledig handmatig beoordeelt en één carrier de enige bron is, koop je vooral onderhoud. Laat de complexiteit van je uitzonderingen de keuze maken, niet de wens om een agent op de homepage te zetten.

De keuzehulp is geen vervanging voor het kader. Hij geeft alleen de snelle route. Bij iedere uitkomst moet je nog steeds de eigenaar, deadlines, bewijs en herstelactie concreet maken.

Uitgewerkt voorbeeld: beschadigde PostNL-zending met vervanging en claim

Onderstaand is een fictief rekenvoorbeeld met echte productnamen en illustratieve ordergegevens. Het is geen klantcasus. De bedragen laten zien welke waarden de agent moet tonen, niet wat een vervoerder automatisch vergoedt.

Een webshop verkoopt woonverlichting via Shopify. Sendcloud maakt de labels en ontvangt carrier-events. De workflow draait in n8n. De webshop gebruikt PostNL met Verzekerservice voor een pakket met een inhoudswaarde onder de verzekerde grens. De order is #10482, bevat één lamp met SKU LAMP-42, verkoopprijs €249,00 en kostprijs €132,50. De beloofde levering was 9 oktober 2026.

Wat er gebeurt

Op 8 oktober maakt Sendcloud het label aan. Op 9 oktober om 08:12 komt een event_type=carrier binnen met phase=out_for_delivery. Om 14:37 volgt phase=delivered met status_type=success. Die gebeurtenis sluit de zaak nog niet, want het dossier wacht op de combinatie van orderstatus en bewijs.

Om 16:05 meldt de klant via de helpdesk dat de doos nat en ingedeukt is aangekomen. De klant uploadt drie foto’s: label, buitenkant en inhoud. Op 10 oktober zet de medewerker de schadefoto’s in het dossier. De agent leest de klantmelding, koppelt het trackingnummer en herkent dat de claimtermijn voor PostNL schade vanaf de bezorging loopt.

De agent maakt dit voorstel:

{
  "order_id": "#10482",
  "parcel_id": "SC-88421",
  "carrier": "PostNL",
  "classification": "damaged",
  "promise_status": "fulfilled_with_damage",
  "customer_resolution": "replace",
  "carrier_recovery": "claim",
  "claim_deadline_at": "2026-10-16T23:59:59+02:00",
  "evidence": [
    "PostNL delivered event 2026-10-09T14:37:00+02:00",
    "customer photos: label, box, contents",
    "sales invoice: €249,00",
    "insurance option: Verzekerservice"
  ],
  "proposed_refund": null,
  "replacement_sku": "LAMP-42",
  "payload_hash": "sha256:...",
  "status": "ready_for_review"
}

De stagingregel toont ook de actuele ATP-snapshot. Er zijn op 10 oktober vier verkoopbare lampen beschikbaar. De agent mag dat gegeven tonen, maar mag de vervangzending niet uitvoeren op basis van de snapshot van gisteren.

De menselijke beslissing

De operationsmedewerker controleert de drie foto’s, de factuur, de verzendservice en de voorraad. De klant is een consument. Dat betekent niet dat de agent automatisch een vervangzending kiest: de medewerker bepaalt op basis van de concrete schade, het bewijs, de voorraad en de klantbelofte welke remedie passend is. In deze casus kiest de medewerker voor een vervangzending; daarvoor hoeft de claimuitkomst niet te worden afgewacht. De medewerker geeft twee acties vrij:

• approve_replace: één nieuwe orderregel voor LAMP-42, naar het bevestigde oorspronkelijke adres;
• approve_claim_only: een PostNL-case met factuur en foto’s van doos en label.

De refund blijft null. Er wordt geen tweede volledige order gemaakt, maar een vervangzending die via de idempotentiesleutel aan #10482 en SC-88421 hangt. n8n roept de eigen order- en verzendadapter aan. De adapter controleert opnieuw voorraad en adres, maakt de vervangzending, leest het nieuwe trackingnummer terug en schrijft het in de stagingregel.

De claimstatus wordt submitted. Zodra de vervangzending is aangemaakt en het nieuwe trackingnummer is teruggelezen, krijgt de klantactie eerst de tussenstatus replacement_in_progress; het versturen van een trackingmail is nog geen bewijs dat de oplossing is geslaagd. Na succesvolle bezorging wordt de klantactie customer_resolved. Als de medewerker in plaats daarvan voor een refund kiest, volgt customer_resolved pas na bevestiging van de terugbetaling. Het dossier blijft awaiting_carrier totdat PostNL reageert. Komt de claim terug met een verzoek om extra bewijs, dan maakt het Sendcloud- of carrier-event een nieuwe taak met attachment_type en deadline. Het dossier wordt niet stilletjes gesloten omdat de klant al een nieuwe lamp krijgt.

Wat de agent hier niet doet

De agent verklaart PostNL niet aansprakelijk. Hij bepaalt niet dat de foto’s voldoende zijn. Hij maakt geen refund én vervangzending tegelijk. Hij verandert het adres niet omdat de klant in een losse zin schrijft dat hij tijdelijk ergens anders verblijft. Hij maakt ook geen tweede label als de eerste API-call een time-out geeft.

Dat is de juiste begrenzing. De machine neemt het zoekwerk en het samenstellen van het dossier over. De medewerker houdt de beslissing die geld, klantbelofte en aansprakelijkheid raakt.

Vergelijkingstabel: kant-en-klaar, workflow of maatwerk

De prijzen hieronder zijn momentopnames van 11 oktober 2026. Carrierlabels, AI-modelkosten, opslag, implementatie en eventuele Shopify- of ERP-licenties komen er nog bij.

Shopify kan webhookabonnementen gebruiken zodat je app gebeurtenissen ontvangt in plaats van steeds te pollen. De actuele API-pagina noemt 2026-10 als latest en wijst voor nieuwe publieke apps naar GraphQL in plaats van de legacy REST Admin API. Shopify beschrijft de webhookwerking en de actuele API-keuze in de documentatie. Gebruik die webhook alleen als trigger. Het volledige uitzonderingsdossier hoort buiten Shopify, zodat een claim niet verdwijnt wanneer een orderstatus naar fulfilled gaat.

De kernkeuze is daarmee helder. Koop de standaardlaag als je probleem vooral zichtbaarheid en meldingen is. Voeg n8n of Make toe als je een beheerste tussenlaag nodig hebt. Bouw maatwerk wanneer verschillende vervoerders, bewijsregels en writes samen één bedrijfskritische beslissing vormen.

Een carrier-event is nooit het einde van een verhaal. Het is het moment waarop je moet kunnen laten zien wat er beloofd was, wat er werkelijk gebeurde, welk bewijs dat ondersteunt en wie de volgende actie heeft vrijgegeven. Wie dat dossier goed bouwt, automatiseert geen losse meldingen maar een herstelproces dat klant, voorraad en claim tegelijk overeind houdt.