Photo de Jan Kopřiva sur Unsplash
« Où est ma commande ? » est l'e-mail le plus coûteux qu'une boutique en ligne puisse recevoir. Non pas parce qu'il est difficile d'y répondre, mais parce que répondre implique d'ouvrir le site du transporteur, de coller un numéro, de lire un statut danois qui ne signifie pas tout à fait la même chose que son équivalent norvégien, puis de le reformuler avec vos propres mots.
La solution n'est pas un plus joli modèle d'e-mail. C'est d'avoir l'état réel du colis dans votre propre système, sous une forme identique pour chaque transporteur que vous utilisez.
Neuf statuts, et c'est voulu
Chaque transporteur invente son propre vocabulaire. Nous ramenons tout cela à neuf statuts :
- created, l'étiquette d'expédition existe et le transporteur en a connaissance
- awaiting_pickup, en attente d'enlèvement par le transporteur
- picked_up, le transporteur a pris en charge le colis
- in_transit, en cours d'acheminement dans le réseau
- out_for_delivery, dans le véhicule de livraison
- ready_for_pickup, dans un point relais, en attente du destinataire
- delivered
- returned
- exception, un problème est survenu
Les statuts delivered et returned sont définitifs. Nous arrêtons d'interroger le transporteur dès qu'un colis atteint l'un d'eux, et plus rien ne peut l'en faire sortir. Un transporteur qui renvoie un ancien événement trois jours plus tard ne « dé-livre » pas un colis. Cela paraît évident, jusqu'au jour où vous voyez cela se produire dans le système de quelqu'un d'autre.
Deux façons de recevoir les mises à jour
Les transporteurs se répartissent en deux camps, et chacun est traité selon ses propres règles.
La plupart exposent une API de suivi, que nous interrogeons donc régulièrement. Une tâche horaire demande l'état de tout ce qui n'a pas encore atteint un statut définitif et convertit ce qui revient.
D'autres envoient eux-mêmes les informations. Event Cast de Bring, ainsi qu'Instabox, Budbee et Porterbuddy, transmettent les événements au moment où ils se produisent. Nous nous abonnons au moment de l'envoi et les événements arrivent sur une URL de rappel.
L'envoi automatique (push) est préférable et nous l'utilisons dès qu'un transporteur le propose. Mais les deux chemins aboutissent au même endroit : un service unique qui dédoublonne l'événement, l'enregistre et met à jour l'expédition, si bien qu'une chronologie est identique quelle que soit la manière dont elle a été alimentée. Vous ne devriez pas avoir à savoir dans quel camp se trouve un transporteur, ni à vous en soucier.
Ce que nous ne faisons pas, délibérément
Nous n'envoyons pas d'e-mails à vos clients. Il n'existe pas de page de suivi aux couleurs de Zippendo qui afficherait notre nom au bas de votre expérience de livraison.
À la place, vous recevez un webhook tracking.updated chaque fois qu'une expédition change d'état, et le même événement est disponible via Klaviyo, Customer.io, Mailchimp, SendGrid, Zapier et Make. Le message reste le vôtre : vos mots, votre modèle, votre domaine d'envoi, et c'est vous qui décidez si « en cours de livraison » mérite un SMS.
Nous pensons que c'est la bonne répartition des rôles. Vous connaissez vos clients. Nous savons où se trouve le colis.
Par où commencer
Activez le webhook tracking.updated et dirigez-le vers un outil qui enregistre les données. Observez de vrais colis passer par les neuf statuts pendant une semaine avant d'automatiser quoi que ce soit par-dessus. Vous découvrirez vite quels transporteurs sont bavards et lesquels restent silencieux deux jours en cours de route, et c'est bon à savoir avant de promettre un créneau de livraison à un client.