- Pour qui ?
- Responsables exploitation, ADV, DSI et directions transport
- Question traitée
- Comprendre comment automatiser la saisie d’un ordre transport reçu par e-mail.
À retenir
- Le déclencheur peut être un e-mail, mais le dossier dépasse toujours ce message.
- Une donnée absente n’est pas forcément inconnue : elle peut dépendre d’une règle client validée.
- La vérification après saisie fait partie du workflow, au même titre que l’extraction.
- Un cas ambigu doit revenir à l’exploitant avec le contexte déjà reconstitué.
- Une checklist commune définit ce qui doit être présent, déduit selon une règle validée ou demandé avant toute écriture.
- Le dossier relie chaque champ à sa source, à l’action décidée et à l’état effectivement relu dans le TMS.
- Un statut « créé » n’est fiable qu’après une relecture indépendante de l’ordre et de ses identifiants.
La saisie commence par une décision métier
Un ordre transport contient des champs visibles — origine, destination, date, marchandise — mais aussi des décisions implicites. Quel compte utiliser ? Quel créneau est acceptable ? Cette modification remplace-t-elle la demande précédente ? Une simple extraction ne répond pas à ces questions.
Le premier travail consiste donc à qualifier l’événement. Est-ce une nouvelle commande, une modification, une annulation, une relance ou une pièce complémentaire ? Cette qualification détermine ensuite le dossier à créer ou à mettre à jour.
Les cinq couches d’un dossier exploitable
- 01Signal
Identifier le canal, l’émetteur, l’heure et la nature probable de la demande.
- 02Données explicites
Lire les références, adresses, créneaux, quantités, contraintes et pièces jointes.
- 03Contexte autorisé
Rapprocher les habitudes client et règles métier validées pour ce workflow.
- 04Décision
Déterminer l’action permise, les données à demander ou le niveau d’escalade.
- 05Preuve
Conserver les sources utilisées et vérifier le résultat après l’écriture dans le TMS.
Exemple : un e-mail incomplet mais pas inexploitable
Un client écrit : « Même enlèvement que mardi, livraison jeudi avant 10 h ». Le message ne contient ni l’adresse d’enlèvement ni la référence habituelle. Le workflow ne doit pas inventer ces données. Il recherche le contexte du client dans le périmètre autorisé, propose les valeurs issues du dossier de mardi et signale clairement leur origine.
Si la règle validée autorise cette reprise et que les contrôles sont satisfaits, l’ordre peut être préparé ou créé. Si deux dossiers du mardi correspondent, le cas devient ambigu : il revient à l’exploitant avec les deux candidats et le reste du dossier déjà complété.
Ce qu’il faut mesurer pendant un pilote
Ces mesures permettent d’étendre le périmètre sur des faits. Elles ne constituent pas une promesse de performance : les résultats dépendent des canaux, des règles, de la qualité des demandes et du niveau d’autorisation retenu.
- part des demandes correctement qualifiées ;
- part des dossiers complets sans reprise humaine ;
- motifs d’escalade et temps de résolution ;
- écarts entre l’action préparée et l’action validée ;
- résultat réellement enregistré dans le TMS ;
- modifications ou annulations correctement rattachées après création.
Checklist avant toute écriture dans le TMS
La checklist sert de barrière de pré-écriture. Elle doit être adaptée aux champs obligatoires, aux règles client et aux droits du workflow réellement déployé. Le modèle d’ordre transport fournit un support pratique pour réunir les informations ; la liste ci-dessous organise ensuite la décision d’écrire, de demander une précision ou de transmettre le dossier.
- La demande est qualifiée : nouvelle commande, modification, annulation, relance ou pièce complémentaire.
- L’émetteur, le client, les sites et les références permettent de rattacher la demande sans ambiguïté.
- Les dates, créneaux, adresses, marchandises, quantités et contraintes attendues sont présents ou couverts par une règle validée.
- Chaque valeur reprise depuis un historique, un référentiel ou une pièce jointe conserve sa source et sa version.
- Les contradictions entre l’e-mail, les documents et les données de référence sont résolues selon une priorité validée ou transmises à l’équipe.
- Le compte, le type de transport et les autres choix structurants du TMS sont déterminés sans extrapolation.
- L’action demandée entre dans le périmètre autorisé et les contrôles après écriture sont disponibles.
- Un responsable et un motif de reprise sont définis pour tout dossier incomplet, ambigu ou hors règle.
Exemple de dossier : de la source à l’état relu
Exemple fictif : un e-mail demande un enlèvement à Lille le 9 septembre et une livraison à Reims le lendemain. Une pièce jointe fournit le détail des palettes, tandis qu’une fiche client validée indique le compte TMS et la consigne de prise de rendez-vous. Avant d’agir, le dossier rend visible l’origine de chaque donnée et le traitement attendu.
| Source | Champs retenus | Action dans le workflow | État relu |
|---|---|---|---|
| E-mail reçu | Référence client, site d’enlèvement, dates demandées | Créer une nouvelle demande et conserver le message source | Référence, sites et dates retrouvés sur l’ordre |
| Pièce jointe | 3 palettes, poids annoncé, nature de la marchandise | Rattacher le document et préparer les lignes correspondantes | Quantités et unité conformes à la pièce jointe |
| Fiche client validée | Compte TMS, consigne de rendez-vous | Appliquer la règle dans son périmètre et tracer sa version | Compte correct et consigne visible sur l’ordre |
| Contrôle de cohérence | Créneau de livraison à confirmer | Suspendre la validation finale et demander une précision ciblée | Statut en attente ; aucune valeur de créneau inventée |
| TMS après écriture | Identifiant de l’ordre, statut, valeurs enregistrées | Relire l’écran ou la réponse du système et comparer au dossier préparé | Identifiant conservé et écarts éventuels transmis |
Choisir entre écrire, demander une précision et transmettre
Cette distinction évite deux erreurs opposées : bloquer toutes les demandes dès qu’un champ n’est pas écrit dans l’e-mail, ou compléter silencieusement un dossier avec une hypothèse. La bonne décision dépend des sources qui font foi, des règles validées et de la possibilité de contrôler le résultat.
| Situation | Décision | Trace attendue |
|---|---|---|
| Champs complets et règles applicables | Préparer ou écrire selon le niveau d’autorisation | Sources, règle utilisée, action et résultat relu |
| Une information manque mais une source autorisée fait foi | Compléter en indiquant la provenance | Valeur, source, version et contrôle effectué |
| Une seule question ciblée peut lever le doute | Demander la précision avant l’écriture concernée | Question envoyée, réponse reçue et nouvelle version du dossier |
| Plusieurs dossiers ou valeurs restent plausibles | Transmettre à l’exploitant sans choisir à sa place | Candidats, éléments déjà vérifiés et motif de l’ambiguïté |
| L’écriture ne peut pas être relue | Ne pas déclarer l’ordre créé ; placer le cas en reprise | Action tentée, état inconnu et contrôle à effectuer |
Questions fréquentes
Réponses directes
Faut-il une API TMS ?
Pas nécessairement. L’interface peut être utilisée sur un périmètre validé ; une API reste préférable lorsqu’elle existe et répond mieux aux contraintes de fiabilité, de volume ou de gouvernance.
Que se passe-t-il si une information manque ?
Le workflow recherche uniquement le contexte autorisé, demande une précision ou transmet le dossier à l’exploitant. Il ne doit pas inventer la valeur.
Une modification reçue plus tard reste-t-elle liée ?
Oui, si les éléments permettent de rattacher l’événement au bon dossier. Une ambiguïté déclenche une validation humaine.
Quelles informations faut-il réunir avant de saisir un ordre transport ?
La liste exacte dépend du TMS et du workflow. Elle couvre généralement les parties et sites, les références, les dates et créneaux, les marchandises et quantités, les contraintes, ainsi que les règles qui déterminent le compte ou le type de transport. Le modèle d’ordre transport lié à cet article aide à structurer cette collecte.
Comment prouver que l’ordre a bien été créé ?
Il faut relire le TMS après l’écriture, retrouver l’identifiant attribué et comparer les champs enregistrés au dossier préparé. Un clic, une requête envoyée ou un message de progression ne suffit pas à prouver le résultat.
Peut-on compléter automatiquement un e-mail incomplet ?
Oui, mais seulement lorsqu’une source autorisée ou une règle validée détermine la valeur sans ambiguïté. La provenance doit rester visible. Sinon, le workflow demande une précision ou transmet le dossier à l’équipe.
Sources et méthode
Cette ressource décrit la méthode produit Axonovia à partir de workflows transport. Les exemples sont illustratifs et ne constituent ni une promesse de performance ni une règle contractuelle universelle.
Relecture produit : Équipe Axonovia · prochaine revue recommandée avant le 31 août 2027 ou lors d’une évolution matérielle du périmètre.