Votre modèle de données pour le traitement des retours et des remboursements
Votre modèle de données pour le traitement des retours et des remboursements
- Attributs recommandés à collecter
- Activités clés à suivre
- Guide d’extraction pour Salesforce Commerce Cloud
Attributs du traitement des retours et des remboursements
| Nom | Description | ||
|---|---|---|---|
|
Heure de l’événement
EventTime
|
Horodatage indiquant quand l’activité ou l’événement concerné s’est produit. | ||
|
Description
L’heure de l’événement indique la date et l’heure exactes auxquelles une activité a été exécutée ou un changement de statut s’est produit. Cet horodatage est essentiel pour ordonner correctement les événements et réaliser toute analyse temporelle. Le Process Mining s’appuie sur ces horodatages pour ordonner les activités, calculer les temps de cycle et les temps d’attente entre les étapes, et analyser les performances du processus sur différentes périodes. Des horodatages exacts sont indispensables à une analyse fiable des processus.
Pourquoi est-ce important ?
Cet horodatage établit l’ordre chronologique des activités, indispensable au calcul des temps de cycle et à la détection des retards dans le processus.
Où trouver ces données
Il s’agit généralement de l’horodatage de création ou de modification d’un enregistrement dans Salesforce Commerce Cloud, par exemple « CreatedDate » ou « LastModifiedDate » pour les objets liés au processus de retour.
Exemples
2023-04-15T10:00:00Z2023-04-16T14:30:00Z2023-04-18T09:15:22Z
|
|||
|
ID du dossier de retour
ReturnCaseId
|
Identifiant unique d’un dossier de retour client, qui relie toutes les activités associées, de l’ouverture à la clôture. | ||
|
Description
L’ID du dossier de retour est l’identifiant principal qui relie toutes les activités associées à un retour client ou à une demande de remboursement. Il permet de suivre et d’analyser l’ensemble du cycle de vie du retour, de son ouverture à sa clôture définitive. En Process Mining, cet attribut est essentiel pour reconstituer les cas. Chaque événement portant le même ID de dossier de retour appartient à la même instance de processus. Vous pouvez ainsi visualiser les cartes de processus, calculer des KPI par cas, comme le temps de cycle, et analyser les variantes du processus de retour.
Pourquoi est-ce important ?
Cette clé principale relie toutes les étapes d’un retour au sein d’un même dossier traçable, indispensable à l’analyse du processus de bout en bout.
Où trouver ces données
Cet identifiant est généralement généré par le processus d’autorisation de retour de marchandise (RMA) dans Salesforce Commerce Cloud. Il figure souvent sur l’objet Return Order ou Case.
Exemples
RT-0012345RT-0012346RT-0012347
|
|||
|
Nom de l’activité
ActivityName
|
Nom de l’étape ou de l’événement précis du processus métier qui s’est produit dans le cadre du retour. | ||
|
Description
Cet attribut décrit la tâche ou l’étape clé qui a été réalisée à un moment donné pour un dossier de retour. Exemples : « Demande de retour créée », « Article reçu à l’entrepôt » et « Remboursement traité ». En Process Mining, le nom de l’activité sert à construire la carte de processus, qui montre l’enchaînement des étapes et le parcours des dossiers. L’analyse des activités est essentielle pour repérer les goulots d’étranglement, les boucles de retour et les écarts par rapport au processus standard.
Pourquoi est-ce important ?
Il définit les étapes de la carte de processus et permet de visualiser et d’analyser le flux de travail des retours.
Où trouver ces données
Cet attribut est généralement issu des journaux d’événements, des enregistrements de changement de statut ou des données d’achèvement des tâches associées aux objets Return Order ou Case dans Salesforce.
Exemples
Demande de retour approuvéeInspection de l’article terminéeRemboursement effectué
|
|||
|
Dernière mise à jour des données
LastDataUpdate
|
Horodatage indiquant la dernière extraction ou actualisation des données depuis le système source. | ||
|
Description
Cet attribut enregistre la date et l’heure de la dernière extraction des données depuis Salesforce Commerce Cloud. Il indique à quel point les données analysées sont récentes. Cette information permet aux utilisateurs de savoir si l’analyse des processus repose sur des données à jour. Elle aide à définir les attentes concernant leur actualité et à vérifier que le jeu de données est complet.
Pourquoi est-ce important ?
Il renseigne les utilisateurs sur l’actualité des données et leur permet de savoir si l’analyse reflète l’état le plus récent du processus.
Où trouver ces données
Cet horodatage est généré par l’outil ou le script d’extraction des données lors de leur actualisation. Ce n’est pas un champ Salesforce.
Exemples
2023-05-20T02:00:00Z2023-05-21T02:00:00Z
|
|||
|
Système source
SourceSystem
|
Système d’où proviennent les données de l’événement. | ||
|
Description
Cet attribut identifie le système source dans lequel les données ont été générées. Pour ce processus, sa valeur sera toujours « Salesforce Commerce Cloud ». Dans le cadre d’une analyse plus large, ce champ est utile pour combiner des données provenant de plusieurs systèmes et comprendre le déroulement des processus sur différentes plateformes. Il assure la traçabilité des données et aide à diagnostiquer les problèmes de qualité propres à une source.
Pourquoi est-ce important ?
Il indique l’origine des données, un élément essentiel pour leur gouvernance et leur intégration depuis plusieurs systèmes d’entreprise.
Où trouver ces données
Il s’agit d’une valeur statique ajoutée lors de l’extraction et de la transformation des données. Ce n’est pas un champ Salesforce, mais une valeur définie dans le modèle de données.
Exemples
Salesforce Commerce Cloud
|
|||
|
Agent de traitement
ProcessingAgent
|
Utilisateur ou agent chargé de traiter le retour ou une activité précise du processus de retour. | ||
|
Description
Cet attribut identifie l’employé ou l’utilisateur système qui a effectué une action sur le dossier de retour, par exemple approuver la demande, inspecter l’article ou traiter le remboursement. Il peut s’agir d’un identifiant ou du nom d’un utilisateur. L’analyse de l’agent de traitement permet de comprendre les écarts de performance entre les personnes ou les équipes. Elle est essentielle au Dashboard « Performance et cohérence des agents », qui aide à repérer les besoins de formation, à équilibrer les charges de travail et à harmoniser les procédures dans l’organisation.
Pourquoi est-ce important ?
Il permet d’analyser les performances et la cohérence entre les différents utilisateurs, afin de repérer les bonnes pratiques et les besoins de formation.
Où trouver ces données
On le trouve généralement dans des champs tels que « OwnerId » ou « LastModifiedById » des objets Case ou Return Order dans Salesforce. Il peut aussi être enregistré dans des objets de tâche ou d’historique associés.
Exemples
Alice SmithBob JohnsonAutomatisation système
|
|||
|
Canal de retour
ReturnChannel
|
Canal utilisé pour lancer le retour, par exemple en ligne, en magasin ou auprès du service client. | ||
|
Description
Cet attribut indique la méthode utilisée par le client pour lancer le processus de retour. Parmi les canaux courants figurent un portail libre-service en ligne, le dépôt de l’article dans un magasin ou la prise de contact avec un représentant du service client. La connaissance du canal de retour est importante pour le Dashboard « Tendances du volume et du débit de traitement des retours ». Elle aide à répartir les ressources efficacement et à déterminer si certains canaux sont associés à des temps de cycle plus longs, à des motifs de retour différents ou à des coûts de traitement plus élevés.
Pourquoi est-ce important ?
Il permet de segmenter les données de retour pour comprendre les différences de processus et les besoins en ressources selon les canaux, par exemple en ligne ou en magasin.
Où trouver ces données
Il peut s’agir d’un champ de l’objet Return Order ou Case, ou d’une information déduite de l’utilisateur ou du système ayant créé l’enregistrement du retour.
Exemples
Portail en ligneEn magasinAppel au service client
|
|||
|
Montant du remboursement demandé
RequestedRefundAmount
|
Montant du remboursement demandé par le client au moment de l’ouverture du retour. | ||
|
Description
Cet attribut indique le montant initial que le client s’attend à recevoir, généralement égal au prix de l’article retourné. Il sert de référence pour le calcul du remboursement. Ce montant est comparé au « Montant réel du remboursement » dans le Dashboard « Analyse des écarts de remboursement ». Des écarts importants ou fréquents peuvent révéler des problèmes liés aux politiques de retour, aux frais de remise en stock ou aux erreurs de calcul du système, et entraîner une insatisfaction des clients.
Pourquoi est-ce important ?
Il sert de référence pour comparer le montant final du remboursement, repérer les écarts et analyser l’incidence financière des ajustements.
Où trouver ces données
Cette valeur est généralement enregistrée dans l’objet Return Order ou Return Order Line Item et calculée à partir de la commande de vente d’origine.
Exemples
49.99125.0089.50
|
|||
|
Montant réel du remboursement
ActualRefundAmount
|
Montant final effectivement remboursé au client. | ||
|
Description
Cet attribut correspond au montant final crédité au client, une fois toutes les évaluations, déductions et tous les calculs terminés. Il peut différer du montant demandé en raison, par exemple, de frais de remise en stock, de promotions ou de l’état de l’article retourné. L’analyse de cet attribut est essentielle au rapprochement financier et au Dashboard « Analyse des écarts de remboursement ». Elle permet de quantifier l’incidence financière des politiques de retour et de repérer les problèmes systémiques liés au calcul et à l’approbation des remboursements.
Pourquoi est-ce important ?
Il s’agit du résultat financier final du retour. La comparaison avec le montant demandé révèle l’incidence financière des politiques de retour et des ajustements.
Où trouver ces données
Cette valeur est généralement enregistrée dans un objet Refund ou Payment Transaction associé à l’objet Return Order dans Salesforce Commerce Cloud.
Exemples
49.99115.000.00
|
|||
|
Motif du retour
ReturnReason
|
Motif indiqué par le client pour le retour de l’article. | ||
|
Description
Le motif du retour indique pourquoi le client a demandé un retour. Il est souvent sélectionné dans une liste prédéfinie, par exemple « Taille incorrecte », « Article endommagé » ou « N’est plus nécessaire ». Cet attribut est essentiel à l’analyse des causes profondes. L’analyse des motifs de retour permet aux entreprises de repérer les tendances liées à la qualité des produits, aux problèmes de taille ou aux descriptions inexactes. Ces constats peuvent guider les améliorations apportées au développement des produits, au marketing et à la chaîne d’approvisionnement, et ainsi réduire le nombre total de retours.
Pourquoi est-ce important ?
Comprendre pourquoi les articles sont retournés aide à repérer les causes profondes, comme les défauts des produits ou les problèmes de taille, et à réduire le nombre de retours à l’avenir.
Où trouver ces données
Il s’agit généralement d’un champ de liste de sélection sur l’objet Return Order ou Case dans Salesforce, souvent renseigné par le client au début du processus de retour.
Exemples
Taille incorrecteArticle endommagé à la réceptionMauvais article expédié
|
|||
|
SKU du produit
ProductSku
|
Unité de gestion des stocks (SKU) de l’article retourné. | ||
|
Description
Cet attribut est l’identifiant unique du produit retourné. Il permet une analyse détaillée à l’échelle de chaque produit. L’analyse des retours par SKU de produit aide à repérer ceux qui présentent un taux de retour élevé, ce qui peut révéler des problèmes de contrôle qualité, des descriptions inexactes ou des défauts de fabrication. Cette information est essentielle au Dashboard « Délai entre la réception à l’entrepôt et l’inspection », car elle peut montrer si certains types de produits prennent plus de temps à inspecter.
Pourquoi est-ce important ?
Il permet d’analyser les tendances de retour par produit et de repérer les articles présentant des problèmes de qualité ou de description.
Où trouver ces données
Cette information se trouve sur l’objet Return Order Line Item ou sur un objet associé qui relie le dossier de retour au produit concerné de la commande d’origine.
Exemples
SHIRT-BL-M-001PANTS-BK-32-004SHOE-RD-10-012
|
|||
|
Date cible du SLA de remboursement
RefundSlaTargetDate
|
Date limite à laquelle le remboursement du dossier de retour doit avoir été entièrement traité. | ||
|
Description
Cet attribut définit l’échéance de l’accord de niveau de service (SLA) pour le traitement du remboursement. Elle est généralement calculée selon des règles métier, par exemple un nombre de jours déterminé après l’approbation de la demande de retour ou la réception de l’article. Cette date sert de référence pour mesurer les performances réelles dans le Dashboard « Conformité au SLA de remboursement ». Le suivi du respect des délais contribue à offrir une expérience client cohérente et positive. Il permet aussi aux responsables de repérer les équipes ou les étapes du processus qui risquent de ne pas respecter les SLA.
Pourquoi est-ce important ?
Il définit l’objectif de performance pour le traitement des remboursements et permet de mesurer le respect du SLA ainsi que son incidence sur la satisfaction client.
Où trouver ces données
Il s’agit souvent d’un champ calculé de l’objet Case ou Return Order, établi à partir de la date de création ou d’approbation à laquelle s’ajoute un délai prédéfini, par exemple CreatedDate + 14 days.
Exemples
2023-04-29T23:59:59Z2023-05-10T23:59:59Z2023-05-15T23:59:59Z
|
|||
|
Délai entre la réception et l’inspection
ReceiptToInspectionTime
|
Durée entre la réception de l’article à l’entrepôt et la fin de son inspection. | ||
|
Description
Cette métrique calculée mesure le temps nécessaire à une étape interne importante de l’activité de l’entrepôt. Elle correspond à la différence entre les horodatages des activités « Article reçu à l’entrepôt » et « Inspection de l’article terminée ». Cette durée est au cœur du Dashboard « Délai entre la réception à l’entrepôt et l’inspection » et du KPI « Délai moyen entre la réception et l’inspection d’un article ». Son analyse aide à repérer les goulots d’étranglement dans les opérations de l’entrepôt, qui peuvent contribuer de manière importante aux retards du processus global.
Pourquoi est-ce important ?
Il aide à repérer les goulots d’étranglement internes à l’entrepôt qui retardent l’ensemble du processus de retour et ont une incidence sur les délais de remboursement et la disponibilité des stocks.
Où trouver ces données
Cette valeur est calculée lors de la transformation des données, en soustrayant l’horodatage de l’activité « Article reçu à l’entrepôt » de celui de l’activité « Inspection de l’article terminée ».
Exemples
1 jour et 2 heures3 jours et 0 heure8 heures
|
|||
|
Emplacement de l’entrepôt
WarehouseLocation
|
Identifiant de l’entrepôt ou du site où l’article retourné a été réceptionné. | ||
|
Description
Cet attribut indique le site physique où l’article retourné a été traité. Il est particulièrement utile aux entreprises qui disposent de plusieurs centres de distribution. L’analyse par emplacement de l’entrepôt peut révéler des écarts de performance entre les sites. Elle peut, par exemple, montrer si certains entrepôts ont des délais d’inspection plus longs ou déclarent plus souvent les articles comme endommagés. Ces constats aident à harmoniser les opérations et à résoudre les problèmes propres à chaque site.
Pourquoi est-ce important ?
Il permet de comparer les performances des entrepôts et de repérer les écarts de délais de traitement ou d’évaluation de la qualité.
Où trouver ces données
Cette information peut être enregistrée dans l’objet Return Order ou dans un objet d’expédition associé. Elle peut aussi être déduite de l’utilisateur qui a effectué la réception.
Exemples
WH-EAST-01WH-WEST-03WH-CENTRAL-02
|
|||
|
État de l’article
ItemCondition
|
État constaté de l’article retourné lors de son inspection à l’entrepôt. | ||
|
Description
Après réception d’un article retourné, une inspection est généralement effectuée pour en déterminer l’état. Cet attribut enregistre le résultat, par exemple « Neuf », « Usagé, revendable » ou « Endommagé ». Cette évaluation a une incidence directe sur le montant final du remboursement et constitue une donnée essentielle du Dashboard « Vue d’ensemble du respect de la politique de retour ». Son suivi aide à comprendre la qualité des articles retournés et à gérer les stocks destinés à la revente, à la remise en état ou à la mise au rebut.
Pourquoi est-ce important ?
Cette évaluation détermine souvent le montant final du remboursement et joue un rôle essentiel dans la gestion des stocks d’articles retournés.
Où trouver ces données
Il s’agit généralement d’un champ personnalisé de l’objet Return Order Line Item, mis à jour lors de l’activité « Inspection de l’article ».
Exemples
Neuf, non ouvertUsagé, comme neufEndommagé, invendable
|
|||
|
ID client
CustomerId
|
Identifiant unique du client à l’origine du retour. | ||
|
Description
Cet attribut est l’ID unique associé au compte du client. Il permet d’agréger les données de retour par client. L’analyse des retours par ID client peut aider à repérer les clients qui retournent un nombre inhabituellement élevé d’articles, ce qui peut signaler un comportement frauduleux ou une insatisfaction récurrente. Elle permet aussi d’analyser les retours par segment de clientèle et de comprendre si certains groupes ont des habitudes ou des comportements différents.
Pourquoi est-ce important ?
Il permet d’analyser les retours par client, de repérer ceux qui en effectuent souvent et de comprendre les comportements des différents segments de clientèle.
Où trouver ces données
Il s’agit d’un champ standard des objets Order et Case dans Salesforce, qui renvoie à l’objet Customer ou Account.
Exemples
CUST-98765CUST-12345CUST-55555
|
|||
|
Motif du rejet
RejectionReason
|
Motif précis du refus d’une demande de retour ou de remboursement. | ||
|
Description
Lorsqu’un retour n’est pas approuvé ou qu’un remboursement est refusé, cet attribut en indique le motif. Exemples : « Délai de retour dépassé », « Article endommagé par le client » ou « Article non retournable ». Cette information est essentielle au Dashboard « Retours rejetés et transmis à un niveau supérieur ». L’analyse des motifs de rejet aide l’entreprise à comprendre les points de friction liés à la politique et au processus de retour. Elle peut conduire à une communication plus claire avec les clients, à des ajustements de la politique ou à une meilleure vérification initiale des demandes de retour.
Pourquoi est-ce important ?
Il permet de comprendre pourquoi les retours échouent et d’améliorer les politiques de retour, la communication avec les clients et la formation des agents.
Où trouver ces données
Il s’agit souvent d’un champ personnalisé de l’objet Return Order ou Case, renseigné lorsque le statut passe à « Rejected » ou « Closed - Denied ».
Exemples
Délai de retour expiréArticle qui n’est plus dans son état d’origineArticle vendu en vente finale
|
|||
|
Respect de la politique de retour
ReturnPolicyAdherence
|
Indicateur précisant si le retour respecte les politiques établies par l’entreprise. | ||
|
Description
Cet attribut signale ou classe les retours selon leur conformité aux politiques de l’entreprise, notamment en ce qui concerne le délai de retour, l’état de l’article ou la preuve d’achat. Il peut s’agir d’un indicateur booléen (conforme/non conforme) ou d’un statut plus détaillé. Cet attribut est au cœur du Dashboard « Vue d’ensemble du respect de la politique de retour » et du KPI « Taux de non-conformité à la politique ». Il permet à l’entreprise de suivre l’application cohérente de ses politiques et d’analyser l’incidence des retours non conformes sur le processus et les finances.
Pourquoi est-ce important ?
Il permet de suivre l’application des politiques, ce qui est important pour maîtriser les coûts, prévenir la fraude et traiter les clients de manière équitable et cohérente.
Où trouver ces données
Il s’agit souvent d’un attribut dérivé de règles métier appliquées à d’autres données, comme la date du retour, l’état de l’article et le type de produit.
Exemples
ConformeNon conforme, retour tardifNon conforme, article endommagé
|
|||
|
Respect du SLA
IsSlaCompliant
|
Indicateur booléen précisant si le remboursement a été traité au plus tard à la date cible définie par le SLA. | ||
|
Description
Cet indicateur prend la valeur « true » si l’activité « Remboursement traité » a eu lieu à la date cible du SLA de remboursement ou avant, et « false » dans le cas contraire. Il fournit un résultat clair, oui ou non, pour le respect du SLA de chaque dossier. Cet attribut est à la base du Dashboard « Conformité au SLA de remboursement » et du KPI « Taux de respect du SLA de remboursement ». Il simplifie l’analyse des taux de conformité et permet d’examiner les causes du non-respect en segmentant les données selon d’autres attributs, comme l’agent de traitement ou le canal de retour.
Pourquoi est-ce important ?
Il simplifie l’analyse du respect du SLA, facilite le calcul des taux de conformité et aide à repérer les facteurs à l’origine des retards.
Où trouver ces données
Il s’agit d’un attribut calculé. La logique est la suivante : IF (Timestamp of 'Refund Processed' <= RefundSlaTargetDate) THEN true ELSE false.
Exemples
truefalse
|
|||
|
Statut du retour
ReturnStatus
|
Statut actuel du dossier de retour dans son cycle de vie. | ||
|
Description
Cet attribut indique l’état actuel du retour, par exemple « En attente d’approbation », « Articles reçus », « Remboursé » ou « Clôturé ». Il évolue au fur et à mesure de la progression du dossier dans le flux de travail. Le Process Mining reconstitue le flux à partir des activités, mais le statut actuel apporte un contexte utile pour filtrer et analyser les dossiers ouverts et clôturés. Il facilite le suivi opérationnel en indiquant le volume de dossiers en attente et la charge de travail à chaque étape du processus.
Pourquoi est-ce important ?
Il indique où en est le dossier de retour dans le processus, ce qui est utile au suivi opérationnel et au filtrage des dossiers actifs.
Où trouver ces données
Il s’agit du champ standard « Status » de l’objet Return Order ou Case dans Salesforce Commerce Cloud.
Exemples
En attente d’approbationApprouvéArticles reçusClôturé
|
|||
Activités liées au traitement des retours et des remboursements
| Activité | Description | ||
|---|---|---|---|
|
Article reçu à l’entrepôt
|
Cette activité marque la réception physique de l’article retourné à l’entrepôt ou au centre de traitement désigné. Elle est enregistrée lorsqu’un opérateur d’entrepôt scanne l’article et met à jour le statut de l’objet ReturnOrderItem associé. | ||
|
Pourquoi est-ce important ?
Cette étape marque le passage des actions du client au traitement interne. Elle sert de point de départ au calcul des indicateurs clés de performance de l’entrepôt, comme le délai entre réception et inspection.
Où trouver ces données
Déduit du changement de statut de l’objet ReturnOrder ou ReturnOrderItem à « Reçu », ou du renseignement du champ « quantityReceived ».
Données à recueillir
Détecter la mise à jour de ReturnOrderItem.quantityReceived ou le changement de statut à « Reçu ».
Type d’événement
inferred
|
|||
|
Demande de retour approuvée
|
Cet événement indique qu’un agent du service client ou une règle automatisée a examiné et autorisé une demande de retour. Il est généralement déduit d’un changement de statut de l’objet ReturnOrder, par exemple de « Nouveau » à « Approuvé ». | ||
|
Pourquoi est-ce important ?
Le suivi de cette étape permet d’évaluer l’efficacité du processus d’approbation et de repérer les goulots d’étranglement. Le délai entre la création et l’approbation est un indicateur clé de la performance des agents.
Où trouver ces données
Déduit de l’horodatage auquel le champ de statut de l’objet ReturnOrder est mis à jour avec une valeur indiquant l’approbation, comme « Approuvé » ou « Autorisé ».
Données à recueillir
Détecter le changement du champ ReturnOrder.status à « Approuvé ».
Type d’événement
inferred
|
|||
|
Demande de retour créée
|
Cette activité correspond à la création d’un dossier d’autorisation de retour dans le système. Elle est enregistrée lorsqu’un nouvel enregistrement ReturnOrder est créé dans Salesforce Commerce Cloud, par un client depuis la boutique en ligne ou par un agent du service client. | ||
|
Pourquoi est-ce important ?
Point de départ du processus de retour, cette activité est indispensable pour mesurer le temps de cycle de bout en bout et suivre l’évolution du volume de demandes de retour.
Où trouver ces données
Cet événement est enregistré à partir de l’horodatage de création de l’objet ReturnOrder dans le système OMS de Salesforce Commerce Cloud.
Données à recueillir
Suivre la création d’un nouvel enregistrement ReturnOrder.
Type d’événement
explicit
|
|||
|
Dossier de retour clôturé
|
Cette activité correspond à la clôture définitive du dossier de retour dans le système, une fois le remboursement, l’échange ou le rejet finalisé. Elle est déduite du passage du statut de ReturnOrder à « Closed » ou « Completed ». | ||
|
Pourquoi est-ce important ?
En tant que point final du processus, cette activité est essentielle au calcul des temps de cycle globaux et à la mesure du débit de traitement des retours.
Où trouver ces données
Déduit de l’horodatage de la mise à jour du champ de statut de l’objet ReturnOrder vers son état final, par exemple « Closed » ou « Completed ».
Données à recueillir
Détecter le changement du champ ReturnOrder.status à « Closed ».
Type d’événement
inferred
|
|||
|
Inspection de l’article terminée
|
Cette activité marque la fin de l’inspection de l’article, au cours de laquelle son état est évalué et consigné. Elle est enregistrée lors d’un changement de statut de l’article retourné et déclenche l’étape suivante, comme le calcul du remboursement. | ||
|
Pourquoi est-ce important ?
Cette étape est un point de décision important, car elle détermine si un remboursement est justifié. Le délai entre la réception et la fin de l’inspection est un indicateur clé de la performance de l’entrepôt.
Où trouver ces données
Déduit de la mise à jour du statut de l’objet ReturnOrderItem à « Inspecté », ou de la confirmation du champ « reasonForReturn » par un agent.
Données à recueillir
Détecter le changement du champ ReturnOrderItem.status à « Inspecté ».
Type d’événement
inferred
|
|||
|
Remboursement effectué
|
Cette activité confirme que le remboursement a bien été traité par la passerelle de paiement et que les fonds ont été envoyés au client. Cet événement est généralement déclenché par un rappel de confirmation du prestataire de paiement. | ||
|
Pourquoi est-ce important ?
Cette étape clé permet de mesurer le respect du SLA de remboursement. Elle confirme que la partie financière du processus de retour est terminée.
Où trouver ces données
Capturé à partir d’un événement de rappel de la passerelle de paiement, qui met à jour le statut de l’objet Payment ou Refund associé dans Salesforce en « Traité » ou « Terminé ».
Données à recueillir
Suivre l’événement de confirmation du prestataire de paiement qui met à jour le statut de l’objet Payment.
Type d’événement
explicit
|
|||
|
Commande d’échange créée
|
Lorsqu’un retour donne lieu à un échange, cet événement indique la création d’une nouvelle commande de vente pour l’article de remplacement. Il s’agit d’une autre option que le remboursement. | ||
|
Pourquoi est-ce important ?
Le suivi distinct de cette voie et des remboursements permet de comprendre les taux d’échange et l’efficacité du traitement des échanges.
Où trouver ces données
Capturé lors de la création d’un nouvel objet SalesOrder lié à l’objet ReturnOrder d’origine.
Données à recueillir
Suivre la création d’un nouveau SalesOrder lié à l’ID ReturnOrder.
Type d’événement
explicit
|
|||
|
Demande de retour refusée
|
Cet événement indique qu’une demande de retour a été refusée et ne sera pas traitée davantage. Il est enregistré lorsque le statut de ReturnOrder passe à « Refusé » ou « Annulé » avant la réception des articles. | ||
|
Pourquoi est-ce important ?
L’analyse des retours refusés permet de repérer les motifs fréquents de refus, comme le non-respect des règles, et d’améliorer la communication avec les clients ainsi que les règles de validation en amont.
Où trouver ces données
Déduit de l’horodatage auquel le champ de statut de l’objet ReturnOrder est mis à jour avec une valeur indiquant un refus, comme « Refusé » ou « Rejeté ».
Données à recueillir
Détecter le changement du champ ReturnOrder.status à « Refusé ».
Type d’événement
inferred
|
|||
|
Étiquette de retour créée
|
Cette activité correspond à la création de l’étiquette d’expédition que le client utilisera pour retourner l’article. Elle peut être enregistrée explicitement si une intégration avec un transporteur consigne cet événement dans le dossier de retour. | ||
|
Pourquoi est-ce important ?
Cette étape compte dans l’expérience client et peut être source de retard si la création de l’étiquette ne se déroule pas correctement. Elle marque le moment où le client prend le relais pour expédier l’article.
Où trouver ces données
L’événement peut être enregistré dans un champ personnalisé ou un objet associé à ReturnOrder par une intégration d’expédition, comme Salesforce Shipping.
Données à recueillir
Suivre l’événement provenant de l’intégration d’expédition ou la création de l’objet personnalisé.
Type d’événement
explicit
|
|||
|
Inspection de l’article commencée
|
Cet événement marque le début de l’évaluation de la qualité et de l’état de l’article retourné. Il est généralement déduit du passage du statut de l’article retourné à « En cours d’inspection » ou à un statut similaire. | ||
|
Pourquoi est-ce important ?
Le suivi du début de l’inspection permet de distinguer sa durée propre du temps d’attente global à l’entrepôt et d’examiner plus précisément les goulots d’étranglement éventuels.
Où trouver ces données
Déduit de la mise à jour du statut de l’objet ReturnOrderItem à une valeur telle que « En cours d’inspection » ou « En inspection ».
Données à recueillir
Détecter le changement du champ ReturnOrderItem.status à « En cours d’inspection ».
Type d’événement
inferred
|
|||
|
Montant du remboursement calculé
|
Cette étape consiste à déterminer le montant final du remboursement en tenant compte de facteurs tels que l’état de l’article, les frais de remise en stock ou les promotions. Il s’agit souvent d’une opération automatisée qui renseigne les champs du montant du remboursement. | ||
|
Pourquoi est-ce important ?
L’analyse de cette étape est essentielle au Dashboard « Analyse des écarts de montant des remboursements ». Elle met en évidence les cas où le montant final diffère de celui demandé par le client.
Où trouver ces données
Cet événement peut être déduit du renseignement ou de la mise à jour des champs du montant du remboursement dans ReturnOrder ou dans un objet de paiement associé au remboursement.
Données à recueillir
Détecter l’horodatage auquel les champs du montant du remboursement sont renseignés.
Type d’événement
inferred
|
|||
|
Remboursement approuvé
|
Cette activité indique que le montant calculé du remboursement a été approuvé et que le remboursement peut être traité. Cette étape peut être automatique ou nécessiter une approbation manuelle pour les retours de montant élevé. | ||
|
Pourquoi est-ce important ?
Cette étape d’approbation peut constituer un goulot d’étranglement, surtout si elle nécessite une intervention manuelle. Elle marque une étape importante avant le lancement de la transaction financière.
Où trouver ces données
Déduit du changement de statut de ReturnOrder ou d’un objet récapitulatif de paiement associé à une valeur telle que « Remboursement approuvé » ou « Prêt pour remboursement ».
Données à recueillir
Détecter le changement de statut de ReturnOrder ou de l’objet de paiement associé.
Type d’événement
inferred
|
|||
|
Remboursement lancé
|
Cet événement marque le moment où Salesforce Commerce Cloud envoie la demande de remboursement à une passerelle de paiement externe. Il correspond au début de la transaction financière. | ||
|
Pourquoi est-ce important ?
Distinguer le lancement du traitement du remboursement est essentiel pour analyser le respect des SLA. Les retards qui surviennent ensuite sont généralement liés au prestataire de paiement, et non au traitement interne.
Où trouver ces données
Enregistré à partir d’un journal d’événements explicite ou d’un enregistrement d’appel API lorsque le système communique avec la passerelle de paiement. L’événement peut aussi être déduit d’un changement de statut d’un objet Payment.
Données à recueillir
Suivre l’appel API à la passerelle de paiement ou le changement de statut à « Remboursement en attente ».
Type d’événement
explicit
|
|||
Guides d’extraction
Prêt à commencer ?
Appuyez-vous sur ce modèle de données pour lancer votre projet de Process Mining. Commencez à optimiser le traitement des retours et des remboursements pour gagner en efficacité et améliorer la satisfaction client.
Améliorez dès aujourd’hui le traitement des retours et des remboursements
Repérez les inefficacités et réduisez de 30 % ou plus le temps de cycle des retours.
Aucune carte bancaire requise. La configuration ne prend que quelques minutes.