Créez un tableau de suivi des envois qui stocke les numéros de suivi, récupère les mises à jour des transporteurs et envoie automatiquement des messages « out for delivery » ou « delayed » aux clients.
La plupart des questions « Où est ma commande ? » ne sont pas de la simple curiosité. Elles apparaissent quand les gens se sentent incertains : le suivi met du temps à se mettre à jour, le libellé des transporteurs est confus, ou la fenêtre de livraison passe sans message.
Pour les équipes support, cette incertitude se transforme en un flux continu de tickets, de chats et de relances. Un colis en retard peut facilement créer trois conversations séparées : « Des nouvelles ? », « Il est marqué livré mais je ne l'ai pas », et « Pouvez‑vous renvoyer le lien de suivi ? » Chacune prend du temps. Chacune augmente le risque d'une demande de remboursement ou d'un mauvais avis.
Le problème s'aggrave quand les informations de suivi sont dispersées. Si les numéros de suivi sont dans des feuilles de calcul, les mises à jour transporteur arrivent dans des boîtes mail et les détails de commande restent dans l'administration du magasin, chaque question client devient une mini‑enquête. Quelqu'un finit par copier‑coller des statuts, deviner ce que « In transit » signifie aujourd'hui, et oublier de prévenir le client quand quelque chose change.
Un tableau de suivi des envois corrige cela en transformant les mises à jour en source de vérité partagée et en envoyant le bon message au bon moment. L'objectif est simple : votre équipe voit ce qui se passe en un seul endroit, et les clients reçoivent des mises à jour proactives comme « out for delivery » ou « delayed » sans avoir à demander.
Ceci reste volontairement concret :
Si vous construisez cela avec un outil no‑code comme AppMaster, pensez en termes d'un flux fiable : stocker les détails de suivi, récupérer les mises à jour selon un planning, normaliser le statut, puis notifier quand c'est important.
Un tableau de suivi des envois reste utile si les données restent propres. Commencez par les enregistrements que vous manipulerez chaque jour, et résistez à la tentation de modéliser tous les détails d'un transporteur dès le départ.
Au minimum, vous avez besoin de quatre objets principaux : la commande, le client, l'envoi et le transporteur. Les commandes et clients existent déjà dans la plupart des systèmes, donc le travail nouveau est généralement l'enregistrement d'envoi : à quelle commande il appartient, quel transporteur est utilisé et le numéro de suivi (plus un nom d'affichage convivial comme « UPS Ground »). Si une commande peut être expédiée en plusieurs colis, prévoyez plusieurs envois par commande dès le départ.
L'historique des statuts est le suivant indispensable car il explique ce qui a changé et quand. Sauvegardez à la fois les champs « propres » que vous voulez afficher (type d'événement, horodatage, localisation) et le message brut du transporteur. Le message brut est votre filet de sécurité lorsque libellés sont ambiguës ou que vos règles de normalisation sont encore jeunes.
Un ensemble de départ pratique ressemble à ceci :
Ce journal de notifications compte plus qu'on ne le pense. Si un client dit « arrêtez de m'envoyer des SMS », vous devez prouver ce que vous avez envoyé, quand, et par quel canal. Il aide aussi à éviter les doublons quand un provider time‑out et que votre système réessaie.
Gardez la confidentialité simple mais effective. Limitez qui peut voir les numéros de téléphone et emails des clients, et séparez « voir le statut d'un envoi » de « voir le contact client ». Un utilisateur d'entrepôt peut avoir besoin du numéro de suivi, mais pas du téléphone du client.
Si vous construisez dans AppMaster, modélisez ces éléments comme entités séparées dans le Data Designer et ajoutez les rôles tôt pour que les écrans affichent les bons champs sans travail supplémentaire.
Un suivi fiable commence par une décision en apparence ennuyeuse : quels transporteurs comptent le plus. Choisissez les 1 à 3 transporteurs que vous utilisez chaque semaine, faites‑les fonctionner de bout en bout, puis ajoutez le reste.
Il y a trois façons courantes d'obtenir des mises à jour de suivi :
La façon dont les mises à jour arrivent compte autant que leur origine. Les webhooks (push) sont idéaux quand vous avez besoin de changements quasi temps réel, comme « out for delivery » ou un scan de livraison. Le polling (pull) est plus simple et fonctionne quand les transporteurs ne supportent pas les webhooks, mais il peut être en retard et coûte plus de requêtes.
Un setup pratique est hybride : webhooks quand possible, polling programmé comme filet de sécurité. Dans AppMaster, par exemple, vous pouvez accepter des événements webhook via un endpoint et exécuter un Business Process planifié pour revérifier les envois qui n'ont pas changé depuis 12 heures.
Rafraîchissez selon l'étape de l'envoi, pas avec un seul minuteur pour tout. Cela réduit les coûts et évite de surcharger les APIs.
Préparez‑vous aux pannes et retards des transporteurs. Stockez le dernier temps de vérification réussi, réessayez avec backoff, et affichez un horodatage clair « dernière mise à jour » dans le tableau pour que votre équipe sache si les données sont fraîches.
Les flux de suivi des transporteurs sont bordéliques. Un transporteur dit « Shipment information received », un autre « Electronic notification », et un troisième envoie dix scans « in transit » par jour. Si vous affichez tout tel quel, votre tableau devient du bruit.
Commencez avec un petit ensemble de statuts internes que votre équipe et vos clients comprennent, et gardez‑les stables en ajoutant des transporteurs :
Puis mappez chaque événement transporteur dans une de ces catégories. Vous pouvez mapper par code d'événement du transporteur, par texte d'événement, ou les deux. Gardez la règle simple : chaque événement entrant met à jour le statut interne seulement s'il fait avancer l'envoi, ou s'il signale un vrai problème.
Sauvegardez toujours la charge utile brute du transporteur (le JSON complet de l'événement plus le texte original). Votre tableau doit afficher le statut normalisé, mais le support et les ops doivent pouvoir ouvrir un envoi et voir exactement ce que le transporteur a envoyé quand quelque chose semble anormal.
Des événements inconnus arriveront. Traitez‑les comme « pas de changement » et enregistrez‑les pour révision. Les scans manquants arrivent aussi : un colis peut passer de « label created » à « out for delivery » sans rien entre les deux. Votre workflow doit permettre ces sauts sans générer d'erreurs ni envoyer des messages confus.
Un schéma pratique est de sauvegarder deux champs : internal_status et carrier_last_event_at. Si vous ne voyez plus d'événements pendant un moment, vous pouvez le marquer comme « needs review » en interne sans dire au client qu'il y a un retard.
Dans AppMaster, ce mapping s'intègre bien dans un Business Process qui prend un événement transporteur, écrit la payload brute, calcule le statut interne et met à jour l'envoi en une seule étape.
Un workflow ne fonctionne que s'il est prévisible. Traitez‑le comme un petit pipeline : capturez le numéro de suivi, récupérez les mises à jour, décidez de ce qui a changé, puis notifiez et enregistrez ce que vous avez fait.
Collectez les informations de suivi dès qu'une étiquette est créée. Prévoyez une saisie manuelle rapide et un import en masse depuis votre outil de fulfillment. Enregistrez le nom du transporteur, le numéro de suivi, l'ID de commande et l'heure d'ajout.
Récupérez les mises à jour transporteur selon un planning défendable. Par exemple : toutes les 2 heures pour « in transit », toutes les 30 minutes pour « out for delivery » et une fois par jour pour « delivered ». Chaque récupération doit enregistrer le dernier événement transporteur (statut, horodatage d'événement, localisation si disponible et message brut) pour que votre tableau reflète la vérité la plus récente.
Décidez de ce qui compte comme un réel changement. Un nouveau scan n'est pas toujours significatif. Déclenchez la logique quand le statut normalisé change (par ex. « in transit » vers « out for delivery »), quand une exception apparaît, ou quand il n'y a pas d'updates depuis trop longtemps (par exemple, pas de scan pendant 48 heures).
Envoyez le message et écrivez une trace d'audit. Chaque notification doit créer un enregistrement de log : qui a été notifié, canal (email/SMS/Telegram), template utilisé et résultat (envoyé, échoué, ignoré). Cela permet au support de répondre « Vous m'avez envoyé un message ? » en quelques secondes.
Gérez les échecs avec des règles calmes et ennuyeuses. Les timeouts et incidents d'API sont normaux. Réessayez avec des temps d'attente croissants (par ex. 5 minutes, 30 minutes, 2 heures), marquez l'envoi « update failed » après le dernier retry, et alertez l'équipe seulement si les échecs persistent sur de nombreux envois. N'envoyez pas d'alertes clients basées uniquement sur des données manquantes.
Si vous construisez dans AppMaster, vous pouvez modéliser envois et événements dans le Data Designer, exécuter le polling et la logique de décision dans un Business Process, et conserver le journal de notifications comme table de première classe pour les rapports.
Un tableau de suivi n'aide que si le support ou les ops peut répondre rapidement à la question : « Quelle est la situation actuelle et que dois‑je faire ensuite ? » Commencez par un écran principal qui ressemble à une boîte de réception.
Rendez la table principale terne et rapide. Mettez d'abord les champs que les gens scannent : nom du client, numéro de commande, transporteur, statut actuel et « dernière mise à jour ». Ajoutez une colonne « action suivante » (par exemple : notifier le client, attendre, enquêter). Ce petit indice réduit les approximations.
Les filtres sont l'endroit où le tableau devient utile. Gardez‑les centrés sur les problèmes :
Quand quelqu'un ouvre un envoi, la vue détail doit raconter l'histoire sans clics supplémentaires. Montrez une timeline de statut en langage clair et placez votre historique de contact à côté, pour éviter d'envoyer des messages contradictoires. Par exemple : « Client notifié du retard à 10:14 » et « Réponse client : laisser à la loge ».
Limitez les actions de masse à des fonctions petites, sûres et réversibles. Quelques actions qui rapportent généralement : renvoyer la dernière notification, envoyer une mise à jour manuelle (basée sur un template), ajouter une note interne et assigner à un collègue.
Si vous construisez dans AppMaster, visez deux écrans propres d'abord (liste et détail) avec les UI builders, puis étendez une fois que l'équipe trouve le flux quotidien naturel.
La façon la plus rapide de rendre le suivi utile (et pas intrusif) est d'envoyer moins de messages, mieux synchronisés. Commencez par les canaux que vos clients utilisent déjà : email pour la plupart des mises à jour, SMS pour les moments sensibles dans le temps, et Telegram si votre audience préfère le chat.
Gardez la bibliothèque de templates petite au départ. Une poignée de messages couvre la plupart des besoins : out for delivery, delayed, delivered et exception (problème d'adresse, retenu par le transporteur, retourné).
Chaque template doit répondre en un coup d'œil à trois questions : qu'est‑ce qui a changé, ce qui va se passer ensuite, et quand le dernier update transporteur a été vu. Incluez le numéro de commande et l'horodatage du dernier scan connu pour que le support puisse résoudre les tickets rapidement.
Les règles de timing comptent autant que le wording. Définissez des heures de silence (selon le fuseau horaire du client si possible) et limitez la fréquence pour ne pas envoyer cinq pings pour cinq scans. Une règle simple comme « max une mise à jour proactive par jour, plus livré » fonctionne bien pour beaucoup de boutiques, avec des exceptions pour des problèmes sérieux.
Les préférences n'ont pas besoin d'être sophistiquées pour être efficaces. Au minimum, conservez des flags d'opt‑out par canal (email off, SMS off, Telegram off) et respectez‑les dans tout le workflow. Si quelqu'un se désabonne du SMS, ne le notifiez pas « juste cette fois ».
Un bon défaut est de notifier seulement sur des changements de statut significatifs après normalisation, pas à chaque événement transporteur. Si le transporteur envoie trois scans « in transit », le client ne voit rien. Si ça bascule en « out for delivery », il reçoit un message.
Dans AppMaster, vous pouvez utiliser les modules email/SMS et Telegram intégrés, puis appliquer heures de silence et limites de fréquence dans un Business Process unique pour que les mêmes règles s'appliquent à tous les canaux.
De bonnes alertes tiennent moins de la fancy tech que de règles claires. Si la règle est vague, le message sera faux et les clients cesseront d'y faire confiance.
Commencez par définir « delayed ». Une règle pratique : « pas de nouveau scan dans X heures » (choisissez un nombre correspondant à votre vitesse de livraison) ou « fenêtre de livraison attendue manquée ». Utilisez les deux quand vous le pouvez : la première attrape les colis coincés tôt, la seconde attrape les livraisons en retard même si les scans continuent.
Pour « out for delivery », traitez‑le comme un moment unique. Les transporteurs répètent parfois cet événement. Envoyez le message client une seule fois par envoi, puis supprimez les répétitions sauf si le statut change réellement en un problème (par ex. une exception après « out for delivery »).
Pour « delivered », confirmez‑la avec le scan de livraison du transporteur et traitez‑la comme finale. Si vous demandez un retour, faites‑le plus tard (par ex. le lendemain) pour ne pas interrompre quelqu'un qui déballe encore son colis.
Les exceptions demandent des règles dédiées car elles nécessitent souvent une action. Les plus courantes : problème d'adresse, retenu en centre, tentative de livraison, et retour à l'expéditeur. Elles ne doivent pas toutes déclencher le même message client. Certaines doivent d'abord remonter à votre équipe, surtout si le client ne peut pas corriger le problème seul.
Un ensemble de règles simple et précis :
Dans AppMaster, gardez les règles éditables (heures seuil, seuil valeur élevée, heures de silence) pour pouvoir les ajuster sans reconstruire le workflow.
La confiance se perd vite quand le suivi paraît bruillant ou faux. La cause principale est de traiter le tableau comme un flux en direct de chaque scan transporteur. Les clients ne se soucient pas de « Arrived at facility » cinq fois de suite. Ils veulent quelques moments clairs qui changent leurs attentes.
Une autre erreur fréquente est la sur‑notification. Les gens se désabonnent quand les messages sont inutiles, et une fois qu'ils se désabonnent, vous perdez votre meilleur canal pour les vrais problèmes. Limitez les événements côté client (label created, out for delivery, delivered, delayed, exception) et laissez le reste dans le tableau interne.
Les retries peuvent aussi détruire la crédibilité. Si votre système time‑out et réessaie, il peut envoyer par erreur deux fois le même message « out for delivery ». Corrigez‑cela avec l'idempotence : enregistrez une clé unique par envoi et événement (par ex. shipment_id + normalized_status + event_time) et n'envoyez pas si vous l'avez déjà fait.
Un souci discret est de ne pas suivre le dernier sync réussi par envoi. Sans cela, soit vous re‑pull trop (créant des doublons) soit vous manquez des updates (créant du silence). Stockez un last_synced_at et l'ID du dernier événement transporteur traité, et ne les mettez à jour qu'après un pull réussi.
Hard‑coder les transporteurs est un autre piège. Ça marche pour un ou deux, puis l'ajout d'un nouveau transporteur devient une réécriture. Normalisez les données entrantes dans votre propre modèle de statuts et gardez le mapping spécifique transporteur en un seul endroit. Dans AppMaster, cela signifie souvent un « carrier adapter » Business Process réutilisable par fournisseur, alimentant les mêmes tables et la même logique de notification.
Avant d'activer le suivi côté client, faites une passe rapide axée sur la confiance : données correctes, mises à jour prévisibles et messages non spammés.
Commencez là où les erreurs commencent souvent : le fulfillment. Assurez‑vous que le numéro de suivi est capturé au moment de la création d'étiquette et validez‑le (format transporteur, non vide, pas d'espaces superflus). Si vous expédiez parfois en plusieurs colis, vérifiez que vous pouvez stocker plusieurs numéros de suivi par commande sans écraser le premier.
Une courte checklist qui attrape la plupart des lacunes :
Si vous construisez dans AppMaster, c'est le bon moment pour revérifier le Business Process qui récupère les mises à jour, les logs d'audit sauvegardés et les filtres sur lesquels votre équipe s'appuiera dès le jour 1.
Une petite boutique envoie environ 80 commandes par jour. Elle utilise deux transporteurs et les numéros de suivi sont ajoutés dès que les étiquettes sont créées. Malgré cela, la boîte support reçoit environ 20 messages quotidiens « Where is my order ? ». La plupart des clients ne sont pas en colère, ils sont juste incertains de ce que signifie le dernier scan.
Ils mettent en place un tableau de suivi des envois qui récupère les mises à jour selon un planning et affiche une vue simple : ce qui progresse normalement, ce qui est bloqué et ce qui nécessite une intervention humaine.
Le plus gros gain vient d'une règle : signaler tout envoi sans nouvelle mise à jour transporteur depuis 48 heures. Ces commandes vont dans une file « attention », tandis que le reste reste « in transit » et hors du champ de l'équipe. Le support arrête de courir après chaque commande et se concentre sur celles réellement à risque.
Quand un colis est effectivement retardé, le client reçoit un seul message clair et actionnable. Il ne répète pas chaque scan. Il explique ce qui a changé, ce que fait la boutique et ce que le client peut faire.
Message d'exemple pour un retard :
"Votre commande n'a pas bougé depuis 2 jours. Nous contactons le transporteur. Si vous en avez besoin de toute urgence, répondez à ce message par 'URGENT' et nous proposerons des options."
Après une semaine, la différence est nette. Le tableau montre clairement quelles commandes nécessitent une action (pas de scans, statut exception, problème d'adresse) versus celles qui sont simplement en transit. Avec moins de mises à jour vagues et moins de recherches manuelles, les tickets WISMO diminuent car les clients se sentent informés avant d'avoir à demander.
Si vous construisez cela dans AppMaster, vous pouvez modéliser commandes et envois dans le Data Designer, planifier le polling transporteur et envoyer emails ou SMS depuis le même workflow sans assembler plusieurs outils.
Commencez petit volontairement. Un tableau de suivi gagne la confiance s'il est précis, cohérent et facile à supporter. Le chemin le plus rapide est une version étroite que vous observez une à deux semaines, puis que vous élargissez.
Débutez avec un transporteur, un canal de notification et deux messages clients : « Out for delivery » et « Delayed ». Cela suffit pour valider que vos pulls fonctionnent, que le mapping des statuts tient et que les clients ne sont pas confus par le timing.
Une première version peut être simple :
Une fois les bases stables, ajoutez les éléments qui évitent les surprises : gestion des exceptions et alertes internes. Par exemple, si le suivi n'a pas été mis à jour depuis 48 heures, prévenez votre équipe au lieu de spammer le client. Si un transporteur renvoie une erreur, réessayez quelques fois puis marquez‑le pour révision.
Si vous voulez construire cela sans beaucoup de code, AppMaster (appmaster.io) est une option pratique pour modéliser les données, automatiser la logique avec des workflows visuels et envoyer des notifications de livraison depuis un seul endroit. Cela facilite aussi l'ajustement des règles plus tard sans laisser des rustines compliquées.
Avant d'étendre à plus de transporteurs et de types de messages, décidez comment vous allez l'opérer au quotidien : surveiller les pulls échoués, revoir les logs de messages et respecter les opt‑outs de manière cohérente. C'est ce qui garde le tableau utile à mesure que le volume augmente.
Un tableau de suivi des envois réduira‑t‑il vraiment les tickets « Where is my order ? »La plupart des équipes voient la baisse la plus significative lorsqu'elles arrêtent les recherches manuelles et commencent à envoyer quelques mises à jour proactives. Une source de vérité unique plus des messages « out for delivery », « delayed » et « delivered » éliminent généralement une grande partie des tickets WISMO.
Quelles données dois‑je stocker d'abord pour garder le tableau utile ?Commencez par l'enregistrement d'envoi, le numéro de suivi, le transporteur, le statut normalisé actuel et une table d'historique des statuts. Ajoutez tôt un journal de notifications pour prouver ce qui a été envoyé, éviter les doublons et respecter les opt‑outs.
Comment rendre les statuts des transporteurs lisibles au lieu d'être confus ?Gardez un petit ensemble stable comme Label created, In transit, Out for delivery, Delivered et Exception. Mappez les codes ou messages des transporteurs dans ces catégories et n'affichez le texte brut du transporteur que lorsqu'un collègue consulte les détails.
Dois‑je utiliser des webhooks ou du polling pour récupérer les mises à jour des transporteurs ?Un setup hybride est souvent le meilleur : webhooks quand le transporteur les fournit, plus du polling programmé en secours. Poller plus souvent pour « out for delivery », moins souvent pour « in transit », et arrêter après confirmation de livraison.
À quelle fréquence dois‑je rafraîchir les mises à jour ?Rafraîchissez selon l'étape du colis plutôt qu'avec un seul minuteur pour tout. Une valeur par défaut pratique : 1–2 fois/jour en pré‑transit, toutes les 4–8 heures en transit, toutes les 30–60 minutes pour out for delivery, puis arrêter après livraison.
Comment régler les notifications pour qu'elles soient utiles et non intrusives ?Notifiez sur des changements de statut significatifs après normalisation, pas à chaque scan. Une règle simple : « max une mise à jour proactive par jour, plus la confirmation de livraison », avec des exceptions pour de vrais problèmes comme des adresses erronées ou des retours.
Quelle règle utiliser pour considérer qu'un colis est « en retard » ?Définissez « delayed » avec des seuils clairs, par exemple « pas de nouveau scan pendant 24–48 heures » et/ou « fenêtre de livraison attendue dépassée ». Préférez d'abord des flags internes pour données manquantes et envoyez un message client seulement lorsque vous êtes sûr qu'il y a un problème.
Comment empêcher les doublons quand mon système réessaie ?Enregistrez chaque message avec l'ID d'envoi, le canal, le destinataire, le type de message, le timestamp et le résultat du provider. Utilisez une clé unique par envoi et événement (par ex. shipment + status + event_time) pour empêcher qu'un retry n'envoie le même alert deux fois.
Que doivent inclure les écrans du tableau pour le support et les opérations ?Donnez au support une vue liste rapide avec des filtres pour exceptions, pas d'updates depuis X heures, out for delivery aujourd'hui et livré aujourd'hui. Dans les détails d'un envoi, affichez une timeline en langage courant à côté de l'historique de contact pour éviter les messages contradictoires.
Puis‑je construire cela dans AppMaster sans beaucoup de code ?Oui — commencez avec un transporteur, un canal et deux messages (« out for delivery » et « delayed ») pour valider le flux. Dans AppMaster, vous pouvez modéliser les envois et événements dans le Data Designer, exécuter la logique dans un Business Process et garder notifications et logs dans la même application.
21 janv. 2026
8 min
20 janv. 20268 min
20 janv. 20268 minExpérimentez avec AppMaster avec un plan gratuit.
Lorsque vous serez prêt, vous pourrez choisir l'abonnement approprié.
