E-commerce
1 juillet 2026
« Colissimo dit livré hier, rien dans ma boîte. » « Photo dépôt chez le voisin, je n'habite pas là. » « Chargeback lancé, colis jamais reçu. » Trois tickets où un DNR mal traité génère avis public, chargeback ou refund prématuré sans enquête.
Le support livré non reçu e-commerce couvre vérifications 24-48 h, POD transporteur, réclamation carrier et résolution replace refund. Distinct colis perdu bloqué transit et POD seule (#527) : ici, process complet litige DNR.
Ce guide #529 couvre policy DNR-SUP, flow DNR-1 à DNR-8 et matrice DNR-MAP. Complète preuve livraison. Paire SAV du futur bot DNR (#530).
Summary
Pourquoi le DNR domine-t-il les litiges livraison ?
Le tracking affiche delivered. Le client affirme absence colis. Sans SOP, l'agent renvoie le lien suivi ou refuse refund sans vérification voisinage ni POD.
Cinq frictions typiques
Scan prématuré : livré carrier avant dépôt réel boîte
Dépôt voisin : photo adresse tierce contestée
Relais non retiré : scan déposé point relais oublié client
Vol porche : livré puis volé boîte immeuble
Chargeback J+2 : client agressif avant attente 24-48 h
Colissimo et Chronopost ouvrent réclamation livraison contestée via portail pro avec POD jointe (Colissimo Entreprise, réclamations 2026). Sans DNR-MAP, chaque agent improvise délais et seuils refund.
DNR #529 vs POD #527, colis perdu, TRACK-ERR #397 et WISMO #184
Cinq contenus, cinq layers litige livraison.
Matrice rapide
#529 DNR : process complet livré non reçu replace refund
#527 POD : obtenir partager preuve signature photo
Colis perdu : bloqué transit NPA vol global
#397 TRACK-ERR : track_err_delivered_not_received anomalie statut
WISMO #184 : statut tracking avant incident DNR
#527 = récupérer POD. #529 = résoudre litige après POD et vérifications. Colis perdu = transit bloqué ou NPA, pas statut delivered confirmé.
Quelles typologies dnr_* classifier ?
Huit scénarios tickets livré non reçu.
Huit typologies dnr
dnr_standard : delivered scan client nie réception
dnr_pod_neighbor : POD photo adresse voisin tierce
dnr_pickup_missed : déposé relais locker non retiré
dnr_mailbox : déposé boîte immeuble consigne
dnr_wrong_address : POD adresse différente commande
dnr_porch_theft : reçu puis volé porche
dnr_fraud_signal : 3e DNR même client valeur élevée
dnr_split_partial : multi-colis un delivered un missing
Tags : dnr, wismo, pod. Lookup delivered_at POD DNR-MAP avant macro.
Comment structurer la matrice DNR-MAP ?
La matrice DNR-MAP documente délais, seuils et résolution par transporteur pour agents et futur bot #530.
Colonnes DNR-MAP
carrier_code : colissimo chronopost mondialrelay dhl
wait_hours_before_claim : 24 ou 48 h post delivered_at
verification_checklist : voisin gardien relais digicode
carrier_claim_type : livraison contestée code portal
resolve_replace_max_eur : seuil replace sans attente carrier
resolve_refund_max_eur : seuil refund immédiat VIP
carrier_wait_days : délai enquête carrier avant resolve
fraud_escalate_signals : repeat dnr new account high AOV
gesture_commercial : code promo si attente prolongée
Une ligne par carrier + AOV tier. Alignée POD-MAP #527 pour claim_parallel.
Policy DNR-SUP en six règles
Six règles support livré non reçu.
WAIT-24-48 : attente voisinage avant claim si delivered J0
POD-FIRST : récupérer POD #527 avant résolution
RESOLVE-CLIENT-FIRST : replace refund sans bloquer claim carrier
ADDRESS-VERIFY : confirmer adresse digicode nom boîte
FRAUD-ESCALATE : signaux repeat DNR → fraude review
DATED-SLA : chaque réponse cite date prochaine étape
Flow DNR DNR-1 à DNR-8
Flow agent huit étapes livré non reçu.
DNR-1 Intake : dnr_* intent + auth order delivered_at
DNR-2 POD retrieve : playbook #527 signature photo
DNR-3 Wait gate : WAIT-24-48 si delivered_at récent
DNR-4 Verify : checklist voisin relais adresse
DNR-5 Classify : dnr_standard neighbor pickup fraud
DNR-6 Carrier claim : réclamation parallel portal pro
DNR-7 Resolve : replace refund gesture DNR-MAP seuils
DNR-8 Close : tag dnr_resolved outcome carrier_claim_id
SLA : DNR-ACK-01 envoyé sous 4 h avec date retour wait_hours + carrier_wait_days cite.
Macros DNR essentielles
Quatre macros agents.
DNR-ACK-01
« Nous comprenons : tracking livré le [delivered_at], colis absent. Vérifications : entourage, gardien, point relais [relais_check]. Retour garanti le [next_date] avec preuve transporteur. »
DNR-VERIFY-01
« Confirmez adresse [address], digicode [code], nom boîte [name]. Avez-vous vérifié voisins étages ? Relais [pickup_address] ? »
DNR-POD-SHARE-01
« Preuve Colissimo jointe : [pod_summary_redacted]. Emplacement indiqué [location]. Si toujours absent, enquête carrier [claim_id] ouverte. »
DNR-RESOLVE-01
« Dossier clos : [replace_shipped / refund_issued]. Réclamation transporteur [claim_id] en cours côté ops. Désolés pour ce désagrément. »
Point relais : cross-ref playbook erreur point relais (#515).
Cas limites : fraude, split et chargeback
Cinq cas hors macro standard.
Fraude repeat DNR : FRAUD-ESCALATE, pas replace auto, review manuel
Chargeback imminent : DNR-RESOLVE-01 sous 24 h si seuil AOV map
Split shipment : un colis delivered un missing
POD adresse erronée : dnr_wrong_address replace immédiat ops
Refus livraison : retour expéditeur #511
Ne jamais conditionner refund client à retour enquête carrier seule : RESOLVE-CLIENT-FIRST après wait gate et verify.
KPI dnr essentiels
Cinq métriques pilotage DNR.
dnr_ticket_rate : tickets DNR / delivered orders
dnr_resolve_success : % résolus replace ou refund SLA
dnr_first_response_sla : DNR-ACK-01 sous 4 h
dnr_chargeback_rate : chargebacks post DNR ticket
dnr_fraud_escalate_rate : sessions FRAUD-ESCALATE review
Cible : dnr_resolve_success > 75 % sous carrier_wait_days avec RESOLVE-CLIENT-FIRST seuils DNR-MAP.
Anti-patterns DNR
Cinq erreurs fréquentes.
Renvoyer lien tracking : reconnaître litige DNR
Refuser sans POD : POD-FIRST #527
Attendre carrier 3 semaines : RESOLVE-CLIENT-FIRST
Pas de date retour : DATED-SLA violation
Traiter tout comme fraude : WAIT-24-48 + verify
DNR avec Qstomy
Qstomy sur Shopify : detect dnr_* intent, POD fetch #527, wait gate auto, verify checklist chat, carrier claim payload, handoff #530 bot tier 1.
Pipeline : #529 agents resolve → #530 bot DNR tier 1 verify → #527 POD si preuve manquante.
Explorez support IA et demander une démo.
Checklist, FAQ et aller plus loin
Checklist DNR (8 étapes)
DNR-MAP v1 : carriers wait seuils resolve fraud
Policy DNR-SUP : 6 règles WAIT-24-48 RESOLVE-CLIENT-FIRST
8 typologies dnr_* : tags helpdesk dnr wismo pod
4 macros DNR-* : ACK VERIFY POD-SHARE RESOLVE
Lien POD #527 : POD-FIRST workflow
Seuils replace refund : AOV tiers DNR-MAP
Formation fraude signals 20 min : FRAUD-ESCALATE
Dashboard KPI : dnr_* section 9
FAQ
Différence POD #527 ?
#527 = obtenir preuve. #529 = résoudre litige complet.
Différence colis perdu ?
Colis perdu = transit bloqué NPA. DNR = statut delivered.
Attendre 48 h obligatoire ?
Oui si delivered_at récent, sauf POD adresse erronée.
Bot #530 suffit ?
Tier 1 verify wait. Replace refund complexe → agents #529.
Aller plus loin
p : Bot DNR (#530)
p : Bot POD (#528)
p : Colis perdu
Cette semaine : documenter DNR-MAP par carrier et AOV, tester macro DNR-ACK-01 avec date retour, aligner seuils replace refund ops, mesurer dnr_first_response_sla.
Enzo
1 juillet 2026
