Le rendez-vous GEODIS vise l’acheteur, pas le contact de réception

Une commande de matériel part vers un atelier, mais les informations de rendez-vous arrivent à l’acheteur du siège. La comptabilité possède l’adresse utilisée dans l’ERP ; la personne qui organise la réception travaille sur un autre site. Le vendeur retrouve une adresse email valide dans son logiciel et ne comprend pas pourquoi le destinataire attend toujours un contact transporteur.

En pratique, la correction doit commencer par le rôle de cette adresse. Un contact d’achat, de facturation ou de réception peut appartenir à la même entreprise sans remplir la même fonction. Le blocage vient du choix de l’interlocuteur : copier le premier email disponible ne désigne pas automatiquement la personne capable de choisir une date et de préparer l’accès à la marchandise.

Pour le rendez-vous web GEODIS, la recette doit relier la prestation choisie au contact désigné pour la livraison. Nous examinerons les champs documentés, la différence entre option et rendez-vous fixé, puis quatorze projections fictives écrites et relues en JSON. Le programme exécute 75 assertions locales ; il n’appelle aucun service GEODIS et n’envoie ni email ni SMS.

Notre accompagnement des vendeurs marketplace peut reprendre cette collecte avec vos équipes commerce, ADV et intégration. Le chantier logistique et fulfillment marketplace sert alors à retrouver le contact utile à la réception, la prestation disponible et la limite de ce que le vendeur peut annoncer au client.

Pour qui : un acheteur professionnel livre sur un autre site

Reconnaître une confusion de rôles avant une panne de messagerie

Ce diagnostic concerne les vendeurs qui expédient vers des agences, ateliers, magasins ou établissements dont la réception n’est pas organisée par la personne passant commande. La fiche de compte peut être correcte pour les échanges commerciaux et impropre à la coordination de ce transport. Le symptôme apparaît parfois seulement lorsque le lien reste sans réponse et que le support appelle plusieurs interlocuteurs pour trouver le bon site.

Commencez par une commande concernée. Retrouvez l’adresse de livraison, le contact sélectionné, la provenance de son email et le rôle convenu avec le client. Comparez ensuite ces données au fragment transmis par votre connecteur ou votre TMS. Une adresse correctement écrite peut avoir été choisie dans le mauvais bloc du dossier ; une enquête de délivrabilité ne corrigera pas cette sélection.

Autoriser une personne à cumuler les fonctions lorsqu’elle le peut

Paradoxalement, interdire l’email de l’acheteur peut refuser le bon contact. Un indépendant ou un responsable de petit établissement peut utiliser la même adresse pour commander, payer et convenir d’une livraison. La règle doit établir que cette personne organise bien la réception pour ce site et cette commande, sans exiger un interlocuteur supplémentaire que son entreprise ne possède pas.

Exemple concret : D conserve l’adresse d’achat avec une désignation de coordination confirmée et produit son fragment. C utilise cette même adresse sans confirmation du rôle et reste à qualifier. Le seuil d’admission de cette recette est une désignation connue pour le site demandé ; une seconde adresse n’apporte aucune preuve supplémentaire de cette attribution.

Anatomie du défaut : l’email existe, mais sa destination est déduite

Suivre la sélection du contact entre commande et expédition

Dans une chaîne courante, la marketplace fournit une commande, l’ERP retrouve un compte et l’outil transport prépare l’envoi. Chaque système peut posséder plusieurs coordonnées. Le défaut apparaît lorsque le mapping réduit cette structure à un champ email général, puis réutilise cette valeur pour une notification destinée à la réception. La donnée n’a pas été perdue ; sa signification a changé pendant la projection.

La recette conserve la référence du site et celle du contact choisi, avec la source qui les relie. Elle ne se limite pas à constater que le champ final est rempli. Si l’ADV doit ensuite expliquer pourquoi le lien a visé le siège, elle doit retrouver la sélection appliquée à cette commande, plutôt qu’un contact de compte modifié depuis dans l’ERP.

Éviter le repli silencieux vers la facturation

Un repli du type « prendre l’email du compte si le contact livraison manque » peut transformer une donnée absente en coordonnée apparemment exploitable. La commande traverse les étapes et l’erreur ne devient visible qu’au moment où le client cherche à organiser la réception. Le vendeur perd le motif qui aurait dû déclencher une demande de précision avant la projection.

Conservez cette absence comme un besoin à qualifier. Une personne habilitée peut désigner l’acheteur, un accueil ou un responsable du site, selon l’organisation réelle du client. Son choix doit rejoindre le dossier de livraison. Réutiliser une adresse de facture sans cette décision ne constitue pas une correction du contact manquant, même si cette boîte finit par transférer le message.

Lire les champs GEODIS sans confondre leurs fonctions

Séparer notification destinataire et information expéditeur

La documentation publique GEODIS API 2026.01.2, consultée le 14 octobre 2026, décrit RDW comme rendez-vous web. Elle indique un email de notification destinataire obligatoire pour cette option, distinct de l’email de notification expéditeur. Le champ SMS est présenté séparément. Ces données ne permettent pas de choisir, à elles seules, le bon interlocuteur dans votre compte client.

Dans le témoin A, le fragment local contient emailNotificationDestinataire avec reception@atelier.example et emailNotificationExpediteur avec transport@vendeur.example. Les noms correspondent aux champs documentés ; les adresses sont fictives. Le premier vise le contact retenu pour le site LYON, le second informe le vendeur. Inverser ces deux usages peut laisser le vendeur recevoir une information qui n’atteint pas la personne attendue pour la réception.

Distinguer rendez-vous web, appel et date souhaitée

Le même document distingue RDW, RDT pour le rendez-vous téléphonique et DSL pour une date souhaitée. Le référentiel de prestation possède aussi des indicateurs d’autorisation du rendez-vous web et téléphonique. La présence du nom d’une option dans la documentation ne démontre pas son ouverture sur le contrat et la prestation de votre vendeur.

Une date saisie par le client n’est pas nécessairement un créneau confirmé. Une sélection de rendez-vous web n’est pas un appel téléphonique. La recette doit garder ces différences dans le message présenté et dans la projection choisie. Une conversion automatique vers un autre mode peut supprimer le service attendu ; vérifiez son admissibilité avec votre interlocuteur transport avant de l’utiliser comme solution de remplacement.

Désigner le contact qui peut organiser cette réception

Rattacher la personne au site, pas seulement à la société

Une entreprise peut acheter depuis son siège et recevoir dans plusieurs établissements. Une adresse de compte ne suffit pas à identifier celui qui gère la livraison. Le dossier doit conserver le site retenu et la personne ou la fonction désignée pour coordonner la réception. Un accueil central peut convenir s’il assure effectivement ce rôle ; une correspondance de nom de société ne l’établit pas.

Cas concret fictif : le contact RECEPTION possède un email valide et une désignation confirmée, mais sa fiche concerne LILLE alors que la commande vise LYON. Le cas K refuse cette projection avec site_contact_mismatch. Le programme n’examine ni accès au quai ni présence d’une équipe. Il vérifie uniquement la cohérence du rattachement déclaré dans ses données locales, qui doit ensuite être éprouvée avec l’organisation du client.

Conserver le sens d’un contact partagé ou d’une boîte de service

Une boîte commune peut être plus adaptée qu’un email individuel si l’équipe qui la relève organise les arrivages. Ce choix dépend de son fonctionnement réel : qui lit les demandes, qui convient d’une date et qui transmet les contraintes au site ? Le connecteur ne peut pas déduire ces responsabilités du mot réception dans l’adresse.

Le commerce ou l’ADV confirme le contact avec le client ; l’intégration conserve cette désignation au bon niveau. Une règle de saisie peut aider à retrouver site, contact et coordonnées sans demander toute l’organisation interne de l’entreprise. Le résultat utile est une destination exploitable pour ce transport, avec une procédure de correction quand l’interlocuteur change.

Ne pas annoncer un rendez-vous fixé dès le choix de l’option

Conserver l’étape de prise de contact dans la promesse

La FAQ GEODIS sur les rendez-vous relie le parcours au service choisi par l’expéditeur. Elle précise que l’appel du service de proximité intervient à l’arrivée dans le département de destination pour l’option téléphonique ; elle décrit aussi une planification par le destinataire depuis une notification pour On Demand. Ces parcours ne doivent pas être remplacés par une étape unique inventée dans votre OMS.

Une commande peut donc poursuivre son transport alors que la coordination finale reste à organiser selon le service. La règle de votre vendeur précise ce qui doit être obtenu avant le départ et ce qui intervient ensuite. N’imposez pas un rendez-vous déjà fixé avant toute expédition simplement parce que votre écran ne sait afficher qu’une date. N’annoncez pas davantage une confirmation que le dossier ne possède pas.

Donner au support un état de coordination compréhensible

Le suivi métier distingue le contact désigné, la projection préparée, l’information effectivement transmise et le rendez-vous connu. Les preuves et systèmes disponibles déterminent lesquels peuvent être observés. Un fragment correct dans votre logiciel ne prouve ni qu’un message a été distribué ni qu’une personne a choisi une date. Le statut transmis au support doit garder cette limite.

Si l’acheteur signale qu’il n’a rien reçu, retrouvez d’abord le service, le site et la destination retenue. La cause peut être un mauvais contact, une notification pas encore attendue à ce stade ou un problème dans la transmission. Chacun appelle un interlocuteur et une vérification différents. Envoyer plusieurs relances à la même adresse ne permet pas de trancher ces situations.

Exercice corrigé : quatorze contacts fictifs avant projection

Le banc reçoit une commande O20, un site LYON, la capacité web déclarée et un contact RECEPTION. Ses données distinguent email d’achat, de facture, d’expéditeur et de réception. Chaque cas est écrit dans un fichier JSON, relu, puis transmis à la fonction locale de projection. Les sorties sont des fragments de notification, pas des demandes SHIPMENT complètes ni des résultats obtenus auprès du transporteur.

Lire les trois admissions sans mesurer une performance transport

A, D et E produisent un fragment. E change l’email général du compte vers la comptabilité, mais la sélection explicite du contact RECEPTION conserve reception@atelier.example. Le banc montre ainsi qu’une modification des coordonnées commerciales ne déplace pas la destination de livraison dans cette règle. Il ne teste pas la façon dont votre ERP propage réellement ses mises à jour.

Trois cas admis sur quatorze représentent seulement le résultat de cet ensemble construit. Ce n’est ni un taux de réussite client ni un taux attendu de délivrabilité. Les 75 assertions vérifient verdicts, conservation des entrées, destination retenue et absence d’appel ou de notification. Tous les cas gardent une confirmation de rendez-vous fausse ; aucun créneau n’a été réservé.

Attribuer les refus à la donnée qui demande une décision

F et G ne doivent pas être regroupés dans « problème contact ». L’un déclare la capacité web fermée, l’autre ne dispose pas de cette information. H et J manquent d’email destinataire, tandis que K possède une relation de site incohérente. N sort volontairement de la recette RDW. Le programme ne conclut pas que DSL serait indisponible ou incorrect ; il indique qu’un autre contrat doit être examiné.

Les désignations, disponibilités et révisions sont fixées à la main dans les données du banc. Son contrôle de syntaxe est élémentaire, sans validation exhaustive des adresses ni test de boîte. Le service réel doit identifier les sources de ces informations et ses conditions d’admission. Une sortie locale lisible facilite la recette ; elle ne remplace pas la confirmation du compte transporteur et du parcours destinataire.

Mettre le mapping sous contrôle dans l’ERP, l’OMS et le TMS

Décrire une projection de rôle plutôt qu’un simple renommage de champ

Le contrat d’entrée conserve commande, site, contact désigné, provenance des coordonnées, prestation et capacité vérifiée. Sa sortie explique la destination retenue ou la donnée à qualifier. Le mapping doit pouvoir être relu par l’ADV : un identifiant technique opaque sans nom de site ni motif de sélection rend difficile la correction d’une erreur que le client décrit en termes opérationnels.

Le contact d’expéditeur reste séparé de celui qui organise la réception. Le logiciel ne doit pas remplir les deux destinations avec une même adresse générale pour supprimer un champ vide. Une personne peut cumuler les rôles, mais ce cumul est une décision connue. La journalisation conserve les références utiles à l’enquête, sans transformer tous les messages de commande en copies de la fiche client complète.

Vérifier la donnée au moment où la projection va servir

Un panier ancien, une commande en attente ou une préparation reprise peuvent conserver un contact qui n’est plus le bon. Le cas M compare une révision locale capturée à 4 avec une révision courante à 5 et demande une revue. Cette politique du laboratoire ne suppose pas qu’un ERP fournit nativement un numéro de révision ; votre implémentation peut conserver une autre preuve de modification et de sélection.

La correction doit préserver ce qui a déjà été préparé ou transmis. Une nouvelle désignation ne change pas rétrospectivement le destinataire d’une notification passée. Le support retrouve l’ancienne sélection, le contact courant et les opérations encore modifiables dans les outils disponibles. Une modification de compte n’autorise pas à recréer aveuglément une expédition pour tenter de faire repartir le parcours de coordination.

Recetter le parcours au-delà du fragment correctement rempli

Comparer la commande source et la projection réellement utilisée

La première vérification examine les interfaces effectivement présentes : connecteur marketplace, passerelle ERP, OMS ou export vers le TMS. Le champ affiché dans le formulaire peut différer de celui que l’import emploie. Comparez les coordonnées et leurs références aux deux extrémités du flux, sur un périmètre autorisé, avant de conclure que le contact saisi par l’ADV est celui transmis.

Faites varier un site secondaire, un acheteur également réceptionnaire et un contact incomplet. Ajoutez un changement de fiche pendant une préparation ouverte. Le seuil de cette recette choisie est zéro substitution de rôle inexpliquée sur les témoins retenus. Cette exigence locale protège la correction du mapping ; elle ne promet pas zéro incident de transport dans votre exploitation.

Éprouver la réception de l’information avec le dispositif convenu

La suite nécessite le compte, la prestation et l’environnement de recette convenus avec GEODIS. Le référent transport ou intégration confirme le parcours admissible et les preuves accessibles. Une réponse de création, une étiquette ou une option enregistrée ne suffit pas à observer la coordination du destinataire. Il faut définir comment celle-ci sera testée et retrouvée sans présenter le fragment de notre laboratoire comme un envoi réussi.

Le rendez-vous réel doit ensuite être rapproché de la commande et du bon site selon les informations disponibles. Si cette étape ne peut pas être automatisée, un traitement attribué peut conserver l’avancement et le contact, sans annoncer de date inventée. Le monitoring sépare défaut de collecte, rejet de projection et coordination encore attendue ; ces situations ne demandent pas la même reprise.

Erreurs fréquentes : faire circuler un message au lieu de qualifier sa cible

Confondre adresse valide et interlocuteur approprié

Une vérification de format écarte certaines valeurs mal saisies ; elle ne sait pas qui organise la réception. L’adresse d’un service comptable peut passer ce contrôle tout en exigeant plusieurs transferts internes avant qu’une personne choisisse une date. Le coût caché apparaît dans les appels ADV, les recherches de contact et les reprises de coordination, même lorsque la messagerie semble techniquement disponible.

Le signal faible est une concentration des relances sur les comptes livrant vers plusieurs sites. Examinez leur modèle de contact avant de modifier toutes les notifications. Une correction ciblée peut porter sur la désignation au niveau du site ou de la commande, plutôt que sur un nouvel outil de routage chargé de deviner le bon interlocuteur à partir d’un email général.

Remplacer une coordonnée manquante par le premier canal disponible

Le cas J garde un numéro SMS mais manque de l’email requis dans notre projection RDW. Il est refusé. Le logiciel ne doit pas considérer deux canaux comme interchangeables sans examiner le service choisi. Une coordonnée disponible peut être utile pour un autre parcours et rester insuffisante pour celui que votre commande demande.

Une autre erreur consiste à convertir une option fermée en appel téléphonique sans vérifier prestation, coordonnées et attente du client. Le repli doit posséder son propre contrat et sa responsabilité. Lorsque cette alternative n’est pas établie, la commande garde un besoin à qualifier ; le connecteur ne remplit pas un mode différent uniquement pour obtenir une sortie sans erreur.

Plan d’action : corriger une sélection de contact sur un site pilote

Reconstituer les destinations avant de modifier les valeurs

Choisissez un vendeur, une prestation et quelques commandes dont la coordination a demandé des reprises. Réunissez la commande source, le site de livraison, le contact retenu, le fragment de notification et les observations accessibles dans les outils transport. L’ADV doit retrouver la sélection appliquée dans le dossier existant, sans entretenir un fichier parallèle de coordonnées qui divergerait à la prochaine mise à jour client.

Attribuez les décisions : le client et l’équipe commerciale qualifient la personne qui organise la réception ; le responsable transport confirme la prestation ; l’intégration conserve le mapping et ses contrôles. La responsabilité de correction reste visible pour un contact absent ou un service inconnu. Une même file générique « erreur livraison » ne permet pas d’adresser ces causes avec les bonnes preuves.

Ouvrir le nouveau mapping et préparer son retour arrière

Publiez la règle sur le site pilote après la recette de ses témoins, puis examinez les prochaines coordinations avec les équipes concernées. Comparez contacts repris, substitutions inexpliquées, demandes de précision et temps ADV, sans confondre une baisse des relances avec une meilleure réception si davantage de commandes restent bloquées en amont. Les résultats observés guideront l’extension ; aucun gain chiffré n’est établi par notre banc fictif.

Le rollback rétablit la règle de projection précédente dans son périmètre, mais n’annule pas une notification déjà distribuée. Préparez la liste des commandes concernées et la procédure qui qualifie leur contact courant. Le repli peut maintenir une préparation en revue plutôt que revenir au choix implicite qui avait produit le défaut. La correction doit rester explicable lorsque la personne habituelle de l’ADV est absente.

• Refuser le repli vers la facturation quand aucun contact de réception n’est désigné.
• Différer la projection RDW lorsque la capacité web de la prestation reste inconnue.
• Conserver l’acheteur comme destinataire lorsque son rôle de coordination est confirmé pour le site.
• Revoir la sélection modifiée avant de recréer ou de retransmettre une opération transport.

Si la recherche des commandes et de leurs exceptions mobilise chaque jour plusieurs canaux, une évaluation de Ciama pour les opérations marketplace peut accompagner le cadrage du cockpit. La collecte du contact, le mapping RDW et les preuves de coordination doivent être qualifiés sur vos interfaces ; cette évaluation ne suppose aucune fonction native GEODIS ni aucun rendez-vous déjà automatisé.

Guides complémentaires : garder contact, prestation et statut distincts

Qualifier la prestation d’un produit encombrant

La méthode de livraison des produits lourds et encombrants sur marketplace relie contraintes physiques, accès, zone et coût. Elle pose le contexte dans lequel une coordination de réception devient nécessaire.

Le présent diagnostic ajoute une frontière de données : même avec une prestation adaptée, le message peut viser un contact qui ne gère pas cette livraison. Le choix du transport et la désignation de la personne doivent être examinés chacun avec leurs propres sources.

Retrouver la règle appliquée dans le TMS

La méthode TMS marketplace, promesse et affectation transport décrit les responsabilités et les preuves utiles à l’exploitation. Le référentiel de prestation sert ici à examiner si le mode de rendez-vous demandé appartient au parcours retenu.

Une affectation correcte ne suffit pas à expliquer le contact sélectionné. Conservez cette information avec la règle de projection afin que le support distingue choix de service, coordonnées et étape de coordination quand plusieurs outils interviennent.

Maintenir les unités commerciales sans en déduire un interlocuteur

Le dossier MOQ, conditionnements et multiples côté vendeur précise ce qui est commandé et transmis à l’ERP. Une commande conforme en quantité peut néanmoins manquer d’un contact de réception désigné.

La personne qui négocie le lot peut organiser sa livraison ou déléguer cette étape. La règle commerciale ne tranche pas cette attribution. Le dossier de transport conserve le site et la désignation utiles à la réception, indépendamment du calcul des cartons et du montant facturé.

Ne pas transformer une notification en preuve de livraison

L’anatomie d’une commande déclarée livrée sans colis retrouvés examine la population qui doit soutenir un statut consolidé. Elle devient utile lorsque le cockpit ferme le dossier sur une information qui ne couvre pas ses expéditions.

Un contact sélectionné, un lien reçu ou un rendez-vous organisé ne constitue pas une réception physique. Gardez ces jalons séparés du statut de livraison. La coordination prépare l’arrivée ; les preuves transport disponibles déterminent ensuite ce que votre système peut déclarer sur la remise.

Conclusion : sélectionner une fonction de réception, pas un email par défaut

Le contact de livraison doit correspondre au site et à la personne désignée pour organiser sa réception. Cette fonction peut être assurée par l’acheteur, une équipe ou une boîte de service ; elle ne se déduit pas du premier email disponible dans le compte. La projection conserve le choix et le rattachement qui permettent à l’ADV de l’expliquer.

Les quatorze cas fictifs montrent pourquoi une valeur remplie ne suffit pas. Une désignation confirmée peut admettre l’acheteur ; une adresse valide peut rester impropre à un autre site ; un SMS présent ne complète pas automatiquement un email manquant pour le mode retenu. Le banc prépare des fragments locaux et ne mesure aucune notification distribuée ni aucun rendez-vous réel.

Corrigez une sélection observée sur un périmètre pilote, puis vérifiez sa transmission et le parcours convenu avec le transporteur. La recette de logistique et fulfillment garde capacité de prestation, destination, coordination et preuve de livraison distinctes. Une nouvelle règle de contact n’autorise ni à promettre un créneau absent ni à recréer une expédition déjà engagée.

Dawap peut examiner vos sources de contacts et vos mappings avec l’ADV, l’équipe transport et l’installateur ERP. Notre expertise agence marketplace pour les vendeurs relie la collecte du contact à sa projection dans les outils transport. Nous préparons les témoins et la reprise des dossiers concernés avec les équipes qui doivent expliquer cette sélection au client.