Support client IA pour les marketplaces : voies acheteurs, vendeurs et confiance

En bref

Une marketplace a deux clients dans chaque transaction, et ils veulent souvent des choses opposées. C'est pourquoi un chatbot générique unique n'est pas la bonne forme. Séparez la file en une voie acheteurs, une voie vendeurs et une voie confiance et sécurité, chacune avec ses propres connaissances et ses propres règles sur ce que l'IA a le droit de faire.

Laissez l'IA gérer entièrement les consultations : statut de commande, statut de remboursement, statut de paiement vendeur et détail des frais. Laissez-la rassembler les preuves pour les litiges acheteur-vendeur, mais gardez une personne pour désigner le gagnant. Envoyez les signalements d'arnaques et de fausses annonces en haut de la file. Et traitez les rétrofacturations par carte comme un sujet à part : l'émetteur de la carte décide, Stripe indique que vous avez généralement 7 à 21 jours, et vous n'avez droit qu'à une seule soumission.

eesel fonctionne ainsi, comme un coéquipier IA dans votre helpdesk existant : il apprend à partir des anciens tickets, appelle vos API de commandes et de paiements, et est simulé sur des tickets historiques avant de répondre à qui que ce soit. SamCart fait tourner un agent eesel sur les tickets vendeurs dans Freshdesk et un autre sur le chat du site, et Rúngne répond aux questions de commande à partir des données Shopify pendant que des personnes gardent les réclamations pour dommages et les litiges.

Pourquoi un seul chatbot échoue-t-il sur une marketplace ?

Je construis les intégrations et les actions qui permettent aux agents d'eesel de lire d'autres systèmes, donc l'essentiel de ma semaine tourne autour d'une question : que doit voir l'IA, et qu'a-t-elle le droit de modifier ? Sur une boutique à marque unique, la réponse est simple. Sur une marketplace, elle se divise en deux, car la personne qui écrit peut être l'acheteur ou le vendeur de la même commande, et il leur est dû des réponses différentes.

Prenons un colis marqué livré que l'acheteur dit ne jamais avoir reçu. L'acheteur veut un remboursement. Le vendeur veut son paiement. Un bot entraîné sur un seul centre d'aide citera soit la politique acheteur au vendeur, soit la politique vendeur à l'acheteur, et les deux sont mauvais. La garantie de remboursement d'eBay montre à quel point ce seul cas repose sur une structure : le vendeur dispose de 3 jours ouvrés pour répondre, chaque partie peut demander à eBay d'intervenir entre 3 et 21 jours ouvrés, et les commandes de 750 $ ou plus exigent une confirmation de signature comme preuve de livraison.

Je l'ai vu de l'intérieur. En mai 2026, une grande marketplace de livraison de repas nous a demandé deux bases de connaissances distinctes dans un seul centre d'aide Zendesk, l'une pour les clients et l'autre pour les restaurants. Cette demande résume tout le problème en une phrase. Nous avons aussi passé des années à placer des agents IA sur de vraies files de support et à voir des bots sûrs d'eux donner de mauvaises réponses, c'est pourquoi chaque déploiement d'eesel est désormais simulé d'abord sur des tickets historiques. Sur une marketplace, une mauvaise réponse peut vous coûter des deux côtés de la même commande.

Quels tickets de marketplace l'IA peut-elle traiter, et lesquels exigent une personne ?

Je trie les tickets de marketplace avec un seul test : existe-t-il une réponse unique et correcte quelque part dans un système ? Si oui, l'IA peut répondre seule. Si la réponse dépend d'un jugement sur qui a raison, une personne décide et l'IA fait la préparation. C'est le cœur d'un bon routage des tickets sur une plateforme à deux faces.

Les quatre premières lignes sont le volume. C'est aussi là que la plupart des bots de marketplace échouent, parce qu'ils répondent depuis le centre d'aide au lieu du système de commandes. « Les paiements arrivent généralement en 2 à 3 jours » n'est pas une réponse à « où est mon paiement ? ». La vraie réponse est un statut et une date, et elle se trouve chez votre prestataire de paiement. La moitié inférieure du tableau est l'endroit où une étape de validation humaine reste en place, définitivement.

Comment séparer acheteurs, vendeurs et confiance et sécurité en voies ?

Trois voies couvrent presque tout. La voie acheteurs gère commandes, livraison et remboursements. La voie vendeurs gère paiements, frais, annonces et vérification. La voie confiance et sécurité gère arnaques, fausses annonces et prises de contrôle de compte, et elle passe devant tout le monde.

Chaque voie a besoin de trois choses qui lui sont propres : une base de connaissances, un ensemble d'actions autorisées, et une personne ou une équipe qui reprend ce que l'IA transmet. La séparation des connaissances est la plus importante. Votre politique de remboursement acheteur et votre politique de dédommagement vendeur se contrediront volontairement, et une IA qui lit les deux les mélangera. C'est le même problème que le support client multi-marques, avec deux publics au lieu de deux boutiques.

Votre helpdesk sait probablement déjà faire cette séparation, même si l'offre à laquelle vous êtes abonné compte :

Sur Zendesk, le moyen le plus économique que j'ai vu pour modéliser acheteurs et vendeurs est une marque vendeur plus des segments d'utilisateurs, avec les fiches vendeurs stockées comme objets personnalisés liés aux tickets. Si les agents ne doivent voir que leur propre voie, c'est une question de permissions distincte, que mes notes sur le contrôle d'accès des agents de support couvrent.

smava est l'exemple le plus clair que je puisse citer de deux publics gardés séparés dans un seul helpdesk. smava et Finanzcheck partagent un seul Zendesk, et eesel traite environ 27,000 tickets par mois sur les deux, en rédigeant à partir d'environ 820 macros et articles du centre d'aide séparés par marque. Une voie vendeurs et une voie acheteurs fonctionnent de la même façon : un helpdesk, deux bases de connaissances qui ne se mélangent jamais.

Vers quelle voie ce ticket va-t-il ?

Voici la logique des voies sous une forme sur laquelle vous pouvez cliquer. Choisissez un ticket et l'outil affiche la voie, ce que l'IA a le droit de faire et qui termine le travail.

Choisissez un ticket pour voir sa voie, ce que l'IA peut faire et qui termine le travail. C'est mon point de départ pour une file de marketplace ; votre équipe de politique fixe les règles finales.

Comment connecter l'IA aux données de commandes et de paiements en direct ?

Les consultations des voies acheteurs et vendeurs ne fonctionnent que si l'IA peut lire vos systèmes en temps réel. Répondre à « où est mon paiement ? » depuis le centre d'aide donne un calendrier générique. Y répondre depuis l'API de paiement donne « votre paiement de 412 $ est en transit et devrait arriver jeudi ». La seconde réponse clôt le ticket, ce qui est tout l'intérêt du support de suivi de commande et de l'automatisation WISMO.

Les paiements vendeurs sont ce qui fait vivre ou mourir la voie vendeurs, et la documentation Connect de Stripe explique pourquoi ces tickets atterrissent chez vous. Si un vendeur ne voit pas les fonds attendus, Stripe dit qu'il doit « contacter la plateforme avec laquelle il travaille », car la plateforme contrôle les réglages et calendriers de paiement. Chaque question de paiement est donc votre ticket, pas celui de Stripe. La même page liste les statuts de paiement qu'une IA doit énoncer clairement : en attente, en transit, versé, échoué et annulé.

Les paiements échoués sont un bon exemple de ticket que l'IA peut en grande partie traiter. Quand un paiement échoue, Stripe met ce compte bancaire en erreur et suspend les paiements planifiés vers lui, et la plateforme peut générer un lien permettant au vendeur de mettre à jour ses propres coordonnées bancaires. C'est une consultation plus un lien, ce que l'IA fait bien. La même page indique que la plateforme peut bloquer un compte bancaire sur l'ensemble de la plateforme en cas de fraude, et cette action revient à une personne.

Les blocages pour vérification fonctionnent de la même manière. La documentation de vérification de Stripe dit qu'il « désactive généralement les paiements » si les informations requises ne sont pas reçues avant l'échéance, et chaque exigence s'accompagne d'une erreur en langage clair que le vendeur peut traiter. Adyen applique un compte à rebours similaire : selon sa présentation de la vérification, les vendeurs ont 30 jours pour corriger les problèmes avant l'arrêt des paiements et 60 jours avant de ne plus pouvoir accepter de paiements. Une IA qui lit les exigences en suspens et dit au vendeur exactement quoi téléverser évite un aller-retour à chaque fois.

Voici la plomberie, côté ingénierie. Il vous faut quatre lectures et presque aucune écriture :

1. Commandes : statut, articles, événements de suivi, depuis la base de données de votre marketplace ou Shopify.
2. Remboursements : émis ou non, montant, date.
3. Paiements vendeurs : statut, date d'arrivée, code d'échec, par compte vendeur.
4. Exigences du compte : quelle vérification est en suspens et pour quand.

Les webhooks maintiennent les données à jour. La page des webhooks Connect de Stripe dit que toute intégration Connect devrait écouter les événements, et ceux qui comptent pour une équipe de support sont account.updated, payout.failed et charge.dispute.created. J'aime faire ouvrir par le webhook d'échec de paiement un ticket de la voie vendeurs avant même que le vendeur n'écrive. Un « votre paiement a échoué, voici le lien pour le corriger » proactif vaut mieux qu'un e-mail confus trois jours plus tard.

Pour les écritures, ma règle est simple : tout ce qui déplace de l'argent ou modifie un compte attend une personne. Cela couvre remboursements, déblocages de paiements, annulations de frais et blocages de comptes. Si vous voulez un modèle pour savoir qui approuve quoi, ma matrice d'approbation des remboursements en propose un, et la gestion des exceptions du support couvre les cas limites.

Comment l'IA doit-elle traiter les litiges acheteur-vendeur ?

C'est là que les intérêts concurrents sont les plus vifs, et là où je ne laisserais jamais l'IA choisir un camp. Les deux parties sont vos clients. L'IA peut en revanche rendre la personne qui décide beaucoup plus rapide et beaucoup plus cohérente.

La cohérence compte plus qu'on ne le croit. Voici un hôte décrivant ce que donnait le support en cas de litige sur une grande marketplace de location :

"... The side you wins is the side you can say the magic words that specific agent wants to hear."

reverend_gonzo, Hacker News

Quand l'issue dépend de l'agent sur lequel on tombe, les deux côtés perdent confiance. La solution est un dossier de preuves standard, identique à chaque fois, constitué avant qu'une personne n'ouvre le dossier.

Mon dossier de preuves comporte cinq parties : le dossier de commande, le suivi du transporteur, le fil complet de messages acheteur-vendeur, une capture de l'annonce telle qu'elle était à l'achat, et l'historique de remboursements et de litiges des deux parties. L'IA les collecte, signale les lacunes (« le vendeur n'a pas répondu depuis 3 jours ouvrés ») et rédige une note à chaque côté une fois que la personne a décidé. Cette dernière étape est facile à sauter, et il ne faut pas le faire. La partie perdante mérite une explication claire, rédigée dans le langage de sa voie.

Les délais varient beaucoup selon le type de marketplace, alors encodez les vôtres au lieu de copier ceux des autres. Une marketplace de biens physiques s'appuie sur le suivi et la preuve de livraison : eBay demande aux vendeurs de répondre sous 3 jours ouvrés, et le processus de litige d'Etsy permet aux acheteurs d'ouvrir un dossier une fois la date de livraison estimée dépassée et 48 heures après avoir écrit au vendeur. Une marketplace de services n'a pas de numéro de suivi, elle s'appuie donc sur les jalons et les messages. Upwork donne aux freelances 7 jours calendaires pour déposer un litige à prix fixe, et le Centre de résolution de Fiverr accepte automatiquement une demande restée sans réponse pendant 48 heures. Si vous gérez une plateforme de services, votre dossier de preuves remplace le suivi par les fichiers livrés et le périmètre convenu.

Qui paie compte aussi, et cela détermine la façon dont l'IA doit formuler les choses. Sur Sharetribe, « seuls les opérateurs de la marketplace peuvent annuler une transaction et lancer un remboursement » par défaut, et une commande contestée est annulée avec remboursement intégral après 60 jours si personne n'agit. Un minuteur de ce genre est exactement ce que l'IA doit faire figurer dans le dossier de preuves, pour que rien n'expire en silence.

En quoi les rétrofacturations diffèrent-elles des litiges acheteur-vendeur ?

Une rétrofacturation peut provenir de la même commande, mais c'est un processus différent avec un juge différent. Dans un litige acheteur-vendeur, vous décidez selon votre propre politique. Dans une rétrofacturation, l'émetteur de la carte de l'acheteur décide, et vous êtes sur l'horloge du réseau.

Les règles de Stripe valent la peine d'être connues en détail, car elles sont strictes :

• Le délai est court. Le guide de réponse aux litiges de Stripe indique que le délai est généralement de 7 à 21 jours selon le réseau de cartes, et le dépasser entraîne une perte automatique.
• Vous n'avez qu'une seule chance. « Vous n'avez qu'une seule occasion de soumettre votre réponse », selon la même page. Pas de modifications, pas de liens, pas d'audio ni de vidéo, et un plafond de 4,5 Mo pour l'ensemble des preuves.
• L'historique du support est une preuve. Stripe demande aux marchands de conserver une trace de toutes les communications avec le client, car elle fait partie du dossier. Votre helpdesk est une archive de litiges, que vous l'ayez prévu ou non.
• Cela coûte de l'argent dans tous les cas. Aux États-Unis, Stripe facture 15 $ à l'arrivée d'un litige et 15 $ de plus si vous le contestez, le second montant étant restitué si vous gagnez.

Qui absorbe la perte dépend de la configuration de vos paiements. La page sur les litiges Connect de Stripe indique que pour les paiements de destination et les paiements séparés avec transferts, « Stripe débite les montants et frais de litige de votre compte de plateforme », et vous pouvez ensuite annuler le transfert pour les récupérer auprès du vendeur. Pour les paiements directs, c'est le solde du vendeur qui est débité. Le comportement par défaut d'Adyen est similaire : la plateforme paie d'abord et peut répercuter le coût sur le vendeur ou le répartir par paiement.

Le rôle de l'IA dans une rétrofacturation est donc étroit : repérer l'événement charge.dispute.created, ouvrir un ticket avec la date d'échéance dans l'objet, et constituer les preuves à partir de la commande, de la preuve de livraison et du fil de support. Une personne de la finance relit et soumet. Si vous voulez le détail côté support, mes guides sur l'IA pour les litiges de paiement et les demandes de rétrofacturation vont plus loin.

De quels contrôles la voie confiance et sécurité a-t-elle besoin ?

Les signalements d'arnaques et de fausses annonces sont les tickets où rapidité et retenue comptent à la fois. La personne qui signale doit se sentir entendue tout de suite, et l'IA ne doit ni alerter ni sanctionner quiconque de son propre chef. Se tromper dans l'autre sens est tout aussi grave, comme l'a constaté cet utilisateur de Facebook Marketplace :

"Last year, I reported a number of people, who were trying to scam me (via Messenger messages related to Marketplace listings). Not only did Facebook did not see anything wrong with the accounts and scammy messages, I was flagged for sending useless reports."

lukaslalinsky, Hacker News

Voici les cinq contrôles que je mets en place pour cette voie :

1. Routage prioritaire. Les signalements sautent la file normale et arrivent à l'équipe confiance et sécurité. Le routage par compétences de votre helpdesk s'en charge ; le rôle de l'IA est d'étiqueter correctement le ticket du premier coup.
2. Conservation des preuves. L'IA enregistre l'annonce, les messages et les détails du compte au moment du signalement, car les escrocs modifient ou suppriment vite.
3. Actions restreintes. L'IA peut accuser réception et étiqueter. Elle ne peut pas bloquer, suspendre, rembourser ni écrire au compte signalé. Ce sont des garde-fous de l'IA que vous définissez une fois et ne desserrez jamais.
4. Vigilance face à l'usurpation d'identité. Les vendeurs reçoivent des messages d'escrocs se faisant passer pour votre support. Un ancien vendeur Etsy décrivait « plus de 20 messages par jour d'escrocs se faisant passer pour des acheteurs ou le support Etsy ». Votre IA ne doit jamais demander de mots de passe ni de données de paiement, et doit le dire dans ses réponses.
5. Recours et piste d'audit. Chaque action sur un compte est consignée avec la personne qui l'a approuvée. Quand un vendeur fait appel d'une suspension, la personne qui l'examine voit tout l'historique au même endroit.

Les prises de contrôle de compte méritent leur propre règle. Si un vendeur écrit « quelqu'un a modifié mes coordonnées bancaires », traitez-le comme urgent et transmettez-le immédiatement à une personne. Les outils de paiement de Stripe permettent à une plateforme de bloquer un compte bancaire sur toute la plateforme ou de rejeter un compte en cas de prise de contrôle, mais ces décisions reviennent à votre équipe, pas à l'IA. Pour le schéma plus général des transmissions propres, voyez mes notes sur la gestion des escalades par l'IA.

Comment déployer tout cela ?

Je commencerais par les consultations, pas par les litiges, et je testerais avant toute mise en service. Voici une séquence qui a fait ses preuves :

1. Semaine 0 : cartographier et connecter. Récupérez 300 tickets récents et triez-les dans les trois voies. Connectez un accès en lecture aux commandes, remboursements, paiements et exigences des comptes. Rédigez la liste des actions restreintes.
2. Semaines 1 à 2 : simuler. Faites tourner l'IA sur des tickets historiques de chaque voie et comparez ses réponses à ce que votre équipe a réellement envoyé. Mon guide de test avant lancement et ma fiche d'évaluation de pilote expliquent comment la noter.
3. Semaines 3 à 4 : consultations en production. Statut de commande, statut de remboursement, statut de paiement et questions sur les frais partent sans intervention humaine. Tout le reste est en brouillon uniquement.
4. Semaines 5 à 8 : dossiers de preuves. L'IA commence à constituer les dossiers de litiges et de rétrofacturations. Les personnes décident toujours de chacun.
5. En continu : étiquetage confiance et sécurité. Activez l'étiquetage prioritaire des signalements, avec zéro action de l'IA sur les comptes, jamais.

L'étape de simulation est celle où les marketplaces découvrent leurs surprises. Un cas typique : l'IA donne à un vendeur la politique de retour acheteur parce qu'un vendeur a demandé « comment fonctionnent les retours ? ». C'est un problème de séparation des connaissances, et vous voulez le découvrir dans un rejeu de tickets passés, pas dans la boîte de réception d'un vendeur réel. Mon guide du pilote de support IA propose la version en quatre semaines de ce plan.

Que mesurer sur une plateforme à deux faces ?

Le taux de déflexion est le mauvais indicateur principal pour une marketplace. Un acheteur qui reçoit une réponse de bot et abandonne compte comme dévié, tout comme un vendeur qui se tait et vend ailleurs. Je mesure chaque indicateur deux fois, une par côté.

Séparer le CSAT par côté est ce que je défends le plus. Les vendeurs forment souvent un groupe plus petit avec une valeur à vie bien plus élevée, et une voie vendeurs qui se dégrade en silence n'apparaîtra pas dans un score global. Pour les définitions, mes analyses des indicateurs d'IA pour l'expérience client et des tickets répétés passent chacun en revue.

Les vendeurs vous diront quand la voie vendeurs est cassée, généralement en public. Voici le propriétaire d'une petite entreprise à propos d'un paiement bloqué :

"We are affected by this as Etsy is currently holding about 4000 of our Euros... The worst thing about it is that we raised a support request for this, for which you have to jump through really stupid hoops, and have not even heard back from them in weeks. Not even a boilerplate response."

handmadeta, Hacker News

Un blocage de paiement peut être la bonne décision pour des raisons de risque. Des semaines de silence ne le sont jamais. Une IA qui lit le motif du blocage et répond le jour même, ne serait-ce que par « vos fonds sont retenus pour un contrôle de vérification, voici ce dont nous avons besoin », transforme ce message en un ticket qui n'est jamais écrit.

Comment eesel s'intègre-t-il à une équipe de support de marketplace ?

eesel est un coéquipier IA qui rejoint le helpdesk que vous utilisez déjà, dont Zendesk, Freshdesk et Gorgias, ainsi que HubSpot. Il apprend à partir de votre centre d'aide et de vos anciens tickets, et vous pouvez faire tourner un agent distinct par voie, chacun avec ses propres connaissances et instructions.

La partie données en direct est celle sur laquelle je travaille le plus. Le réglage Network Access d'eesel permet à un agent d'appeler vos propres API, afin qu'il puisse consulter en direct commandes, remboursements ou paiements. Vous autorisez un domaine et définissez l'en-tête d'authentification, et les identifiants sont joints à chaque requête par eesel, de sorte que l'IA ne les voit jamais. Les données de commandes Shopify se connectent via l'intégration Shopify. Les permissions d'action vous permettent de régler chaque action sur automatique, avec approbation ou désactivée, ce qui garde remboursements et modifications de compte derrière une personne.

Si vos ingénieurs préfèrent travailler depuis un terminal, la CLI eesel fait tourner le même coéquipier et le même espace de travail en ligne de commande. Vous pouvez examiner les approbations en attente, lire le journal d'activité de chaque exécution et modifier les instructions permanentes de l'agent, et des agents de code comme Claude Code peuvent aussi la piloter. Pour une marketplace qui gère déjà ses systèmes de commandes et de paiements sous forme de code, cela garde les règles de l'agent de support à côté de tout le reste.

Deux témoignages clients montrent les voies en pratique. SamCart, une plateforme par laquelle plus de 75 000 entreprises vendent, fait tourner eesel sur son support vendeurs : un agent répond aux tickets Freshdesk et un autre gère le chat du site, tous deux répondant à partir d'environ 280 articles du centre d'aide. L'agent ne répond que tant qu'aucun coéquipier n'est assigné, et quand un vendeur demande une personne, le ticket est étiqueté pour transmission et l'agent s'arrête. Rúngne illustre le côté acheteur : eesel a traité environ 2,100 tickets Gorgias en un mois, répondant aux questions « où est ma commande » et de stock à partir des données Shopify, tandis que annulations, articles endommagés, colis perdus et litiges douaniers vont à des personnes.

Les limites, honnêtement : eesel ne tranche pas les litiges et ne soumet pas à votre place les réponses aux rétrofacturations, et je ne voudrais pas qu'il le fasse. Son audit SOC 2 Type II est en cours, avec une période d'observation débutant le 1er octobre 2026. Les tarifs figurent sur la page tarifs : une offre gratuite avec 100 crédits, et des offres Teammate à partir de $299 par mois pour 500 crédits, où un ticket ou un chat représente un crédit. Si vous hésitez entre une couche d'IA distincte et l'IA intégrée de votre helpdesk, j'ai comparé les deux dans ma comparaison des couches d'IA.

Essayez eesel sur la file de votre marketplace

Si vos acheteurs et vos vendeurs reçoivent les mêmes réponses toutes faites, eesel peut donner à chaque côté sa propre voie dans le helpdesk que vous utilisez déjà : consultations en direct des commandes et paiements pour les tickets faciles, dossiers de preuves pour les litiges, et chaque décision d'argent laissée à votre équipe. Chaque déploiement commence par une simulation sur vos tickets historiques, pour que vous voyiez comment il répond aux acheteurs et aux vendeurs avant tout le monde.

Essayez eesel gratuitement avec 100 crédits, ou réservez une démo et apportez un échantillon de tickets d'acheteurs et de vendeurs pour que nous cartographiions vos voies ensemble.