Mise à jour du cycle de retour (Closed Loop Return Update)

Aperçu

Les mises à jour de statut et d'action ZigZag permettent aux retailers d'informer ZigZag lorsqu'un retour a été reçu, traité ou évalué. Elles garantissent l'exactitude de la chronologie du retour et contribuent à la fiabilité des réclamations, des rapports opérationnels, de la prévention de la fraude et de l'analyse du comportement des clients.

info

La fonctionnalité Closed Loop Return Update est également appelée Closed Loop Scans dans le contexte opérationnel.

Qu'est-ce qu'une Closed Loop Return Update ?

Une Closed Loop Return Update est un événement envoyé à ZigZag par un retailer, un entrepôt, un WMS, un OMS ou ZigZag RMS pour confirmer qu'un colis retourné a été reçu et, le cas échéant, traité.

Elle boucle le cycle du retour en confirmant ce qui s'est passé après que le client a renvoyé le colis. Cela peut inclure la réception par le retailer, le traitement du remboursement, l'évaluation des articles, leur remise en vente, leur rejet, leur destruction ou l'exécution d'une commande.

Ce que cela signifie en pratique

Le client renvoie le colis. Le transporteur peut le scanner. Le retailer le reçoit. Le retailer informe ensuite ZigZag : "Nous avons reçu le colis, et voici ce qui s'est passé ensuite." Cette mise à jour permet de boucler le cycle du retour.

Ces mises à jour sont parfois appelées Closed Loop Scans, mais elles ne doivent pas nécessairement provenir d'un scan physique. Elles peuvent être générées lors de la réception dans un entrepôt, par un événement WMS, un workflow OMS, une action RMS, une intervention du service client ou un processus d'évaluation au niveau des articles.

Pourquoi est-ce important ?

Les Closed Loop Return Updates permettent à ZigZag de ne pas dépendre uniquement du suivi des transporteurs. Les scans des transporteurs peuvent être retardés, manquants ou incomplets. L'entrepôt du retailer, son WMS, son OMS ou ZigZag RMS peuvent savoir qu'un colis est arrivé avant que les données du transporteur ne le confirment complètement.

• Suivre l'intégralité du parcours, de l'initiation du retour jusqu'à son traitement.
• Enregistrer le moment où le colis est reçu dans les opérations du retailer.
• Enregistrer les événements d'évaluation, de remise en vente, de destruction ou d'exécution d'une commande après réception.
• Réduire les réclamations erronées causées par des séquences de scans incomplètes des transporteurs.
• Mesurer les performances des transporteurs par rapport aux SLA convenus.
• Mesurer le délai entre la livraison à l'entrepôt et le traitement du remboursement.
• Suivre le comportement des clients et le Keep Rate, qui mesure la proportion d'articles conservés par un client par rapport à ceux qu'il achète.
• Entraîner de futurs modèles d'aide à la décision à partir des résultats historiques des retours, au niveau des clients et des articles.
• Améliorer la prévention de la fraude, le traitement des réclamations et les rapports opérationnels.

Comment fonctionne le processus ?

1. Le retour est initié via ZigZag, le transporteur ou le parcours de retour du retailer.
2. Le client renvoie le colis.
3. Le colis est reçu par l'entrepôt du retailer, son WMS, son OMS ou ZigZag RMS.
4. Le retailer transmet un statut de réception à ZigZag, tel que DeliveredToRetailer.
5. ZigZag enregistre le nouveau jalon opérationnel dans la chronologie du retour.
6. Le retailer peut ensuite transmettre des actions supplémentaires, telles que le traitement, l'acceptation, le rejet, l'évaluation, la remise en vente, la destruction ou l'exécution d'une commande.
7. Si nécessaire, le retailer peut transmettre les résultats au niveau des articles pour chaque unité d'un même retour.

Options de mise à jour prises en charge

Endpoint	Méthode	Utilisation recommandée	Remarques
/api/v1/Returns/ChangeStatus	POST	Indiquer que le retour a été reçu par le retailer ou le faire passer à un état opérationnel clé	Idéal pour les mises à jour simples de réception, telles que DeliveredToRetailer.
/api/v1/Returns/ChangeAction	POST	Mettre à jour le retour après son traitement par l'entrepôt	Utile pour les actions telles que Processed, Accepted, Rejected, Resell, Fulfill ou Destroy.
/api/v1/Returns/ChangeActionPerUnit	POST	Mettre à jour les résultats au niveau des articles d'un même retour	Idéal lorsque chaque unité nécessite son propre résultat ou statut de traitement.
/api/v1/Returns/{returnId}/CustomProperties	POST	Ajouter des champs spécifiques au retailer	À utiliser pour les notes d'évaluation, les références internes, les métadonnées de réclamation ou d'autres données définies par le retailer.

Exemple de modification de statut

Utilisez cet endpoint lorsque le retailer souhaite confirmer que le colis a été reçu dans ses propres opérations. Endpoint: POST /api/v1/Returns/ChangeStatus

{
  "orderStatus": "DeliveredToRetailer",
  "returnId": "NL000-1-HM61FG6434445",
  "returnUniqueIdentifier": null,
  "externalStatusCode": null,
  "externalReasonCode": null
}

Exemple de parcours de retour

Un client retourne trois articles. Le suivi du transporteur indique toujours que le colis est en transit, mais l'entrepôt du retailer l'a déjà reçu.

Le retailer envoie à ZigZag une mise à jour DeliveredToRetailer. ZigZag sait désormais que le colis est revenu chez le retailer, même si le transporteur n'a pas encore transmis le scan final de livraison.

Plus tard, le retailer transmet les résultats au niveau des articles :

• Article 1 - Accepté et remboursé.
• Article 2 - Rejeté en raison de signes d'usure.
• Article 3 - Accepté et remis en stock.

Cela permet à ZigZag de disposer d'une vue complète du parcours de retour et du résultat opérationnel de chaque unité.

Approche de mise en œuvre recommandée

• Envoyez un statut de réception dès que le colis est physiquement reçu ou identifié dans les opérations du retailer.
• Utilisez ChangeStatus pour les jalons simples au niveau du retour, tels que DeliveredToRetailer.
• Utilisez ChangeAction lorsque le retour a été traité dans son ensemble.
• Utilisez ChangeActionPerUnit lorsque le retour contient plusieurs articles ayant des résultats différents.
• Utilisez CustomProperties pour les notes d'évaluation spécifiques au retailer, les références internes, les métadonnées de réclamation ou les champs d'audit supplémentaires.
• Évitez de vous fier uniquement aux scans des transporteurs lorsque le retailer dispose de données d'entrepôt plus précises.
• Veillez à utiliser des noms de statuts et d'actions cohérents entre les différents environnements afin de préserver la qualité des rapports.

Avantages pour les données et les rapports

Les Closed Loop Return Updates permettent de produire des rapports opérationnels plus précis en reliant la demande de retour initiale, le parcours du transporteur, la réception à l'entrepôt et le résultat final du traitement.

Domaine	Avantages
Réclamations	Permet d'identifier les colis reçus malgré l'absence d'un scan du transporteur.
Prévention de la fraude	Améliore les données historiques au niveau des clients utilisées pour détecter les comportements de retour suspects.
Performance des transporteurs	Compare les événements de livraison définis par les SLA des transporteurs aux événements de réception des retailers.
Performance des entrepôts	Mesure les délais entre la réception, l'évaluation et le traitement du remboursement.
Analyse du comportement des clients	Facilite l'analyse du Keep Rate et le suivi global du comportement des clients.
Entraînement des modèles	Fournit des données plus fiables sur les résultats pour les futurs modèles d'aide à la décision et d'évaluation des risques.

Remarque sur la terminologie

Note

Utilisez "Closed Loop Return Update" dans les communications externes.

Ce terme est plus large et plus clair que Closed Loop Scan, car l'événement peut provenir d'un scan, d'une réception en entrepôt, d'un processus WMS, d'une action OMS, d'une mise à jour RMS ou d'un événement d'évaluation au niveau des articles.

Pour les équipes internes ou opérationnelles, le terme Closed Loop Scan peut toujours être utilisé comme abréviation familière, à condition que la documentation technique précise qu'un scan physique n'est pas obligatoire.

Résumé

Une Closed Loop Return Update confirme qu'un retour est parvenu au retailer et enregistre ce qui s'est passé ensuite. Elle permet à ZigZag de disposer d'une chronologie complète et précise du retour et contribue à la fiabilité des remboursements, à la réduction des réclamations, à la mesure du respect des SLA des transporteurs, aux rapports sur les performances des entrepôts, à la prévention de la fraude et à l'analyse du comportement des clients.