Sommaire
Réponse directe
Un colis refusé en COD est un colis que le client n’accepte pas à la livraison (montant, produit, disponibilité, méfiance). On le distingue du non-livré, du retour en transit et du retour en attente de validation entrepôt (return_pending_scan). On agit surtout en confirmation (montant, contenu, téléphone, adresse, ville), puis on mesure avec une formule claire, on segmente (ville, produit/variante, agent, transporteur) et on applique un plan d’action. ERP-STOK structure confirmation, suivi et COD Delivery Insights ; il ne garantit pas zéro refus ni une baisse en pourcentage.
Qu’est-ce qu’un colis refusé en COD ?
En Cash on Delivery (paiement à la livraison), le client paie le livreur. Un colis « refusé » désigne en pratique le cas où le livreur rapporte que le destinataire a décliné le colis — souvent pour montant, produit, absence d’intention réelle, ou méfiance.
Ce n’est pas la même chose qu’une commande annulée en confirmation avant envoi : le refus se constate après que le colis a été confié au transporteur.
Les libellés exacts (« refusé », « refused », etc.) dépendent du transporteur et de la synchronisation (polling) dans ERP-STOK.
Refus, non-livraison, retour et validation entrepôt
Mélanger ces signaux conduit à de mauvaises actions : on « corrige le stock » trop tôt, ou on traite un problème de confirmation comme un problème d’entrepôt.
Le stock n’est pas déduit à la confirmation : il l’est au ramassage (pickup / « ramassé »). Un statut transporteur « retourné » ou « refusé » ne restaure pas automatiquement le stock : le flux entrepôt (scan puis validation) reste requis.
| Notion | Ce que ça veut dire | Levier principal |
|---|---|---|
| Refus (à la porte) | Client décline le colis présenté | Confirmation, clarté COD, données client |
| Non-livraison / échec | Colis non remis (absent, hors zone, report…) | Adresse, créneau, suivi, notes |
| Retour en transit | Colis repart vers l’entrepôt / le marchand | Suivi transporteur + process retour |
| return_pending_scan | Retour attendu : pas encore scanné / validé | Scan session retour puis validation |
| Retour validé entrepôt | Contrôle physique terminé selon workflow | Restauration stock après validation |
Principales causes de colis refusés
La plupart des refus « évitables » se jouent avant l’envoi. Voici les causes les plus fréquentes côté opérations COD marocaines.
- Confirmation faible ou incomplète : intention d’achat, montant COD total et contenu non rappelés.
- Téléphone, adresse ou ville incorrects / incomplets — le livreur ne trouve pas ou le client nie la commande.
- Commandes en double ou frauduleuses (faux numéro, tests, spam) envoyées malgré tout.
- Malentendu client : produit, variante (taille/couleur), prix ou délai de livraison non clarifiés.
- Délais de livraison trop longs ou mal annoncés — le client change d’avis à la porte.
- Absence de suivi / relance après envoi (statuts bloqués, pas de note ops).
- Concentrations problématiques : certaines villes, produits, variantes ou sources d’acquisition plus risquées — à vérifier sur volume suffisant.
Calculer le taux de refus (formule)
Avant d’agir, mesurez. Sur une plage de dates (cohorte de commandes créées, created_at), définissez clairement le numérateur.
Dans COD Delivery Insights, la métrique refused_returned_orders (et refused_rate_pct) regroupe des libellés refus et retour pour le KPI — utile en tendance, mais ce n’est pas un « refus pur » isolé. Pour isoler le refus à la porte, croisez aussi les libellés transporteur dans le module livraison.
Formule opérationnelle simple (à documenter en interne) :
- Choisir une période comparable (ex. 30 jours calendaires).
- Compter le total des commandes créées sur la période.
- Compter les échecs selon la définition choisie (KPI regroupé OU libellés « refusé » seuls).
- Calculer le taux et le noter avec la définition utilisée.
- Ne pas comparer deux périodes si la définition du numérateur a changé.
| Élément | Définition |
|---|---|
| Cohorte | Commandes créées entre date début et date fin |
| Total | Nombre de commandes de la cohorte (total_orders) |
| Refusés / retournés (KPI) | refused_returned_orders — classification KPI ERP-STOK |
| Taux KPI | refused_rate_pct = refused_returned_orders ÷ total_orders × 100 |
| Livraison réussie | delivery_rate_pct = delivered_orders ÷ total_orders × 100 (delivery_status = delivered) |
Pourquoi le taux global seul ne suffit pas
Un taux national ou « toutes villes » cache des réalités opposées : une ville ou une variante peut tirer le taux vers le haut pendant que le reste est stable.
Un petit échantillon trompe : 2 refus sur 4 commandes = 50 %, sans signification opérationnelle. Pour les classements « pires villes », COD Insights exige au minimum 10 commandes (WORST_CITY_MIN_ORDERS).
Le regroupement refus + retours dans le KPI peut augmenter le numérateur par rapport à un refus « à la porte » seul — lisez toujours la définition avant de décider.
Analyser par ville, produit, variante, agent et transporteur
Segmentez pour trouver où agir — sans inventer de causalités sur 3 commandes.
| Dimension | Ce que permet réellement ERP-STOK | Limite |
|---|---|---|
| Ville | COD Insights : volumes, livrés, pires villes par taux refus/retour (≥ 10 commandes) | Normalisation ville (override / customer / provider) ; petit volume exclu |
| Produit / variante | Top produits/variantes livrés ; patterns retours via guides dédiés | Pas de classement Insights « refus pur par SKU » garanti |
| Agent confirmation | File, notes, historique, charge ; leaderboards confirmation (Team Performance) | Pas de KPI Insights « refus par agent de confirmation » |
| Agent d’envoi | Team Performance : envois (sent_to_delivery_by), livrés, retournés | Mesure l’envoi, pas la qualité d’appel |
| Transporteur | Filtres En livraison par prestataire configuré ; libellés sync | Pas de widget Insights « pire transporteur » dédié |
| Source d’acquisition | Champ source sur la commande (ex. boutique, Sheets) + export / filtres ops | COD Insights ne publie pas de taux refus par source ads/UTM |
Plan d’action pratique pour réduire les refus
Traitez d’abord les leviers contrôlables avant l’envoi. Aucune étape ne « garantit zéro refus ».
- Semaine 1 — Mesurer : cohorte 30 jours, noter taux KPI et (si possible) volume de libellés « refusé » seuls.
- Semaine 1 — Script confirmation : montant COD total, contenu/variante, ville, téléphone, délai annoncé ; note obligatoire.
- Semaine 2 — Qualité données : corriger faux numéros, villes, doublons avant envoi transporteur.
- Semaine 2 — Files : relances planifiées (rappel_plus_tard) ; ne pas envoyer les commandes encore douteuses.
- Semaine 3 — Segmentation : lire pires villes (≥ 10 cmd) et variantes à risque ; adapter le script ou la promesse produit.
- Semaine 3 — Suivi livraison : filtrer En livraison, noter les blocages, distinguer refus vs return_pending_scan.
- En continu — Retours : scanner puis valider en entrepôt ; ne pas restaurer le stock au seul statut portail.
- En continu — Comparer deux cohortes comparables après un changement de script — sans promesse de %.
- Montant COD répété à chaque confirmation.
- Variante / taille / couleur vérifiées sur les lignes.
- Téléphone et ville corrigés avant envoi.
- Doublons et faux numéros stoppés en confirmation.
- Notes agent lisibles pour le shift suivant.
- Seuil d’échantillon respecté avant de « blacklister » une ville.
Comment ERP-STOK aide à appliquer et suivre le process
ERP-STOK ne remplace pas le jugement ops : il centralise les étapes où les refus se préviennent et se mesurent.
Confirmation : assignation multi-agents, statuts d’appel, notes, relances planifiées — avant tout envoi transporteur.
Livraison : envoi aux intégrations configurées, suivi par polling, filtres (transporteur, ville, agent), vues livrés / retours.
Stock : déduction au ramassé ; retours via scan de session puis validation — pas au seul signal provider.
COD Delivery Insights (lecture seule) : total_orders, delivered_orders, refused_returned_orders, delivery_rate_pct, refused_rate_pct, tendances journalières, villes et top produits/variantes livrés.
Exemple fictif
Exemple illustratif (fictif) — calcul et action
Boutique fictive « Atlas Home » (Casablanca), cohorte 30 jours : 200 commandes créées. COD Insights affiche 120 delivered (delivery_rate_pct = 60 %) et 40 refused_returned_orders (refused_rate_pct = 20 %). Sur les libellés bruts, l’équipe compte 28 « refusé » à la porte et 12 retours déjà en transit — le KPI 20 % mélange les deux. Les « pires villes » Insights listent une ville à 18 commandes et taux élevé ; une autre à 6 commandes est ignorée (seuil 10). Action : script confirmation avec montant COD + taille, correction téléphone avant envoi. Aucun pourcentage de baisse n’est promis ; on recompare une cohorte de 30 jours plus tard avec la même définition.
Où trouver ces leviers dans ERP-STOK
File confirmation : statuts, assignation, notes, rappels planifiés.
Module livraison : delivery_status, libellés sync, filtres prestataire / ville / agent.
COD Delivery Insights : summary, tendances refus/retour, pires villes (≥ 10 commandes), export CSV.
Team Performance : volumes confirmation et performance des envois par utilisateur (sent_to_delivery_by).
Retours : return_pending_scan → scan session → validation ; stock restauré après validation, pas au seul statut portail.
Pour conclure
Réduire les colis refusés commence par une définition claire (refus ≠ retour validé), un calcul documenté, puis des actions de confirmation et de données client.
Segmentez avec prudence d’échantillon ; utilisez ERP-STOK pour exécuter et mesurer le process — sans attendre une promesse de taux.
Limites et points d’attention
- Aucune garantie de zéro refus ni de réduction chiffrée.
- refused_returned_orders regroupe refus et retours pour le KPI.
- Libellés et délais dépendent du transporteur et du polling.
- Pas de classement Insights refus par source d’acquisition ads/UTM.
- Le détail du flux retour entrepôt est traité dans les guides retours / échanges.