E-commerce
1 juillet 2026
« Mon suivi est bloqué depuis 5 jours sur « en transit ». » « Le transporteur dit livré, Shopify dit expédié seulement. » « Aucun scan depuis l'étiquette créée, le colis est-il perdu ? » Trois messages où le client ne cherche pas « où est ma commande » en général, mais une explication sur une anomalie tracking transporteur.
Le support erreurs tracking transporteur e-commerce traite statut bloqué, scan manquant, incohérence entre Shopify et carrier API, faux « livré » et numéro invalide. Sans policy, chaque ticket devient reship prématuré ou silence client pendant 72 h.
Ce guide #397 couvre policy TRACK-ERR, flow CARR-FLOW et KPI track_err. Il complète le suivi commande général ; ici le focus erreurs et anomalies transporteur post-expédition. Distinct du futur bot tracking (#398) : process agents, escalades carrier et macros.
Sommaire
Pourquoi les erreurs tracking transporteur surchargent-elles le SAV ?
Un ticket erreur tracking support arrive quand le colis est expédié mais le statut carrier ne progresse pas, contredit Shopify, ou affiche une exception opaque.
Cinq frustrations client typiques
Statut figé : « en transit » sans nouveau scan 4+ j
Scan manquant initial : étiquette créée, zero mouvement J+2
Incohérence plateformes : Shopify fulfilled, carrier « label created »
Faux livré : carrier « delivered » sans réception client
Numéro invalide : lien tracking 404 ou mauvais transporteur
AfterShip estime que 11 à 15 % des colis e-commerce présentent au moins un retard ou anomalie statut en transit (AfterShip, carrier updates 2026). ShippyPro rappelle que les scans manqués en hub initial sont fréquents les pics volume (ShippyPro, WISMO 2026).
Angle #397 vs contenus voisins
Bot WISMO #184 : automation lookup statut standard. Le #397 = anomalies carrier, escalades ops et litiges.
Parcours suivi #181 : page branded, notifications. Le #397 = ticket SAV quand le tracking échoue malgré le parcours.
Retard livraison : communication retard ETA. Le #397 = statut bloqué ou incohérent, pas simple dépassement délai.
Préparation #395 : unfulfilled prep. Le #397 = post-expédition, fulfilled.
Assurance perdu #361 : claim Route après procédure. Le #397 = investigation carrier avant claim.
Exemple DTC
Marque mode, Colissimo + Chronopost, 94 tickets track_err/mois. Après TRACK-ERR + CARR-FLOW : track_err_fcr 81 %, premature_reship_rate -38 %, carrier_claim_success +22 pts.
Volume typique
12 à 22 % tickets WISMO fulfilled concernent une anomalie tracking, pas une simple demande ETA.
En quoi une erreur tracking diffère-t-elle du WISMO standard ?
Trois niveaux de question post-expédition, trois playbooks distincts.
Matrice question → playbook
WISMO standard (#184) : statut progresse, client veut ETA
Retard simple (#late) : scans OK, ETA dépassé
Erreur tracking (#397) : statut bloqué, incohérent ou absent
Signaux erreur vs WISMO normal
Dernier scan > 72 h sans exception carrier documentée
Shopify tracking URL ≠ statut AfterShip/carrier API
Statut « label created » ou « info received » seul J+3+
Exception carrier : address issue, held at customs, damaged in transit
Sources vérité à croiser
Shopify fulfillment events, API carrier directe ou agrégateur (AfterShip, ShippyPro, Malomo), WMS scan ship confirm. CARR-FLOW exige double lookup avant réponse client.
Reroute prep #395
Si fulfillment_status unfulfilled : pas TRACK-ERR, reroute PREP-FLOW #395 ou bot #396.
Promesse #397
Policy TRACK-ERR, typologies track_err_*, flow CARR-FLOW, macros TRACK-*, escalade carrier, seuils reship vs investigation.
Quelles typologies track_err_* cartographier ?
Douze typologies tickets erreur tracking pour routing cohérent.
Douze scénarios track_err
track_err_stale_scan : pas de scan 72 h+ en transit
track_err_no_initial_scan : label créé, zero scan hub J+2+
track_err_shopify_carrier_mismatch : statuts contradictoires
track_err_invalid_number : tracking 404, mauvais carrier code
track_err_delivered_not_received : faux livré DNR
track_err_returned_to_sender : retour expéditeur sans action client
track_err_address_exception : adresse incomplète, colis en attente hub
track_err_customs_hold : blocage douane transit international
track_err_damaged_in_transit : exception dommage carrier
track_err_split_confusion : mauvais tracking consulté (#356)
track_err_lost_confirmed : carrier confirme perte ou 15 j stale
track_err_wrong_tracking_sent : numéro d'une autre commande
Tags helpdesk
track_err, track_stale, track_mismatch, track_dnr, track_rts, track_lost. Distinct wismo_standard et late_delivery.
Données intake CR-1
order_id, tracking_number, carrier, last_scan_at, last_scan_location, shopify_fulfillment_status, carrier_api_status, days_since_ship, customer_verbatim.
Mining tickets
WISMO fulfilled : reclassifier % track_err vs wismo_eta. Alimente macros et seuils stale.
Comment rédiger la policy TRACK-ERR en huit règles ?
La policy erreurs tracking TRACK-ERR documente seuils investigation, escalade carrier et reship avant litige.
Huit règles TRACK-ERR
Double lookup obligatoire : Shopify + carrier API avant réponse
Stale threshold : 72 h sans scan = investigation carrier (48 h express)
No initial scan : J+2 ouvrés post-ship = ping entrepôt + carrier
Mismatch : screenshot client + vérif ops sous 24 h
DNR procedure : attente 48 h + voisin/consigne avant reship
Reship seuil : lost confirmé ou 10 j stale sans réponse carrier
Assurance : claim Route/SHIP-INS après procédure #361, pas avant
Communication : jamais « perdu » sans preuve carrier ou seuil policy
Publication /pages/suivi-commande
FAQ : « Mon suivi ne bouge pas », « Que faire si livré mais absent », délais stale normaux vs anomalie. Lien macros self-service.
Alignement logistique
Support ne reship pas sans ticket carrier ou seuil TRACK-ERR règle 6. Revue mensuelle support + ops + 3PL.
Carriers prioritaires
Documenter procédure réclamation par transporteur : Colissimo, Chronopost, DHL, UPS, Mondial Relay.
Comment appliquer le flow CARR-FLOW en huit étapes ?
Le framework CARR-FLOW structure réponse tickets erreur tracking.
Huit étapes CR-1 à CR-8
CR-1 Intake : order_id, tracking, verbatim, typologie track_err_*
CR-2 Lookup Shopify : fulfillment, tracking_number, carrier, ship_date
CR-3 Lookup carrier API : last_scan, status, exceptions
CR-4 Comparer : match | mismatch | stale | no_scan | exception
CR-5 Classifier : typologie confirmée, reroute split/customs/dmg si besoin
CR-6 Répondre : macro TRACK-* + prochaine étape grounded data
CR-7 Escalader : ticket carrier, ops entrepôt, reship si seuil
CR-8 Documenter : note order, tag track_err, carrier_case_id
CR-4 arbre décision
unfulfilled → #395 prep, pas CARR-FLOW
stale 72 h+ → TRACK-STALE-01 + carrier claim CR-7
no initial scan J+2 → TRACK-NOSCAN-01 + entrepôt ping
delivered DNR → TRACK-DNR-01 procédure 48 h
invalid number → TRACK-INVALID-01 + ops vérif label
split wrong tracking → reroute #356 SPLIT-FLOW
SLA réponse support
Track_err : première réponse 4 h avec statut carrier cité. Escalade carrier ouverte sous 24 h si stale. DNR : follow-up J+2.
Carrier case tracking
CR-8 enregistre carrier_case_id, date ouverture, SLA réponse carrier (5-10 j ouvrés).
Quelles macros TRACK-* pour les agents ?
Dix macros agents erreur tracking couvrent 90 % des tickets track_err.
TRACK-STALE-01 (scan figé)
« Commande #[X], colis #[tracking] expédié le [date]. Dernier scan : [location] le [date_scan]. Les colis peuvent rester sans scan intermédiaire 2-4 j entre hubs. Nous avons ouvert une enquête transporteur (réf. [case_id]). Mise à jour sous 48-72 h. Aucune action requise de votre part. »
TRACK-NOSCAN-01 (pas de scan initial)
« Étiquette créée le [date]. Le premier scan hub peut prendre 24-48 h ouvrés après prise en charge. Nous vérifions avec l'entrepôt. Si aucun scan d'ici [date+2j], enquête transporteur automatique. »
TRACK-MISMATCH-01 (incohérence)
« Nous constatons un écart entre nos systèmes. Vérification ops sous 24 h. Pouvez-vous confirmer le statut affiché sur [lien tracking] ? Nous revenons avec statut exact. »
TRACK-DNR-01 (livré non reçu)
« Transporteur indique livré le [date] à [location]. Vérifiez boîte, gardien, voisins, point relais. Si absent sous 48 h, répondez NON RECU : enquête + procédure remplacement selon policy. »
TRACK-INVALID-01 (numéro invalide)
« Le numéro [tracking] ne répond pas sur le site [carrier]. Nous vérifions l'étiquette entrepôt. Numéro corrigé sous 24 h si erreur label. »
Autres macros
TRACK-RTS-01 : retour expéditeur, options reship/refund
TRACK-ADDR-01 : exception adresse, action client requise
TRACK-CUSTOMS-01 : hold douane, documents (#65)
TRACK-LOST-01 : perte confirmée, reship ou refund
TRACK-INS-01 : renvoi claim assurance #361
Règles macros
Toujours citer last_scan grounded CR-3. Jamais « colis perdu » sans TRACK-LOST seuil. Jamais reship promis dans TRACK-STALE sans supervisor OK.
Comment escalader vers le transporteur et l'entrepôt ?
L'escalade carrier tracking support suit un protocole reproductible par transporteur.
Quatre niveaux escalade
N1 Agent : CR-1 à CR-6, macros, rassurance client
N2 Ops logistique : vérif label entrepôt, reship autorisé
N3 Claim carrier : formulaire transporteur, case_id
N4 Assurance : SHIP-INS #361 si lost/stolen confirmé
Ticket carrier minimum
tracking_number, carrier, ship_date, last_scan, recipient_address, order_value, nature réclamation (stale, DNR, RTS, lost), photos si DNR.
Entrepôt ping no-scan
Slack #warehouse ou ticket 3PL : « Label [tracking] créé [date], zero scan. Confirm handoff carrier ou reship si non déposé. » SLA entrepôt 24 h.
Reship vs refund
Stale 10 j + claim ouvert : reship stock OK ou refund client choix
Lost confirmé carrier : reship prioritaire si stock, sinon refund
DNR après 48 h enquête : reship si LTV OK, sinon investigation
Split shipment
Erreur sur mauvais colis : manifeste fulfillments avant escalade. Aligner SPLIT-SHIP #356.
International customs
track_err_customs_hold : reroute douanes #65, pas reship immédiat.
Quels outils connecter pour le lookup carrier ?
Le stack lookup tracking support évite réponses basées sur Shopify seul.
Couche Shopify
Fulfillment tracking_number et tracking_company
Fulfillment created_at : date ship référence stale calc
Fulfillment events : historique statuts Shopify
Shopify Admin fulfillment API (Shopify Dev, Fulfillment API).
Couche agrégateur carrier
AfterShip / ShippyPro : statut unifié 1000+ carriers
Malomo / Wonderment : page branded + webhook exceptions
API directe : Colissimo, La Poste, DHL pour FR
Widget agent helpdesk
Sidebar Gorgias/Zendesk : order + last_scan + days_stale + exception flag. Agent copie TRACK-* sans ouvrir 3 onglets.
Alertes proactives
Webhook carrier exception → ticket interne avant contact client. Réduit track_err inbound 15-20 % selon ShippyPro.
Cohérence bot #184
Bot WISMO lit même API. Track_err escalades au-delà automation. Futur bot #398 couvrira stale/DNR en chat.
Quels KPI track_err mesurer ?
Les KPI erreurs tracking support pilotent qualité réponse et coût reship.
Huit métriques clés
track_err_fcr : résolu premier contact / tickets track_err
track_stale_rate : % colis stale 72 h+ / expéditions
premature_reship_rate : reship avant seuil TRACK-ERR (cible < 3 %)
carrier_claim_success_rate : claims résolus favorables
track_mismatch_rate : incohérences Shopify/carrier / mois
dnr_resolution_days : délai médian DNR → clôture
invalid_tracking_rate : labels erronés entrepôt / mois
track_err_csat : satisfaction post CARR-FLOW
Benchmark DTC
track_err_fcr 78-85 %, premature_reship < 3 %, carrier_claim_success 55-70 %, dnr_resolution 3-5 j, invalid_tracking < 0,5 % shipments.
Dashboard mensuel
Top typologies track_err_*, carrier breakdown stale, reship coût, corrélation peak volume et no_scan rate.
Audit tickets 15/mois
Score : double lookup CR-2+CR-3 ? last_scan cité ? pas « perdu » prématuré ? carrier_case_id documenté ?
Alerte ops
invalid_tracking_rate > 1 % : review process étiquetage entrepôt sous 48 h.
Quels edge cases et anti-patterns éviter ?
Dix edge cases track_err et réponses playbook.
1. Reship immédiat sur stale J+3
Anti-pattern coûteux. Attendre seuil 72 h stale ou 10 j avant reship policy.
2. Réponse Shopify seule sans carrier API
Shopify « in transit » peut lag 24 h. CR-3 obligatoire.
3. DNR sans procédure 48 h voisin/consigne
Carrier exige enquête. TRACK-DNR-01 complet avant reship.
4. Split : client regarde tracking colis 1, colis 2 en route
Reroute #356 manifeste. Pas TRACK-LOST sur mauvais numéro.
5. Customs hold traité comme perdu
Attente documents client. Reroute #65, pas refund.
6. Assurance claim avant investigation
Route refuse sans stale proof. CARR-FLOW complet puis #361.
7. Mauvais tracking envoyé email Klaviyo
track_err_wrong_tracking : ops vérifie fulfillment vs email template.
8. Express stale 48 h vs standard 72 h
Seuil TRACK-ERR règle 2 adapté mode ship. Tag express order.
9. Colis déposé point relais, statut « awaiting pickup »
Pas stale. Macro relais + date limite retrait.
10. Prep confondu stale
Unfulfilled sans tracking : #395, pas track_err_stale.
Anti-patterns
Copier-coller lien tracking sans expliquer last_scan
Promettre livraison demain sur stale sans ETA carrier
Pas de carrier_case_id en CR-8
Comment Qstomy aide sur les anomalies tracking ?
Qstomy sur Shopify : lookup fulfillment + carrier status, détection stale/DNR, templates grounded last_scan, handoff CARR-FLOW avec ticket pré-rempli pour agents.
Capacités tracking Qstomy
track_err_detect : 12 typologies section 3
track_dual_lookup : Shopify + carrier API
track_stale_calc : days_since_last_scan automatique
track_explain_template : last_scan cité plain language
track_reroute : prep #395, split #356, customs #65, ins #361
track_handoff_ticket : CR-1 à CR-4 brief agents
track_no_premature_lost : guardrail seuil TRACK-ERR
Complément #184 et futur #398
Bot WISMO #184 résout ETA standard. Qstomy escalade track_err vers agents CARR-FLOW. Roadmap bot #398 automatisera stale et DNR en chat.
Scénario DTC chiffré
Marque mode, 94 tickets track_err/mois, AfterShip connecté.
Après Qstomy + TRACK-ERR : track_err_fcr 83 %, premature_reship -41 %, track_err_handoff_complete 91 %, track_err_csat 4,2/5.
Explorez support client et demander une démo.
Quelle checklist pour déployer TRACK-ERR ?
Checklist TRACK-ERR (12 étapes)
Rédiger policy 8 règles TRACK-ERR + FAQ /pages/suivi-commande
Documenter 12 typologies track_err_* section 3
Connecter carrier API ou AfterShip/ShippyPro au helpdesk
Créer 10 macros TRACK-* Gorgias/Zendesk
Former agents CARR-FLOW CR-1 à CR-8 (45 min)
Documenter procédure claim par transporteur principal
Définir seuils stale 72 h standard / 48 h express
Intégrer reroute prep #395, split #356, douanes #65, assurance #361
Widget sidebar agent : last_scan + days_stale
Alertes webhook carrier exception proactive
Dashboard KPI track_err mensuel
Audit 15 tickets/mois + corréler premature_reship
En bref
#397 = anomalies carrier, pas WISMO ETA standard (#184)
CARR-FLOW : double lookup → classifier → macro → escalade
TRACK-ERR : seuils stale, DNR 48 h, reship contrôlé
Grounded last_scan : jamais « perdu » sans preuve
KPI track_err_fcr : cible 78-85 %
FAQ
Différence avec #184 WISMO bot ?
#184 automation statut normal. #397 playbook agents anomalies, claims et reship.
Quand considérer le colis perdu ?
Carrier confirme perte, ou 10 j stale sans scan après claim. Pas avant seuil TRACK-ERR.
Relation retard livraison ?
Retard = scans progressent, ETA dépassé. Erreur = statut bloqué ou incohérent.
Relation assurance #361 ?
Investigation CARR-FLOW d'abord. Claim SHIP-INS après lost confirmé ou stale 15 j.
Futur bot #398 ?
Automatisera stale/DNR en chat. #397 reste policy et escalades agents.
Aller plus loin
Testez CARR-FLOW sur 5 tickets stale réels : vérifiez double lookup, last_scan cité, carrier_case_id CR-8, zero reship avant seuil.
Partagez ce guide #397 avec support et logistique : une erreur tracking bien traitée évite reship inutile et chargebacks DNR.
Enzo
1 juillet 2026
