Un acheteur renvoie deux lignes d’une commande multi-seller dans le même colis. L’étiquette pointe vers l’entrepôt opérateur, mais l’un des produits devait retourner au vendeur et l’autre vers un centre de contrôle. Le colis arrive, personne ne sait l’ouvrir dans le système et le remboursement reste bloqué.
Le problème n’est pas uniquement l’étiquette. Motif, propriété du stock, dangerosité, responsabilité, coût, capacité de contrôle et règle de remboursement ont été décidés séparément. Le transport devient une boîte noire entre une demande client et une dette financière.
Le vrai enjeu du routage des retours dans une marketplace opérateur est d’envoyer chaque unité vers l’acteur capable de la recevoir et de produire la preuve attendue. Contre-intuitivement, centraliser tous les colis peut augmenter coût, délai et erreurs.
Vous allez comprendre comment qualifier policy, dossier, responsabilité, destination, transport, réception et remboursement, puis réconcilier chaque étape. Les décisions restent versionnées, les appels idempotents, et monitoring, files d’exception, canary et rollback évitent les colis orphelins.
Définir la décision de routage
Séparer route et résolution
La route décide où et comment l’unité voyage ; la résolution décide remboursement, échange, réparation ou refus. Elles se coordonnent mais ne se confondent pas. Un remboursement immédiat peut être autorisé avant réception sans changer la destination du produit.
Chaque route indique destinataire, service, délai, preuve, coût et fallback. Le dossier conserve la policy appliquée. Une adresse imprimée n’explique ni pourquoi elle a été choisie ni qui doit agir à l’arrivée.
Attribuer les obligations
L’acheteur emballe et remet, le transporteur achemine, le destinataire réceptionne, un acteur contrôle et finance rembourse. Seller, opérateur ou partenaire peuvent porter chaque rôle. Le contrat ferme les combinaisons autorisées.
Le support voit prochaine action, owner et SLA. Il ne demande pas au client d’appeler le seller si l’opérateur possède la décision. Les escalades suivent l’obligation en retard, pas le dernier message reçu.
Écrire la policy de retour
Définir conditions et branches
Pays, catégorie, motif, délai, état, valeur, seller et mode de fulfillment déterminent le parcours. La policy retourne éligible, preuves requises, route et résolution possible. Les spécialistes compétents valident les droits applicables selon le contexte.
Chaque version porte date d’effet et population. Une commande conserve la règle contractuelle pertinente. Les exceptions commerciales possèdent approbation et expiration ; elles ne deviennent pas une route permanente cachée.
Borner coût et responsabilité
La policy indique qui finance transport, contrôle, remise en stock et perte. Le coût attendu peut orienter vers remboursement sans retour pour un faible montant, si sécurité et risque le permettent.
Si le coût retour dépasse la valeur récupérable, alors une branche alternative est proposée. Elle reste auditée et ne s’applique pas aux produits dangereux, réglementés ou nécessitant destruction contrôlée.
La simulation applique la policy à trente dossiers réels et compare route, coût, remboursement et responsabilité au traitement historique. Les divergences sont classées attendues ou bloquantes. Si une branche augmente le délai client de plus de deux jours sans gain suffisant, alors elle est rejetée ou limitée à une population mieux ciblée.
Qualifier le dossier
Identifier lignes et unités
La demande sélectionne commande, ligne, quantité et unité sérialisée éventuelle. Un panier multi-seller devient plusieurs dossiers ou colis selon compatibilité. Le système ne route pas au niveau commande globale.
Les identifiants produit, offre, seller, lot et numéro de série restent ceux du snapshot commandé. Une correction du catalogue ne transforme pas l’unité retournée. Les photos et documents portent source et droits.
Structurer motif et état déclaré
Le motif utilise codes et questions adaptatives. Taille, panne, dommage transport, erreur de référence et rétractation demandent des preuves différentes. Un champ libre complète sans remplacer la qualification.
Les réponses servent route et contrôle, mais restent déclaratives. Le destinataire confirme ensuite l’état. Le système distingue divergence de bonne foi et signal d’abus selon une policy séparée.
Une validation empêche quantité supérieure à la commande, numéro de série inconnu ou produit déjà remboursé de passer en self-service. Le dossier conserve les éléments refusés. Si l’identité peut être corrigée par une preuve, alors un reviewer modifie la qualification avec audit ; il ne recrée pas une seconde demande sans lien.
Identifier origine et responsabilité
Relier fulfillment et seller
Le vendeur de l’offre, le propriétaire du stock, l’expéditeur et le responsable du service peuvent différer. Le snapshot de commande conserve ces rôles. La route ne déduit pas le destinataire depuis l’adresse d’expédition seule.
Une offre fulfilled by operator peut revenir à l’entrepôt, tandis qu’un seller-fulfilled revient au vendeur ou à un hub. Les contrats et capacités actuelles déterminent la décision avec fallback.
Qualifier la cause avant allocation
Produit défectueux, mauvaise préparation, dommage transport et changement d’avis répartissent les coûts différemment. Le motif initial reste provisoire jusqu’au contrôle. La responsabilité finale crée un verdict et des mouvements.
Scénario : le carton arrive intact mais la référence ne correspond pas à la commande. Si le contrôle confirme erreur de préparation, alors les coûts portent l’acteur responsable. Ils ne sont pas automatiquement déduits du seller si l’opérateur préparait.
Choisir la destination
Maintenir un référentiel de capacités
Entrepôt, seller, atelier, centre de contrôle, recyclage et destruction possèdent zones, catégories, dimensions, dangerosité, calendrier et capacité. Une adresse active ne signifie pas qu’elle accepte ce produit.
Les capacités sont versionnées avec date et owner. Saturation ou fermeture temporaire retire la route pour les nouvelles demandes. Les dossiers déjà étiquetés suivent un plan de continuité explicite.
Optimiser sans casser la preuve
Coût, distance, délai, valeur récupérable et qualité de contrôle participent à la décision. L’option la moins chère n’est pas choisie si elle retarde le remboursement ou expose un produit.
Le moteur conserve candidats, exclusions et gagnant. Si deux destinations sont équivalentes, alors une règle stable répartit la charge. Le seller comprend la route sans accéder aux capacités concurrentes sensibles.
Le plan de continuité définit une destination secondaire par famille et pays. Sa capacité est testée avant incident. Si le site principal ferme après émission d’un label, alors les colis non déposés reçoivent une nouvelle instruction ; les colis en transit suivent une redirection confirmée avec le transporteur, jamais une adresse changée seulement dans la base.
Fermer l’éligibilité logistique
Vérifier produit et transport
Batterie, liquide, température, taille, valeur et pays peuvent interdire un service standard. Le moteur combine classification produit, colis et restrictions transporteur. Une étiquette ne doit pas être générée puis rejetée au dépôt.
Les données manquantes produisent une revue ou une collecte complémentaire. Le système ne suppose pas « non dangereux » pour préserver le self-service. Les raisons indiquent l’action et le délai.
Composer les colis compatibles
Plusieurs unités partagent un colis seulement si destination, service, contraintes et preuve sont compatibles. Le regroupement conserve contenu attendu. Un colis multi-dossiers possède un manifeste scannable.
Si deux lignes vont vers des destinations différentes, alors l’interface génère deux instructions et explique pourquoi. Elle n’imprime pas une seule étiquette tout en demandant au hub de redistribuer sans mandat.
Par exemple, une batterie et un textile de la même commande ne partagent pas forcément service ni emballage. Si le transporteur standard refuse la batterie, alors deux colis sont créés avec preuves et coûts distincts. L’acheteur voit les deux dépôts, tandis que finance sait quel acteur supporte chaque étiquette.
Créer une instruction exécutable
Générer label et manifeste
L’étiquette porte service, tracking, destination et expiration ; le manifeste relie colis, dossiers et unités. Les appels transporteur utilisent idempotency key. Un retry retrouve la même expédition ou annule proprement l’ancienne.
Les entrées du service sont route, colis, service et identité ; ses sorties sont label, tracking, instructions ou rejet. Returns reste owner de la route, Logistics du contrat et Platform de l’intégration. L’instrumentation suit retries, seuils, dépendances et erreurs.
Donner des consignes adaptées
Emballage, dépôt, enlèvement, documents et date limite varient selon produit et pays. L’acheteur reçoit des étapes courtes et localisées. Une consigne générique ne couvre pas un produit fragile ou réglementé.
Le point de dépôt est vérifié au moment de l’affichage. Les alternatives restent consultables. Si le label expire, alors une régénération revalide route et policy au lieu de seulement changer la date.
Le manifeste encode aussi poids attendu, nombre d’unités et contrôles particuliers. À la réception, un scan retrouve immédiatement le dossier. Si le transporteur retourne un label sans service réellement disponible dans la zone, alors l’intégration rejette la réponse et sélectionne un fallback ; elle ne laisse pas l’acheteur découvrir l’erreur au dépôt.
Suivre le transport retour
Normaliser les événements
Created, dropped_off, in_transit, exception, delivered et lost sont mappés depuis les transporteurs avec occurrence et source. Un webhook hors ordre ne fait pas revenir un colis livré à in_transit.
Les statuts servent promesse et SLA. Le support voit événement brut et état normalisé. Les doublons sont dédupliqués. Une absence de scan déclenche une enquête après seuil, pas un remboursement refusé automatiquement.
Gérer perte et preuve de dépôt
Ticket de dépôt, scan, collecte et poids peuvent prouver la prise en charge. La policy définit ce qui suffit. L’acheteur n’est pas rendu responsable d’un silence transporteur après preuve valide.
Si aucun événement n’arrive 48 heures après dépôt confirmé, alors Logistics ouvre le dossier et la résolution client suit la protection prévue. Le coût est rapproché au transporteur ou à l’acteur responsable après enquête.
La réconciliation quotidienne compare labels créés, premiers scans, livraisons et colis reçus. Chaque rupture possède âge, valeur et owner. Si plus de 0,3 % des labels déposés restent sans scan après le SLA, alors les nouveaux labels du service concerné sont limités et le transporteur doit fournir un plan de correction.
Contrôler la réception
Scanner colis et contenu
La réception identifie tracking, manifeste, unités et écarts. Un colis sans dossier rejoint une file d’orphelins avec photos, poids et localisation. Il n’est pas posé dans une zone physique sans enregistrement.
La preuve porte date, site, opérateur et état extérieur. L’ouverture compare contenu attendu. Une réception partielle conserve les unités manquantes et déclenche le bon SLA.
Produire un verdict de contrôle
Conforme, endommagé, incomplet, mauvais produit, utilisé ou non contrôlable s’appuient sur critères par famille. Photos et mesures sont gouvernées. Un avis libre ne suffit pas pour refuser un remboursement sensible.
Les entrées du contrôle sont unité, motif, critères et preuves ; ses sorties sont verdict, responsabilité, valeur récupérable et action. Warehouse reste owner de l’observation, Returns de la policy et Finance de l’effet. Monitoring et files suivent les délais.
Un échantillon à double lecture mesure la cohérence des verdicts par site et famille. Si l’accord tombe sous 95 %, alors les décisions sensibles nécessitent un second reviewer et une formation ciblée. Les photos de référence, critères et versions sont mis à jour avant que le site retrouve son autonomie complète.
Déclencher le remboursement
Choisir le bon événement
Le remboursement peut partir à la demande, au dépôt, à la livraison ou après contrôle selon risque et droits. Le déclencheur est annoncé et versionné. Une réception technique ne bloque pas une policy de remboursement anticipé.
Montant, taxes, livraison, frais et commission sont calculés par ligne. Le snapshot cite financeur et raison. Les appels PSP et ledger restent idempotents et réconciliés.
Traiter divergence et recours
Si le contrôle contredit le motif, alors la décision suit policy avec preuves et possibilité de recours. Le client voit faits et conséquence. Le seller peut contester une responsabilité attribuée.
Par exemple, un produit déclaré neuf arrive utilisé. Le reviewer vérifie preuves de départ et réception avant de réduire le remboursement. Toute correction crée un mouvement compensatoire et conserve le verdict initial.
Le rapprochement financier associe demande, montant autorisé, appel PSP, mouvement ledger et financement seller ou opérateur. Une divergence au centime bloque la clôture du dossier, pas l’enquête entière. Le retry réutilise la clé du remboursement ; un timeout ne peut pas déclencher un second versement.
Piloter coût et incidents
Mesurer la chaîne complète
Le dashboard suit demandes, routes, labels, dépôts, transport, réception, contrôle, remboursement, coût et valeur récupérée. Il ventile seller, catégorie, destination et cause. Les percentiles révèlent les colis durablement bloqués.
Le coût business inclut transport, manutention, remboursement, perte, support et stock immobilisé. Une route moins chère mais lente peut coûter davantage. Chaque seuil possède owner, population et action.
Déployer en shadow et rollback
Une nouvelle policy calcule en shadow sur dossiers historiques et entrants. Le canary limite catégories et destinations. L’équipe compare coût, délais, éligibilité et responsabilité.
Si plus de 0,5 % des colis deviennent orphelins ou si le délai de remboursement dépasse le garde-fou, alors le go est refusé. Le rollback restaure routes et labels des nouvelles demandes sans détourner les colis déjà expédiés.
La revue mensuelle relie aussi coûts de transport, valeur récupérée, avoirs et contacts support à chaque route. Trois incidents identiques sur une destination deviennent un correctif avec owner et échéance. La réouverture exige réception témoin, scan complet et délai sous seuil sur deux cohortes consécutives.
Adapter la méthode et éviter les erreurs
Pour qui le routage des retours convient
Il devient nécessaire lorsque plusieurs sellers, fulfilments, catégories ou destinations coexistent. Une petite plateforme peut commencer par une route seller et une route opérateur, mais doit déjà conserver dossier, label et preuve.
Returns possède policy ; Catalogue classification ; Logistics transport ; Warehouse contrôle ; Finance remboursement ; Support recours. Chaque partenaire déclare ses capacités et SLA avant activation.
Erreurs fréquentes du routage des retours
Router au niveau commande, utiliser l’adresse d’expédition, mélanger produits incompatibles, générer avant éligibilité, clore au scan transporteur, rembourser sans ligne et oublier les colis orphelins sont les erreurs majeures.
Une autre erreur consiste à centraliser sans mesurer coût et capacité. Enfin, une étiquette ne constitue pas une policy. Sans destination capable, preuve attendue et owner, elle déplace seulement le problème.
Plan d’action pour router les retours
Semaines 1 à 4 : policy et capacités
La première semaine rapproche vingt retours de bout en bout. La deuxième ferme motifs, lignes, responsabilités, destinations, coûts et déclencheurs. Returns, sellers, logistique et finance valident les branches. Une revue chiffre colis orphelins, délai de remboursement et pertes par route, puis attribue chaque donnée ou capacité manquante à un owner avant la construction.
Les semaines trois et quatre construisent référentiel, moteur et manifeste. Les tests couvrent multi-seller, dangerosité, colis groupé, label dupliqué, perte, réception partielle et remboursement anticipé. Chaque dossier garde une prochaine action.
La recette suit ensuite dix dossiers physiques depuis la demande jusqu’au mouvement financier. Returns vérifie la route, Logistics les scans, Warehouse le contrôle et Finance le remboursement. Chaque colis doit être retrouvé par tracking comme par ligne ; tout écart obtient owner, échéance et preuve de correction avant le canary, sans tableur ou rapprochement verbal parallèle.
Semaines 5 à 8 : canary et réconciliation
La cinquième semaine exécute en shadow. La sixième ouvre un canary sur une catégorie. L’instrumentation suit routes, coûts, scans, orphelins, délais et remboursements avec seuils, owners et runbooks.
Les semaines sept et huit provoquent destination fermée, événement hors ordre et rollback, puis réconcilient colis et ledger. Le go exige route exécutable, réception traçable et remboursement sous SLA.
Le dossier final conserve policies, capacités, classifications, fixtures, labels, preuves, mouvements et procédures. Toute unité retournée possède une destination, un contrôle attendu et une résolution. Toute exception possède owner et échéance.
- À faire d’abord : fermer motifs, lignes, destinations et responsabilités.
- À tester ensuite : colis groupé, perte, contrôle, remboursement et rollback.
- À différer : les optimisations sans capacité de réception prouvée.
- À refuser : toute étiquette sans policy, manifeste et événement de résolution.
Ressources complémentaires pour l’opérateur
Structurer catalogue et pilotage
Le catalogue PIM marketplace fournit les classifications de routage.
Les écrans du back-office opérateur rendent dossiers et recours consultables.
Borner les premières routes
Le MVP marketplace avant ouverture aide à limiter les partenaires initiaux.
La méthode pour ouvrir une première catégorie fournit une cohorte de retours maîtrisée.
Conclusion : router une obligation
Le routage transforme une demande de retour en destination, transport, contrôle et résolution financière explicites.
Policy versionnée, manifeste rapproché et preuve empêchent les unités de disparaître entre seller, hub et transporteur, même lorsqu’un événement arrive tardivement ou qu’une destination ferme pendant le trajet.
Réconciliation, recours et rollback gardent chaque dossier actionnable jusqu’au remboursement ou à sa clôture prouvée.
Dawap peut vous accompagner pour construire cette orchestration dans votre marketplace opérateur.
