Timeline de statut de commande qui explique ce qui se passe, ce qui va se produire ensuite et quand s'inquiéter, en utilisant un modèle d'événements simple qui maintient les mises à jour cohérentes.
La plupart des tickets « Où est ma commande ? » ne concernent pas vraiment la livraison. Ils concernent l'incertitude. Si un client ne sait pas ce qui se passe, il demande à un humain même quand rien ne va mal.
Les mêmes questions reviennent : où est la commande maintenant, a‑t‑elle été expédiée ou est‑elle encore en préparation, quand arrivera‑t‑elle (et la date a‑t‑elle changé), puis‑je annuler ou modifier l'adresse, et que faire quand le tracking n'avance pas.
Lorsque votre équipe répond manuellement, deux problèmes surviennent rapidement. D'abord, ça ne scale pas. Un petit pic de commandes peut devenir un flot de tickets et les temps de réponse empirent. Ensuite, les réponses divergent. Un agent dit « en traitement », un autre dit « en cours d'emballage », et le client perçoit un conflit au lieu de la clarté. Cela engendre des relances et crée encore plus de travail.
L'objectif est simple : les clients doivent pouvoir consulter le statut de leur commande sans deviner ni nécessiter des réponses personnalisées. Une bonne timeline de statut le fait en transformant l'activité interne en une histoire claire que le client peut suivre.
La transparence ne signifie pas exposer chaque détail interne. Cela signifie que le client voit clairement l'état actuel en langage simple, quand il a changé (avec un horodatage raisonnable), ce qui se passe ensuite (et ce qui pourrait le retarder), et quand il est pertinent de vous contacter.
Quand les clients peuvent répondre eux‑mêmes à « que se passe‑t‑il et que dois‑je faire ? », beaucoup de tickets ne sont jamais créés.
Les clients ne consultent pas le suivi par curiosité. Ils cherchent des réponses rapides : où est ma commande maintenant, quand a‑t‑elle été mise à jour pour la dernière fois, et quelle est la prochaine étape prévue.
Une bonne UI de suivi raconte une histoire, pas seulement un label. « Expédié » est un label. Une histoire serait : « Emballé dans notre entrepôt hier à 15:12, pris en charge par le transporteur, prochaine mise à jour : scan en transit. » L'histoire réduit les conjectures, donc les gens n'appellent pas le support.
Trois éléments importent le plus sur une timeline de statut :
L'anxiété augmente quand le tracking est silencieux ou vague. Les déclencheurs principaux sont de longues périodes sans explication, un texte de statut qui peut signifier n'importe quoi (« En traitement ») et l'absence de créneaux de livraison. Si vous ne pouvez pas encore estimer la livraison, dites‑le franchement et expliquez ce que vous attendez, par exemple : « Nous afficherons une ETA après le scan du transporteur. »
L'exactitude compte plus que l'optimisme. Les gens pardonnent plus les retards que les promesses non tenues. Si vos données sont partielles, montrez ce que vous savez et évitez de faire semblant de tout savoir.
Un exemple simple : si un colis reste sur « Étiquette créée » pendant 36 heures, les clients supposent qu'il est bloqué. Une timeline utile ajoute du contexte : « Le transporteur n'a pas scanné le colis. Prochaine mise à jour attendue après la prise en charge. S'il n'y a pas de scan d'ici demain 17h, nous enquêterons. » Cette phrase peut éviter une vague de tickets « Où est ma commande ? »
Une bonne timeline de statut doit répondre en un coup d'œil à trois choses : où est la commande maintenant, ce qui s'est passé avant, et ce que le client doit attendre ensuite. Restez simple. Si les gens doivent lire un article d'aide pour comprendre la timeline, elle ne réduira pas les tickets.
Commencez par un petit ensemble de jalons compréhensibles par le client. La plupart des boutiques peuvent couvrir la majorité des questions avec un ensemble stable comme : Commande passée, Payée, Préparée, Expédiée, Livrée, plus des fins claires comme Annulée et Retournée.
Pour chaque étape, ajoutez une microcopie d'une ligne qui explique ce que cela signifie et ce qui se passe ensuite. Par exemple : « Préparée : Vos articles sont préparés dans notre entrepôt. Suite : remis au transporteur. » Cela évite le classique « Est‑ce que c'est vraiment expédié ? »
Affichez toujours les horodatages et indiquez la source de la mise à jour afin d'inspirer confiance. « Mis à jour 14:32 par Entrepôt » n'est pas la même chose que « Mis à jour aujourd'hui ». Quand la source est externe, indiquez‑le : « Mis à jour par le transporteur. » Si vous ne connaissez pas la source, ne devinez pas.
Les exceptions doivent être plus visibles que le progrès normal. Traitez‑les comme une étape distincte ou un badge clair sur l'étape concernée, en langage simple et avec l'action suivante. Exemples courants : Retard, Problème d'adresse, Tentative de livraison échouée.
Un modèle simple et fiable :
Exemple : un client voit « Expédié (Transporteur) 09:10 » puis « Tentative de livraison échouée 18:40 ». Si l'UI affiche aussi « Le transporteur n'a pas pu accéder au bâtiment. Prochaine tentative : demain », vous évitez des échanges à rallonge.
Votre workflow interne peut inclure des dizaines d'étapes : picking, packing, batching des étiquettes, remise au transporteur, relances, exceptions, etc. Les clients n'ont pas besoin d'un tel niveau de détail. Ils veulent des réponses claires à des questions simples : « Avez‑vous reçu ma commande ? », « A‑t‑elle été expédiée ? », « Quand arrivera‑t‑elle ? », et « Y a‑t‑il un problème ? »
C'est pourquoi il est utile de séparer les opérations internes des états visibles par le client. Gardez votre workflow interne aussi complexe que nécessaire, mais présentez un petit ensemble stable d'étapes qui ont du sens hors de l'entrepôt.
Une approche pratique est d'ajouter une couche de mapping : de nombreux événements internes se regroupent en quelques états de timeline. Par exemple, paiement autorisé, contrôle anti‑fraude passé et inventaire réservé peuvent remonter en « Commande confirmée ». Pick démarré, emballé et étiquette créée peuvent apparaître comme « Préparation ». Remise au transporteur et scans en transit deviennent « Expédiée ». Un scan « en cours de livraison » devient « En cours de livraison », et un scan de livraison plus photo devient « Livrée ».
Cette couche de mapping est aussi votre filet de sécurité. Si vous changez votre backend plus tard (nouveau transporteur, nouveau centre de fulfillment, nouvelle logique de retry), la timeline ne doit pas se mettre à sauter d'étapes ou à en ajouter de nouvelles. Les clients gagnent en confiance quand la timeline reste cohérente d'une commande à l'autre.
Rendez chaque état visible par le client lisible et accessible. Utilisez d'abord des libellés en texte clair, puis accompagnez‑les d'icônes et de couleurs. La couleur ne doit jamais être le seul signal. Un état retardé doit dire « Retardé » en toutes lettres. Gardez un contraste élevé, utilisez un marqueur clair pour l'étape actuelle, et rédigez un court texte d'aide comme « Nous préparons votre commande (généralement 1–2 jours). » Cela réduit les tickets « qu'est‑ce que ça veut dire ? » avant qu'ils n'apparaissent.
Une bonne timeline commence par une idée simple : stocker des événements, pas seulement le dernier statut. Un événement est un fait qui s'est produit à un moment précis, comme « étiquette créée » ou « colis livré ». Les faits ne changent pas après coup, donc votre timeline reste cohérente.
Si vous ne faites que remplacer un champ status = shipped, vous perdez l'histoire. Quand un client demande « Quand cela a‑t‑il été expédié ? » ou « Pourquoi c'est revenu en arrière ? », vous n'avez pas de réponse claire. Avec des événements, vous avez un historique et un audit trail fiables.
Gardez l'enregistrement petit et ennuyeux. Vous pourrez ajouter plus tard.
order_id : à quelle commande appartient l'événementevent_type : ce qui s'est passé (picked_up, out_for_delivery, delivered)happened_at : quand cela s'est produit (heure de l'action réelle)actor : qui l'a déclenché (system, warehouse, carrier, support)details : petites données supplémentaires (numéro de suivi, lieu, note)Quand votre UI rend la timeline, elle trie les événements par happened_at et les affiche. Si vous changez ensuite la manière dont vous nommez les étapes visibles, vous pouvez remapper les types d'événements sans réécrire l'historique.
Les systèmes de livraison renvoient souvent la même mise à jour. L'idempotence signifie : si le même événement arrive deux fois, il ne doit pas créer deux entrées dans la timeline.
L'approche la plus simple est de donner à chaque événement entrant une clé unique stable (par exemple, un ID d'événement du transporteur, ou un hash de order_id + event_type + happened_at + tracking_number) et de le stocker. S'il réapparaît, vous l'ignorez.
Une timeline fonctionne mieux quand elle reflète des moments réels que les clients reconnaissent, pas vos tâches internes. Commencez par lister les points où quelque chose change vraiment pour l'acheteur : l'argent capturé, une boîte existante, le transporteur en possession, l'arrivée.
Un petit ensemble suffit souvent pour répondre à la plupart des « Où est ma commande ? » :
Gardez les noms cohérents et spécifiques. « Préparé » et « Prêt » se ressemblent, mais signifient des choses différentes pour les clients. Choisissez un sens par événement et n'utilisez pas le même label pour un autre moment.
Tous les événements backend ne doivent pas apparaître dans l'UI. Certains sont uniquement pour votre équipe (contrôle anti‑fraude, début du picking, validation d'adresse). Une bonne règle : si le montrer générerait plus de questions que de réponses, gardez‑le interne.
Mappez les étapes internes en moins d'états clients. Vous pouvez avoir cinq étapes en entrepôt, mais la timeline n'affiche que « Préparation de votre commande » jusqu'à « Remis au transporteur ». Cela garde l'UI calme et prévisible.
Le temps compte autant que le label. Stockez deux horodatages quand c'est possible : quand l'événement s'est produit et quand vous l'avez enregistré. Affichez l'heure d'occurrence dans l'UI (heure du scan transporteur, heure de confirmation de livraison). Si vous n'affichez que l'heure de traitement, une importation tardive peut donner l'impression que le colis est retourné en arrière.
Les données du transporteur manqueront parfois. Prévoyez‑le. Si vous ne recevez jamais de scan « Remis au transporteur », affichez en fallback « Étiquette créée » avec un message clair comme « En attente du scan du transporteur. » Évitez d'inventer du progrès.
Un exemple concret : l'entrepôt imprime une étiquette à 10:05, mais le transporteur ne scanne qu'à 18:40. Votre modèle d'événements doit stocker les deux événements, mais votre timeline ne doit pas laisser supposer un mouvement pendant l'écart. Ce choix seul évite beaucoup de tickets « Il est marqué expédié mais n'a pas bougé ».
Étape 1 : rédigez d'abord la timeline client. Listez 5 à 8 étapes qu'un acheteur comprendra (par exemple : Commande passée, Payée, Préparée, Expédiée, En cours de livraison, Livrée). Rédigez la phrase exacte que vous montrerez pour chaque étape. Restez calme et précis.
Étape 2 : définissez des types d'événements et un mapping. Vos systèmes peuvent avoir des dizaines d'états internes, mais les clients doivent voir un ensemble réduit. Créez un tableau de mapping simple comme warehouse.picked -> Préparée et carrier.in_transit -> Expédiée.
Étape 3 : stockez des événements, puis calculez la vue. Sauvegardez chaque événement comme un enregistrement append‑only avec order_id, type, occurred_at et des data optionnels (comme le code transporteur ou le motif). L'UI doit être générée depuis les événements, pas depuis un champ de statut mutable.
Étape 4 : retournez une API prête pour la timeline. La réponse doit être simple pour le front : étapes (avec labels), index de l'étape actuelle, horodatages connus et un court message.
{
"order_id": "123",
"current_step": 3,
"steps": [
{"key":"placed","label":"Order placed","at":"2026-01-09T10:11:00Z"},
{"key":"paid","label":"Payment confirmed","at":"2026-01-09T10:12:00Z"},
{"key":"packed","label":"Packed","at":"2026-01-09T14:40:00Z"},
{"key":"shipped","label":"Shipped","at":null,"message":"Waiting for carrier scan"}
],
"last_update_at": "2026-01-09T14:40:00Z"
}
Étape 5 : gardez l'UI fraîche sans être bruyante. Pour une timeline, le polling toutes les 30 à 120 secondes suffit souvent durant le transport actif, et beaucoup moins souvent quand rien n'a changé.
Étape 6 : ajoutez des fallback pour les données retardées. Si le scan transporteur est en retard, affichez la dernière mise à jour connue et une action claire : « S'il n'y a pas de mise à jour d'ici demain, contactez le support avec la commande 123. »
Un exemple pratique : le client voit « Préparée » avec un horodatage, puis « Expédiée : En attente du scan du transporteur » jusqu'à l'arrivée de carrier.accepted. Pas de réponses personnalisées nécessaires, juste un état honnête.
Un client commande un sweat. Le paiement est instantané, mais l'emballage prend deux jours ouvrés. L'expédition rencontre ensuite un retard côté transporteur. Le client doit rester informé sans devoir contacter le support.
Voici la timeline que le client voit, jour après jour (même UI, juste de nouvelles entrées) :
| Jour et heure | Statut affiché | Message en langage simple |
|---|---|---|
| Lun 09:12 | Commande passée | « Nous avons reçu votre commande. Vous recevrez des mises à jour au fur et à mesure. » |
| Lun 09:13 | Paiement confirmé | « Paiement approuvé. Suite : préparation de votre colis. » |
| Mar 16:40 | Préparation de votre commande | « Nous emballeons vos articles. Date d'expédition prévue : Mer. » |
| Mer 14:05 | Expédiée | « Remise au transporteur. Le tracking sera mis à jour au fur et à mesure des scans. » |
| Jeu 08:30 | En transit | « En chemin. Estimation actuelle : livraison Ven. » |
| Ven 10:10 | Livraison retardée | « Le transporteur a signalé un retard dû au volume. Nouvelle estimation : Sam. Aucune action requise pour le moment. » |
| Sam 12:22 | En cours de livraison | « Avec votre livreur local. Arrive généralement aujourd'hui. » |
| Sam 18:05 | Livrée | « Livrée. Si vous ne la trouvez pas, vérifiez autour de l'entrée et auprès des voisins. » |
Remarquez ce qui a changé vendredi : vous n'avez pas créé un nouveau flow. Vous avez ajouté un événement (shipment_delayed) et l'avez mappé à un message client clair. Les étapes précédentes restent identiques et l'UI reste stable.
L'option de contact doit n'apparaître qu'après un seuil clair pour éviter les clics anxieux. Une règle simple fonctionne bien : afficher « Contactez‑nous » si la commande a dépassé de 24 heures la dernière estimation de livraison, ou si le statut n'a pas changé pendant 72 heures alors qu'elle est « En transit ». Avant cela, montrez de la rassurance et l'estimation actuelle.
Une bonne timeline réduit les messages « où est ma commande ? ». Une mauvaise en crée de nouveaux parce que l'UI et les données ne correspondent pas à l'expérience réelle.
Si vous exposez chaque étape interne, les clients se perdent. Quinze micro‑statuts comme « pické », « trié », « étiqueté », « en attente » et « en file » semblent chargés mais ne répondent pas aux deux vraies questions : « Quand arrivera‑t‑elle ? » et « Y a‑t‑il un problème ? » Gardez la timeline publique sur un petit ensemble de jalons clairs et laissez le reste interne.
Écraser le statut actuel sans sauvegarder les événements horodatés crée des contradictions. Un client voit « Expédié », rafraîchit et soudain ça indique « Préparation » parce qu'une relance ou une modification manuelle s'est produite. Stockez un historique d'événements horodatés et construisez l'état courant à partir de cet historique.
Les pièges courants sont faciles à repérer :
Voici pourquoi c'est important. Un article part aujourd'hui et le second est en rupture. Si vous affichez seulement « Expédié », le client s'attend à ce que tout soit parti. Si vous affichez « Expédié partiellement (1 sur 2) » et liez « Livrée » à chaque colis, la timeline reste crédible.
Considérez les labels de timeline comme du copy produit, pas des champs de base de données. Rédigez‑les pour des humains, puis mappez vos événements internes à ces quelques étapes conviviales.
Avant de déployer la timeline à tous les clients, faites une passe du point de vue du client : « Si je voyais ça à 23h, ouvrirais‑je quand même un ticket ? » L'objectif est la clarté sans laisser penser qu'il y a un problème.
Commencez par le temps et l'attente. Chaque commande doit afficher la « Dernière mise à jour » et suggérer ce qui se passe normalement ensuite. « Dernière mise à jour il y a 2 heures » + « Suite : prise en charge par le transporteur » réduit l'impression de blocage.
Checklist pré‑lancement :
Ensuite, testez quelques commandes « sales » volontairement. Prenez une commande à expédition fractionnée, une avec un transporteur qui scanne tard, et une avec une tentative de livraison échouée. Si la timeline ressemble à un mystère, les clients demanderont à des humains de l'interpréter.
Enfin, vérifiez que votre équipe support voit la même vue que le client, y compris horodatages et messages d'exception. Quand les deux parties lisent la même histoire, les réponses sont plus courtes et beaucoup de tickets ne sont jamais créés.
Commencez petit. Une timeline minimale qui répond aux questions clés (Avez‑vous reçu ma commande ? Quand sera‑t‑elle expédiée ? Où est‑elle maintenant ?) vaut mieux qu'un tracker compliqué plein de cas limites. Déployez d'abord les états de base, puis ajoutez du détail uniquement si les retours clients montrent que c'est utile.
Planifiez un déploiement progressif pour apprendre sans briser la confiance. Choisissez un petit sous‑ensemble de commandes (par exemple, un entrepôt, un mode d'expédition, ou un pays) et observez l'impact sur le volume de support et le comportement client avant d'élargir.
Ne devinez pas. Instrumentez la timeline pour vérifier si elle atteint son objectif. Comparez les raisons les plus courantes des tickets « Où est ma commande ? » avant et après le lancement, et suivez quelles pages de statut les clients consultent juste avant de contacter le support.
Un jeu de métriques de départ :
La plupart de la charge support vient des exceptions : étiquette créée sans scan, retard météo, problème d'adresse, envoi fractionné. Préparez des modèles de message pour ces cas afin que votre équipe donne la même réponse à chaque fois. Restez concis, clair et orienté action : ce qui s'est passé, ce que vous faites, ce que le client doit attendre.
Si vous prototypez l'UI et l'API événementielle, une plateforme vibe‑coding comme Koder.ai (koder.ai) peut être un moyen pratique de générer une première version depuis une courte conversation, puis d'affiner le copy et les mappings en vous basant sur les tickets réels.
Étendez la couverture par étapes. Quand la portion test montre moins de tickets (et pas de nouvelle confusion), déployez à d'autres types de commandes et transporteurs. Maintenez un rythme de revue régulier : toutes les quelques semaines, scrutez les nouveaux thèmes de tickets et décidez si la solution est une meilleure formulation, un nouveau modèle d'exception ou un nouvel événement alimentant la timeline.
Privilégiez une timeline courte et lisible qui répond à trois questions : que se passe-t-il maintenant, quand cela a-t-il changé pour la dernière fois, et quelle est la prochaine étape. La plupart des tickets viennent de l'incertitude, donc la timeline doit réduire les suppositions (par exemple « En attente du scan du transporteur » plutôt qu’un vague « En traitement »).
Utilisez un ensemble stable que la majorité des clients comprend :
Incluez aussi des fins claires comme Annulée et Retournée. Gardez les étapes internes (préparation/emballage/batch/retry) hors de la vue client.
Affichez l'horodatage pour chaque étape et un clair « Dernière mise à jour ». Si vous vendez à l'international, incluez le fuseau horaire (ou rendez‑le non ambigu). Un timestamp transforme « rien ne bouge » en « ceci est récent », ce qui évite les relances.
Traitez‑le comme une exception visible, pas comme un progrès normal. Un message par défaut utile est :
N'indiquez pas de mouvement que vous ne pouvez pas prouver.
Séparez les faits (événements) de la timeline cliente (états). Conservez les événements internes détaillés, puis mappez‑les en quelques étapes conviviales. Cela maintient l'interface cohérente même si le workflow entrepôt change.
Enregistrez les événements comme des faits append‑only (par exemple : label_created, picked_up, out_for_delivery, delivered) avec :
Utilisez l'idempotence. Donnez à chaque mise à jour entrante une clé unique stable (ID d'événement du transporteur, ou un hash des champs clés) et ignorez les doublons. Cela empêche des entrées répétées comme « En cours de livraison » qui apparaissent plusieurs fois quand le transporteur renvoie les mêmes infos.
Affichez la meilleure estimation disponible, et soyez honnête sur ce que vous attendez. Si vous n'avez pas encore d'ETA, dites‑le simplement (par exemple : « Nous afficherons une ETA après le premier scan du transporteur »). La précision vaut mieux que des promesses optimistes qui brisent la confiance.
Rendez les exceptions visibles et orientées action. Exemples courants :
Les exceptions doivent être plus visibles que le flux normal et indiquer au client quoi faire, si nécessaire.
Une règle pratique : afficher les options de contact seulement après un seuil clair, par exemple :
Avant cela, affichez des messages rassurants, la dernière mise à jour et la prochaine étape prévue pour éviter des clics anxieux.
order_idevent_typehappened_atactor (system/warehouse/carrier/support)details optionnelsPuis générez la timeline depuis l'historique des événements plutôt qu'à partir d'un champ de statut mutable.