Un seller manager prépare le comité hebdomadaire d’un vendeur stratégique. Le CRM le présente comme « sain », le catalogue montre 3 200 offres mais 600 sont bloquées, la finance retient deux payouts et le support traite quatorze dossiers sans connaître la suspension documentaire. Après quarante minutes d’enquête, l’équipe découvre que chaque écran décrit une partie différente du même vendeur.
Le problème n’est pas l’absence de données : c’est l’absence de contexte partagé. Une mosaïque de KPI sans date, population ni cause donne une illusion de maîtrise. Elle pousse les opérateurs à ouvrir dix onglets, copier des chiffres dans un tableur et prendre une décision de risque sur des informations qui ne convergent pas.
Le vrai enjeu d’une vue vendeur 360 sur une marketplace opérateur est de réunir les preuves nécessaires à une décision, sans fabriquer une nouvelle source de vérité. Contre-intuitivement, l’écran le plus utile ne montre pas tout : il hiérarchise état, tendance, obligations, incidents et actions selon le rôle et le moment.
Vous allez comprendre comment relier identité, organisation, catalogue, commandes, finance, risque et conformité. La conception garde provenance, fraîcheur et version ; les actions sensibles utilisent prévisualisation, idempotence et audit, tandis que le run mesure les dossiers incomplets et la capacité réelle à décider depuis une chronologie commune.
Définir la mission de la vue 360
Partir des décisions à prendre
La page doit répondre à des questions précises : peut-on activer le vendeur, ouvrir une catégorie, libérer un payout, traiter un incident ou renouveler un contrat ? Chaque décision possède ses entrées minimales, son owner et un délai. Les données sans usage opérationnel restent accessibles en profondeur, pas dans la synthèse.
Le contrat reçoit vendeur, rôle utilisateur et instant ; il retourne état, alertes, obligations et prochaines actions. Cette sortie ne remplace pas les domaines. Elle cite leurs verdicts et leurs versions. Une carte financière ne recalcule jamais le solde ; elle présente le montant issu du ledger avec sa dernière réconciliation.
Limiter la synthèse à l’actionnable
Une première zone affiche identité, statut opérable, niveau de service et trois alertes prioritaires. Une deuxième explique les causes ; une troisième donne la chronologie et les dossiers. Le reste s’ouvre à la demande. Cette hiérarchie permet au support de comprendre en trente secondes sans priver l’analyste de détail.
Le compromis oppose exhaustivité et lisibilité. Ajouter cinquante KPI réduit les changements d’écran mais augmente les interprétations et la charge cognitive. L’équipe mesure clics, temps de résolution et champs jamais consultés. Un élément sans décision associée pendant trois mois quitte la synthèse après revue de son owner.
Ancrer identité et organisation
Distinguer compte, entité et enseigne
Le vendeur visible peut représenter une société légale, plusieurs établissements, une marque et des comptes utilisateurs. La vue nomme ces niveaux et leurs liens. Elle affiche identifiant interne, références PSP, contrat, pays d’établissement, établissements actifs et enseignes publiques sans fusionner leurs responsabilités.
Une hiérarchie versionnée indique parent, filiale, établissement payeur et périmètre commercial. Les changements de raison sociale ou de contrôle ne réécrivent pas les commandes historiques. Un alias de recherche permet de retrouver l’entité depuis ancien nom, numéro légal, email professionnel ou identifiant partenaire.
Rendre les contacts responsables
Commercial, catalogue, finance, conformité, logistique et urgence possèdent des contacts distincts avec canal, langue, horaires et date de vérification. Une adresse générique ne remplace pas un owner. Le statut « contact invalide » devient une obligation avec échéance et conséquence opérationnelle.
Par exemple, si le contact finance rebondit à sept jours d’un payout, alors la page avertit seller management et bloque seulement les changements bancaires, pas tout le catalogue. La résolution associe nouveau contact, preuve, valideur et instant. L’ancien reste dans l’audit sans être utilisé pour une notification future.
Résumer le contexte opérationnel
Présenter statut et périmètre effectif
Actif, limité, suspendu ou en sortie ne suffit pas. La synthèse précise marchés, catégories, capacités et actions réellement autorisées. Un vendeur peut publier en France, vendre en Belgique et rester bloqué pour l’Allemagne. Le statut effectif est calculé depuis règles et obligations, puis expliqué.
Le moteur de policy retourne décision, raisons, version et date de prochaine revue. La vue présente la règle dominante et les exceptions. Si deux domaines se contredisent, elle affiche « incohérent » et ouvre un dossier ; elle ne choisit pas silencieusement l’état le plus favorable ou le plus récent.
Montrer tendance et événements récents
Volume, taux de service, litiges et catalogue sont comparés à la période précédente et à un segment pertinent. Une hausse de 50 % n’est pas bonne ou mauvaise sans dénominateur. Les marqueurs indiquent lancement, promotion, incident ou changement de contrat qui explique la rupture de série.
La chronologie regroupe événements métier : activation, import majeur, sanction, changement bancaire, incident, payout et correction. Chaque entrée cite source, acteur et dossier. Les logs techniques restent derrière un lien de diagnostic ; ils ne polluent pas l’histoire racontée à l’opérateur.
Expliquer la santé du catalogue
Distinguer volume et offre publiable
La vue sépare produits reçus, reconnus, complets, modérés, publiés et réellement achetables. Un total de 10 000 lignes peut cacher 300 offres visibles. Les compteurs utilisent la même date et le même périmètre, puis proposent les catégories ou causes qui expliquent la différence.
Les entrées viennent du PIM, de la modération, du stock, du prix et des droits. Une projection matérialisée facilite la lecture mais conserve les versions sources. Une réconciliation quotidienne compare projection et domaines ; tout écart rejoint une file avec ancienneté, population et owner.
Prioriser les blocages réparables
Attribut manquant, image refusée, prix incohérent, stock absent et catégorie non autorisée reçoivent chacun nombre d’offres, chiffre potentiel et marche de correction. L’opérateur distingue défaut vendeur, attente opérateur et dépendance externe. Une file générique « catalogue incomplet » ne permet aucun pilotage.
Scénario : 800 offres sont bloquées, mais 650 partagent le même mapping de taille. Si la correction du mapping débloque plus de 70 % du potentiel, alors elle devient première action. Le back-office simule le résultat, affiche les exceptions et publie par cohorte après validation du responsable catalogue.
Relier commandes et service
Mesurer le parcours complet
Commandes reçues, acceptées, expédiées, livrées, retournées et litigieuses forment un funnel avec délais et dénominateurs. La vue sépare stock vendeur, transport et intervention opérateur. Un taux de livraison agrégé ne doit pas accuser le vendeur pour une panne de label ou masquer ses retards récurrents.
Chaque KPI ouvre sa population et ses exemples. Le seller manager peut passer d’un taux de 4,2 % à la liste des commandes, puis à leur chronologie. Les données personnelles sont minimisées ; l’accès au détail dépend du rôle et toute consultation sensible est auditée.
Faire remonter les engagements menacés
Les commandes sans accusé, expéditions dépassant le SLA, litiges sans réponse et retours sans remboursement apparaissent avant l’échec définitif. L’alerte indique seuil, âge, valeur et owner. La synthèse privilégie le risque actuel plutôt que le nombre total d’incidents déjà clos.
Si vingt commandes dépassent deux heures sans acceptation et que le taux normal est inférieur à 0,5 %, alors le run ouvre un incident vendeur. La page montre contact d’urgence, dernier événement, webhook et procédure de repli. Le retour au vert attend le verdict de chaque dossier exposé.
Rendre la situation financière lisible
Séparer vendu, gagné et payable
GMV, fonds capturés, commission, remboursement, retenue, réserve et solde disponible sont des concepts distincts. La carte financière définit période, devise et événement de reconnaissance. Elle rapproche commandes, ledger et payouts ; elle ne soustrait pas quelques compteurs affichés pour fabriquer un net approximatif.
Le relevé montre solde initial, mouvements, retenues et solde final. Une divergence entre ledger et PSP porte montant, commandes et statut d’investigation. Le vendeur voit la part partageable ; finance accède aux références complètes. Les deux projections viennent du même dossier versionné.
Expliquer retenues et échéances
Une retenue cite motif, règle contractuelle, montant, date de revue et action attendue. « Payout bloqué » sans cause crée des tickets et des manipulations dangereuses. Les montants non contestés peuvent rester payables si le contrat l’autorise ; la page explicite ce compromis au lieu de figer tout le compte.
Par exemple, si un document bancaire expire mais que l’identité légale reste valide, alors les nouveaux payouts sont retenus tandis que les commandes continuent sous plafond. Au seuil de 20 000 euros ou quinze jours, conformité réévalue la mesure. Chaque changement produit un événement et une communication cohérente.
Présenter le risque sans sentence
Décomposer le score
Le risque est présenté par dimensions : identité, fraude, service, catalogue, finance, conformité et cybersécurité. La synthèse montre facteurs, tendance et date de calcul. Un score unique ne doit jamais remplacer les signaux ni déterminer automatiquement une sanction irréversible.
Chaque facteur cite source, fenêtre, poids et confiance. Une donnée manquante est « inconnue », pas zéro risque. La version du modèle reste attachée au verdict. Les utilisateurs autorisés peuvent comparer le résultat avant et après un signal sans exposer des règles exploitables aux fraudeurs.
Relier niveau et contrôles proportionnés
Un risque élevé peut déclencher revue documentaire, plafond, délai de payout ou échantillonnage renforcé. La page explique le contrôle, son owner et sa sortie. Produit vérifie que deux vendeurs semblables reçoivent le même traitement ou qu’une différence possède une raison documentée.
Scénario : le taux de litige double après une campagne, mais les commandes sont concentrées sur un nouveau produit. Si le reste du catalogue demeure sain, alors le contrôle cible la référence et la cohorte ; il ne suspend pas automatiquement l’entreprise entière. L’analyste conserve la décision et sa révision prévue.
Piloter les obligations ouvertes
Transformer une exigence en dossier
Document, formation, plan de correction, réponse à litige ou mise à jour de contact deviennent des obligations structurées. Chacune contient cause, preuve, owner vendeur, owner opérateur, échéance, statut et conséquence. Une note libre ne suffit pas pour automatiser rappel ou limitation.
Les dépendances sont visibles : une catégorie peut attendre une assurance, un payout une vérification bancaire et une activation une formation. La fermeture exige une preuve et un valideur. Une correction refusée conserve son motif et la prochaine action afin d’éviter les boucles de soumission.
Prioriser selon impact et échéance
La file combine criticité, délai, chiffre exposé et capacité à corriger. Une obligation légale imminente passe avant un enrichissement éditorial ancien. Le vendeur dispose d’une liste cohérente avec le back-office ; les deux parties ne se disputent plus sur des statuts provenant de systèmes différents.
Si une preuve critique expire sous sept jours, alors rappel, escalation et limitation prévue sont planifiés. Une expiration automatique n’efface pas la relation : elle applique la policy, crée l’événement et ouvre le runbook. Le retour exige preuve validée et propagation confirmée sur les capacités touchées.
Sécuriser les actions opérateur
Prévisualiser l’effet
Suspendre, limiter, relancer, débloquer un lot ou corriger un statut sont des commandes métier. L’interface présente population, effets immédiats, dépendances, communication et rollback avant confirmation. Au-delà d’un seuil financier ou d’un nombre d’offres, une seconde approbation devient obligatoire.
Les entrées comprennent vendeur, périmètre, version, motif et clé idempotente ; la sortie donne commande, verdict et événements créés. Une action concurrente sur une version différente est refusée. Le back-office ne transforme jamais un double clic en double sanction ou double message.
Journaliser et réconcilier
Le journal enregistre auteur, policy, avant, après, ticket et résultats par domaine. Une outbox propage la commande ; chaque consumer accuse succès, échec ou version déjà supérieure. Le statut global reste partiel tant qu’une destination critique n’a pas confirmé.
Par exemple, une suspension retire les offres mais l’index conserve vingt pages. Si la convergence dépasse cinq minutes, alors le run maintient l’incident, invalide l’index et identifie les sessions exposées. Le rollback restaure uniquement les domaines ayant appliqué la version fautive, sans ressusciter une offre modifiée depuis.
Adapter la vue aux responsabilités
Créer des projections par rôle
Seller management voit relation, obligations et potentiel ; support voit dossiers et actions autorisées ; finance voit ledger et payout ; conformité voit preuves et risque. Une base commune évite les contradictions, tandis que les projections masquent les champs inutiles ou sensibles.
Les droits sont évalués à la lecture, à l’export et à l’action. Un rôle temporaire possède motif et expiration. Les recherches sensibles et téléchargements sont audités. Une capture ou un export ne doit pas contourner les restrictions appliquées à l’écran.
Conserver un parcours d’enquête
Chaque carte ouvre son domaine avec filtres et contexte déjà positionnés. Le retour conserve vendeur et période. L’opérateur ne recopiera pas un identifiant entre cinq outils. Des liens profonds signés permettent le partage interne sans exposer la page à un utilisateur non autorisé.
Le support part d’une commande ou d’un email et retrouve le vendeur, puis les obligations pertinentes. Le seller manager part d’un vendeur et ouvre les commandes exposées. Ces deux chemins doivent converger vers le même dossier et les mêmes versions, sinon la vue 360 ne fait que déplacer la fragmentation.
Gouverner données et fraîcheur
Afficher provenance et âge
Chaque carte connaît source, instant, version et SLA. Un badge « temps réel » est interdit si la projection a dix minutes de retard. Les données critiques peuvent revalider à l’ouverture ; les tendances acceptent un rafraîchissement plus lent. La page indique l’incertitude plutôt que de cacher un timeout.
L’instrumentation mesure fraîcheur, erreurs de jointure, identités orphelines et cartes sans owner. Un cache possède clé et invalidation par vendeur. Si la source tombe, alors la vue garde les valeurs encore sûres et désactive les actions dépendantes d’un verdict actuel.
Réconcilier les domaines
Un job compare statuts, compteurs et versions avec leurs sources. Les écarts rejoignent une file classée par impact. La correction se fait dans le domaine autoritaire ; la projection est reconstruite. Aucun opérateur ne modifie directement une carte pour la rendre visuellement cohérente.
Le SLI principal mesure dossiers décidables : proportion de vendeurs dont identité, statut, obligations et données critiques sont à jour. Si ce taux passe sous 99 % ou si un vendeur stratégique reste incohérent plus de quinze minutes, alors le run réduit les actions sensibles et ouvre le rapprochement.
Adapter la méthode et éviter les erreurs
Pour qui une vue vendeur 360 convient
Elle devient utile lorsque plusieurs domaines et équipes interviennent sur le cycle vendeur. Une petite marketplace peut commencer par identité, statut, catalogue, commandes et obligations. Elle n’a pas besoin d’un data lake ; elle a besoin d’identifiants stables, de sources nommées et de décisions traçables.
Produit porte la mission ; domaines les verdicts ; data les projections ; sécurité les accès ; opérations les actions ; support la chronologie. Chaque carte possède un owner. Les vendeurs accèdent à une projection distincte, cohérente mais limitée aux informations qu’ils peuvent comprendre et corriger.
Erreurs fréquentes dans une vue vendeur 360
Copier les données, afficher un score sans facteurs, mélanger périodes, masquer la fraîcheur et ajouter des actions sans prévisualisation sont les erreurs majeures. Elles créent un écran impressionnant mais dangereux, dont les chiffres ne peuvent pas être défendus lors d’un incident.
Une autre erreur consiste à viser le temps réel partout. Cette exigence augmente coût et fragilité sans bénéfice pour une adresse légale stable. La bonne fraîcheur dépend de la décision : secondes pour une suspension, minutes pour un backlog, journée pour une segmentation commerciale.
Plan d’action pour construire la vue vendeur 360
Semaines 1 à 4 : décisions et projections
La première semaine observe dix enquêtes et liste les décisions, données et écrans utilisés. La deuxième fixe identité, rôles, sources et fraîcheur pour cinq cartes : statut, catalogue, service, finance et obligations. Chaque métrique reçoit définition, période, dénominateur et lien vers sa population.
Les semaines trois et quatre construisent la projection et la chronologie avec version, provenance et réconciliation. Sécurité ferme les champs par rôle ; support teste la recherche multi-identifiants ; seller management compare vingt dossiers à ses pratiques. Les incohérences connues restent visibles avec owner et échéance.
Semaines 5 à 8 : actions et run
La cinquième semaine branche obligations et actions en lecture seule. La sixième active une commande réversible avec prévisualisation, idempotence, audit et rollback. L’instrumentation suit fraîcheur, temps de décision, changements d’écran et populations sans verdict.
Les semaines sept et huit ouvrent une cohorte de seller managers puis de support. La recette rejoue vendeur multi-entités, payout retenu, catalogue bloqué, score incomplet et suspension partielle. Le go exige zéro source parallèle, 99 % de dossiers décidables et une réconciliation exécutée sans correction directe.
Le dossier final contient dictionnaire, policies, matrice d’accès, dashboards et runbooks. Toute nouvelle carte déclare décision, source, owner, fraîcheur et parcours de détail. Si elle ne réduit ni délai ni erreur, elle reste hors synthèse jusqu’à preuve de son utilité.
- À faire d’abord : choisir cinq décisions et leurs sources autoritaires.
- À tester ensuite : identité ambiguë, projection périmée, action concurrente et rollback partiel.
- À différer : les KPI sans owner ni population consultable.
- À refuser : toute action sensible fondée sur un statut incohérent ou sans version.
Ressources complémentaires pour l’opérateur
Structurer catalogue et dossiers
Le catalogue PIM marketplace fournit les identités et statuts nécessaires à la santé de l’offre.
Les écrans du back-office opérateur aident à organiser cartes, files, chronologies et actions.
Borner la première cohorte
Le MVP marketplace avant ouverture permet de limiter domaines et rôles au nécessaire.
La méthode pour ouvrir une première catégorie éprouve la vue sur des vendeurs et incidents réels.
Conclusion : décider depuis un même dossier
Une vue vendeur 360 utile assemble des verdicts sourcés autour des décisions, sans recopier les vérités de chaque domaine.
Identité, catalogue, service, finance, risque et obligations restent explicables, datés et accessibles selon la responsabilité.
Les actions utilisent prévisualisation, idempotence et audit. La réconciliation maintient l’écran aligné avec la réalité opérationnelle.
Pour concevoir cette vue et son run, Dawap peut vous accompagner dans votre marketplace opérateur.
