Votre modèle de données de traitement des retours et remboursements
Votre modèle de données de traitement des retours et remboursements
- Attributs recommandés à collecter
- Activités clés à suivre
- Guide d'extraction pour Salesforce Commerce Cloud
Attributs de traitement des retours et remboursements
| Nom | Descriptionn | ||
|---|---|---|---|
|
Heure de l'événement
EventTime
|
L'horodatage indiquant quand l'activité ou l'événement spécifique s'est produit. | ||
|
Descriptionn
L'horodatage de l'événement enregistre la date et l'heure exactes de l'exécution d'une activité ou d'un changement de statut. Cet horodatage est impératif pour séquencer correctement les événements et pour effectuer toute analyse basée sur le temps. 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 la performance du processus sur différentes périodes. Des horodatages précis sont la base d'une analyse de processus fiable.
Pourquoi est-ce important ? :
Cet horodatage établit l'ordre chronologique des activités, ce qui est indispensable pour calculer les temps de cycle et identifier les retards de processus.
Source des données :
C'est généralement l'horodatage de création ou de modification d'un enregistrement dans Salesforce Commerce Cloud, tel que 'CreatedDate' ou 'LastModifiedDate' sur 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
|
L'identifiant unique pour un seul dossier de retour client, reliant toutes les activités associées de l'initiation à la clôture. | ||
|
Descriptionn
L'ID du dossier de retour sert d'identifiant principal, reliant toutes les activités associées à une demande spécifique de retour ou de remboursement client. Cela garantit que l'ensemble du cycle de vie d'un retour, de son initiation à sa clôture finale, peut être suivi et analysé en détail. Dans le Process Mining, cet attribut est indispensable pour la reconstruction des cas. Chaque événement avec le même ID de dossier de retour fait partie de la même instance de processus. Cela facilite la visualisation des cartes de processus, le calcul des KPI au niveau des cas comme le temps de cycle, et l'analyse des variantes de processus liées aux retours.
Pourquoi est-ce important ? :
C'est la clé primaire qui connecte toutes les étapes d'un processus de retour en un seul cas traçable, ce qui est indispensable pour l'analyse de processus complet.
Source des 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. On le trouve souvent sur l'objet Return Order ou Case.
Exemples
RT-001, 2, 3, 45RT-001, 2, 3, 46RT-001, 2, 3, 47
|
|||
|
Nom de l'activité
ActivityName
|
Le nom de l'étape spécifique du processus métier ou de l'événement qui s'est produit dans le processus de retour. | ||
|
Descriptionn
Cet attribut décrit la tâche spécifique ou le jalon qui a été achevé à un moment donné pour un dossier de retour. Les exemples incluent 'Demande de retour créée', 'Article réceptionné à l'entrepôt' et 'Remboursement traité'. Dans le Process Mining, le nom de l'activité est utilisé pour construire la carte de processus, montrant la séquence des étapes et le flux des cas. L'analyse des activités est indispensablele pour identifier les points de blocage, les boucles de reprise et les écarts par rapport au processus standard.
Pourquoi est-ce important ? :
Il définit les étapes de la carte de processus, pour visualiser et l'analyse du workflow de retour.
Source des données :
Cet attribut est généralement dérivé des journaux d'événements, des enregistrements de changement de statut ou des données d'achèvement de tâches associées aux objets Return Order ou Case dans Salesforce.
Exemples
Demande de retour approuvéeInspection de l'article terminéeRemboursement traité
|
|||
|
Dernière mise à jour des données
LastDataUpdate
|
L'horodatage indiquant la dernière extraction ou le dernier rafraîchissement des données depuis le système source. | ||
|
Descriptionn
Cet attribut consigne la date et l'heure de la dernière extraction de données de Salesforce Commerce Cloud. Il offre une transparence sur la la réactualisation des données analysées. Cette information est indispensablele pour que les utilisateurs comprennent l'actualité de l'analyse du processus. Elle aide à gérer les attentes concernant la pertinence des données et est importante pour valider l'exhaustivité de l'ensemble de données.
Pourquoi est-ce important ? :
Il informe les utilisateurs sur la réactualisation des données, garantissant qu'ils comprennent si l'analyse reflète l'état le plus actuel du processus.
Source des données :
Cet horodatage est généré par l'outil ou le script d'extraction de données au moment de l'actualisation des données. Ce n'est pas un champ dans Salesforce.
Exemples
2023-05-20T02:00:00Z2023-05-21T02:00:00Z
|
|||
|
Système source
SourceSystem
|
Le système d'où proviennent les données d'événement. | ||
|
Descriptionn
Cet attribut identifie le système source où les données ont été générées. Pour ce processus, il s'agira systématiquement de 'Salesforce Commerce Cloud'. Dans un contexte d'analyse plus large, ce champ est utile lors de la combinaison de données provenant de plusieurs systèmes pour comprendre comment les processus circulent entre différentes plateformes. Il assure une traçabilité claire des données et aide à diagnostiquer les problèmes de qualité des données spécifiques à une source.
Pourquoi est-ce important ? :
Il fournit un contexte sur l'origine des données, ce qui est impératif pour la gouvernance des données et lors de l'intégration de données provenant de plusieurs systèmes d'entreprise.
Source des données :
C'est une valeur statique ajoutée lors de l'extraction et de la transformation des données. Ce n'est pas un champ dans Salesforce lui-même, mais il est défini comme faisant partie du modèle de données.
Exemples
Salesforce Commerce Cloud
|
|||
|
Agent de Traitement
ProcessingAgent
|
L'utilisateur ou l'agent responsable du traitement du retour ou d'une activité spécifique dans le processus de retour. | ||
|
Descriptionn
Cet attribut identifie l'employé ou l'utilisateur du système qui a effectué une action sur le dossier de retour, comme l'approbation de la demande, l'inspection de l'article ou le traitement du remboursement. Il peut s'agir d'un ID utilisateur ou d'un nom spécifique. L'analyse de l'Agent de traitement aide à comprendre les variations de performance entre les individus ou les équipes. Elle est indispensablele pour le 'Tableau de bord de performance et de cohérence des agents' afin d'identifier les besoins en formation, d'équilibrer les charges de travail et de standardiser les procédures dans l'organisation.
Pourquoi est-ce important ? :
Il permet l'analyse des performances et de la cohérence entre les différents utilisateurs, aidant à identifier les meilleures pratiques et les domaines de formation.
Source des données :
Généralement disponible dans des champs comme 'OwnerId' ou 'LastModifiedById' sur les objets Case ou Return Order dans Salesforce. Peut également être stocké dans des objets de tâche ou d'historique liés.
Exemples
Alice SmithBob Johnson`Automatisation du système`
|
|||
|
Canal de retour
ReturnChannel
|
Le canal par lequel le retour a été initié, comme en ligne, en magasin ou via le service client. | ||
|
Descriptionn
Cet attribut spécifie la méthode utilisée par le client pour initier le processus de retour. Les canaux courants incluent un portail de libre-service en ligne, le retour de l'article à un magasin physique ou la prise de contact avec un représentant du service client. Comprendre le canal de retour est important pour le 'Tableau de bord des tendances du volume et du débit des retours'. Il aide à allouer les ressources efficacement et à analyser 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 aide à segmenter les données de retour pour comprendre les différences de processus et les besoins en ressources selon les différents canaux comme en ligne ou en magasin.
Source des données :
Cela peut être un champ sur l'objet Return Order ou Case, ou cela pourrait être déduit de l'utilisateur ou du système qui a créé l'enregistrement de retour.
Exemples
Portail en ligneEn magasinAppel du service client
|
|||
|
Montant du remboursement demandé
RequestedRefundAmount
|
La valeur monétaire du remboursement demandé par le client au moment de l'initiation du retour. | ||
|
Descriptionn
Cet attribut capture le montant initial du remboursement attendu par le client, qui correspond généralement au prix de l'article retourné. Cette valeur sert de référence pour le processus de calcul du remboursement. Ce montant est comparé au 'Montant réel du remboursement' dans le tableau de bord d'analyse des écarts de montants de remboursement. Des différences significatives ou fréquentes peuvent indiquer des problèmes avec les politiques de retour, les frais de réapprovisionnement ou des erreurs de calcul du système, ce qui peut entraîner l'insatisfaction du client.
Pourquoi est-ce important ? :
Il sert de base de référence pour comparer le montant final du remboursement, aidant à identifier les écarts et à analyser l'impact financier des ajustements.
Source des données :
Cette valeur est généralement stockée sur l'objet Return Order ou Return Order Line Item, dérivée de la commande de vente originale.
Exemples
49.99125.0089.50
|
|||
|
Montant du remboursement réel
ActualRefundAmount
|
La valeur monétaire finale qui a été effectivement remboursée au client. | ||
|
Descriptionn
Cet attribut représente le montant final crédité au client après que toutes les évaluations, déductions et calculs sont terminés. Cela pourrait différer du montant demandé en raison de facteurs tels que les frais de réapprovisionnement, les promotions ou la condition de l'article retourné. L'analyse de cet attribut est indispensablele pour la réconciliation financière et pour le 'Tableau de bord d'analyse des écarts de montants de remboursement'. Elle aide à quantifier l'impact financier des politiques de retour et identifie les problèmes systémiques dans le workflow de calcul et d'approbation des remboursements.
Pourquoi est-ce important ? :
C'est le résultat financier final du retour. Sa comparaison avec le montant demandé révèle l'impact financier des politiques de retour et des ajustements.
Source des données :
Cette valeur est généralement stockée sur un objet de Remboursement ou de Transaction de Paiement lié à la commande de retour dans Salesforce Commerce Cloud.
Exemples
49.99115.000.00
|
|||
|
Motif de retour
ReturnReason
|
Le motif fourni par le client pour le retour de l'article. | ||
|
Descriptionn
Le motif de retour indique pourquoi un client a initié un retour. Il est souvent sélectionné à partir d'une liste prédéfinie, telle que 'Taille incorrecte', 'Article endommagé' ou 'Plus nécessaire'. Cet attribut est impératif pour l'analyse des causes profondes. En analysant les motifs de retour, les entreprises peuvent identifier les tendances liées à la qualité des produits, aux problèmes de taille ou aux inexactitudes de description. Cette information peut stimuler les améliorations dans le développement de produits, le marketing et la chaîne d'approvisionnement, réduisant ainsi le volume global des retours.
Pourquoi est-ce important ? :
Comprendre pourquoi les articles sont retournés est indispensable pour identifier les causes profondes, telles que les défauts de produit ou les problèmes de taille, ce qui peut aider à réduire les volumes de retours futurs.
Source des données :
C'est généralement un champ de liste de sélection sur l'objet Return Order ou Case dans Salesforce, souvent rempli par le client pendant le processus d'initiation du retour.
Exemples
Taille incorrecteArticle endommagé à l'arrivéeArticle erroné expédié
|
|||
|
SKU du produit
ProductSku
|
L'unité de gestion des stocks (SKU) de l'article retourné. | ||
|
Descriptionn
Cet attribut est l'identifiant unique du produit spécifique retourné. Il permet une analyse détaillée au niveau du produit individuel. L'analyse des retours par SKU de produit aide à identifier les produits avec des taux de retour élevés, ce qui peut indiquer des problèmes de contrôle qualité, des descriptions de produit médiocres ou des défauts de fabrication. Cette information est indispensablele pour le 'Tableau de bord du temps de réception à l'inspection de l'entrepôt', car elle peut révéler si certains types de produits prennent plus de temps à inspecter.
Pourquoi est-ce important ? :
Il permet d'analyser les modèles de retour par produits spécifiques, aidant à identifier les articles présentant des problèmes de qualité ou de description.
Source des données :
Cette information se trouve sur l'élément de ligne de la commande de retour (Return Order Line Item) ou un objet lié qui associe le dossier de retour au produit spécifique de la commande originale.
Exemples
SHIRT-BL-M-001PANTS-BK-32-004SHOE-RD-10-012
|
|||
|
Adhérence à la politique de retour
ReturnPolicyAdherence
|
Un indicateur de la conformité du retour aux politiques commerciales établies. | ||
|
Descriptionn
Cet attribut marque ou catégorise les retours en fonction de leur adhérence aux politiques de l'entreprise, telles que la fenêtre 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 central pour le 'Tableau de bord de l'aperçu de l'adhérence à la politique de retour' et le 'Taux de non-conformité à la politique' KPI. Il permet à l'entreprise de surveiller la cohérence de l'application des politiques et d'analyser l'impact des retours non conformes sur le processus et les finances.
Pourquoi est-ce important ? :
Il permet le suivi de l'application des politiques, ce qui est impératif pour la gestion des coûts, la prévention de la fraude et l'assurance d'un traitement client juste et cohérent.
Source des données :
C'est souvent un attribut dérivé basé sur un ensemble de règles métier appliquées à d'autres points de données, tels que la date de retour, l'état de l'article et le type de produit.
Exemples
ConformeNon conforme - Retour tardifNon conforme - Article endommagé
|
|||
|
Date cible SLA de remboursement
RefundSlaTargetDate
|
La date cible à laquelle le remboursement du dossier de retour doit être entièrement traité. | ||
|
Descriptionn
Cet attribut définit la date limite de l'accord de niveau de service (SLA) pour l'achèvement du remboursement. Il est généralement calculé sur la base de règles métier, comme un nombre de jours défini après l'approbation de la demande de retour ou la réception de l'article. Cette date est la référence par rapport à laquelle la performance réelle est mesurée dans le 'Tableau de bord de conformité au SLA de remboursement'. Le suivi de la conformité aide à garantir une expérience client cohérente et positive et permet aux managers d'identifier les équipes ou les étapes de processus qui mettent les SLA en péril.
Pourquoi est-ce important ? :
Il définit l'objectif de performance pour le traitement des remboursements, permettant la mesure de la conformité aux SLA et de son impact sur la satisfaction client.
Source des données :
C'est souvent un champ calculé sur l'objet Case ou Return Order, dérivé de la date de création ou d'approbation plus un intervalle de temps prédéfini (par exemple, DateCréation + 14 jours).
Exemples
2023-04-29T23:59:59Z2023-05-10T23:59:59Z2023-05-15T23:59:59Z
|
|||
|
Délai de réception à l'inspection
ReceiptToInspectionTime
|
La durée entre la réception de l'article à l'entrepôt et l'achèvement de son inspection. | ||
|
Descriptionn
Cette métrique calculée mesure le temps nécessaire pour une étape interne clé dans l'entrepôt. C'est la différence entre les horodatages des activités 'Article réceptionné à l'entrepôt' et 'Inspection de l'article terminée'. Cette durée est au centre du 'Tableau de bord du temps de réception à l'inspection de l'entrepôt' et du KPI 'Temps moyen de réception-inspection des articles'. L'analyse de cette métrique aide à identifier les points de blocage dans les opérations d'entrepôt, ce qui peut contribuer de manière significative aux retards globaux du processus.
Pourquoi est-ce important ? :
Il aide à identifier les points de blocage internes de l'entrepôt qui retardent l'ensemble du processus de retour, impactant les délais de remboursement et la disponibilité des stocks.
Source des données :
Ceci est calculé lors de la transformation des données en soustrayant l'horodatage de 'Article réceptionné à l'entrepôt' de l'horodatage de 'Inspection de l'article terminée'.
Exemples
1 jour 2 heures3 jours 0 heures8 heures
|
|||
|
Emplacement de l'entrepôt
WarehouseLocation
|
L'identifiant de l'entrepôt ou de l'installation où l'article retourné a été reçu. | ||
|
Descriptionn
Cet attribut spécifie le lieu physique qui a traité l'article retourné. C'est particulièrement pertinent pour les entreprises ayant plusieurs centres de distribution. L'analyse par emplacement d'entrepôt peut révéler des différences de performance entre les installations. Par exemple, elle peut montrer si certains entrepôts ont des temps d'inspection plus longs ou des taux plus élevés d'articles marqués comme endommagés. Cela aide à standardiser les opérations et à résoudre les problèmes spécifiques aux installations.
Pourquoi est-ce important ? :
Il permet de comparer les performances entre différents entrepôts, en mettant en évidence les variations des temps de traitement ou de l'évaluation de la qualité.
Source des données :
Cette information peut être stockée sur l'objet Return Order ou un objet d'expédition lié. Elle peut également être déduite de l'utilisateur qui a effectué l'activité de réception.
Exemples
WH-EAST-01WH-WEST-03WH-CENTRAL-02
|
|||
|
Est conforme aux SLA
IsSlaCompliant
|
Un indicateur booléen indiquant si le remboursement a été traité dans la date cible de SLA définie. | ||
|
Descriptionn
Cet indicateur est défini sur 'vrai' si l'activité 'Remboursement traité' a eu lieu à la date cible du SLA de remboursement ou avant, et 'faux' sinon. Il fournit un résultat binaire clair pour la performance du SLA au cas par cas. Cet attribut est la base du 'Tableau de bord de conformité au SLA de remboursement' et du KPI 'Taux d'respect des SLA de remboursement'. Il simplifie l'analyse des taux de conformité et permet d'approfondir les raisons de la non-conformité en segmentant les données avec d'autres attributs comme 'Agent de traitement' ou 'Canal de retour'.
Pourquoi est-ce important ? :
Il simplifie l'analyse des performances SLA, permettant un calcul facile des taux de conformité et l'identification des facteurs contribuant aux retards.
Source des données :
C'est un attribut calculé. La logique est : SI (Horodatage de 'Remboursement traité' <= DateCibleSlaRemboursement) ALORS vrai SINON faux.
Exemples
truefaux
|
|||
|
État de l'article
ItemCondition
|
La condition évaluée de l'article retourné lors de l'inspection à l'entrepôt. | ||
|
Descriptionn
Après réception d'un article retourné, celui-ci est généralement inspecté pour en déterminer l'état. Cet attribut enregistre le résultat, tel que 'Neuf', 'Usagé - Revendable' ou 'Endommagé'. Cette évaluation a un impact direct sur le montant final du remboursement et est une entrée clé pour le tableau de bord 'Aperçu de la conformité aux politiques de retour'. Le suivi de ces données aide à comprendre la qualité des marchandises retournées et à gérer les stocks pour la revente, la remise à neuf ou l'élimination.
Pourquoi est-ce important ? :
Cette évaluation détermine souvent le montant final du remboursement et est indispensablele pour la gestion des stocks des marchandises retournées.
Source des données :
C'est généralement un champ personnalisé mis à jour lors de l'activité 'Inspection de l'article', situé sur l'objet Return Order Line Item.
Exemples
Neuf/Non ouvertUsagé - Comme neufEndommagé/Invendable
|
|||
|
ID client
CustomerId
|
Un identifiant unique pour le client qui a initié le retour. | ||
|
Descriptionn
Cet attribut est l'ID unique associé au compte du client. Il permet d'agréger les données de retour au niveau du client. L'analyse des retours par ID client peut aider à identifier les clients ayant des taux de retour anormalement élevés, ce qui peut indiquer un comportement frauduleux ou une insatisfaction chronique. Elle permet également une analyse basée sur les segments de clientèle, aidant à comprendre si certains groupes de clients ont des habitudes ou des comportements de retour différents.
Pourquoi est-ce important ? :
Il permet une analyse au niveau client pour identifier les clients qui retournent fréquemment des articles et comprendre le comportement de retour à travers différents segments de clientèle.
Source des données :
C'est un champ standard sur les objets Order et Case dans Salesforce, qui renvoie à l'objet Customer ou Account.
Exemples
CUST-98765CUST-1, 2, 3, 45CUST-55555
|
|||
|
Motif de refus
RejectionReason
|
La raison spécifique pour laquelle une demande de retour ou un remboursement a été refusé. | ||
|
Descriptionn
Lorsqu'un retour n'est pas approuvé ou qu'un remboursement est refusé, cet attribut capture la justification. Les exemples incluent 'Hors délai de retour', 'Article endommagé par le client' ou 'Article non-retournable'. Cette information est indispensable pour le tableau de bord 'Retours rejetés et escaladés'. L'analyse des motifs de rejet aide l'entreprise à comprendre les points de blocage dans la politique et le processus de retour. Cela peut conduire à une communication plus claire avec les clients, à des ajustements de politique ou à une meilleure vérification initiale des demandes de retour.
Pourquoi est-ce important ? :
Il fournit des informations cruciales sur les raisons des échecs de retour, aidant à améliorer les politiques de retour, la communication client et la formation des agents.
Source des données :
C'est souvent un champ personnalisé sur l'objet Return Order ou Case, qui est renseigné lorsque le statut est modifié en 'Rejected' ou 'Closed - Denied'.
Exemples
Délai de retour expiréArticle non dans son état d'origineArticle en solde final
|
|||
|
Statut du retour
ReturnStatus
|
Le statut actuel du dossier de retour dans son cycle de vie. | ||
|
Descriptionn
Cet attribut indique l'état actuel du retour, tel que 'En attente d'approbation', 'Article reçu', 'Remboursé' ou 'Clos'. Il s'agit d'un attribut dynamique qui change à mesure que le cas progresse dans le workflow. Bien que le Process Mining dérive le flux des activités, avoir le statut actuel fournit un contexte précieux pour filtrer et analyser les cas ouverts par rapport aux cas clos. Il aide au suivi opérationnel pour comprendre l'arriéré actuel et la charge de travail à différentes étapes du processus.
Pourquoi est-ce important ? :
Il fournit un aperçu de l'emplacement d'un cas de retour dans le processus, ce qui est utile pour le suivi opérationnel et le filtrage des cas actifs.
Source des données :
C'est un champ 'Statut' standard sur l'objet Return Order ou Case dans Salesforce Commerce Cloud.
Exemples
En attente d'approbationApprouvéArticles réceptionnésClôturé
|
|||
Activités de traitement des retours et remboursements
| Activité | Descriptionn | ||
|---|---|---|---|
|
Article réceptionné à 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 capturée lorsqu'un opérateur d'entrepôt scanne l'article, ce qui met à jour le statut de l'article de retour associé (ReturnOrderItem). | ||
|
Pourquoi est-ce important ? :
C'est une étape critique qui fait passer le processus de l'action client au traitement interne. C'est le point de départ pour mesurer les KPI d'efficacité de l'entrepôt, comme le délai de réception à l'inspection.
Source des données :
Déduit d'un changement de statut sur l'objet ReturnOrder ou ReturnOrderItem à un état 'Reçu', ou lorsque le champ 'quantityReceived' est renseigné.
Capture
Détecter la mise à jour de ReturnOrderItem.quantityReceived ou le changement de statut à 'Received'.
Type d'événement
inferred
|
|||
|
Demande de retour approuvée
|
Cet événement signifie qu'une demande de retour a été examinée et autorisée par un agent de service ou une règle automatisée. Il est généralement déduit d'un changement de statut sur l'objet ReturnOrder, par exemple, de 'Nouveau' à 'Approuvé'. | ||
|
Pourquoi est-ce important ? :
Le suivi de ce jalon aide à analyser l'efficacité de l'étape d'approbation et à identifier les points de blocage. Le temps entre la création et l'approbation est un KPI clé pour la performance de l'agent.
Source des données :
Déduit de l'horodatage lorsque le champ de statut de l'objet ReturnOrder est mis à jour à une valeur représentant l'approbation, telle que 'Approuvé' ou 'Autorisé'.
Capture
Détecter le changement du champ ReturnOrder.status à 'Approved'.
Type d'événement
inferred
|
|||
|
Demande de retour créée
|
Cette activité marque la création d'un dossier d'autorisation de retour dans le système. Elle est capturée lorsqu'un nouvel enregistrement ReturnOrder est créé dans Salesforce Commerce Cloud, soit par un client via le front-office, soit par un agent de service. | ||
|
Pourquoi est-ce important ? :
En tant que point de départ du processus de retour, cette activité est indispensablele pour mesurer le temps de cycle complet et analyser le volume des demandes de retour entrantes au fil du temps.
Source des données :
Cet événement est capturé à partir de l'horodatage de création de l'objet ReturnOrder dans Salesforce Commerce Cloud OMS.
Capture
Suivre la création d'un nouvel enregistrement ReturnOrder.
Type d'événement
explicit
|
|||
|
Dossier de retour clos
|
Cette activité représente la clôture finale du dossier de retour dans le système, après la finalisation d'un remboursement, d'un échange ou d'un rejet. Elle est déduite du changement de statut de ReturnOrder à 'Closed' ou 'Completed'. | ||
|
Pourquoi est-ce important ? :
En tant que point final principal du processus, cette activité est indispensablele pour calculer les temps de cycle globaux et mesurer le débit de l'opération de traitement des retours.
Source des données :
Déduit de l'horodatage lorsque le champ de statut de l'objet ReturnOrder est mis à jour à son état final, tel que 'Clos' ou 'Terminé'.
Capture
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, où sa condition est évaluée et documentée. Elle est capturée par un changement de statut sur l'article de retour, déclenchant l'étape suivante comme le calcul du remboursement. | ||
|
Pourquoi est-ce important ? :
C'est un point de décision clé dans le processus qui détermine si un remboursement est justifié. La durée de la réception à l'achèvement de l'inspection est un KPI majeur pour les opérations d'entrepôt.
Source des données :
Déduit d'une mise à jour de statut sur l'objet ReturnOrderItem à 'Inspecté' ou lorsque la 'reasonForReturn' est confirmée par un agent.
Capture
Détecter le changement du champ ReturnOrderItem.status à 'Inspected'.
Type d'événement
inferred
|
|||
|
Remboursement traité
|
Cette activité confirme que le remboursement a été traité avec succès 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 fournisseur de paiement. | ||
|
Pourquoi est-ce important ? :
C'est une étape critique pour mesurer l'respect des SLA de remboursement. Elle confirme l'achèvement réussi de la partie financière du processus de retour.
Source des données :
Capturé à partir d'un événement de rappel de la passerelle de paiement qui met à jour le statut de l'objet Paiement ou Remboursement associé dans Salesforce à 'Traité' ou 'Terminé'.
Capture
Suivre l'événement de confirmation du fournisseur de paiement mettant à jour le statut de l'objet Paiement.
Type d'événement
explicit
|
|||
|
Commande d'échange créée
|
Pour les retours entraînant un échange, cet événement marque la création d'une nouvelle commande de vente pour l'article de remplacement. Il s'agit d'une voie alternative à un remboursement monétaire. | ||
|
Pourquoi est-ce important ? :
Le suivi de ce chemin séparément des remboursements est important pour comprendre les taux d'échange et l'efficacité du processus de traitement des échanges.
Source des données :
Capturé à partir de la création d'un nouvel objet SalesOrder qui est lié à l'objet ReturnOrder original.
Capture
Suivre la création d'une nouvelle SalesOrder liée à l'ID ReturnOrder.
Type d'événement
explicit
|
|||
|
Demande de retour rejetée
|
Cet événement indique qu'une demande de retour a été refusée et ne sera pas traitée davantage. Cela est capturé lorsque le statut de ReturnOrder est mis à jour à 'Rejected' ou 'Canceled' avant la réception des marchandises. | ||
|
Pourquoi est-ce important ? :
L'analyse des retours rejetés aide à identifier les raisons courantes de refus, telles que les violations de politique, ce qui peut améliorer la communication client et les règles de validation frontend.
Source des données :
Déduit de l'horodatage lorsque le champ de statut de l'objet ReturnOrder est mis à jour à une valeur représentant le rejet, comme 'Rejeté' ou 'Refusé'.
Capture
Détecter le changement du champ ReturnOrder.status à 'Rejected'.
Type d'événement
inferred
|
|||
|
Étiquette de retour générée
|
Cette activité représente le moment où une étiquette d'expédition est créée pour que le client l'utilise pour retourner l'article. Cela peut être capturé explicitement si une intégration avec un fournisseur d'expédition enregistre cet événement par rapport au dossier de retour. | ||
|
Pourquoi est-ce important ? :
Cette étape est un élément clé de l'expérience client et peut être une source de retard si le processus de génération n'est pas fluide et efficace. Elle marque le transfert au client pour l'expédition de l'article.
Source des données :
Potentiellement enregistré dans un champ personnalisé ou un objet lié de l'objet ReturnOrder par une intégration d'expédition comme Salesforce Shipping.
Capture
Suivre l'événement de l'intégration d'expédition ou de la création d'objet personnalisé.
Type d'événement
explicit
|
|||
|
Inspection de l'article commencée
|
Cet événement signifie le début de l'évaluation de la qualité et de la condition de l'article retourné. Il est généralement déduit lorsque le statut de l'article de retour passe à 'En inspection' ou à un état similaire. | ||
|
Pourquoi est-ce important ? :
Le suivi du début de l'inspection aide à isoler la durée pure de l'inspection du temps d'attente global de l'entrepôt, offrant une vue plus granulairesre des points de blocage potentiels.
Source des données :
Déduit d'une mise à jour de statut sur l'objet ReturnOrderItem à une valeur comme 'Inspection en cours' ou 'Sous inspection'.
Capture
Détecter le changement du champ ReturnOrderItem.status à 'Inspecting'.
Type d'événement
inferred
|
|||
|
Montant du remboursement calculé
|
Cela représente l'étape où le montant final du remboursement est déterminé, en tenant compte de facteurs tels que la condition de l'article, les frais de réapprovisionnement ou les promotions. Il s'agit souvent d'une étape de système automatisée qui renseigne les champs de montant de remboursement. | ||
|
Pourquoi est-ce important ? :
L'analyse de cette étape est indispensablele pour le tableau de bord 'Analyse des écarts de montants de remboursement', mettant en évidence les cas où le montant final diffère de ce que le client a demandé.
Source des données :
Cet événement peut être déduit de la population ou de la mise à jour des champs de montant de remboursement sur l'objet ReturnOrder ou un objet de paiement de remboursement associé.
Capture
Détecter l'horodatage lorsque les champs de montant de remboursement sont remplis.
Type d'événement
inferred
|
|||
|
Remboursement approuvé
|
Cette activité signifie que le montant du remboursement calculé a été approuvé et est prêt à être traité. Cela peut être une étape automatique ou nécessiter une approbation manuelle pour les retours de grande valeur. | ||
|
Pourquoi est-ce important ? :
Cette étape d'approbation peut être un goulot d'étranglement, surtout si elle nécessite une intervention manuelle. C'est une étape clé avant l'initiation de la transaction financière.
Source des données :
Déduit d'un changement de statut sur l'objet ReturnOrder ou un objet de résumé de paiement lié à un état comme 'Remboursement approuvé' ou 'Prêt pour le remboursement'.
Capture
Détecter le changement de statut sur ReturnOrder ou l'objet de paiement associé.
Type d'événement
inferred
|
|||
|
Remboursement initié
|
Cet événement marque le moment où Salesforce Commerce Cloud envoie la demande de remboursement à une passerelle de paiement externe. Il représente le début de la transaction financière. | ||
|
Pourquoi est-ce important ? :
Distinguer l'initiation du traitement est indispensable pour l'analyse de la conformité au SLA. Les retards après ce point sont généralement liés au fournisseur de paiement, et non au traitement interne.
Source des données :
Capturé à 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. Il peut également être déduit d'un changement de statut sur un objet Paiement.
Capture
Suivre l'événement d'appel API vers la passerelle de paiement ou un changement de statut à 'Remboursement en attente'.
Type d'événement
explicit
|
|||