Koppel een Sendcloud-pakket aan een webshoporder met een gecontroleerde identiteitsladder: werkruimte en provideraccount eerst, daarna een vaste externe orderreferentie en pas vervolgens aanvullende kenmerken. Match nooit op alleen naam, postcode of bedrag. Bij nul of meerdere kandidaten stopt automatische verwerking, omdat een verkeerde trackinglink moeilijker te herstellen is dan een ontbrekende.
Waarom pakketidentiteit lastig wordt
Eén order kan meerdere pakketten hebben, een nalevering kan als gekoppelde order bestaan en verschillende webshops kunnen hetzelfde zichtbare ordernummer gebruiken. Een vervoerdersaccount kan bovendien zendingen uit meerdere kanalen bevatten. De vraag is daarom niet “welke zending lijkt erop?”, maar “welke lokale order en fulfilmentstap hebben deze pakketidentiteit aantoonbaar gemaakt?”.
Leg bij het aanmaken van een pakket direct de relatie vast tussen werkruimte, webshoporder, provideraccount en externe parcel-ID. Bewaar die identiteit bij latere trackingwebhooks. Een webhook die alleen een parcel-ID noemt hoeft dan geen brede zoekactie over klantdata uit te voeren. Dit sluit aan op Connect als integratielaag: identiteit reist mee met de processtap.
De identiteitsladder
- Werkruimte. Accepteer alleen het account en de webhookconfiguratie van de actieve organisatie.
- Externe parcel-ID. Zoek eerst de eerder opgeslagen exacte pakketidentiteit.
- Vaste orderreferentie. Gebruik een door beide kanten behouden referentie wanneer de parcel-ID nog wordt vastgelegd.
- Account en winkel. Beperk iedere fallback tot het juiste verkoopkanaal.
- Aanvullende kenmerken. Gebruik datum of postcode alleen ter bevestiging, niet als primaire sleutel.
- Ambiguïteit. Stop, toon kandidaten en laat een bevoegde medewerker besluiten.
Maak daarnaast onderscheid tussen pakket, label en order. Een opnieuw geprint label hoeft geen nieuw pakket te zijn; een nalevering kan juist wel een tweede parcel bij dezelfde oorspronkelijke klantvraag hebben.
Fictief voorbeeld: twee pakketten naar één adres
Fictief voorbeeld: kantoorleverancier HelderWerk ontvangt op dezelfde dag twee orders van hetzelfde bedrijf, beide naar dezelfde receptie en met een gelijk bedrag. Matchen op naam, postcode, datum en totaal zou willekeurig zijn. Bij het maken van de pakketten zijn echter de orderreferenties HW-4401 en HW-4402 plus twee parcel-ID’s opgeslagen.
Een trackingwebhook voor de tweede parcel vindt exact HW-4402 binnen het juiste provideraccount. Alleen die order krijgt de trackinggebeurtenis. Wanneer een oud pakket uit een gemigreerd account binnenkomt zonder bekende identiteit, past het systeem geen update toe en ontstaat een onderzoekstaak. Dit fictieve voorbeeld toont dat “veel overeenkomende velden” nog geen betrouwbare primaire sleutel vormt.
Acceptatietest voor pakketmatching
| Testgeval | Verwachte uitkomst |
|---|---|
| Twee orders, zelfde klant en bedrag | Exacte referentie kiest de juiste |
| Eén order, twee parcels | Beide identiteiten blijven afzonderlijk |
| Gelijk ordernummer in twee winkels | Account- en werkruimtescope scheiden |
| Onbekende parcel-ID | Geen orderupdate, wel onderzoek |
| Herhaalde webhook | Zelfde event zonder dubbel klantbericht |
Toon in Desk parcel-ID, orderreferentie, huidige status en herkomst van de koppeling. Een medewerker hoeft dan niet op basis van klantnaam te gokken. Voor het totale order- en ERP-pad biedt de integratiechecklist aanvullende ontwerpvragen.
Plan een aparte migratieroute wanneer al pakketten bij Sendcloud bestaan voordat de nieuwe integratie start. Importeer niet automatisch iedere historische zending. Kies een afgebakende periode, beperk op het juiste account en bouw een rapport met exacte matches, ontbrekende orders en ambiguïteiten. Laat een steekproef van de automatische matches controleren voordat trackingevents worden vrijgegeven. Oude parcels kunnen verwijzen naar geannuleerde of opnieuw aangemaakte orders; die geschiedenis vraagt een andere behandeling dan een nieuw pakket dat door de actuele workflow zelf is gemaakt.
Definieer ook wat een medewerker mag doen bij een mismatch. Handmatig koppelen moet de twee identiteiten, reden en actor bewaren en mag alleen binnen dezelfde werkruimte. Ontkoppelen hoort niet stil eerdere klantmeldingen te wissen. Wanneer een parcel aantoonbaar verkeerd is gekoppeld, herstel je eerst toekomstige events en beoordeel je daarna afzonderlijk welke reeds verzonden trackinginformatie moet worden gecorrigeerd. Daarmee blijft de pakketidentiteit zowel technisch als voor klantenservice betrouwbaar.
Let ook op het verschil tussen opnieuw aanbieden en een nieuw pakket. Een mislukt labelverzoek kan veilig opnieuw leesbaar blijken, terwijl een echte deellevering bewust een extra parcel nodig heeft. Laat de bediening daarom eerst bestaande provideridentiteiten en pakketstatussen tonen. Vraag bij “nieuw pakket” om een reden en de orderregels die erbij horen. Zo voorkom je dat een supportmedewerker uit tijdsdruk een tweede zending aanmaakt terwijl alleen de eerste zending opnieuw moest worden opgehaald.
Wil je pakket- en orderidentiteiten door je hele fulfilmentketen volgen? Laat Yindle een matching- en migratieplan maken.