Comment automatiser les notifications d'expédition : déclencheurs, canaux et modèles en 6 étapes
Pour automatiser les notifications d’expédition, reliez les événements d’expédition aux enregistrements de commande, définissez les changements de statut qui méritent l’envoi d’un message, choisissez un canal de livraison autorisé et associez un modèle à chaque déclencheur. Ajoutez ensuite la prévention des doublons, la gestion des exceptions et les tests avant le lancement. Les six étapes ci-dessous montrent aux équipes e-commerce comment créer un flux de travail qui fournit aux clients des mises à jour utiles sans envoyer d’alertes répétitives ou trompeuses.
Ce guide s’adresse aux marchands, aux équipes des opérations e-commerce et aux développeurs responsables des communications post-achat. Le point de départ recommandé consiste à utiliser un petit ensemble de notifications fiables : prise en charge par le transporteur, sortie pour livraison, livraison effectuée et exceptions nécessitant une action du client. N’ajoutez d’autres messages que lorsqu’ils répondent à une question distincte du client.
1. Relier les événements de suivi à la bonne commande et au bon destinataire
Une étiquette d’expédition, un scan du transporteur et une notification client sont trois choses différentes. La création d’une étiquette ne prouve pas que le transporteur a reçu le colis. Votre automatisation doit préserver cette distinction dès le départ.
Commencez par identifier le système qui prendra en charge les décisions relatives aux notifications. Il peut s’agir du flux de notifications de votre boutique, d’une application de suivi ou d’un service connecté à votre système de gestion des commandes. Désignez un responsable pour chaque type de message afin que plusieurs systèmes n’envoient pas indépendamment la même mise à jour.
Deux méthodes pratiques de mise en œuvre sont possibles :
- Configuration basée sur une application : utilisez une application de suivi e-commerce lorsque votre équipe souhaite configurer les événements pris en charge et les messages destinés aux clients sans créer toute l’intégration. Pour les marchands Shopify, la fiche de l’application 17TRACK constitue un point de départ pertinent pour évaluer les flux de suivi des expéditions et de notifications. Vérifiez les déclencheurs, canaux, options de personnalisation et exigences du forfait avant de configurer vos règles.
- Configuration basée sur une API : utilisez une intégration de suivi lorsque les événements d’expédition doivent alimenter un système de commande existant ou un flux de messagerie personnalisé. La 17TRACK Tracking API et sa documentation officielle sont des références pertinentes pour la mise en œuvre. Vérifiez le mécanisme de transmission des événements, les champs de la charge utile, l’authentification et le comportement en cas de nouvelle tentative pour l’intégration que vous prévoyez d’utiliser. La réception des données de suivi et l’envoi de messages aux clients sont deux responsabilités distinctes.
Quelle que soit la méthode choisie, associez chaque expédition à la bonne commande et au bon destinataire. Un enregistrement interne utile contient :
- La référence de commande et l’identifiant de l’expédition.
- Le numéro de suivi et l’identifiant du transporteur, lorsqu’ils sont disponibles.
- Les articles inclus dans cette expédition, en particulier pour les commandes fractionnées.
- Les coordonnées du client, sa langue, son fuseau horaire et ses préférences de canal.
- Le dernier statut d’expédition accepté et l’heure de l’événement.
- L’historique des notifications, y compris l’expédition concernée par chaque message.
Conservez séparément l’heure à laquelle l’événement s’est produit et l’heure à laquelle votre système a reçu la mise à jour. Un scan retardé ne doit pas automatiquement devenir une nouvelle alerte client. Conservez également la description originale du transporteur à côté de votre statut normalisé afin que le support puisse examiner les événements ambigus.
2. Définir des déclencheurs qui reflètent les changements importants de l’expédition
Un déclencheur doit représenter un changement pertinent pour le client, et non chaque nouvel enregistrement de suivi. Plusieurs scans effectués dans des centres peuvent tous signifier « en transit ». Envoyer une notification pour chacun d’eux crée du bruit sans aider le client à prendre une décision.
Associez les événements entrants à un petit ensemble de statuts compréhensibles. Le tableau suivant propose un flux de travail, et non un dictionnaire universel des statuts des transporteurs.
| Déclencheur | Condition d’envoi | Objectif du message |
|---|---|---|
| Étiquette créée | Facultatif ; distinguer la préparation de la prise en charge par le transporteur. | Expliquer que les informations de suivi sont disponibles. |
| Prise en charge par le transporteur | Un événement pris en charge indique que le transporteur a reçu le colis. | Confirmer que l’expédition est entrée dans le réseau du transporteur. |
| En transit | Étape facultative ; supprimer les scans de routine répétés. | Fournir une progression significative, et non un flux scan par scan. |
| Sortie pour livraison | Le statut entrant confirme explicitement cette interprétation. | Aider le client à se préparer à recevoir le colis. |
| Exception de livraison | Un problème important ou une action requise est identifié. | Expliquer le problème et l’étape utile suivante. |
| Livrée | Le transporteur signale la livraison de cette expédition. | Confirmer le résultat signalé et fournir un moyen d’obtenir de l’aide. |
Traitez les exceptions avec davantage de précaution que les étapes de routine. Une tentative de livraison échouée, un problème douanier, une adresse incorrecte et un retour à l’expéditeur peuvent nécessiter des instructions différentes. Si l’événement n’explique pas ce que le client doit faire, n’inventez pas de solution.
Pour une règle « aucune mise à jour récente », choisissez un seuil adapté au service et à l’itinéraire plutôt que d’appliquer un intervalle universel. L’absence de scans ne prouve pas qu’un colis est perdu. Orientez les cas incertains vers une file d’examen interne ou envoyez une mise à jour neutre décrivant précisément ce qui est connu.
Conservez les dates de livraison estimées séparément des statuts d’expédition. N’incluez une estimation que si vous disposez d’une source fiable, identifiez-la comme une estimation et évitez de remplacer des données manquantes par une promesse calculée que votre organisation ne peut pas tenir.
3. Choisir les canaux et définir les règles de contact
Utilisez un canal parce qu’il convient au message et aux préférences du client, et non simplement parce qu’il est disponible. L’e-mail constitue un point de départ pratique pour les mises à jour détaillées. Un canal plus immédiat peut être utile pour une action urgente, mais uniquement lorsque l’autorisation, les règles du fournisseur et les exigences locales le permettent.
- E-mail : adapté au contexte de la commande, aux liens de suivi, aux explications concernant les expéditions fractionnées et aux instructions de support. Incluez une version en texte brut et vérifiez l’affichage sur mobile.
- SMS : utile pour les alertes courtes et exploitables lorsque cela est autorisé. Identifiez l’expéditeur, restez concis et évitez d’exposer des informations de commande inutiles.
- Notifications push : appropriées lorsque les clients utilisent votre application et ont activé les notifications. Créez un lien vers l’expédition concernée plutôt que vers un écran d’accueil générique.
- Applications de messagerie : envisagez-les lorsque les clients utilisent déjà ce canal et que votre mise en œuvre respecte les exigences de la plateforme en matière d’autorisation et de messages.
- Page de suivi : utilisez-la comme destination de référence détaillée. Elle complète les notifications sortantes, mais ne remplace pas une alerte lorsque le client doit agir.
Documentez la relation entre les canaux. Vous pouvez par exemple utiliser l’e-mail pour les étapes de routine et un canal mobile autorisé pour un problème de livraison nécessitant une action. N’envoyez pas automatiquement chaque événement sur tous les canaux disponibles.
Définissez la gestion des heures silencieuses et une politique de secours. Un échec temporaire de l’e-mail ne doit pas automatiquement autoriser l’envoi d’un SMS. Avant de changer de canal, vérifiez que vous disposez des coordonnées et de l’autorisation appropriées et qu’un autre système n’a pas déjà envoyé le message.
Maintenez les mises à jour d’expédition à caractère opérationnel. L’ajout de contenu promotionnel peut influer sur le traitement d’un message en vertu des règles applicables. Aux États-Unis, les directives CAN-SPAM de la FTC expliquent que l’objectif principal d’un message est important lorsque du contenu commercial et transactionnel est combiné. Ne supposez pas que tout message mentionnant une commande est exempt des exigences relatives aux e-mails commerciaux.
4. Créer des modèles avec un comportement de repli clair
Chaque modèle doit répondre à trois questions : que s’est-il passé ? Qu’est-ce que cela signifie pour cette expédition ? Que doit faire le client ensuite ? Utilisez des champs conditionnels afin que les données manquantes disparaissent proprement au lieu de laisser des espaces réservés défectueux.
Les exemples ci-dessous sont des modèles de départ. Les variables entre crochets sont données à titre d’illustration et ne correspondent pas à la syntaxe d’un modèle propre à une plateforme.
E-mail de prise en charge par le transporteur
Objet : Votre expédition pour la commande [order_number] est en route
Bonjour [first_name],
[carrier_name] a reçu votre expédition pour la commande [order_number]. Vous pouvez suivre sa progression ici : [tracking_link].
[Si une estimation fiable est disponible : Livraison estimée : [estimated_delivery_date]. Cette estimation peut changer.]
[Si la commande est fractionnée : Cette expédition contient [shipment_items]. Les autres articles de votre commande feront l’objet de mises à jour de suivi distinctes.]
Message de sortie pour livraison
Selon la dernière mise à jour du transporteur, votre expédition pour la commande [order_number] est sortie pour livraison. Consultez sa progression et les détails de livraison disponibles : [tracking_link].
N’ajoutez pas d’heure d’arrivée garantie à moins que votre organisation dispose d’une base solide pour faire cette promesse. « Sortie pour livraison » est un statut signalé, et non la garantie que la livraison sera effectuée ce jour-là.
Message d’exception avec une étape suivante vérifiée
Objet : Mise à jour de livraison pour la commande [order_number]
Le transporteur a signalé [plain_language_issue] pour votre expédition. [verified_next_step]. Consultez les dernières informations ici : [tracking_link]. Si vous avez besoin d’aide, contactez-nous à [support_link].
Si aucune étape suivante n’est confirmée, remplacez cette phrase par : « Nous ne disposons pas encore d’une prochaine étape confirmée. Consultez la page de suivi pour obtenir des mises à jour ou contactez notre équipe d’assistance. » Dites que votre équipe enquête uniquement si un examen a effectivement été attribué.
E-mail de livraison
Objet : Votre expédition a été marquée comme livrée
[carrier_name] a marqué votre expédition pour la commande [order_number] comme livrée le [delivery_date]. Consultez les détails de livraison disponibles ici : [tracking_link]. Si vous ne parvenez pas à la trouver, contactez-nous à [support_link] afin que nous puissions vous aider à déterminer les prochaines étapes.
Utilisez une formulation au niveau de l’expédition pour les commandes fractionnées. « Votre commande est arrivée » peut être trompeur lorsqu’un autre colis est encore en transit. Si le nom du transporteur, la date ou le nom du client n’est pas disponible, utilisez une phrase alternative testée plutôt que d’afficher un champ vide.
5. Ajouter des protections contre les messages en double, obsolètes et trompeurs
L’automatisation doit conserver une trace de ce qu’elle a déjà effectué. Un flux de travail qui envoie simplement un message chaque fois qu’un événement arrive peut répéter des alertes après des nouvelles tentatives ou diffuser des informations obsolètes après une étape plus récente.
- Empêcher le traitement en double : utilisez un identifiant d’événement stable lorsqu’il est disponible. Sinon, définissez une clé de déduplication à partir de champs appropriés, tels que l’expédition, le type d’événement et l’heure à laquelle l’événement s’est produit. Enregistrez séparément si la notification correspondante a déjà été planifiée ou envoyée.
- Supprimer la répétition des statuts : plusieurs scans associés au même statut visible par le client ne doivent pas automatiquement produire plusieurs messages.
- Vérifier la pertinence de l’événement avant l’envoi : réévaluez les messages en file d’attente avant de les envoyer. Supprimez une ancienne alerte de transit si la livraison a été signalée depuis.
- Gérer les corrections délibérément : conservez l’historique original des événements et examinez les régressions apparentes. Ne supposez pas que chaque événement reçu plus tard est nécessairement plus récent ou plus exact.
- Effectuer les nouvelles tentatives en toute sécurité : faites la distinction entre un échec d’envoi et un résultat inconnu. Lorsque cette fonction est prise en charge, utilisez les fonctionnalités d’idempotence du fournisseur afin de réduire le risque qu’une nouvelle tentative crée un autre message.
- Protéger l’association au destinataire : n’associez jamais une expédition à un client uniquement sur la base d’une correspondance non vérifiée du numéro de suivi.
- Faire remonter les exceptions non résolues : désignez un responsable opérationnel au lieu d’envoyer plusieurs fois le même avertissement au client.
Pour les intégrations personnalisées, suivez l’approche documentée par le fournisseur en matière d’authentification, d’accusé de réception des événements et de nouvelles tentatives. Conservez des journaux de traitement utiles sans y copier de données personnelles inutiles. Les liens de suivi doivent également éviter d’exposer les commandes ou informations d’autres clients au-delà de ce dont le destinataire a besoin.
Une séquence de traitement utile est la suivante : valider l’événement, identifier l’expédition, mettre à jour son état, vérifier l’éligibilité à une notification, sélectionner un canal autorisé, générer le modèle, mettre le message en file d’attente et enregistrer le résultat. Revérifiez l’éligibilité au moment de l’envoi si le message reste dans une file d’attente.
6. Tester le parcours complet, puis lancer progressivement
Ne jugez pas le flux de travail uniquement en vérifiant si un e-mail de test semble correct. Testez l’ensemble du parcours, de l’événement d’expédition jusqu’à la destination du client, y compris les cas d’échec.
- Parcours normal : la prise en charge, le transit, la sortie pour livraison et la livraison produisent les messages prévus.
- Événement répété : la répétition du même événement ne crée pas une autre notification.
- Événement dans le désordre : un scan de transit retardé ne déclenche pas une alerte obsolète après la livraison.
- Commande fractionnée : chaque message identifie la bonne expédition et ne laisse pas entendre que tous les articles sont arrivés.
- Champs manquants : l’absence du nom, du transporteur, de l’estimation ou de la liste d’articles produit un texte de remplacement lisible.
- Restrictions de contact : le flux respecte les préférences de canal, les règles de suppression et les heures silencieuses configurées.
- Échec de livraison : les adresses invalides, les erreurs du fournisseur et les nouvelles tentatives produisent des résultats traçables sans renvois incontrôlés.
- Action du client : chaque lien de suivi et d’assistance mène à la destination prévue sur mobile.
Commencez avec un groupe limité d’expéditions et examinez l’historique des messages en parallèle de celui du suivi. Donnez au personnel d’assistance un moyen de voir ce que le client a reçu. Maintenez une commande de pause afin que l’équipe puisse arrêter une règle défectueuse sans désactiver le suivi des expéditions lui-même.
Surveillez l’éligibilité aux notifications, les tentatives d’envoi, l’acceptation par le fournisseur, les échecs, les doublons et le délai entre la réception de l’événement et l’envoi du message. L’acceptation par le fournisseur ne prouve pas que le client a lu le message, et les seuls taux d’ouverture ne prouvent pas que le flux de travail a été utile.
Pour évaluer l’impact sur les clients, comparez les taux de contacts liés aux expéditions en utilisant une définition cohérente et des groupes d’expéditions comparables. Tenez compte des changements dans la composition des transporteurs, des problèmes de livraison et du volume des commandes avant d’attribuer une évolution aux notifications.
FAQ
Faut-il envoyer une confirmation d’expédition lorsque l’étiquette est créée ?
Vous pouvez envoyer une mise à jour indiquant que l’étiquette a été créée, mais décrivez-la avec précision. Indiquez que les informations d’expédition sont disponibles ou que l’expédition est en cours de préparation. Réservez la formulation confirmant la prise en charge par le transporteur à un événement qui la justifie.
Les notifications d’expédition peuvent-elles fonctionner sans intégration API ?
Oui. Un flux de travail basé sur une application peut gérer la connexion et les règles de notification via son interface. Vérifiez les événements, les canaux, les contrôles des modèles et la gestion des exceptions disponibles dans la configuration choisie. Les intégrations personnalisées sont plus appropriées lorsque vos systèmes existants nécessitent un routage ou une logique de décision spécialisés.
Combien de notifications chaque expédition doit-elle recevoir ?
Il n’existe pas de nombre idéal universel. Commencez par des étapes distinctes et utiles ainsi que par des exceptions nécessitant une action. Supprimez les scans de transit répétés et n’ajoutez des messages que lorsqu’ils fournissent les informations dont le client a besoin.
Que doit-il se passer lorsque le suivi cesse d’être mis à jour ?
Appliquez une règle d’examen adaptée au service plutôt que de déclarer l’expédition perdue. Vérifiez le dernier événement, l’estimation de livraison lorsqu’elle est disponible et le processus opérationnel concerné. N’envoyez une mise à jour au client que lorsqu’elle ajoute une information vérifiée ou une prochaine étape utile.
Une notification de livraison peut-elle clôturer automatiquement un dossier d’assistance ?
Un scan de livraison peut mettre à jour un dossier, mais il ne doit pas automatiquement résoudre le signalement d’un client qui n’a pas reçu son colis. Traitez le statut de livraison du transporteur et le problème du client comme deux enregistrements distincts, puis suivez votre processus d’enquête.
Sources
- Fiche de l’application 17TRACK pour Shopify — référence produit pour évaluer une configuration de suivi et de notifications basée sur une application.
- 17TRACK Tracking API — référence produit pour une intégration de suivi basée sur une API.
- Documentation de l’API 17TRACK — référence de mise en œuvre pour vérifier le comportement et les exigences de l’intégration prise en charge.
- FTC : guide de conformité CAN-SPAM pour les entreprises — directives relatives aux e-mails commerciaux et aux messages combinant du contenu transactionnel et promotionnel.


