Introduction
Dans notre feuilleton Marketplace, il y a un feuilleton dans le feuilleton… Après avoir parlé des grands principes dans un premier article, nous avons en effet commencé à traiter les impacts techniques de l’intégration d’une marketplace dans l’article précédent. Devant l’étendue de la tâche, nous avons découpé les sujets pour proposer 5 articles différents :
- L’intégration de la marketplace dans mon écosystème e-Commerce : Les impacts techniques généraux
- L’intégration technique d’une marketplace EN AMONT : de l’onboarding vendeur à la diffusion des catalogues
- L’intégration technique d’une marketplace ON SITE : adapter le back-office de mon e-Commerce
- L’intégration technique d’une marketplace ON SITE : adapter le front-office de mon e-Commerce” (à venir)
- L’intégration technique d’une marketplace EN AVAL : l’après vente (à venir)
En prenant, comme repère central, le moment où un client visite votre marketplace et passe une commande, le schéma suivant présente tout ce qu’il se passe avant (EN AMONT) pendant (ON SITE : pendant la visite) et après (EN AVAL : l’après vente).
Dans cet article nous allons détailler : L’intégration technique d’une marketplace EN AMONT, de l’onboarding vendeur à la diffusion des catalogues.
0. Initialisation, paramétrages et modélisations
Cette première étape est assez évidente : elle débute après avoir choisi un éditeur de solution de marketplace et contractualisé son utilisation.
Et se poursuit par une phase d’initialisation de la plateforme en ayant :
- Fait les paramétrages minimums pour démarrer son utilisation
- Prévu une modélisation (un format, une structure) pour accueillir les produits et offres de vos vendeurs
Cette modélisation consiste dans le fait d’avoir paramétré… :
- vos catégories,
- vos attributs produits,
- vos listes de valeurs.
… de sorte que vos vendeurs vont pouvoir faire matcher leurs informations produit avec ce format.
Pour faire cette modélisation il peut y avoir des impacts techniques si vous décidez de synchroniser cela avec votre référentiel produit (un PIM, ou votre e-commerce, voire l’ERP si c’est lui votre référentiel).
/! ne pas confondre
- La synchronisation des fiches produits des vendeurs : cette synchronisation sera à faire entre la marketplace et l’e-Commerce quoi qu’il en soit pour publier les catalogues des vendeurs
- La synchronisation de la modélisation : les attributs, les catégories, les listes de valeurs.
Nous reviendrons plus en détail, dans un prochain article, sur la construction de cette modélisation produit pour la marketplace. C’est une étape indispensable, structurante, et qu’il faut réussir dès le départ car il sera compliqué de revenir en arrière quand vous aurez des dizaines ou centaines de vendeurs sur votre marketplace.
1. Pre-boarding
C’est une phase de recrutement, de candidature, de négociation, … la phase commerciale pour aboutir à un accord entre opérateur et vendeur. On parlera de pre-boarding ou d’onboarding administratif/commercial/… phase pendant laquelle il faut :
- Valider la cohérence de l’offre opérateur/vendeur,
- Négocier les commissions,
- Contractualiser.
Cette phase ne présente pas réellement d’impact technique pour votre écosystème e-commerce, sauf si vous choisissez de mettre un formulaire d’inscription sur votre site. Il s’agira alors de :
- Créer ce formulaire, et de le rendre visible (un lien dans le footer “vendre sur la marketplace”)
- Coupler ce formulaire à votre CRM ou directement sur la solution de marketplace pour créer automatiquement un vendeur.
Une fois la phase de pre-boarding terminée (on suppose que les aspects contractuels, administratifs et commerciaux sont finalisés ou se traitent en parallèle de l’onboarding technique), l’opérateur peut créer un/des compte(s) utilisateur(s) au vendeur.
2. Onboarding technique des vendeurs
L’opérateur qui a créé un compte vendeur peut inviter ce dernier à se connecter au back office vendeur sur la marketplace.
Le vendeur commence alors son travail d’onboarding et doit fournir :
Des informations vendeurs
Il est nécessaire, pour le vendeur, de fournir un certain nombre d’informations :
- Des informations d’identification (mail, adresse, statut juridique, …) et informations de paiement (RIB).
- Des informations diverses (politique de retour, description de son activité, politique RSE, …)
Ces 2 premiers points font principalement intervenir de la saisie d’informations, par le vendeur, dans son espace sur la marketplace.
Ces données seront restituées en front office pour le client qui souhaite en savoir plus sur un vendeur. On affichera alors une “page vendeur” reprenant toutes ces informations ainsi que les avis clients.
Des documents KYC
Les documents KYC et la procédure KYC (Know Your Customer ) permettent de s’assurer de l’identité du marchand (afin de prévenir l’usurpation d’identité, la fraude fiscale, le blanchiement d’argent ou le financement du terrorisme). Par “Customer”, il faut entendre ici les marchands qui commercialisent leurs produits sur la marketplace et non les acheteurs finaux.
Cette procédure est en général à déléguer à votre PSP qui portera la responsabilité de valider les KYC.
Le vendeur doit vous fournir ces documents et vous devez les transmettre au PSP.
Pour cela, 2 solutions :
- Manuellement
– Exemple : vous récupérez les documents auprès des vendeurs, vous les transmettez au PSP (le tout par mail).
Le PSP contrôle les documents et vous renvoie un statut par mail. ; - Automatiquement
– Le vendeur upload les documents depuis son compte sur la marketplace, via un formulaire prévu à cet effet (que vous aurez préalablement paramétré).
– L’intégration technique avec le PSP permet un envoi automatique.
Les 2 cas décrits ici sont très simplifiés. Il faut une procédure bien rodée pour ne rien oublier, et une phase de tests conséquente pour s’assurer du bon fonctionnement.
Dans ces 2 cas, il n’y a pas réellement d’impacts techniques dans la mesure où l’intégration entre le moteur de marketplace et le PSP (sur le périmètre de process KYC) ne fera pas intervenir vos ressources techniques en tant qu’opérateur.
En effet, à moins de choisir un PSP et une solution de marketplace trop exotique, un connecteur existe sûrement (s’en assurer avant le choix de la solution).
Attention, même si l’on vous dit qu’un connecteur existe, bien vérifier :
- son périmètre,
- les retours d’expérience d’intégrations sur d’autres marketplaces,
- s’il n’est pas obsolète.
La non validation des KYC pour un vendeur peut :
- soit l’empêcher d’accéder à son compte sur le moteur de marketplace,
- soit l’empêcher de publier ses catalogues,
- soit, et cela arrive aussi, il peut vendre sur la marketplace mais ne pourra pas récupérer les fonds.
Les catalogues des vendeurs
Il faut pouvoir récupérer les catalogues des vendeurs (les produits et les offres) et les exposer sur le site e-commerce.
Cette partie, en amont du moteur de marketplace, est surtout un sujet pour votre vendeur.
Il doit vous envoyer ses produits et ses offres, et pour cela il faut lui proposer un maximum de possibilités. En général il peut :
- Créer manuellement ses produits et ses offres sur l’interface de son compte vendeur (rarement utilisé pour des gros vendeurs avec plusieurs centaines ou milliers de produits),
- Uploader des fichiers plats, puis mapper avec le format paramétré par l’opérateur,
- S’intégrer par API,
- Passer par un agrégateur de flux (Lengow, Shopping feed, iziflux ….). Sur ce point, il faut avoir en tête que l’intégration technique d’un agrégateur sur votre marketplace ne sera pas de votre ressort, mais du ressort (et de la bonne volonté) de l’agrégateur lui-même. Cela aura potentiellement un coût (pas toujours) mais en général assez indolore comparé au coût global d’un projet marketplace.
Publication et modération des catalogues des vendeurs
Une fois les produits et les offres validés (on sous-entend ici que les produits, fournis par vos vendeurs, ont passé les contrôles techniques et commerciaux mis en place par l’opérateur) sur le moteur de marketplace, l’opérateur doit les publier sur le site e-commerce : soit directement vers la solution e-commerce, soit en passant par un PIM.
La logique voudrait :
- Les produits * : depuis la marketplace vers le PIM puis depuis le PIM vers l’e- commerce.
- Les offres * : depuis la marketplace vers l’e-commerce (à une fréquence plus importante que les produits pour les mises à jour de prix et de stocks).
* Rappel :
- Un produit = l’ensemble des informations “froides” qui décrit un produit (descriptions, caractéristiques)
- Une offre = les données “chaudes” dans le cadre de la vente d’un produit (le stock, le prix. L’information de l’état du produit – neuf, reconditionné, occasion, … – est également portée par l’offre). 2 marchands peuvent vendre un même produit : ce sera 2 offres différentes.
– Aparté –
À ce stade se pose toujours la question : PIM ? pas PIM ?
C’est- à- dire : est-ce que je mets les produits de mes vendeurs dans mon référentiel produit ?
Ce sujet pourrait faire l’objet de beaucoup de discussions, mais ce qui doit nourrir la réflexion pour y répondre peut tenir en 4 points principaux (hors considérations financières, et time to market) :
- Est-ce que je souhaite publier les fiches produits (y compris les produits marketplace) sur d’autres canaux que l’e-commerce ?
- Est-ce que j’ai déjà un flux technique PIM – > e-commerce ? et je veux que l’e-commerce ne consomme qu’un seul flux produit ?
- Est-ce que j’ai des règles métiers dans mon PIM qui ne peuvent être reportées ailleurs, et que les produits marketplace doivent satisfaire pour garantir la qualité de ma donnée produit au global ?
- Est-ce que je souhaite, en tant qu’opérateur, enrichir les produits des vendeurs avec des contenus supplémentaires ?
– Fin de l’aparté –
Donc… Les produits des marchands sont dans l’outil de marketplace, ils ont passé les contrôles techniques, la modération, le dédoublonnage, … et il faut les publier sur le site.
En général les solutions de marketplace exposent déjà toutes les API pour venir consommer toutes les données. Il faut donc mettre en place la demi interface côté e-commerce pour intégrer les flux Marketplace <> e-commerce.
Hop hop hop, est-ce qu’on n’est pas allé un peu vite en s’arrêtant là ?
En effet, on vient d’évoquer : “contrôles techniques”, “modération”, “dédoublonnage”.
Derrière ces mots se cachent des choses assez structurantes et toutes les solutions de marketplace n’offrent pas le même niveau de fonctionnalités pour adresser correctement ces 3 sujets.
Mais vous serez bien obligés de contrôler un minimum la validité du format de la donnée produit fournie par le vendeur, ne pas créer autant de fiches produits que d’offres sur un même article, et de valider la cohérence globale de l’offre produit sur votre site.
Donc soit c’est la solution de marketplace qui peut répondre à cela, soit il faudra le développer quelque part (dans le PIM, dans l’e-commerce, dans une brique spécifique).
Résumé des impacts techniques de l’intégration d’une marketplace de l’écosystème e-commerce (de l’onboarding vendeur à la diffusion des catalogues)
En résumé, cette partie AMONT n’implique pas énormément de bouleversements techniques pour votre DSI.
On sait qu’il faut une solution pour :
- Faire l’interface avec les vendeurs
- Contrôler la donnée produit
- Diffuser les données produits/offres/vendeurs
Tous ces process AMONT sont idéalement adressés en grande partie par la solution de marketplace qui exposera ensuite les demi interfaces pour s’y brancher.
Nous verrons dans le prochain article, les impacts techniques côté e-commerce pour accueillir ces données.
Résumé en 1 tableau :
