Un acheteur connecté à son portail voit un tarif négocié, son encours et un catalogue réservé. Le même produit apparaît aussi sur une marketplace ouverte, avec un prix public et une livraison standard. Si les deux canaux ne portent pas la même promesse, tout va bien. S’ils utilisent des règles implicites, un prix contractuel peut fuir, une commande hors conditionnement peut entrer ou un commercial peut découvrir trop tard qu’une offre publique concurrence son propre accord-cadre.
Le choix n’oppose donc pas un canal moderne à un canal ancien. Un portail B2B approfondit une relation connue ; une marketplace ouverte crée de la découverte auprès d’acheteurs que le vendeur ne maîtrise pas encore. Le premier accepte la singularité d’un compte. La seconde exige une offre comparable, commandable et exploitable selon les règles de la plateforme. Leur valeur dépend de cette différence, pas de leur apparence.
Le bon arbitrage consiste souvent à combiner les deux, mais pas avec le même assortiment ni les mêmes engagements. Contre-intuitivement, une couverture plus étroite sur la marketplace peut augmenter le chiffre d’affaires utile : les références simples attirent de nouveaux clients, tandis que les configurations, conditions et services complexes restent dans le portail. La frontière protège alors la marge, le support et la relation commerciale.
Une agence marketplace intervient précisément sur cette articulation entre acquisition, catalogue, opérations et rentabilité. Le sujet ne se résume pas à publier un flux supplémentaire : il faut décider quelles offres exposer, quelles données restent privées et comment chaque commande rejoint l’ERP sans perdre son contrat commercial.
Ne pas confondre accès privé et acquisition ouverte
Le portail B2B commence par une identité vérifiée. L’acheteur appartient à une entreprise, dispose d’un ou plusieurs rôles et accède à des conditions déjà convenues : prix, remises, assortiment, plafond de crédit, adresses autorisées, documents ou circuit d’approbation. La connexion ne sert pas seulement à sécuriser une page. Elle sélectionne le contrat qui doit gouverner la commande.
La marketplace ouverte commence par une intention d’achat. L’utilisateur cherche, compare et peut commander sans relation préalable avec le vendeur. La plateforme fournit l’audience, le cadre transactionnel et une partie de la confiance. En échange, elle normalise la présentation, le paiement, le niveau de service et parfois la communication client. Un produit incompréhensible hors contexte commercial y restera difficile à vendre, même si sa fiche est techniquement complète.
La question utile devient alors : la vente dépend-elle surtout de la découverte ou de la connaissance du compte ? Une référence standard, disponible et livrable à un prix public peut être découverte. Une configuration liée à un parc installé, un tarif négocié ou un engagement de volume doit être reconnue avant d’être commandée. Cette distinction donne un premier critère de canal plus fiable qu’une préférence d’outil.
Le portail B2B sert une relation commerciale déjà établie
Le portail est pertinent lorsque le client revient, commande pour plusieurs sites ou doit retrouver des règles propres à son organisation. Il peut afficher ses références habituelles, ses prix nets, ses reliquats, ses factures, ses avoirs et ses documents techniques. Le gain ne vient pas d’un catalogue caché, mais de la continuité entre la négociation, l’achat, la livraison et le service après-vente.
Cette continuité justifie des fonctions que le commerce grand public utilise peu : délégations, centres de coûts, paniers partagés, bons de commande, validation par montant, demandes de devis, commandes récurrentes ou listes propres à un établissement. Une entreprise peut autoriser un technicien à préparer un panier, un acheteur à le valider et la finance à consulter la facture. Le portail matérialise ces responsabilités au lieu de les reporter dans des e-mails.
Il ne doit cependant pas devenir une copie exhaustive de l’ERP. L’ERP conserve les comptes, contrats, stocks et écritures ; le portail présente les informations nécessaires à l’action du client. Lorsqu’une règle n’est pas assez fiable pour être exposée, mieux vaut l’isoler dans un devis que fabriquer une disponibilité ou un prix rassurant. Le self-service n’a de valeur que si sa réponse reste opposable.
La marketplace ouverte transforme l’offre en produit comparable
Sur une marketplace, le vendeur entre dans une catégorie partagée. Le titre, les attributs, le prix, la disponibilité et la promesse de livraison sont confrontés à d’autres offres. Cette comparabilité accélère l’acquisition, mais elle réduit l’espace disponible pour expliquer une exception commerciale. Une condition essentielle cachée dans une description longue produira des refus, des annulations ou du support.
La bonne offre ouverte possède une unité de vente évidente, un périmètre de livraison stable et un prix calculable avant le paiement. Elle peut conserver une technicité élevée si les compatibilités sont structurées et si le client peut vérifier son choix sans intervention commerciale. En revanche, une référence dont le prix dépend du chantier, du pays, du volume annuel et de la qualification du compte n’est pas devenue standard parce qu’un flux sait la publier.
La marketplace apporte aussi ses propres contraintes : barème de commission, délais de traitement, règles de contenu, qualité de service, retours et litiges. L’audience a donc un coût opérationnel qui doit être rapproché de chaque famille de produits. Le volume brut ne suffit pas pour juger le canal. Une offre très visible peut dégrader la marge si elle génère des transports atypiques ou des questions que la fiche ne peut résoudre.
Choisir le canal à partir du niveau de négociation
Distinguer condition commerciale et configuration de commande
Une remise par volume n’impose pas automatiquement un portail. Si le barème est public, stable et compatible avec le moteur de la marketplace, il peut devenir une offre par lot. À l’inverse, un prix fixé pour un groupe de clients, associé à une ristourne annuelle ou à un service inclus, dépend d’une identité contractuelle. L’exposer publiquement créerait une ambiguïté que le support ne pourrait pas corriger après paiement.
La négociation porte parfois moins sur le prix que sur le risque. Un acheteur peut demander une date garantie, un certificat, une installation ou une pénalité de retard. Ces engagements modifient la responsabilité du vendeur et doivent être acceptés explicitement. Le portail ou le devis permettent cette validation. La marketplace reste adaptée à la partie standard de l’offre, à condition de ne pas laisser croire qu’elle inclut les mêmes garanties.
Reconnaître les signaux d’une vente non standard
Trois signaux invitent à conserver le parcours privé : le résultat dépend d’une information détenue par le commercial, la commande doit être approuvée avant engagement, ou le prix final ne peut pas être calculé avec les données de la fiche. Si l’un de ces cas représente l’exception, une file de devis suffit. S’il constitue la majorité des ventes, la marketplace ne doit servir que d’entrée de gamme ou de canal de génération de demande.
Le test doit partir d’une commande réelle, pas d’une fiche idéale. L’équipe demande si un acheteur inconnu peut choisir la bonne référence, connaître son prix final et comprendre la livraison sans appel. Chaque réponse négative révèle soit une donnée à structurer, soit une décision qui doit rester dans le portail. Cette lecture empêche de confondre une amélioration de contenu avec une négociation impossible à automatiser.
Segmenter l’assortiment au lieu de dupliquer tout le catalogue
Le même catalogue maître peut alimenter plusieurs canaux, mais chaque canal doit recevoir un assortiment décidé. La segmentation commence par les usages : produits immédiatement commandables, références qui ouvrent la relation, consommables récurrents, pièces liées à un équipement, configurations sur devis et services. Cette lecture évite de raisonner seulement par marque ou catégorie, alors que deux références voisines peuvent exiger des parcours très différents.
Une matrice simple croise découvrabilité et complexité transactionnelle. Une offre facile à comparer et simple à exécuter convient à la marketplace. Une offre simple mais réservée à des comptes connus convient au portail. Une offre visible mais complexe peut être présentée publiquement avec une demande de qualification, sans promettre une commande immédiate. Une offre à la fois privée et complexe reste dans le parcours commercial assisté.
Exemple concret. Sur un catalogue de 1 000 références, une équipe peut ouvrir 120 références standard sur la marketplace, proposer 450 références contractuelles dans le portail et laisser les configurations restantes sur devis. Ces nombres ne sont pas une norme : ils forcent une décision vérifiable. Si 30 des 120 offres ouvertes génèrent l’essentiel des annulations, il faut réduire cette cohorte avant d’étendre, pas publier les 880 références suivantes.
Les passerelles entre canaux restent possibles. Une marketplace peut faire découvrir un consommable puis orienter le compte professionnel vers un contrat récurrent. Un portail peut afficher une référence publique lorsqu’aucune condition privée ne s’applique. L’important est de conserver la provenance du prix et de la promesse, afin qu’un passage d’un canal à l’autre ne remplace pas silencieusement le contrat.
Protéger les tarifs contractuels et l’identité des comptes
Le risque le plus coûteux n’est pas seulement qu’un tarif privé soit visible publiquement. Il peut aussi être appliqué au mauvais établissement, mis en cache après une déconnexion ou associé à un compte dont le contrat a expiré. Le moteur tarifaire doit donc recevoir une identité commerciale complète : société, établissement, contrat, devise, date d’effet et éventuels segments. Un simple e-mail utilisateur ne suffit pas toujours.
La marketplace reçoit un prix public calculé pour ce canal, jamais le résultat d’un moteur appelé sans contexte. Le portail demande un prix contractuel et affiche sa période de validité. Lorsque le calcul échoue, la réponse sûre n’est pas nécessairement le prix catalogue : cela pourrait transformer une indisponibilité technique en changement commercial. Selon le produit, le système bloque la commande, maintient un prix précédemment validé pendant une durée bornée ou bascule vers un devis.
Les promotions doivent suivre la même séparation. Une remise financée sur une marketplace n’a pas à réduire le prix privé, et une condition négociée ne doit pas alimenter un prix barré public. L’analyse des tarifs B2B et de la marge aide à relier prix affiché, commissions, transport et coût de traitement au lieu de comparer deux montants hors contexte.
Traiter MOQ, colisages et devis comme des règles de commande
Un minimum de commande, un multiple de vente et une unité logistique ne sont pas des notes de bas de page. Ils déterminent ce que l’entrepôt peut préparer et ce que le client paie. Si une fiche affiche l’unité mais que l’ERP interprète un carton de douze, l’erreur survient avant même la synchronisation. Chaque offre doit porter une unité de vente, une quantité par colis et une règle d’arrondi explicites.
La marketplace convient lorsque ces règles peuvent être exprimées dans son modèle : lot fixe, quantité minimale stable ou déclinaison dédiée. Lorsqu’un MOQ dépend du fournisseur, du compte ou du transport, le portail offre davantage de contexte. Il peut expliquer le seuil, proposer la quantité valide suivante et conserver le motif. Les règles de MOQ et de conditionnement doivent être partagées avec l’ERP, pas recodées dans chaque interface.
Le devis répond à une autre incertitude : le vendeur ne peut pas encore s’engager sur le prix, la date ou la configuration. Il ne doit pas être utilisé pour masquer un catalogue incomplet. Un workflow de demande de devis utile possède une date de réponse attendue, un responsable, une version de l’offre et une expiration. La commande finale référence cette version afin que la négociation ne disparaisse pas lors de la saisie.
Attribuer une source de vérité à chaque donnée
Le modèle hybride échoue lorsque le portail, la marketplace et l’ERP peuvent tous modifier la même vérité. Le PIM peut gouverner les descriptions et attributs ; l’ERP, les comptes, contrats et écritures ; l’OMS, l’orchestration des commandes ; le WMS, le stock physique ; le moteur tarifaire, le prix contextualisé. Les canaux consomment ces décisions et renvoient des événements, mais ne deviennent pas automatiquement leurs propriétaires.
Cette répartition doit descendre au niveau du champ. Le stock physique ne suffit pas à calculer le stock publiable, car réservations, sécurité et capacité logistique interviennent. La date fournisseur ne devient pas une disponibilité confirmée. Le titre peut être enrichi pour une marketplace sans écraser la désignation interne. Chaque transformation conserve la source, la version et le canal cible afin de reconstruire une offre litigieuse.
Une règle de priorité explicite traite aussi les conflits. Si une offre a été suspendue manuellement après un incident, un prochain export ne doit pas la réactiver parce que le PIM la considère complète. L’état de diffusion et sa raison possèdent leur propre autorité. Cette séparation réduit les corrections fantômes où chaque système rétablit légitimement une valeur que l’autre vient de retirer.
Unifier la commande sans effacer les différences de canal
Les commandes peuvent rejoindre une file commune sans devenir identiques. Une commande marketplace porte l’identifiant de la plateforme, ses délais d’acceptation, ses frais, son adresse et ses règles de message. Une commande portail porte le compte, le contrat, le bon d’achat, les approbations et éventuellement l’encours. L’OMS normalise ce qui sert à préparer et facturer, tout en conservant les attributs nécessaires au service du canal.
L’idempotence protège l’import lorsque la plateforme renvoie un événement ou lorsque l’ERP répond après un timeout. La clé associe canal et identifiant de commande ; elle ne dépend pas seulement du numéro visible par le client. Une file de traitement persiste le message avant l’appel aval, applique les mutations dans l’ordre et place les échecs non récupérables en quarantaine. Un retry ne doit jamais recréer la commande ni consommer deux fois l’encours.
Les accusés d’exécution remontent ensuite vers le bon canal. L’acceptation, l’expédition, le tracking, l’annulation et le remboursement utilisent le vocabulaire attendu par la plateforme ou le portail. Une table de correspondance versionnée évite qu’un statut ERP ambigu soit publié comme une promesse client. La réconciliation compare périodiquement source et cible pour retrouver une commande préparée mais restée « en attente » dans l’interface.
Comparer la marge nette et le coût de service
Le portail évite certaines commissions, mais il demande acquisition directe, maintenance, authentification, support et évolution fonctionnelle. La marketplace facture son audience et impose des opérations spécifiques, mais elle peut ouvrir un segment que l’équipe commerciale n’aurait pas atteint. Comparer uniquement le taux de commission au coût du portail produit donc un arbitrage incomplet.
La contribution par commande part du chiffre d’affaires net et retire remise, commission, paiement, préparation, transport, retours, gestes commerciaux et temps de support attribuable. Pour le portail, il faut aussi répartir le coût de la plateforme et du maintien des contrats. Pour la marketplace, la publicité, les pénalités et les opérations de contenu rejoignent le calcul. Le résultat se lit par cohorte de produits et de clients, pas seulement au niveau du canal.
Cas concret. Une gamme génère 80 commandes mensuelles sur une marketplace et seulement 45 via le portail. Si la première mobilise 24 heures de support et la seconde 6 heures, le volume ne permet pas de conclure. L’équipe rapproche contribution et charge, puis décide : conserver l’offre ouverte si elle recrute des comptes rentables, simplifier la fiche si le support vient d’une mauvaise information, ou retirer la gamme si chaque vente détruit durablement de la marge.
Préserver la relation client et les données d’usage
Le portail permet au vendeur de connaître les rôles, les récurrences et les besoins d’un compte. Cette connaissance améliore le réassort, le service et la négociation, à condition de limiter les données aux finalités attendues. La marketplace conserve souvent une partie de l’identité et encadre la communication. Il faut accepter cette médiation dans le modèle économique au lieu de bâtir une stratégie qui dépend d’informations indisponibles.
Chaque canal peut contribuer au parcours sans chercher à capturer l’autre. La marketplace sert la découverte, la transaction standard et la preuve de demande. Le portail prend le relais lorsqu’un compte qualifié a besoin de prix, de rôles ou de services contractuels, dans le respect des règles de la plateforme. À l’inverse, le portail peut proposer une offre publique lorsque le client souhaite un achat ponctuel sans négociation.
La continuité s’observe dans les références partagées : produit, client autorisé, commande et document. Une équipe support doit pouvoir retrouver l’origine d’une vente et savoir quel engagement s’applique. Elle ne doit jamais promettre au client portail le délai standard de la marketplace ni accorder au client public un service réservé à un contrat, simplement parce que les deux commandes se ressemblent dans l’ERP.
Pour qui le modèle hybride est-il pertinent ?
Le modèle hybride convient aux fabricants, distributeurs et grossistes qui servent déjà des comptes contractuels tout en cherchant de nouveaux acheteurs sur des offres standard. Il devient particulièrement utile lorsque certaines références se commandent seules tandis que d’autres exigent prix négocié, compatibilité, volume, document ou service. La coexistence des parcours reflète alors la diversité commerciale réelle au lieu de la masquer.
Il est moins pertinent pour une entreprise dont toutes les ventes nécessitent une étude et dont aucune offre ne peut être comprise publiquement. Dans ce cas, un portail ou un parcours de qualification suffit. À l’autre extrême, un vendeur sans contrats spécifiques ni récurrence de compte n’a pas besoin de financer un portail complexe : la marketplace et un site transactionnel peuvent couvrir l’essentiel.
Le prérequis n’est pas la taille du catalogue, mais la capacité à gouverner deux promesses. Si l’équipe ne sait pas attribuer les prix, les stocks et les incidents par canal, elle commence par fiabiliser un seul flux. Le second canal s’ouvre lorsque l’organisation peut expliquer une différence au client, la mesurer dans la marge et la corriger sans consigne informelle.
Organiser l’équipe autour de deux promesses de service
Le commerce possède les contrats et les exceptions du portail. L’équipe marketplace possède l’offre publique, les règles des plateformes et la performance vendeur. Le catalogue garantit la qualité des données communes. Les opérations exécutent les commandes ; la finance rapproche prix, frais et encaissements ; le support traite les écarts selon la promesse du canal. Cette répartition évite qu’un responsable marketplace modifie un tarif contractuel ou qu’un commercial réactive une offre publique suspendue.
Les deux équipes partagent néanmoins une revue des collisions : prix incohérents, stock alloué deux fois, offres devenues non rentables, retours récurrents, demandes publiques qui devraient devenir contractuelles. La réunion ne parcourt pas tous les indicateurs. Elle tranche les cas où une décision de canal est nécessaire et attribue la correction, son délai et sa preuve.
En incident, le gel doit pouvoir viser un canal sans couper l’autre. Une fuite de tarif public impose de suspendre les offres concernées, pas forcément les commandes privées dont le calcul reste sain. Une indisponibilité du moteur contractuel peut bloquer le portail tout en maintenant des prix publics pré-calculés. Les runbooks décrivent ces frontières avant la panne, avec les personnes autorisées à les activer.
Concevoir une architecture hybride sans double vérité
Séparer les décisions communes des projections par canal
Le socle commun porte les identifiants, le contenu maître, les contrats, le stock diffusable et les règles de commande. Une projection portail ajoute identité du compte, prix privé, rôles et documents. Une projection marketplace ajoute taxonomie, attributs obligatoires, prix public, stock alloué et délai compatible. Les projections sont recalculables ; elles ne deviennent pas des bases concurrentes où l’on corrige directement une erreur.
Les API synchrones conviennent aux décisions qui doivent être connues avant l’action, comme l’autorisation d’un compte ou le prix d’un panier privé. Les événements et files asynchrones conviennent à la diffusion du catalogue, au stock et aux accusés de commande, à condition d’exposer leur fraîcheur. Chaque message possède un identifiant, une version de règle et une clé d’idempotence. Les webhooks entrants sont vérifiés, persistés puis traités hors de la requête de réception.
Prévoir le repli avant d’ouvrir le second canal
Le mode dégradé dépend de la donnée. Un contenu peut conserver sa dernière version valide ; un stock trop ancien doit être réduit ou masqué ; un prix contractuel expiré peut nécessiter un devis ; une commande déjà payée doit rester visible même si un service aval est indisponible. Le système journalise la décision de repli et sa durée afin que la valeur temporaire ne devienne pas la nouvelle norme.
Le rollback d’une diffusion restaure une projection connue sans annuler les commandes déjà acceptées. La réconciliation vérifie ensuite prix, stock, état d’offre et commandes sur chaque canal. Ce contrôle est plus important qu’un tableau « flux réussi » : un export peut être techniquement terminé tout en ayant publié une valeur obsolète ou une offre interdite.
Mesurer la performance avec des indicateurs distincts
Le portail se juge sur l’adoption des comptes éligibles, la part de commandes autonomes, le délai de devis, la récurrence, les erreurs évitées et le coût de service. La marketplace se juge sur la découvrabilité, la conversion, la contribution nette, la qualité de service, les annulations, les retours et l’acquisition de nouveaux segments. Un taux de conversion commun mélangerait des acheteurs déjà engagés et des visiteurs en comparaison.
Quelques indicateurs doivent toutefois être rapprochés : marge nette par commande, fraîcheur du stock, temps de résolution, taux d’erreur de prix et charge support. Ils révèlent si un canal transfère son coût vers une autre équipe. Une croissance marketplace accompagnée d’une explosion des demandes commerciales n’est pas forcément mauvaise ; elle peut signaler un intérêt pour une offre trop complexe. La décision consiste alors à créer un parcours de qualification, pas à masquer le signal.
Lorsque les deux canaux produisent trop d’exports et de décisions dispersées, Ciama peut réunir les écarts de catalogue, de stock, de commande et de marge dans une file de pilotage commune. L’outil ne remplace pas les sources de vérité : il aide les responsables à attribuer, prioriser et suivre les anomalies jusqu’à une décision vérifiable.
Les seuils sont fixés par cohorte. Une équipe peut décider que toute fuite de prix contractuel bloque immédiatement l’extension, que plus de 2 % de commandes avec unité corrigée impose de revoir le conditionnement, et qu’une réconciliation non résolue au-delà de 24 heures suspend les nouvelles publications. Ce sont des règles de pilotage internes, à calibrer sur la capacité réelle, pas des standards de marché.
Décision : portail, marketplace ou modèle hybride
La décision se prend offre par offre avant de devenir une politique de canal. Le bon modèle n’est pas celui qui couvre le plus de fonctions, mais celui qui garde prix, promesse et responsabilité compréhensibles pour le client et pour l’exploitation.
- D’abord, nommer la relation. Choisir le portail lorsque l’identité du compte, son contrat ou ses rôles modifient matériellement la vente.
- Ensuite, tester la standardisation. Ouvrir la marketplace si le produit, le prix, l’unité et la livraison restent compréhensibles sans contexte commercial caché.
- Puis, attribuer l’assortiment. Conserver une liste explicite des références publiques, privées, sur devis et exclues, avec une raison et un responsable.
- Après cela, calculer la contribution. Comparer marge nette, acquisition, retours et charge support sur une cohorte réelle plutôt que sur le chiffre d’affaires seul.
- Enfin, décider du modèle hybride. Relier les canaux par les données et l’orchestration, sans faire circuler automatiquement les prix ni les engagements.
- Bloquer l’extension si la preuve manque. Une fuite tarifaire, une unité ambiguë ou une commande non réconciliée suffit à maintenir le palier précédent.
Erreurs fréquentes qui rendent les deux canaux incohérents
- Publier tout ce que le PIM contient. La complétude d’une fiche ne prouve ni la rentabilité ni la commandabilité publique de l’offre.
- Utiliser le prix portail comme prix de référence. Un montant contractuel peut dépendre d’un compte, d’une période et d’engagements invisibles sur la marketplace.
- Masquer la complexité dans la description. MOQ, compatibilité ou installation doivent devenir des attributs et règles contrôlées, pas une phrase que l’acheteur peut manquer.
- Partager un stock sans allocation. Deux canaux peuvent vendre la dernière unité avant que l’autre reçoive la mise à jour.
- Réécrire les commandes dans un format minimal. La préparation est commune, mais le contrat, les délais et les preuves propres au canal doivent survivre.
- Mesurer seulement le chiffre d’affaires. Les commissions, retours, support et traitements manuels peuvent inverser le classement économique des canaux.
- Confier toutes les exceptions au commercial. Une règle non formalisée ne peut être ni testée, ni supervisée, ni appliquée pendant son absence.
Plan d’action en six semaines
Semaines 1 et 2 : cartographier les offres et les contrats
Sélectionnez une famille représentative, quelques comptes actifs et une marketplace cible. Pour chaque offre, relevez l’unité, le prix, le stock, la livraison, les documents, le niveau de négociation et la charge support. Classez-la en quatre états : publique, privée, sur devis ou exclue. Le commerce, les opérations et la finance valident ensemble les raisons, pas seulement le résultat.
Identifiez ensuite la source de chaque donnée et les transformations par canal. Le registre précise le propriétaire, la fréquence, la durée de validité et le comportement en cas d’absence. Rejouez des commandes passées pour détecter les informations qui n’existent que dans un e-mail ou dans la mémoire d’un commercial. Toute dépendance invisible devient un chantier ou une limite du pilote.
Semaines 3 et 4 : construire les projections et la reprise
Produisez une projection portail et une projection marketplace depuis le même socle. Vérifiez qu’un prix contractuel ne peut jamais alimenter le flux public, qu’une unité de vente possède la même signification jusqu’au WMS et qu’un stock est alloué avant publication. Les tests couvrent expiration de contrat, retard fournisseur, dernier stock concurrent, changement de colisage et rejet d’une fiche par la plateforme.
Branchez les commandes avec une clé d’idempotence et une quarantaine consultable. Provoquez un webhook dupliqué, un timeout ERP et un événement reçu dans le désordre. Le support doit retrouver la source, la version de règle et l’effet appliqué, puis relancer sans accès direct à la base. Exécutez aussi le repli : suspension d’une offre publique, maintien des commandes acceptées et retour à la dernière projection valide.
Semaines 5 et 6 : piloter une cohorte et rendre le verdict
Ouvrez un assortiment limité avec un nombre de comptes, de références et de commandes que l’équipe peut relire. Comparez prix, unités, délais et statuts entre les systèmes chaque jour au début, puis espacez lorsque la preuve devient stable. Suivez la contribution, les annulations, les demandes de devis, la charge support et les nouveaux comptes réellement qualifiés.
Le verdict distingue maintien, correction et extension. Une référence reste ouverte si sa promesse est tenue et sa contribution positive ; elle retourne sur devis si l’incertitude persiste ; elle est retirée si le canal ne peut pas porter son service. L’extension attend zéro fuite de prix, aucune commande dupliquée et une reprise exécutée par l’équipe de run. Le comité attribue enfin la prochaine cohorte et la dette acceptée.
- D’abord, choisir une famille et nommer les responsables commerce, catalogue, opérations, finance et support.
- Ensuite, figer la matrice d’assortiment et les sources de vérité avant toute nouvelle publication.
- Puis, tester prix, stock, unités, commandes et rollback sur des cas contradictoires.
- Décider de maintenir, limiter ou retirer chaque offre selon la preuve économique et opérationnelle.
- Élargir seulement lorsque le run sait expliquer et réparer un écart sans consigne privée.
Approfondir prix, devis, conditionnements et délais
Vérifier que l’offre B2B reste commandable
La réflexion sur la vente de produits B2B sur une marketplace aide à sélectionner les familles compatibles avec un parcours ouvert. Elle complète cette décision par les attentes de contenu, de service et de rentabilité côté vendeur.
Lorsque les quantités changent de sens entre unité, colis et palette, la méthode de conversion des unités et colisages permet de contractualiser les facteurs, les arrondis et les contrôles jusqu’à la préparation.
Sécuriser les promesses qui dépendent d’un fournisseur
Une disponibilité calculée à partir d’un approvisionnement n’a pas la même force qu’un stock réservé. Le traitement des produits à délai fabricant précise comment conserver la source, le niveau de confiance et une date révisable sans promettre un stock inexistant.
- Relire le contrat commercial avant de publier un prix ou une disponibilité hors du portail.
- Comparer la fiche publique à l’exécution réelle : unité préparée, transport, retour et support.
- Faire valider chaque extension par une preuve de marge, une réconciliation et un rollback exécuté.
Conclusion : affecter chaque vente au canal qui peut tenir sa promesse
Le portail B2B et la marketplace ouverte ne répondent pas au même moment commercial. Le portail reconnaît un compte et exécute un contrat. La marketplace rend une offre découvrable et comparable. Les forcer à partager le même prix, le même assortiment et le même parcours détruit précisément ce qui fait leur utilité.
Le modèle hybride devient robuste lorsque les données communes ont une autorité, que chaque canal possède une projection contrôlée et que les commandes gardent leur contexte. Prix contractuels, unités, stock, devis et délais ne sont plus des exceptions dispersées : ils deviennent des décisions versionnées, testées et réparables.
La meilleure ouverture reste progressive. Une famille, une cohorte de comptes et un assortiment public limité suffisent pour vérifier la promesse. Si la contribution est saine, que les écarts sont explicables et que le support sait reprendre un incident, l’équipe peut élargir. Sinon, réduire le périmètre protège mieux la relation client qu’une présence multicanale seulement visible en surface.
Si vous devez cadrer cette frontière, notre agence marketplace peut vous accompagner pour structurer l’assortiment, les flux, la mesure de marge et le pilote, puis sécuriser l’extension sans mélanger conditions privées et promesses publiques.
