E-commerce
1 juillet 2026
« Envoyez-moi la signature de livraison. » « Photo du colis déposé chez le voisin, je ne l'ai pas. » « Colissimo dit livré, je veux la preuve avant chargeback. » Trois tickets où une demande de preuve de livraison mal traitée prolonge litige, chargeback ou réclamation transporteur.
Le support preuve livraison e-commerce couvre signature, photo dépôt, scan relais et manifeste WMS. Distinct du DNR (#529) et colis perdu : ici, obtenir et communiquer la POD depuis source transporteur.
Ce guide #527 couvre policy POD-SUP, flow POD-1 à POD-8 et matrice POD-MAP. Complète tracking et litiges. Paire SAV du futur bot POD (#528).
Sommaire
Pourquoi les demandes de preuve de livraison explosent-elles ?
Le client veut voir qui a signé ou où le colis a été déposé. Sans SOP, l'agent envoie capture tracking générique ou promet preuve jamais récupérée auprès du transporteur.
Cinq frictions typiques
Demande administrative : client veut justificatif assurance ou entreprise
Litige DNR amont : livré mais absent, preuve avant escalade
Photo dépôt floue : adresse voisin ou boîte aux lettres contestée
Relais sans retrait : scan déposé point relais, client nie passage
POD indisponible : délai carrier 24 à 72 h post-livraison
Colissimo, Chronopost et Mondial Relay exposent signature ou photo selon service via portail pro ou API tracking (La Poste Pro, suivi 2026). Sans POD-MAP par transporteur, chaque ticket repart de zero.
POD #527 vs DNR #529, colis perdu, TRACK-ERR #397 et NOTRACK #525
Cinq contenus, cinq layers litige livraison.
Matrice rapide
#527 POD : obtenir et partager preuve signature photo scan
Colis perdu : réclamation carrier seuils replace
#397 TRACK-ERR : track_err_delivered_not_received statut anomalie
#525 NOTRACK : pas de suivi, manifeste WMS seul
#527 = récupérer POD source carrier. #529 = résoudre litige après analyse POD. Router pod_dispute_intent vers DNR playbook si client nie réception.
Quelles typologies pod_* classifier ?
Huit scénarios tickets preuve livraison.
Huit typologies pod
pod_request_admin : justificatif signature pour dossier interne
pod_request_dispute : preuve car colis non reçu, amont DNR
pod_signature_available : signature nom lisible carrier portal
pod_photo_deposit : photo boîte voisin consigne
pod_pickup_point : scan déposé Mondial Relay locker
pod_local_delivery : POD flotte interne photo GPS
pod_unavailable_delay : livré J0, POD carrier pas encore API
pod_untracked_manifest : méthode sans POD, manifeste ship WMS
Tags : pod, wismo, dnr si dispute. Lookup carrier fulfillment delivered_at POD-MAP avant macro.
Comment structurer la matrice POD-MAP ?
La matrice POD-MAP documente comment récupérer et partager preuve par transporteur pour agents et futur bot #528.
Colonnes POD-MAP
carrier_code : colissimo chronopost mondialrelay dhl
pod_type : signature photo gps scan none
retrieval_method : portal pro API AfterShip email carrier
retrieval_sla_hours : délai normal disponibilité post-livraison
customer_shareable : Y partial redact N internal only
redact_fields : nom signataire adresse voisin floutée
dispute_routing : pod_dispute → #529 DNR flow
claim_parallel : Y ouvrir réclamation carrier simultané
fallback_proof : ship manifest WMS si pod_type none
Une ligne par carrier + service level. Mise à jour trimestrielle avec ops logistique.
Policy POD-SUP en six règles
Six règles support preuve livraison.
POD-CARRIER-SOURCE : preuve depuis transporteur ou WMS only
NO-FAKE-POD : jamais signature ou photo inventée
REDACT-PII : masquer nom voisin adresse tierce avant envoi
DISPUTE-ROUTING : pod_request_dispute → playbook DNR #529
CARRIER-CLAIM-PARALLEL : réclamation carrier si dispute, sans bloquer client
SLA-CITE : retrieval_sla_hours map si POD pas encore dispo
Flow POD POD-1 à POD-8
Flow agent huit étapes preuve livraison.
POD-1 Intake : pod_* intent + order lookup delivered_at
POD-2 Carrier check : fulfillment tracking carrier_code
POD-3 POD-MAP : pod_type retrieval_method sla shareable
POD-4 Classify : admin dispute photo relais unavailable
POD-5 Retrieve : portal API ops ticket carrier si delay
POD-6 Redact : REDACT-PII avant envoi client
POD-7 Respond : macro POD grounded + dispute routing si besoin
POD-8 Close : tag pod_resolved pod_escalated_dnr outcome
SLA : pod_request_admin répondu en une interaction si POD déjà en cache AfterShip ou portail pro.
Macros POD essentielles
Quatre macros agents.
POD-SIGNATURE-01
« Preuve de livraison Colissimo : signé le [delivered_at] par [signatory_redacted]. Pièce jointe : [pod_attachment]. Questions sur réception : répondez, nous activons vérifications complémentaires. »
POD-PHOTO-01
« Photo dépôt transporteur du [delivered_at] en pièce jointe. Emplacement indiqué : [location_redacted]. Si colis introuvable : vérifiez voisinage et consigne sous 24 h. »
POD-DELAY-01
« Livraison confirmée le [delivered_at]. Preuve signature disponible sous [retrieval_sla_hours] h auprès du transporteur. Nous vous l'envoyons dès réception. »
POD-DISPUTE-01
« Nous récupérons la preuve transporteur et lançons vérifications livré non reçu. Délai retour : [dnr_sla]. En attendant : vérifiez entourage et boîte aux lettres. »
Livraison locale : voir playbook livraison locale pour POD flotte interne.
Cas limites : relais, refus et sans tracking
Cinq cas hors macro standard.
Point relais : scan déposé + preuve retrait si client a retiré
Refus livraison : refus client, POD retour expéditeur
Split shipment : POD par fulfillment, pas commande globale
Sans tracking : #525 NOTRACK manifeste WMS ship photo entrepôt
Chargeback imminent : POD + carrier claim ID dans réponse datée
Ne jamais partager POD complète avec nom voisin lisible sans REDACT-PII : risque RGPD et conflit voisinage.
KPI pod essentiels
Cinq métriques pilotage POD.
pod_ticket_rate : tickets POD / delivered orders
pod_retrieve_success : % POD obtenue sous retrieval_sla
pod_one_touch_admin : % pod_request_admin résolu une interaction
pod_dispute_escalate_dnr : sessions routées #529
pod_fake_violation : NO-FAKE-POD, cible 0
Cible : pod_retrieve_success > 85 % après cache AfterShip et accès portail pro par carrier.
Anti-patterns POD
Cinq erreurs fréquentes.
Capture tracking générique : pas une POD, NO-FAKE-POD
Ignorer dispute intent : router #529 DNR
PII non redactée : nom voisin adresse tierce
Attendre POD pour répondre : SLA-CITE + carrier claim parallel
Confondre colis perdu : POD d'abord, lost playbook ensuite
POD avec Qstomy
Qstomy sur Shopify : detect pod_* intent, POD-MAP lookup, cache AfterShip POD, redact auto PII, handoff #528 bot tier 1, escalate #529 DNR payload.
Pipeline : #527 agents retrieve redact → #528 bot POD tier 1 → #529 DNR si dispute confirmée.
Explorez support IA et demander une démo.
Checklist, FAQ et aller plus loin
Checklist POD (8 étapes)
POD-MAP v1 : carriers pod_type retrieval sla shareable
Policy POD-SUP : 6 règles NO-FAKE-POD REDACT-PII
8 typologies pod_* : tags helpdesk pod wismo dnr
4 macros POD-* : SIGNATURE PHOTO DELAY DISPUTE
Accès portail pro : Colissimo Chronopost Mondial Relay
Cache AfterShip POD : API webhook delivered event
Formation dispute routing 20 min : POD vs DNR #529
Dashboard KPI : pod_* section 9
FAQ
Différence DNR #529 ?
#527 = obtenir partager POD. #529 = résoudre litige livré non reçu.
Client chargeback imminent ?
POD redactée + carrier claim ID + réponse datée sous 24 h.
POD pas disponible ?
POD-DELAY-01 cite retrieval_sla_hours map.
Bot #528 suffit ?
Tier 1 retrieve cache. Dispute complexe → agents #527 ou #529.
Aller plus loin
p : Bot POD (#528)
p : Colis perdu
Cette semaine : documenter POD-MAP par transporteur, tester récupération signature Colissimo, configurer redact PII template, mesurer pod_retrieve_success.
Enzo
1 juillet 2026
