FONCTIONNALITÉS MARKETPLACE

1.INTRODUCTION À LA SOLUTION DE MARKETPLACE IZBERG

A. Philosophie Produit

IZBERG est une solution API First et modulaire.

L'ensemble des produits et fonctionnalités d'IZBERG sont disponibles au travers d'une API Rest. Cette approche "API First" facilite votre intégration et vous donne une totale liberté dans votre projet. Vous choisissez les modules à utiliser et pouvez même ajouter des fonctionnalités dans les back-offices IZBERG.

Agile, lean, modulaire : les clients peuvent très rapidement avoir une première version de leur projet à présenter..

Customer centric : nous avons construit la solution IZBERG en partant d'un socle stable et extensible sur lequel nous développons des modules métiers. Nous sommes les premiers utilisateurs de nos APIs et nos clients ont les mêmes possibilités que nous pour construire leurs propres briques par dessus IZBERG.

We love developers : nous sommes une entreprise d'ingénieurs et nous pensons aux développeurs. La plateforme IZBERG dispose d'une documentation en ligne, de collections Postman et d'outils pour tester rapidement les intégrations à nos APIs.

B. Introduction à la solution IZBERG

IZBERG propose une solution SaaS entièrement disponible par API. Fournissant la couche Back-end et se plaçant au centre de l’architecture SI du client, IZBERG peut être interfacé rapidement et facilement à l’environnement technique de l’opérateur et des marchands. Les API d’IZBERG sont développées selon le principe d'architecture REST, ce qui permet un temps de déploiement et d’intégration considérablement réduit, sur tout type de technologie Front-end utilisée.

IZBERG dispose de nombreux modules pour accompagner au mieux les besoins de chaque place de marché :

Principe général IZBERG Platform

Parmi les nombreuses fonctionnalités, on peut citer :

• Le PIM (Product & Service Information Management)

• Le module de gestion des commandes

• Le module de gestion des marchands

• La gestion de la facturation et du paiement des commissions

• Le module de Webhooks qui permet une synchronisation facilitée en temps réel avec le SI de l’opérateur

IZBERG fournit également des interfaces pour que les marchands et l’opérateur puissent chacun piloter efficacement leurs activités. Dans les 2 chapitres qui suivent, nous allons présenter les principales fonctionnalités mises à disposition de l’opérateur et des marchands.

Important :

La suite du document présente les fonctionnalités IZBERG en se basant sur une utilisation via les back-office (marchands et opérateurs), mais il est important de souligner que toutes les fonctionnalités sont disponibles par API.

2. PRÉSENTATION DU BACK-OFFICE OPÉRATEUR

A. Tableau de bord et Performance

L’opérateur dispose depuis son back-office d’un tableau de bord personnalisable, lui permettant de suivre l’activité de la Marketplace dans sa globalité. Personnalisable car l’opérateur choisit dans la liste des indicateurs disponibles ceux qu’il souhaite afficher.

De nombreux KPI sont disponibles :

Le panier moyen

Le nombre de nouvelles commandes et commandes marchands

Le chiffre d’affaire généré et son évolution

Le volume de vente et son évolution

Le montant des commissions et son évolution

Le nombre d’offres actives

Moyenne des offres actives par marchand

Note moyenne des avis acheteurs

Taux d’annulation de commandes

Taux de confirmation de commandes

Taux de retard dans l’envoi des commandes

Taux de retour

Délai de résolution des retours

L’opérateur peut sélectionner une période avec plusieurs niveaux de granularité et aussi filtrer les données par marchand ou une liste de marchands.

Back-Office : Tableau de bord Opérateur

Dans un souci de comparaison et de compréhension aisées, les données correspondantes à la plage précédente sont également affichées.

Back-office : Exemple de comparatif période à période

Le menu Performance permet à l’opérateur de visualiser, les différents KPI par marchand, avec la possibilité de filtrer par période, marchand / liste de marchands et un tri sur chaque KPI:

B. Gestion des marchands

L’opérateur peut créer et configurer les marchands de sa Marketplace directement depuis l’interface, au travers d’un import (en utilisant le Mapper, l’outil universel d’importation d’IZBERG) ou par API.

Pour créer un marchand depuis l’interface, Il suffit d’indiquer les informations nécessaires (nom, région, langue par défaut, devise par défaut…). A ces informations par défaut, l’opérateur peut décider d’ajouter d’autres informations dont il a besoin de la part du marchand pour que ce dernier puisse devenir marchand sur sa marketplace.

Interface de gestion des marchands par l’opérateur

Lorsqu’un nouveau marchand est créé sur la Marketplace, il reçoit un accès à son back-office - composé d’un login et d’un mot de passe - qui lui permettra de gérer son activité sur la Marketplace (configurations, gestion des commandes, catalogues de produits, ajout d’utilisateurs, etc.) de manière indépendante.

Lors de l’inscription, le marchand doit suivre le processus d’Onboarding pour que ses offres soient disponibles à la vente. Ces étapes sont détaillées dans le chapitre « Onboarding marchand ».

Il est également possible de :

• Mettre en « pause » un marchand : il conserve un accès à la Marketplace, mais la prise de nouvelles commandes lui est impossible

• Supprimer définitivement un marchand.

L’opérateur peut également créer des groupes de marchands afin de faciliter la gestion opérationnelle de sa Marketplace.

Les groupes peuvent avoir de multiples intérêts. Par exemple, l’opérateur peut créer un groupe pour un marchand ayant besoin de gérer plusieurs « boutiques » pour la même Marketplace (le marchand pourra ainsi gérer ses différentes activités depuis un unique point d’accès):

Exemple : création d’un groupe multi-boutiques

C. Gestion des produits

IZBERG fournit en natif une solution complète de gestion des produits et services (PIM) permettant de gérer et centraliser toutes les informations depuis une seule et même interface.

Cela évite la mise en place d’une solution de gestion de référentiel produit (PIM) tierce, et permet ainsi de minimiser les coûts, les intégrations, les complexités d’évolution, le temps de déploiement et les risques associés..

Cela permet également d’avoir un contrôle total sur les catégories, les produits, les familles de produits, les offres, les attributs et les variations, tout cela sans aucune dépendance ou interconnexion à un outil tiers.

Grâce au PIM intégré nativement, IZBERG propose autant de méthodes d’intégration des catalogues facilitant au maximum le travail des marchands et de l’opérateur. Il devient alors très simple d’harmoniser les données pour déployer facilement le catalogue de chaque marchand.

IZBERG permet ainsi à l’opérateur de ne jamais être limité en termes de choix des marchands à intégrer sur la Marketplace.

Si l’opérateur dispose d’un PIM qu’il souhaite utiliser également pour sa marketplace, il est tout à fait possible, au travers des API, de connecter le PIM d’IZBERG à celui de l’opérateur.

A. Gestion des catégories et des attributs

Une interface permet à l’opérateur de la Marketplace de définir et gérer son arborescence de catégories.

Back-Office Opérateur : Arbre des catégories

La création, ajout et mise à jour de l’arborescence peut également être faite au travers d’un import par le Mapper ou par API.

Lorsque l’opérateur valide les catégories, l’arbre est exposé aux marchands actifs. Ces derniers peuvent ajouter leurs produits ou services en respectant l’arborescence mise en place par l’opérateur.

L'opérateur peut utiliser les attributs natifs IZBERG applicables à toutes les catégories et décider pour chacun de l’activer ou non, de le rendre obligatoire ou non. L’opérateur peut également ajouter autant d’attributs personnalisés qu’il souhaite pour chaque catégorie ou sous catégorie pour définir les caractéristiques d’un produit, d’un service ou d’une offre.

Par exemple :

• Pour les vêtements : taille du col, longueur de la ceinture, température de lavage…

• Pour les meubles: le nombre de place, les dimensions….

Pour chaque attribut, l’opérateur peut définir les caractéristiques tels que :

• Type (nombre, texte, booléen, date, etc.)

• Langue

• Obligatoire ou facultatif

• Liste de valeurs

• La ou les catégories ou sous catégories sur lesquelles l’attribut est appliqué

Gestion des produits et des offres : Catalogue ouvert / Catalogue fermé / Catalogue Enrichi

Les produits et les offres sont deux notions distinctes :

Un produit ou un service est défini par un ensemble d’attributs statiques (nom, description, photos, fiche technique…).

Une offre est un ensemble d’attributs rattachés au produit ou au service, contenant tous les éléments liés à la commercialisation: prix de vente, stock, variations etc… Ces attributs sont généralement dynamiques, et sont mis à jour très régulièrement par les marchands au cours de la journée.

L’opérateur de la Marketplace peut travailler de 2 façons différentes : Il peut laisser chaque marchand créer sa fiche produit et l’offre associée, ou bien imposer un catalogue de produits et laisser les marchands uniquement apposer des offres. C’est la notion de catalogue ouvert / fermé.

Catalogue Ouvert

L’opérateur de la Marketplace expose son arbre de catégories aux marchands. Chaque marchand peut ensuite créer sa fiche produit en renseignant les informations demandées par l’opérateur au travers des attributs de produits et de l’offre.

Catalogue Fermé

Le référentiel de produits et services est géré et maintenu par l’opérateur afin d’assurer l’intégrité et la cohérence des produits proposés par la Marketplace.

Les marchands pourront uniquement apposer des offres sur les produits et services existants dans le référentiel.

Pour aider les marchands à constituer leur catalogue d'offres, un moteur de recherche est disponible dans leur back-office, afin de rechercher les produits existants.

Ainsi l’opérateur garde la main sur la définition de la fiche produit (description & photos), et plusieurs offres de différents marchands sont ensuite rattachées à un même produit.

Catalogue Enrichi

Nous travaillons actuellement sur l’ajout d’une nouvelle configuration du catalogue, entre le catalogue ouvert et le catalogue fermé. Si un marchand souhaite proposer un produit (et donc une offre) qui n’existe pas dans le référentiel imposé par l’opérateur, avec le catalogue enrichi, il pourra directement depuis le back-office et travers d’un import, soumettre à la validation de l’opérateur sa demande. L’opérateur pourra alors décider d’accepter ou de refuser la demande d’ajoute faite par le marchand.

La configuration du catalogue dépend des besoins de l’opérateur et de la typologie de produits et services mis en vente.

Le PIM permet également à l’opérateur d’organiser son référentiel. Il peut très facilement modifier, enrichir et catégoriser les produits et les services, de façon unitaire ou en masse (avec la sélection multiple). Par exemple ajouter des informations complémentaires pour faciliter le SEO…

Back-office : Gestion de produits sur le PIM IZBERG

IZBERG fournit aussi un serveur d’image (via un CDN) qui permet l’hébergement de plusieurs images pour chaque produit.

B. Gestion des variations

Le concept de variation offre une grande granularité dans la gestion des stocks et des prix associés.

Pour un produit donné, il est par exemple possible d’en configurer différentes variations de tailles, puis de gérer prix et stock pour chacune des tailles indépendamment les unes des autres.

Back-office Opérateur : Édition des variations

C’est une notion fondamentale pour gérer finement ses stocks et pouvoir afficher en temps réel sur son front-end les disponibilités de chaque produit en fonction de ses variations (tailles, couleurs, matières…).

C. Modération des offres

Un workflow de validation des offres permet à l’opérateur de vérifier et valider toutes les nouvelles offres soumises par les marchands avant leur mise à la vente.

L’opérateur peut accéder à la liste des offres à valider directement dans son Back-Office.

L’opérateur a une vue détaillée de chaque produit ou offre en attente de validation. Il peut ensuite :

• Accepter l’offre qui passe en “actif”, l’offre remonte sur le front et devient alors disponible à la vente

• Refuser l’offre : Le marchand peut consulter toutes les offres refusées et a la possibilité de retravailler le produit et l’offre, pour la soumettre à nouveau et recommencer le processus.

       D. Familles de produit

L’opérateur peut créer des familles de produits, afin de regrouper des types de produits sous un même ensemble. Une famille de produit est un sélecteur intelligent : l’opérateur configure un ensemble de conditions, puis chaque produit (déjà existant ou futur) les remplissant sera automatiquement ajouté à la famille de produits. L’opérateur peut ensuite interroger IZBERG pour obtenir la liste des produits associés à chacune de ces familles. Cela peut par exemple s’avérer utile lorsqu’il souhaite créer des promotions applicables uniquement à un ensemble de produits et non à l’ensemble du catalogue.

Back-Office Opérateur : Famille de produits

De son côté, les marchands ont également la possibilité de créer des familles de produits ce qui peut être utile pour gérer par exemple des modalités de livraison différentes ou encore les promotions..

E. Gestion des promotions

IZBERG fournit un module permettant à l’opérateur de créer facilement des promotions directement depuis son Back-Office.

Plusieurs types de promotions sont configurables :

• Des promotions sur les produits, en pourcentage, montant ou prix fixe du produit

• Des promotions sur les frais de livraison de la commande dans sa globalité

• Des promotions sous forme de “bons”/chèques cadeaux, utilisables uniquement sur la place de marché

Back-office : Création d’une promotion

Pour chaque promotion, l’opérateur peut configurer une date de début et une date de fin, ainsi qu’un ensemble de critères d’éligibilité. Ces critères portent sur un nombre minimum d’achat, un prix minimum, un prix maximum, une famille de produit (permettant ainsi de limiter aux produits d’un marchand ou d’un ensemble de marchands), etc. Une promotion peut également être partagée avec un ou plusieurs marchands et l’opérateur peut définir le taux du financement par lui et le(s) marchand(s).

Exemple : Configuration d’une promotion

D. Gestion des commandes

IZBERG dispose d’un module de gestion des commandes complet permettant d’avoir une vue claire sur chaque étape du processus de commande.

A. Panier

IZBERG fournit un objet panier, qui peut être entièrement créé et contrôlé par API. Plusieurs articles de différents marchands peuvent facilement être ajoutés à un panier sans que le front-end n’ait à se soucier du calcul des taxes, du calcul des frais de port, ou des promotions associées. IZBERG permet ainsi de s’affranchir d’une solution e-commerce pour la création du panier.

Ayant une vue sur tous les paniers en cours, l’opérateur a un suivi précis du tunnel de conversion.

B. Commande

Lorsqu’un Panier est validé, IZBERG transforme le panier en commande et crée automatiquement les commandes vers chacun des marchands concernés :

Répartition des commandes multi-marchands

IZBERG permet de gérer tant les paniers contenant les produits d’un seul marchand, que les paniers multi marchands contenant des produits de différents marchands.

Une fois la commande créée, le cycle de vie de commande est initié et le marchand doit alors suivre le workflow prévu. Ce workflow est expliqué en détail au chapitre « Gestion des commandes ».

Chaque mise à jour de statut peut entraîner une notification sous forme de webhook déclenchant un email automatique vers le client. La notification indique le changement de statut (statut d’origine vers le nouveau statut) permettant ainsi de contextualiser les emails envoyés au client.

Les statuts de commande fournis par IZBERG sont des statuts standards tels que :

• Initial

• A confirmer

• A traiter

• Traitée

• Finalisée

• Annulée

L’opérateur peut suivre l’ensemble des commandes passées sur sa place de marché depuis son back-office :

Back-office opérateur : listing des commandes

C. Retour et remboursements

Le module de commande permet de gérer les retours et les demandes de remboursements. De façon similaire à la gestion d’une commande, un workflow complet de retour et de remboursement a été mis en place pour gérer tous les cas de figures entre marchands et clients finaux.

Ce workflow est expliqué en détail au chapitre « IV.E.3 Retour et Remboursements »

Chaque mise à jour de statut peut entraîner une notification sous forme de webhook, qui peut être utilisée pour déclencher un email automatique vers le client. La notification indique le changement de statut (statut d’origine vers le nouveau statut) permettant ainsi de contextualiser les emails envoyés au client.

Les statuts fournis par IZBERG sont des statuts standards tels que :

• Retour en attente d’acceptation

• Accepté, en attente du colis

• Colis reçu

• Fermé par l’acheteur

• Fermé par le marchand

• Remboursement en attente

• Remboursement à traiter

L’opérateur, en tant que tiers de confiance, a une vue complète sur ces processus et peut intervenir en cas de litige pour arbitrer sur la suite à donner.

Back-office opérateur : visualisation des demandes de retours

E. Gestion financière

A. Gestion des commissions

A la différence du modèle e-commerce, le modèle économique d’une Marketplace repose sur le prélèvement d’une commission par l’opérateur suite à un acte de vente. L’opérateur prélève une commission pour service rendu : il permet à l’acheteur et au marchand de se rencontrer sur sa plateforme digitale, et d’y effectuer un acte de vente sécurisé.

Le module IZBERG de gestion des commissions permet à l’opérateur de configurer des règles de commissions en fonction de nombreux critères, notamment au niveau :

• Du marchand

• De la catégorie de produit

• D’une marque

• De la famille de produit

• Du pays de provenance des produits

• De la zone de destination des produits

Il est également possible de :

• Ajouter une licence mensuelle

• Programmer des taux de commission sur une période donnée

• Ajouter des frais fixes par transaction

• Calculer les commissions sur différents prix : HT ou TTC, frais de livraison inclus ou non-inclus

Enfin, toutes ces commissions peuvent s’exprimer en pourcentage ou en montant fixe, et il est possible de définir plusieurs règles exclusives ou bien cumulables.

Une interface de gestion des commissions est mise à disposition de l’opérateur dans son back-office. Il est également possible de gérer les commissions au travers d’un import ou par API.

Back-office opérateur : listing de toutes les règles de commissions paramétrées

Back-office opérateur : interface de paramétrage d’une commission sur les articles

B. Module de paiement

Dans le modèle Marketplace, l’encaissement est complexe et de plus en plus réglementé. L’opérateur de Marketplace fournit un service de paiement sans pour autant posséder les produits de la vente, et agit donc comme “intermédiaire d’agent commercial” en proposant d’encaisser et de reverser des flux financiers. A ce titre, il doit se conformer à la législation européenne (DSP2) et, en France, disposer d’un agrément auprès de l’ACPR pour pouvoir réaliser ce service.

Cette procédure d’agrément auprès de l’ACPR étant généralement longue et coûteuse, et à moins d’avoir - cas rare - une exemption, l’opérateur préfèrera souvent s’adosser à une Solution de paiement tierce spécialisée dans la gestion des flux financiers et agréée.

IZBERG propose une passerelle générique qui permet de s’interconnecter techniquement à différents partenaires de paiement, et piloter ainsi encaissement des flux, ventilation et cashout.

Ces différentes étapes étant dissociables, IZBERG peut piloter tout ou partie du cycle de paiement selon les besoins de l’opérateur.

Principe de pilotage de l’encaissement et ventilation des flux financiers

C. Module de facturation

Le module de facturation IZBERG permet d’automatiser l’édition des factures entre l’opérateur et chacun de ses marchands. L’opérateur retrouve dans son back-office l’ensemble des factures mensuelles éditées automatiquement pour chaque marchand.

Back-Office Opérateur : Facturation marchands

La facture reprend les transactions mensuelles (commandes, remboursements, éventuel abonnement) et taxes applicables, les commissions rétrocédées à l’opérateur, les opérations promotionnelles..

IZBERG effectue une tenue de compte rigoureuse afin que les marchands et l’opérateur puissent avoir une vue claire sur l’ensemble des transactions qui ont eu lieu (crédit, débit, frais de promotions…). Ces informations sont restituées sous forme de balance commerciale. Cette visualisation permet d’avoir une synthèse globale sur l’activité.

De plus, si le module de facturation est couplé au module de paiement, alors IZBERG peut directement piloter la ventilation des flux financiers selon les besoins de l’opérateur ou de chaque marchand. Dans ce cas, l’opérateur et les marchands peuvent demander de retirer l’argent disponible sur leurs balances en un simple clic. Cela permet d’automatiser les opérations de virements qui peuvent elles aussi devenir rapidement chronophages.

F. Configuration de la Marketplace

A. Méthodes de livraisons et transporteurs

IZBERG fournit un module de livraison qui identifie les méthodes de livraison éligibles à un panier et calcule le prix des frais de port. Ces calculs dépendent de différentes configurations, certaines faites par l’opérateur et d’autres par le marchand.

L’opérateur définit les zones de livraison, les méthodes de livraison et les transporteurs autorisés sur sa marketplace.

Ces zones, transporteurs et méthodes de livraison seront ensuite disponibles dans les back office des marchands (voir le chapitre « Frais de ports » pour le fonctionnement détaillé dans le back-office).

Back-office opérateur : création et gestion des méthodes de livraison

B. Gestion de la communication et des notifications

Les principales fonctionnalités de gestion de la communication et des notifications dans IZBERG sont:

• La Messagerie intégrée qui permet la communication entre l’Opérateur et les Marchands ainsi que entre les Marchands et les Clients

• Le Mailer d’IZBERG qui permet de configurer des e-mails automatique qui sont déclenchés par certaines actions;

• Les Webhooks qui sont déclenchés à la suite de certains événements

Les principales fonctionnalités de communication et de gestion des notifications

La Messagerie intégrée

Elle permet la communication entre:

• L’Opérateur et les Marchands

• Les Marchands et les Clients

• Les Clients et l’Opérateur

L’opérateur et les marchands peuvent échanger directement depuis leur back-office.

Back-office Opérateur: boîte de réception

Les marchands et l’opérateur peuvent écrire aux clients depuis leur back-office. La fonctionnalité est disponible dans le détail de la commande. Pour que les clients puissent recevoir ces messages, une intégration front-end est nécessaire.

Le Mailer

Une liste d’actions est disponible et permet la configuration d’e-mails automatiques en utilisant des variables qui permettent la personnalisation du message. Ainsi il est par exemple possible de configurer des templates de mails à destination des marchands dans le cas où ils auraient reçu une nouvelle commande ou demande client.

Back-office opérateur: configuration d’un template de mail

Webhooks

IZBERG propose un système de notification en temps réel en mode “push” (de IZBERG vers l'extérieur) permettant la synchronisation automatique de la Marketplace au SI de l’opérateur.

Cette fonctionnalité de push est une composante essentielle de la solution IZBERG. Elle permet de synchroniser de nombreux évènements qui ont lieu sur la plateforme en temps réel et ainsi d’avoir des workflows beaucoup plus rapides. L’opérateur peut par exemple déclencher des communications clients immédiatement après les actions des marchands.

IZBERG utilise la technologie de Webhook (POST http vers une URL donnée), permettant à des services externes d’être notifiés instantanément lorsque certains événements se produisent sur la Marketplace.

Grâce à l’interface IZBERG, l’opérateur peut configurer l’ensemble des événements pour lesquels IZBERG doit déclencher un webhook, ainsi que l’ensemble des URLs d’appels pour chacun de ces événements, et permettre ainsi des appels vers différents services selon l'événement.

Le POST contient tous les détails relatifs à l’événement pour permettre à l’opérateur de déclencher les actions corrélées (email au client, envoi de SMS...)

A nouveau, dès qu’une action a lieu sur la marketplace, une notification est envoyée depuis la plateforme IZBERG vers le SI de l’opérateur, permettant une synchronisation en temps réel entre les 2 systèmes.

Back-Office Opérateur : Configuration d’un webhook

3. PRÉSENTATION DÉTAILLÉE DU BACK-OFFICE MARCHAND

A. Onboarding marchand

Pour pouvoir apparaître en ligne et commencer à vendre sur la Marketplace, le marchand doit suivre différentes étapes permettant de collecter les informations nécessaires : c’est le processus d’Onboarding.

Les étapes de l’Onboarding sont configurables en fonction des besoins de l’opérateur de la Marketplace (documents nécessaires à importer, informations concernant le marchand à fournir, import d’un premier catalogue…).

Back office : Exemple d’informations demandées par l’opérateur

B. Tableau de bord et KPI

Les marchands ont accès depuis leur back-office à un tableau de bord détaillé, leur permettant de suivre leur activité en un seul coup d’œil.

Le tableau de bord présente de nombreux indicateurs clés de performance (KPI) tels que :

• Le panier moyen

• Le nombre de commandes

• Le chiffre d’affaire généré

• Le montant disponible sur le wallet Marketplace

• Le montant en attente de transfert sur le wallet Marketplace

• Les gains du mois en cours

• Le nombre de commandes à confirmer

• Le nombre de commandes à expédier

• Le nombre de retours en attente

• Le nombre de nouveaux messages

• Le nombre d’offres actives

• Le nombre d’offre inactives

• Le nombre d’offre en brouillon (pas encore validés par l’opérateur, ou pas encore soumis à l’opérateur)

• Les produits les plus vendus

Back office : Extrait Tableau de bord marchand

Le marchand peut sélectionner une période avec plusieurs niveaux de granularité (jusqu'au jour). Les indicateurs clés de performances sont alors mis à jour avec les données correspondantes à la plage sélectionnée.

Back office : choix de la période

Pour comparer plus facilement l’évolution, sont affichées également les données correspondantes à la plage précédente.

Par exemple, si le marchand souhaite obtenir ses ventes entre le 1er Août et le 31 Août, seront également affichées en dessous et en plus petit, les données du 1er Juillet au 31 Juillet. Cela permet de suivre très facilement l’évolution de son activité

Back office : Exemple de comparatif période à période

Chaque marchand dispose donc d’un outil complet pour piloter efficacement son activité sur la Marketplace. Les indicateurs présentés lui permettent de prendre les bonnes actions et décisions pour optimiser son activité.

De plus, toutes les données sont exportables en fichier plat (csv) lui permettant ainsi de les retravailler de son côté et de les agréger facilement avec ses autres statistiques.

C. Gestion des produits

IZBERG fournit une solution complète de gestion des produits (PIM) permettant de gérer et centraliser toutes les informations depuis une seule et même interface.

Principe général d’import des produits dans le PIM IZBERG

IZBERG a développé plusieurs méthodes d’imports de produit, permettant d’adresser toute taille/typologie de marchand :

1. Import de fichier

2. FTP

3. URL externe

4. Google Sheet

5. API Rest

En fonction de la taille du catalogue du marchand et de son existant, IZBERG fournit des conseils et du support sur la méthode d’import à utiliser.

Les imports via flux XML et CSV peuvent être fait par chaque marchand via un upload dans leur back-office, ou en configurant un import sur une URL externe. Dans ce dernier cas, IZBERG récupère le fichier à la fréquence souhaitée par le marchand pour l’importer dans le PIM.

Back office : Différente sources d’import

Il devient alors très simple d’harmoniser les données pour déployer facilement le catalogue de produits de chaque marchand.

A. Mapping du catalogue

IZBERG fournit un outil de mapping du catalogue marchand. IZBERG Mapper analyse la source du marchand, et lui propose un mapping automatique avec les catégories et attributs existants définis par l’opérateur de la marketplace.

Via un puissant algorithme développé par les équipes d’IZBERG, le Mapper analyse le format du flux et passe automatiquement la donnée. Les formats gérés sont les suivants :

• JSON

• XML

• CSV

• Google sheet

Une fois le fichier analysé, le Mapper propose automatiquement un mapping des attributs.

Mapping des catégories
Mapping des attributs

Le marchand peut ensuite adapter le mapping et forcer certaines valeurs d’attributs.

De nombreuses options sont disponibles pour définir une règle d’attribut (valeur figée, liste de valeurs, attribution via l’exécution d’un script JS…)

Mapper : Configuration du mapping des attributs

Un résumé des produits du flux, contenant le résultat des règles de mapping, est proposé.

Le marchand peut ensuite lancer l’import dans le PIM de la Marketplace. Chaque import déclenche un rapport contenant le nombre de produits valides, invalides, ayant déclenché une erreur, etc.

Mapper : Rapport d'exécution

En offrant aux marchands une flexibilité totale dans le choix du format du flux produit, IZBERG leur permet un déploiement simple et extrêmement rapide de leurs produits sur la Marketplace de l’opérateur.

Pour l’opérateur, c’est un facteur clé de succès dans le recrutement massif de ses futurs marchands, car il n’a pas besoin de leur imposer un formalisme rigide pour l’import des produits… argument de taille pour les convaincre de rejoindre sa Marketplace !

Couvrant un spectre fonctionnel large, IZBERG permet de faciliter le travail de l’opérateur au quotidien en termes de sélection et d’intégration des futurs marchands.

B. Cas du catalogue fermé

Les regroupements peuvent se faire automatiquement via un identifiant unique qui sera défini par l’opérateur de la Marketplace. L’identifiant unique peut être un attribut (code EAN, code GTIN, ID spécifique…) ou une concaténation de plusieurs attributs (NOM + ID produit).

Un moteur de recherche permet au marchand de trouver les produits existants dans le catalogue initial.

Back-office: Moteur de recherche catalogue

Une fois le produit identifié, le marchand peut ajouter une offre directement depuis l’interface en renseignant les informations relatives à l’offre.

Back-office: Ajout d’une offre sur un produit existant

A noter que les offres peuvent être envoyées en masse par API ou par un fichier avec le Mapper. Dans ce cas, le fonctionnement est le même que décrit au chapitre précédent “Mapping du catalogue”.

C. Gestion des promotions

Les marchands ont la possibilité de créer des promotions depuis leur back-office. Ils peuvent créer plusieurs types de promotions :

• Sur leurs produits et offres (soit en pourcentage, soit en montant fixe du prix du produit)

• Sur les frais de livraison de la semi-commande dans sa globalité

Back office : création d’une promotion

Les remises peuvent être configurées en fonction de différents critères notamment :

• Date de début, date de fin avec gestion des horaires

• Par famille de produit (permettant ainsi de limiter aux produits d’une seule typologie)

Tous les critères doivent être remplis pour que la promotion soit considérée comme valide et donne lieu à la réduction.

D. Gestion des commandes

A. Commande

IZBERG dispose d’un module de gestion des commandes permettant de diviser la commande en plusieurs sous-commandes par marchand. Chaque marchand reçoit directement les sous-commandes le concernant, indépendamment des autres marchands qui sont impliqués dans la commande globale.

Le module de commande IZBERG permet donc de gérer aussi bien les paniers qui contiennent des produits d’un seul et même marchand, que les paniers qui contiennent des produits de différents marchands (panier multi-marchands)

La répartition des commandes vers chacun des marchands concernés est réalisée automatiquement par IZBERG.

Les commandes sont créées dans le back-office du marchand, qu’il peut traiter directement depuis cette interface. Le marchand peut également automatiser le processus de synchronisation des commandes Marketplace avec son système de gestion de commande interne existant, en le synchronisant aux API IZBERG.

IZBERG propose une vue filtrée des commandes pour faciliter une gestion rapide des commandes en fonction de leur état:

• À confirmer: paiement autorisé, confirmation du marchand en attente

• À traiter: commande confirmée, et en attente de traitement chez le marchand

• Incident ouvert: en cas de retour ou remboursement

• Traité: Commande traitée par le marchand

• Toutes: regroupe toutes les commandes, en incluant les commandes annulées (paiement non autorisé)

Les marchands disposent d’un filtre similaire, qui leur permet de prendre rapidement l’outil en main et de limiter le temps passé sur le back-office.

Back office : Interface de gestion des commandes

Dans le détail de la commande, le marchand dispose de toutes les informations nécessaires pour pouvoir efficacement traiter celle-ci : le/les article(s) commandé(s), le prix, les informations sur le client ainsi que toutes les informations que l’opérateur jugera utiles à transmettre au marchand.

Le workflow de commande impose une première étape de confirmation ou annulation de la commande, indispensable pour débuter le cycle de vie de la commande.

Back Office : confirmation commande

Un temps limité de confirmation peut être configuré par l’opérateur depuis son back-office. Si le marchand ne confirme pas la commande dans le temps imparti, la commande est annulée automatiquement.

Une fois la commande validée, le marchand prépare la commande, puis il doit la notifier comme expédiée.

Back Office : Déclarer comme envoyée

Une fois la commande notifiée comme envoyée, il pourra y ajouter le lien de « tracking » fourni par son transporteur et les informations relatives au colis :

Back office : ajout d’un lien de suivi

Ce lien pourra être repris dans les communications avec le client final, pour lui permettre de suivre son colis directement sur le site du transporteur.

A chaque modification de statut de commande ou de colis, une notification en temps réel peut être envoyée par IZBERG (webhook) et permet de déclencher un événement vers le client final pour l’informer du changement de statut (envoi d’un email, envoi d’un sms, etc.).

Le marchand peut exporter toutes ses commandes en fichier plat depuis son back office.

B. Retour et remboursement

IZBERG propose un workflow complet pour gérer les demandes de retour et de remboursement. Une fois la commande envoyée, le marchand reçoit directement les demandes de retour et de remboursements qui le concernent, indépendamment des autres marchands impliqués dans la commande initiale. Pour cela, le front-end doit autoriser le client final à faire une demande en ligne (via l’ajout d’un bouton par exemple) pour chaque article de la commande.

Un workflow détaillé de statut de retour et de remboursement permet de comprendre très rapidement l’état de chaque commande. Il impose une première étape obligatoire d’acceptation du retour, indispensable pour débuter le cycle de vie du retour et/ou remboursement.

En cas de litige, l’opérateur a toujours la main pour forcer l’acceptation d’un retour et d’un remboursement depuis son back-office, permettant ainsi d’arbitrer la relation entre le client et le marchand.

Demande de retour

Deux types de retours existent : un retour pour échange ou contre remboursement.

Le marchand reçoit directement les demandes de retour sur son back-office. La première étape consiste à accepter le retour. Il peut à ce stade envoyer un message au client, s’il a besoin de plus d’informations.

Le message est ensuite récupéré par le front-end, qui peut alors le router vers l’adresse email du client et / ou l’afficher directement dans l’espace client sous forme de message.

Back-office: visualisation d’une demande de retour

Selon le cas, le marchand peut :

• Renvoyer un nouveau colis ce qui a pour action de fermer la demande de retour avec le statut « fermé par le marchand »

• Réaliser un remboursement, ce qui a pour action d’initier le workflow de remboursement

• Modifier la finalité du retour, si par exemple un échange n’est pas possible, il peut requalifier le retour en remboursement.

Les remboursements

Le marchand peut réaliser un remboursement total ou un remboursement partiel, en indiquant le montant souhaité.

Back office : choix du montant à rembourser

Le remboursement peut être lié à une demande de retour ou directement initié par le marchand (soit à la demande du client soit de sa propre initiative) et ce à partir du moment où la commande est confirmée.

Une fois le remboursement demandé et, dans le cas où IZBERG est connecté au partenaire de paiement de la Marketplace, la demande est envoyée au partenaire de paiement pour traitement de celui-ci. Dans l’éventualité où IZBERG ne serait pas connecté au partenaire de paiement de la Marketplace, la demande est alors enregistrée et à traiter par l’opérateur avec son partenaire de paiement.

Workflow (simplifié) de retour et remboursement IZBERG

C. Système de notations

Le système de notation des marchands par les clients est un élément clé pour le bon fonctionnement de la Marketplace. Pour les clients, c’est la garantie de la meilleure expérience possible, et d’éviter les mauvaises surprises. Pour les marchands, avoir la meilleure note possible constitue le meilleur moyen d’augmenter ses ventes et de fidéliser ses clients Marketplace. Enfin, pour l’opérateur c’est un gage de transparence envers l’ensemble des internautes et clients, et une promesse forte quant à la qualité de service proposée.

IZBERG fournit un module de notation permettant aux clients d’évaluer chaque sous-commande marchand et d’ajouter un retour d’expérience (sous forme de commentaire). Il est possible de réaliser une notation sur avec des notes de 1 à 5 pour chaque critère (1=très mauvaise, 5=excellent). IZBERG calcule ensuite la moyenne pour chaque marchand et cette information peut être affichée sur la Marketplace.

Le module permet d'afficher les notes globales des marchands sur le front-end.

L’opérateur peut modérer les notations en modifiant le commentaire de l’acheteur ou en supprimant complètement la note.

G. Configuration marchand

A. Frais de ports

Depuis son back-office, le marchand peut indiquer sa ou ses grilles de transport. Pour cela, il sélectionne d’abord la méthode de calcul qu’il souhaite utiliser, parmi celles que l’opérateur aura autorisé depuis son back-office.

Back office : exemple de méthodes de livraison disponibles
Il existe différentes méthodes de calculs (par exemple en fonction du poids, du prix, du nombre d’articles).

Un marchand peut utiliser une ou plusieurs méthodes de calcul, selon ses produits et les transporteurs avec lesquels il travaille. Pour chacune des méthodes de calcul choisies, il peut configurer le transporteur utilisé, la zone de chalandise (zone de livraison), la catégorie ou les catégories de produit(s) pour lesquelles la méthode est disponible, et enfin les tarifs associés.

Lorsque la méthode est dépendante d’une unité (prix ou poids), le marchand a également la possibilité de créer une grille de tarifs.

Le marchand gère facilement ses méthodes de livraison depuis le back-office, il peut en ajouter/modifier/supprimer.

Back office : Gestion des méthodes de livraison

Le marchand peut configurer plusieurs méthodes de calculs en fonction de la catégorie de produit par exemple, et avoir ainsi une gestion optimisée de ses frais de ports. Pour chaque commande, le calcul des frais de port associés est réalisé automatiquement par IZBERG en se basant sur ce que le marchand a configuré.

B. Gestion des taxes

IZBERG dispose d'un module de taxes qui permet à l'opérateur et aux marchands de définir simplement des valeurs par défaut, ou un paramétrage propre à chaque offre via le mapper. La réglementation européenne sur le prélèvement des taxes dans le cadre des marketplaces changera le 1er juillet prochain, ce module est donc en cours d'adaptation pour simplifier au maximum la configuration et le reporting des taxes pour l'opérateur comme pour les marchands.

Back office : configuration des taxes

4. HÉBERGEMENT ET SÉCURITÉ

A. Infrastructure

Toute l’infrastructure IZBERG est virtualisée sur Amazon Web Services (AWS) qui propose un large choix de services de calcul, de stockage, de base de données, d'analyse et de déploiement, ainsi que des services applicatifs.

AWS permet une scalabilité et une élasticité maximale de la plateforme, fournissant ainsi aux clients IZBERG les meilleures performances du marché. AWS permet de facilement anticiper les montées en charge en dimensionnant dynamiquement l’infrastructure.

IZBERG est partenaire technologique d’AWS.

Les données sont stockées sur 3 data center distincts en Irlande pour l’activité européenne d’IZBERG. (Amazon est conforme au programme Safe Harbor).

Les serveurs IZBERG sont protégés au sein d’un VPC Amazon, et tous les accès publics se font uniquement via le protocole HTTPS. L’équipe technique dispose d’un accès via une private gateway, avec un SSH et un filtrage par IP.

B. Politique de sécurité

La sécurité des données clients est un enjeu majeur pour IZBERG. En étant partenaire technologique d’AWS, IZBERG bénéficie d'un centre de données et d'une architecture réseau conçus pour répondre aux exigences des organisations les plus pointilleuses en termes de sécurité.

AWS dispose de nombreuses certifications sur lesquelles IZBERG peut s’appuyer pour proposer une plateforme robuste et sécurisée.

Liste (non exhaustive) des certifications couvertes par AWS

Un ingénieur système (certifié AWS) travaille au sein de l’équipe technique IZBERG. Il est chargé de l’infrastructure, de la sécurité et de la supervision de la plateforme. Il met en place les outils techniques et les procédures de sécurité permettant de garantir à nos clients un niveau de service excellent.

C. Performances

L’infrastructure IZBERG est entièrement virtualisée et le dimensionnement est réalisé dynamiquement grâce aux fonctionnalités offertes par AWS.

Par défaut, IZBERG s’assure que la plateforme n'atteint jamais plus de 50% de sa capacité d'absorption. Si tel est le cas, alors IZBERG ajoute des ressources virtuelles afin de revenir au seuil maximum de 50%. Tout ceci est automatisé et ne nécessite pas d’intervention humaine. Ce qui permet de pouvoir facilement absorber les pics d’activités liés aux temps forts du calendrier e-commerce (soldes, noël, black friday, cyber monday, back2school…)

Des tests de charge sont réalisés de manière régulière pour challenger la robustesse de la plateforme.

IZBERG est bien entendu ouvert à ce que le client réalise un audit de performance et de sécurité.

D. Monitoring de la plateforme

IZBERG utilise le service Amazon CloudWatch pour monitorer l’application. L’outil permet de configurer des alarmes sur différents critères (instance down, charge trop importante etc.), et de surveiller ainsi le service en temps réel.

Pour chaque alarme, des appels sont effectués toutes les minutes. Si un appel est KO pendant 3 minutes consécutives alors l’alarme est déclenchée.

Pour plus d’information voir: https://aws.amazon.com/fr/cloudwatch/details/

Cet outil est couplé au service Pager Duty (www.pagerduty.com) qui permet de gérer également les astreintes et les différents niveaux d’escalades.

IZBERG dispose d’une console de supervision permettant d’agréger tous les KPI et de le monitorer en temps réel.

/Users/davidchaouat/Desktop/Capture d’écran 2016-05-11 à 15.24.33.png

Console de supervision IZBERG