Automatisation post-achat pour Shopify : flux de travail à configurer avec Shopify Flow et votre service d’assistance
Shopify Flow peut automatiser les étapes de l’assistance après achat côté Shopify, tandis que votre service d’assistance reste le système utilisé pour les conversations avec les clients, l’attribution des tickets et le suivi par les agents. La configuration la plus fiable consiste à utiliser Flow pour détecter un événement de commande, vérifier un petit nombre de conditions, puis soit mettre à jour la commande, soit envoyer des informations structurées à une intégration de service d’assistance. Ne considérez pas Flow seul comme un système complet de suivi des expéditions : les retards des transporteurs, les exceptions de livraison et les événements liés aux retours peuvent nécessiter une plateforme de suivi ou de gestion des retours capable de fournir ces signaux.
Ce guide explique comment concevoir le workflow, choisir le bon déclencheur, connecter le résultat à votre service d’assistance et tester l’automatisation sans créer de tickets en double ni envoyer de messages trompeurs aux clients.
Ce que le workflow doit faire
Un workflow après achat utile comporte quatre éléments :
- Événement : Quelque chose se produit sur une commande, comme un paiement, une exécution, une annulation ou un remboursement.
- Décision : Flow vérifie si l’événement nécessite une action. Les conditions peuvent inclure la valeur de la commande, le pays d’expédition, le statut d’exécution, les balises ou le fait qu’un client ait déjà contacté l’assistance.
- Action : Flow ajoute une balise, met à jour une commande, envoie un e-mail ou une notification, ou transmet des données à un point de terminaison externe.
- Responsable : Une personne ou une file d’attente du service d’assistance reçoit le dossier lorsqu’un jugement ou une communication avec le client est nécessaire.
L’objectif n’est pas d’automatiser chaque interaction avec le client. Il s’agit de supprimer le travail répétitif de tri tout en conservant un transfert clair pour les exceptions.
Avant de commencer : définissez la source de vérité
Commencez par déterminer quel système connaît chaque information. Shopify est généralement la source des informations relatives aux commandes, aux paiements, à l’exécution, aux remboursements et aux clients. Un transporteur ou une plateforme de suivi peut être la source des scans en transit, des exceptions de livraison et de la confirmation de livraison. Le service d’assistance doit être la source de l’historique des conversations, du statut des tickets, de leur attribution et des notes des agents.
Cette distinction permet d’éviter une erreur de conception courante : créer un workflow qui suppose que Shopify Flow peut identifier chaque problème de livraison. Flow peut réagir aux événements Shopify et aux informations rendues disponibles par des applications connectées ou des services externes, mais il ne peut pas déduire un retard du transporteur simplement parce qu’une commande a été exécutée. Un événement d’exécution confirme qu’un enregistrement ou un statut d’exécution a changé ; il ne prouve pas, à lui seul, que le colis progresse normalement.
Notez l’événement dont vous avez réellement besoin avant de sélectionner un déclencheur. Par exemple :
- « La commande a été exécutée et le client doit recevoir le message après achat standard. »
- « Une expédition fait l’objet d’une exception du transporteur et l’assistance doit recevoir un dossier prioritaire. »
- « Un remboursement a été créé et le client doit être dirigé vers la file des remboursements si une conversation existe déjà. »
Architecture recommandée avec Shopify Flow et un service d’assistance
Il existe deux modèles de connexion pratiques.
Modèle 1 : utiliser une intégration native du service d’assistance
Si votre service d’assistance dispose d’une intégration Shopify, installez-la et configurez-la en premier. Les intégrations natives rendent généralement les détails de la commande disponibles dans un ticket ou permettent aux agents d’ouvrir la commande concernée sans copier manuellement les données. Les événements et actions exacts dépendent du service d’assistance ; vérifiez-les donc dans sa documentation actuelle au lieu de supposer que chaque événement Shopify est pris en charge.
Dans ce modèle, Flow peut gérer la classification côté Shopify. Par exemple, il peut ajouter une balise telle que post_purchase_priority lorsqu’une commande répond à vos critères d’assistance. Le service d’assistance peut ensuite utiliser cette balise, les données de commande ou un événement fourni par une application pour acheminer la conversation.
Modèle 2 : envoyer une requête HTTP depuis Flow
Lorsqu’aucune action native ne couvre le transfert, Shopify Flow peut envoyer une requête HTTP à un service intermédiaire, une plateforme d’automatisation ou un point de terminaison du service d’assistance lorsque cette option est prise en charge. Le système destinataire doit valider la requête, transformer la charge utile si nécessaire, puis créer ou mettre à jour un ticket.
Utilisez ce modèle uniquement si vous pouvez contrôler l’authentification, la détection des doublons, la gestion des erreurs et les données envoyées au service externe. Une requête qui crée simplement un nouveau ticket à chaque exécution de Flow peut rapidement produire des dossiers en double.
Workflow 1 : transfert d’une exécution vers l’assistance client
C’est un bon workflow de départ, car l’exécution est un événement Shopify clair et le résultat opérationnel est facile à mesurer.
Étape 1 : choisir le déclencheur
Dans Shopify Flow, créez un workflow à l’aide du déclencheur lié à l’exécution qui correspond à votre processus. Le nom exact du déclencheur et les variables disponibles peuvent changer lorsque Shopify met Flow à jour ; sélectionnez donc l’option actuelle affichée dans votre interface d’administration et examinez les variables disponibles dans l’éditeur de workflow.
Étape 2 : ajouter les conditions métier
N’envoyez pas chaque commande exécutée à un agent. Ajoutez des conditions qui identifient une exception ou un segment opérationnel utile. Exemples :
- La commande présente une priorité d’assistance interne élevée.
- La destination d’expédition appartient à un marché disposant d’une file de service distincte.
- La commande contient un produit nécessitant des instructions spéciales après achat.
- La commande comporte une balise indiquant une réclamation client antérieure ou une vérification manuelle.
- L’exécution est partielle et le client peut avoir besoin d’une explication.
Gardez la première version ciblée. Une règle telle que « toutes les commandes internationales sont envoyées à l’assistance » peut créer plus de travail qu’elle n’en supprime, sauf si elle répond à une raison opérationnelle précise.
Étape 3 : choisir l’action
Pour une classification à faible risque, ajoutez une balise de commande ou une note interne. Pour un dossier nécessitant un responsable, envoyez une notification au service d’assistance ou créez un ticket via l’intégration. N’incluez que les informations nécessaires à l’équipe destinataire :
- ID et numéro de commande Shopify
- Nom du client et identifiant de contact
- Pays ou région d’expédition
- Statut d’exécution et référence de suivi, lorsqu’ils sont disponibles
- Motif de l’acheminement
- File et priorité suggérées
Si l’API du service d’assistance exige un format JSON spécifique, utilisez sa documentation comme contrat. Ne devinez pas les noms des champs. Dans Flow, insérez si possible les variables via le sélecteur de variables, puis comparez la charge utile de test avec les champs requis par le système destinataire.
Étape 4 : empêcher les tickets en double
Utilisez une stratégie d’idempotence. Avant de créer un nouveau dossier, vérifiez si la commande possède déjà une balise d’assistance, une référence de ticket ouvert ou un champ personnalisé indiquant que le transfert a été effectué. Si votre service d’assistance prend en charge une clé d’idempotence, utilisez une valeur stable basée sur la commande et l’événement plutôt qu’un horodatage. Si ce n’est pas le cas, demandez au service intermédiaire de rechercher un dossier ouvert existant avant d’en créer un autre.
Workflow 2 : escalade d’une exception de livraison
Les exceptions de livraison nécessitent davantage de précautions, car l’événement peut provenir de l’extérieur de Shopify. Shopify Flow ne doit servir de couche d’action que si l’application ou l’intégration de suivi transmet un événement fiable à Shopify ou au point de terminaison utilisé par Flow.
Une conception solide ressemble à ceci :
- Un transporteur ou un service de suivi signale une exception.
- Le service de suivi ou le service intermédiaire vérifie si l’expédition est toujours ouverte et si une exception similaire a déjà été traitée.
- Le système envoie un événement structuré au service d’assistance ou à un point de terminaison compatible avec Flow.
- Le service d’assistance crée ou met à jour un ticket, attribue la file appropriée et affiche le contexte de suivi à l’agent.
- Un agent décide de contacter le client, d’attendre un autre scan, de demander la confirmation de l’adresse ou de proposer une résolution approuvée.
Utilisez une liste contrôlée de catégories d’exception, telles que problème d’adresse, retard douanier, tentative de livraison échouée, expédition endommagée ou absence de scan récent. Évitez de promettre automatiquement une date de livraison, sauf si le service sous-jacent fournit une estimation actuelle et que votre politique de service client autorise ce message.
Si vous utilisez Flow pour baliser la commande associée, choisissez des balises qui décrivent l’état plutôt que le résultat. carrier_exception_open est plus sûr que delivery_failed lorsque le transporteur n’a pas confirmé un échec définitif.
Workflow 3 : retours, remboursements et questions après achat
Les retours et les remboursements génèrent souvent des questions répétitives, mais ils ne doivent pas être regroupés dans une seule automatisation. Un remboursement peut être terminé alors que le client attend encore que le prestataire de paiement crédite les fonds. Un retour peut avoir été demandé sans avoir encore été reçu. Chaque état doit avoir une réponse différente du service d’assistance ou une instruction interne différente.
Utilisez Shopify Flow pour classer des événements tels qu’une demande de retour, la création d’un remboursement, une annulation ou une mise à jour de commande lorsque ces événements sont disponibles dans la configuration Flow de votre boutique. Acheminez le résultat selon votre politique :
- Informatif : Ajoutez une étiquette interne et laissez la macro existante du service d’assistance répondre aux questions courantes.
- Urgent : Créez ou priorisez un ticket lorsqu’une fenêtre de service promise est menacée.
- Vérification manuelle : Acheminez les produits endommagés, les remboursements contestés ou les historiques de commande inhabituels vers un spécialiste.
- Action du client requise : Demandez uniquement les informations manquantes, comme des photographies ou une adresse corrigée.
Si les retours sont gérés par une application dédiée, conservez le statut du retour dans ce système et transmettez le statut nécessaire à Shopify ou au service d’assistance. Ne maintenez pas de statuts manuels concurrents dans trois systèmes sans processus clair de rapprochement.
Comment configurer le transfert vers le service d’assistance
Avant d’activer une action externe, préparez le côté du service d’assistance.
Définir les files et les responsables
Créez des files correspondant à de véritables décisions, et pas uniquement à des intitulés généraux. « Exception de livraison », « correction d’adresse » et « vérification de remboursement » conduisent généralement à des procédures différentes. Attribuez une file de secours pour les événements incomplets ou non reconnus afin que les échecs d’automatisation ne disparaissent pas.
Créer un schéma d’événement compact
Utilisez des noms et des valeurs de champs cohérents. Un événement pratique peut inclure event_type, event_id, shopify_order_id, order_number, customer_reference, tracking_number, reason_code, priority et occurred_at. Envoyez un ID d’événement stable et enregistrez-le côté destinataire.
Minimisez les données personnelles. Le service d’assistance peut déjà être en mesure de récupérer le profil du client à partir du numéro de commande ; n’envoyez donc pas plus d’informations client que l’intégration ne l’exige.
Définir la règle de contact client
Décidez quels événements créent un ticket interne, lesquels envoient un message destiné au client et lesquels font les deux. Une exception du transporteur justifie souvent une vérification interne avant l’envoi d’un e-mail automatisé. Une confirmation d’exécution standard peut convenir à un modèle approuvé. La règle doit être consignée dans la documentation du workflow afin que les agents sachent pourquoi un message a été envoyé.
Liste de contrôle pour les tests et la surveillance
Testez par étapes plutôt que d’activer toutes les actions en même temps.
- Tester le déclencheur : Vérifiez que l’événement sélectionné s’exécute pour les types de commande attendus et ne s’exécute pas pour des modifications sans rapport.
- Tester les conditions : Utilisez des exemples positifs et négatifs, notamment des exécutions partielles, des destinations internationales, des remboursements et des commandes comportant déjà des balises.
- Inspecter la charge utile : Vérifiez les identifiants de commande, les données de suivi, les dates, la priorité et le code motif. Vérifiez que les champs vides ne perturbent pas l’API destinataire.
- Tester le comportement en cas de doublon : Exécutez le même événement plusieurs fois et confirmez qu’il ne crée pas plusieurs tickets actifs.
- Tester la gestion des échecs : Utilisez temporairement un point de terminaison ou un champ obligatoire invalide dans un environnement contrôlé. Vérifiez que l’échec est visible par un responsable.
- Effectuer un lancement limité : Commencez avec une file, un marché ou un type d’événement. Examinez les tickets et les retours des agents avant d’élargir le périmètre.
Surveillez les résultats opérationnels et ceux liés aux clients. Les indicateurs utiles comprennent le nombre de transferts automatisés, de tickets en double, de tickets non attribués, de requêtes échouées, le délai avant la première vérification humaine et le pourcentage de dossiers acheminés que les agents reclassent. Une automatisation qui crée davantage de tickets sans améliorer l’attribution ou la résolution ne fonctionne pas correctement, même si l’historique d’exécution de Flow indique un succès.
Erreurs courantes à éviter
- Utiliser l’exécution comme preuve de livraison : L’exécution et la livraison sont des états différents.
- Créer un ticket pour chaque commande : Utilisez des conditions et des seuils d’acheminement pour réserver les agents aux exceptions.
- Envoyer des identifiants instables : Les numéros de commande, les ID d’événement et les références de suivi doivent être associés de manière cohérente.
- Négliger l’authentification : Considérez un point de terminaison HTTP recevant des données client ou de commande comme un service protégé.
- Ignorer les limites des applications et des forfaits : Vérifiez quelles actions Flow, quels déclencheurs, quels appels API et quelles fonctionnalités du service d’assistance sont disponibles dans votre configuration actuelle.
- Automatiser les décisions de politique : Laissez Flow classer les dossiers courants, mais maintenez les remboursements, les compensations, les changements d’adresse et les fraudes présumées dans le cadre de règles approuvées et d’une vérification humaine.
Déroulement pratique du déploiement
Pour la plupart des boutiques Shopify, la séquence la plus sûre consiste à commencer par une balise ou une notification interne, puis à ajouter l’acheminement vers le service d’assistance et, seulement plus tard, l’automatisation destinée aux clients. Commencez par un événement facile à vérifier, comme une exception d’exécution ou un état de remboursement connu. Documentez le déclencheur, les conditions, l’action, le responsable, la règle de détection des doublons et le chemin d’échec. Une fois que le workflow produit des résultats stables, ajoutez d’autres types d’événements un par un.
La meilleure conception n’est pas celle qui comporte le plus d’actions Flow. C’est celle qui fournit aux agents d’assistance le bon contexte au bon moment, laisse une trace vérifiable et évite de demander à un client de répéter des informations déjà disponibles dans Shopify ou dans le système de suivi concerné.
FAQ
Shopify Flow peut-il créer directement un ticket dans un service d’assistance ?
Cela dépend du service d’assistance et de l’intégration disponible dans votre boutique. Si aucune action Flow native n’est disponible, une requête HTTP peut transmettre les données de l’événement à un service intermédiaire ou à un point de terminaison du service d’assistance lorsque cette option est prise en charge. Vérifiez les exigences du système destinataire en matière d’authentification, de charge utile et de création de tickets avant d’activer le workflow.
Flow peut-il détecter qu’un colis est en retard ?
Pas à partir du seul statut d’exécution. Une expédition en retard nécessite une règle de délai de livraison et une source fiable d’événements du transporteur ou de suivi. Utilisez une intégration ou un service de suivi fournissant ces signaux, puis acheminez l’événement vers le service d’assistance ou le workflow Shopify approprié.
Chaque événement après achat doit-il créer un ticket ?
Non. Utilisez des balises, des notifications internes ou les automatisations existantes du service d’assistance pour les événements à faible risque. Créez un ticket lorsqu’une personne doit enquêter, contacter le client, approuver une solution ou surveiller une exception.
Comment empêcher la création de tickets en double ?
Utilisez un ID d’événement stable ou une clé basée sur la commande et l’événement, vérifiez l’existence d’un ticket ouvert et enregistrez le résultat du transfert. Une balise telle que support_handoff_complete peut être utile pour les workflows simples, mais une recherche dans le service d’assistance ou le service intermédiaire est plus sûre lorsque les événements peuvent être réessayés.
Que faut-il tester avant le lancement ?
Testez le déclencheur, les conditions, le mappage des données, les autorisations, le comportement en cas de doublon, les alertes d’échec et la formulation destinée aux clients. Incluez les exécutions partielles, les données de suivi manquantes, les événements répétés, les remboursements et les commandes comportant déjà un dossier d’assistance.
