Aller au contenu
Retour

Dossier transport & opérations

Commandes transport multicanales : réunir e-mails, portails, EDI et appels

Comment traiter une commande transport dont les informations arrivent par e-mail, portail, EDI, document ou appel sans perdre le fil du dossier.

Mis à jour le 31 août 2026 7 minPar l’Équipe Axonovia
Pour qui ?
Exploitants, responsables transport et équipes SI
Question traitée
Structurer la gestion des flux entrants transport multicanaux.

À retenir

  • Le même transport peut être créé par EDI puis modifié par e-mail ou téléphone.
  • Chaque événement doit conserver sa source, son horodatage et son effet sur le dossier.
  • La priorité est le rattachement au bon contexte, pas l’uniformisation forcée des canaux.
  • Les conflits entre deux sources nécessitent une règle de priorité ou une escalade.

Pourquoi un canal unique ne suffit pas

Un portail peut créer la commande, un appel avancer le créneau et un e-mail joindre la pièce corrigée. Si chaque canal est traité dans une file séparée, l’équipe doit reconstituer manuellement la chronologie avant chaque décision.

Le bon modèle n’est donc pas « une boîte mail automatisée », mais un dossier qui reçoit des événements. Le dossier garde l’état courant tout en conservant les versions précédentes et la raison de chaque changement.

Une séquence multicanale typique

  1. 01
    08:12 · EDI

    Une nouvelle commande porte une référence client et les premières données.

  2. 02
    08:29 · Portail

    Un créneau est confirmé et complète le dossier.

  3. 03
    10:04 · E-mail

    Le client modifie le nombre de palettes et joint un document.

  4. 04
    11:17 · Appel transcrit

    L’interlocuteur demande de prévenir avant l’arrivée.

  5. 05
    Après traitement

    Le TMS et l’historique doivent refléter les informations retenues et leurs sources.

Les règles de continuité à définir

  • quels identifiants permettent de rattacher un événement ;
  • quelle source fait foi pour chaque type d’information ;
  • quels changements peuvent être appliqués automatiquement ;
  • quels délais ou changements rendent une validation obligatoire ;
  • comment conserver la trace d’une valeur remplacée ;
  • qui reçoit les événements impossibles à rattacher.

Commencer par un périmètre observable

Le pilote peut commencer par un seul type de commande et deux canaux fréquents. L’objectif initial est de mesurer la qualité du rattachement et la nature des exceptions, avant d’ajouter d’autres sources ou d’autoriser davantage d’actions.

Cette progression évite de confondre couverture théorique et fonctionnement fiable. Un canal est réellement couvert lorsqu’il est observé, compris, relié et contrôlé dans le workflow concerné.

Questions fréquentes

Réponses directes

Les appels peuvent-ils faire partie du dossier ?

Une transcription ou un compte rendu peut devenir un événement si le canal, le consentement et la qualité attendue sont cadrés. Le site ne suppose pas cette capacité active partout.

Comment traiter deux informations contradictoires ?

Le workflow applique la règle de priorité validée ou transmet l’arbitrage à l’équipe avec les deux sources.

Faut-il centraliser tous les outils ?

Non. Vigilo vise à relier le contexte tout en laissant les données et actions dans les outils retenus pour le workflow.

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.

Prochaine étape

Cartographier ce workflow dans votre exploitation

Partons d’un flux réel, des outils déjà utilisés et des décisions qui demandent encore du contexte.

Étudier ce workflow