
Ce qu'est un helpdesk multi-clients, et qui en a besoin
Un helpdesk multi-clients est un seul compte de helpdesk configuré pour qu'une équipe de support serve plusieurs entreprises distinctes, chacune avec ses propres clients, son ton et ses règles. Chaque éditeur de helpdesk appelle le « client » autrement : une marque dans Zendesk et Deskpro, un produit ou un Workspace dans Freshdesk, une Inbox dans Help Scout, un workspace dans Front, une boutique dans Gorgias, un département dans Zoho Desk, un client dans HaloPSA.
Quatre types d'équipes en utilisent un :
- Des agences qui vendent du support en tant que service à plusieurs marques, souvent en plus d'un travail de marketing ou de développement. Mon article sur l'IA pour le support des agences couvre ce modèle économique.
- Des équipes de support externalisées (BPO) qui assurent la file pour des entreprises clientes. Voir mon guide sur l'externalisation du service client.
- Des MSP qui assurent le support informatique de nombreuses entreprises clientes, généralement sur un outil PSA. Mon tour d'horizon des systèmes de tickets pour MSP les détaille.
- Des entreprises multi-marques avec une seule équipe de support derrière plusieurs boutiques ou gammes de produits.
J'ai passé ces dernières années à construire les intégrations de helpdesk derrière eesel, et c'est avec les configurations multi-marques que j'ai le plus appris. Plus tôt cette année, une équipe Gorgias avec 3 marques, une équipe Zendesk qui avait besoin de deux agents avec des jeux d'articles différents et une configuration Zendesk à marques séparées se sont toutes heurtées au même mur sur eesel : la configuration par marque était trop difficile à faire seul, et deux utilisateurs d'un même compte ont résilié pour cette raison. C'est pourquoi chaque marque Zendesk se connecte désormais à eesel séparément et peut pointer vers son propre agent. Aujourd'hui, une entreprise de bien-être multi-marques sur Zendesk fait tourner cinq agents IA dédiés sur eesel, un par marque, chacun apprenant à partir des tickets de cette marque.
La leçon de ces déploiements est la thèse de cet article. Séparer la boîte de réception prend un après-midi. Empêcher les clients de se mélanger est le vrai chantier.
La boîte de réception est la partie facile
Tous les helpdesks que j'ai examinés peuvent donner à chaque client sa propre porte d'entrée. Le problème, c'est la pièce derrière.

Voici ce qui se sépare proprement par client dans la plupart des outils :
- Adresse e-mail et boîte de réception. Zendesk crée une adresse de support par marque, Help Scout donne à chaque Inbox sa propre boîte partagée, et Gorgias donne à chaque boutique son propre e-mail de support et sa signature.
- Centre d'aide. Chaque marque Zendesk peut avoir son propre centre d'aide, chaque produit Freshdesk obtient un portail, et chaque département Zoho Desk peut en avoir un à son image dans Enterprise.
- Objectifs de SLA. Help Scout définit des politiques de SLA par Inbox, Deskpro par marque, HaloPSA par site.
- Réponses enregistrées et macros. Help Scout limite les réponses enregistrées par Inbox ; Gorgias propose des macros et des règles propres à chaque marque.
Et voici ce qui a tendance à rester partagé, directement d'après la documentation de chaque éditeur :
| Ce qui reste partagé | Où l'éditeur le dit |
|---|---|
| Fiches clients | Zendesk : « Vous ne pouvez pas segmenter les utilisateurs finaux ou les organisations par marque » (documentation multibrand). Front : les workspaces « ne fournissent pas de silos de données de contacts » (aide Front). Freshdesk : les contacts et les entreprises ne sont pas limités par Workspace. HubSpot : les contacts sont filtrés par une propriété Brands, pas séparés |
| Accès administrateur | Les administrateurs Zendesk sont ajoutés à toutes les marques et ne peuvent pas être retirés. Les administrateurs Freshdesk rejoignent automatiquement tous les Workspaces. Les Super Admins HubSpot peuvent toujours voir les ressources restreintes |
| Champs de ticket et modèles | Freshdesk partage champs de ticket, formulaires, modèles, rôles et automatisations globales entre Workspaces (documentation des Workspaces). Zendesk n'a qu'un seul modèle d'e-mail pour tout le compte |
| Édition des connaissances | Dans Help Scout, un simple Utilisateur peut « créer et modifier des articles sur tous les sites Docs » même s'il est limité à l'Inbox d'un seul client (documentation des rôles) |
Rien de tout cela n'est un défaut de ces produits. Ils ont été conçus pour une entreprise avec plusieurs marques, ce qui est un modèle de confiance différent de celui d'une agence qui détient les données de dix clients sans lien entre eux. Il suffit de savoir quel modèle vous achetez.
Les trois façons dont une configuration multi-clients fuit
Quand un helpdesk multi-clients tourne mal, c'est presque toujours l'une de trois choses. Je concevrais votre configuration à rebours à partir d'elles.

1. Une réponse part de la mauvaise marque
C'est celle que les clients remarquent, car leur client reçoit un e-mail signé par l'entreprise d'un autre. Les causes sont banales. Dans Zendesk, le compte n'a qu'un seul modèle d'e-mail, donc les e-mails propres à chaque marque nécessitent des déclencheurs (triggers) séparés, et « vous n'avez qu'un seul jeu de triggers » à délimiter avec des conditions de marque. La marque d'une adresse de support ne peut pas être modifiée ensuite ; on la supprime et on la recrée. Les triggers peuvent même affecter un ticket à un agent extérieur à sa marque, qui se heurte alors à une erreur d'accès.
Ce n'est pas seulement un problème de marque. Un MSP sur Reddit a décrit un client qui a transféré l'e-mail de ticket d'un autre prestataire, lequel correspondait à un numéro de ticket de son PSA :
« ce qui a fait que le numéro de ticket dans l'objet de l'e-mail a rouvert un ticket clos pour un autre client, et notre client s'est demandé pourquoi nous n'avions jamais fait de suivi »
La solution est ennuyeuse et elle marche : une adresse de support par client, des conditions de marque sur chaque trigger qui envoie des e-mails, et un ticket de test vers l'adresse de chaque client après toute modification.
2. Une fiche client est partagée entre clients
Si deux de vos clients partagent des clients finaux (fréquent pour un BPO qui sert plusieurs marques d'une même maison mère, ou un MSP dont le personnel client circule entre entreprises), la fiche du contact n'existe généralement qu'une fois dans le compte. Front prévient que les champs personnalisés sont partagés quand le même contact écrit dans deux workspaces. Les propriétés de contact associées à une marque dans HubSpot sont « disponibles pour tous les contacts, pas seulement ceux associés à la marque » (documentation HubSpot).
Pour la plupart des entreprises multi-marques, ce n'est pas gênant, voire utile. Pour une agence qui détient les données de clients sans lien entre eux, c'est l'argument le plus fort en faveur de comptes séparés.
3. L'IA répond à partir des connaissances du mauvais client
C'est la fuite la plus récente et celle qui m'inquiète le plus, car personne ne relit chaque réponse de l'IA. Si un agent IA peut voir les centres d'aide de cinq clients, il finira tôt ou tard par donner la politique de remboursement du client A au client final du client B.
L'IA propre à chaque helpdesk gère cela différemment. Zendesk associe un agent IA au centre d'aide d'une marque, n'autorise qu'un seul agent IA actif par canal et, pour l'e-mail, recommande un agent adapté par marque plutôt que plusieurs. Freshdesk laisse chaque agent IA Freddy choisir le portail dont il apprend, mais plafonne les sources de sites web à 25 par compte, donc 10 clients avec 3 URL chacun n'y tiennent pas (documentation Freshdesk). Je détaille le volet IA plus bas.
Une responsable du support qui configurait Zendesk pour deux régions est tombée exactement là-dessus sur Reddit :
« Zendesk AI puise ses connaissances dans les centres d'aide liés à la même marque, quels que soient la langue ou la région. Donc si une cliente brésilienne pose une question, l'IA peut baser sa réponse sur tous les contenus associés, même sur des articles tout juste créés pour les États-Unis. »
Son alternative a été une marque par région, avec des centres d'aide et des configurations d'IA distincts. Pour une configuration multi-clients, c'est la seule version à laquelle je ferais confiance.
Comment chaque helpdesk gère plusieurs clients
Voici la comparaison côte à côte. Les prix sont par agent et par mois avec facturation annuelle, d'après la page tarifaire de chaque éditeur en octobre 2026, et « mur strict » désigne un paramètre qui empêche un agent de voir les tickets d'un autre client, pas un filtre d'affichage.
| Helpdesk | Unité cliente | Forfait le moins cher qui l'inclut | Clients inclus | Mur strict pour les agents | IA par client | Ce qui reste partagé |
|---|---|---|---|---|---|---|
| Zendesk | Marque | Suite Professional $115 | 5 (300 dans Enterprise) | Enterprise uniquement (espaces de département) | Agent IA par centre d'aide de marque ; 1 par canal | Utilisateurs finaux, organisations, modèle d'e-mail, administrateurs |
| Freshdesk | Produit ou Workspace | Pro $55 | 5 produits (illimités dans Enterprise) ; 30 Workspaces dans Enterprise | Workspaces, Enterprise $89, sur demande | L'agent IA Freddy choisit un portail ; 25 URL par compte | Contacts, rôles, champs de ticket, modèles |
| Help Scout | Inbox | Standard $25 (2 Inboxes) | 2 / 5 / 10, Inbox supplémentaire $10 | Tous les forfaits | Un agent IA par Beacon client | Édition de Docs sur tous les sites |
| Front | Workspace | Professional $65 | 5 (illimités dans Enterprise) | Rôles de workspace ; rôles personnalisés dans Enterprise | Sources de connaissances par workspace | Contacts, facturation, intégrations |
| Gorgias | Boutique | Tout forfait (facturé au ticket, à partir de $50/300 tickets) | « Une boutique ou 30 » | Non documenté | Un agent IA par boutique Shopify | Rôles à l'échelle du compte |
| Zoho Desk | Département | Professional $23 | 10 (50 dans Enterprise) | Affectation de département | Answer Bot par département | Non précisé dans la documentation |
| HubSpot Service Hub | Marque (option) | $1,000/mois par marque sur Marketing Hub Enterprise | Jusqu'à 100 | Aucune règle basée sur la marque trouvée | Un agent client par marque | Contacts |
| Deskpro | Marque | Team $39 (min. 5 agents) | 3 / 10 / centres d'aide illimités | Autorisations par marque | Non documenté par marque | Non précisé |
| HaloPSA | Client > Site | £69, un seul niveau | Illimités, clients gratuits | Restrictions de client par agent | Listes de KB par client | Non précisé |
Mon avis : Zoho Desk et Help Scout offrent les murs réels les moins chers, les Workspaces de Freshdesk le plus profond, et Zendesk est le plus complet mais réclame un tarif Enterprise pour le mur. Voici ce que vous cliqueriez réellement dans chacun.
Zendesk
Zendesk appelle cela multibrand, géré dans Admin Center > Account > Brand management. Suite Growth et Professional obtiennent 5 marques et 5 centres d'aide ; Suite Enterprise et Enterprise Plus en obtiennent 300. La page actuelle des tarifs Zendesk indique Suite Team avec un seul centre d'aide, donc Suite Professional à $115 est le forfait public le moins cher avec plus d'un.

Faire tourner des marques depuis une seule file fonctionne bien une fois en place. Un évaluateur de Zendesk sur G2 appréciait d'avoir « une équipe qui travaille depuis la même file » sur deux marques, avec la réserve honnête que tout administrateur multi-marques reconnaîtra :
« Garder les triggers et les automatisations cohérents sur les deux marques a demandé plus de soin que prévu ; j'ai construit une règle pour une marque et j'ai complètement oublié de la répliquer sur l'autre »
Le piège, c'est l'accès. Les espaces de département, qui limitent les agents aux marques dont ils sont membres, nécessitent Customer Service Suite Enterprise ou Support Enterprise. Les nouveaux membres de l'équipe rejoignent toutes les marques par défaut, et les administrateurs « doivent être membres de toutes les marques ». Dans Growth et Professional, la solution de contournement est un groupe par marque plus « tickets de leurs groupes » dans le profil de chaque agent. Mon article sur la configuration multi-marques de Zendesk détaille les clics.

Freshdesk
Freshdesk a deux couches. Multiple Products donne à chaque client une boîte, un portail et une base de connaissances, jusqu'à 5 dans Pro ($55) et illimités dans Enterprise ($89). Mais « les agents peuvent voir les tickets de tous les produits dans leur vue de tickets » à moins d'ajouter des règles de routage et de périmètre de tickets.
La couche la plus récente, ce sont les Workspaces : jusqu'à 30 activités de support indépendantes dans un compte, chacune avec ses propres agents, groupes, SLA, automatisations, e-mail, portails et base de connaissances. Elle est réservée à Enterprise et activée sur demande. Une licence d'agent couvre chaque Workspace auquel l'agent appartient, ce qui compte pour un BPO avec du personnel partagé.

Deux détails sur les Workspaces à connaître avant de vous engager : un Workspace ne peut pas être supprimé une fois créé, et Freshdesk lui-même dit qu'une facturation distincte ou une propriété juridique distincte peuvent justifier des comptes séparés. Mon décryptage de Freshdesk AI couvre les restrictions de forfait de Freddy.
Help Scout
L'unité de Help Scout est l'Inbox, et il offre le réglage par défaut le plus adapté aux agences que j'aie trouvé : un Utilisateur « n'a accès qu'aux Inboxes spécifiées », dans tous les forfaits. Les forfaits incluent 2, 5 ou 10 Inboxes, les suppléments coûtent $10 par mois, et les sites Docs (centres d'aide) sont 2, 3 ou 5 avec des suppléments à $20. Les réponses enregistrées et les SLA sont tous deux définis par Inbox.
Pour l'IA, vous créez un agent IA par client avec ses propres sources de connaissances, puis vous le liez au Beacon (widget de chat) de ce client. AI Answers coûte $0.75 par résolution sur la page des tarifs Help Scout.

La faille : Docs n'est pas cloisonné. Restreindre un Utilisateur à l'Inbox du client A ne l'empêche pas de modifier le centre d'aide du client B. Si vos clients tiennent à savoir qui touche à leurs articles, limitez la rédaction à un petit groupe. Plus de détails dans mon article sur les alternatives à Help Scout.
Front
Front répartit les clients en workspaces, chacun avec « ses propres workflows, analyses et ressources comme les étiquettes ou les modèles de messages ». Starter en a 1, Professional ($65) jusqu'à 5, Enterprise illimités. Chaque membre de l'équipe reçoit un rôle par workspace : Aucun accès, Admin ou Membre.

Les sources de connaissances de l'IA de Front se trouvent dans les paramètres du workspace, donc un workspace par client est aussi la façon de donner à chaque client ses propres connaissances d'IA. Les forfaits sont définis au niveau de l'organisation, vous ne pouvez donc pas mettre un client sur Starter et un autre sur Enterprise. Mon article sur Front AI couvre les tarifs d'Autopilot, qui démarrent à $0.05 par conversation.
Gorgias
Gorgias convient naturellement à une agence qui gère plusieurs boutiques en ligne, car il facture au ticket et non à l'agent : « Que vous ayez une boutique ou 30, vous pouvez toutes les gérer dans un seul helpdesk Gorgias. » Chaque boutique a ses propres canaux, son e-mail de support, ses macros et ses règles, et « vous obtenez un agent IA dédié pour chaque boutique Shopify que vous connectez », avec jusqu'à 100 entrées de consignes par boutique.
Deux réserves tirées de la documentation : l'agent IA par boutique est formulé pour les boutiques Shopify, et je n'ai trouvé aucun paramètre pour restreindre un agent aux tickets d'une seule boutique. Supprimer une boutique « supprimera toutes les intégrations et données associées », donc faites le départ d'un client de façon délibérée. Mon guide sur la gestion de plusieurs marques dans Gorgias va plus loin.
Zoho Desk, HubSpot, Deskpro et HaloPSA
- Zoho Desk utilise des départements : jusqu'à
10dans Professional ($23),50dans Enterprise ($40) et jusqu'à500avec une option. Une fois affecté, un agent « ne peut accéder et consulter que les tickets qui appartiennent à ce département » (documentation Zoho). Les centres d'aide à l'image de chaque département nécessitent Enterprise, et le passage à une connexion séparée par marque ne peut pas être annulé sans le support de Zoho. Mon article sur Zoho Desk AI couvre Zia. - HubSpot Service Hub gère plusieurs marques via HubSpot Brands, une option à
$1,000par mois et par marque vendue uniquement sur Marketing Hub Enterprise. Elle débloque un agent client par marque ; mon article sur les alternatives IA à HubSpot couvre des voies moins chères. Le propre tableau de HubSpot indique que Brands ne convient pas aux « modèles d'activité / de données très différents », ce qui décrit la plupart des agences. - Deskpro donne à chaque marque son propre centre d'aide, ses objectifs de SLA et ses rapports, et dit qu'un agent de la marque A « n'a aucune visibilité sur les tickets de la marque B sauf autorisation explicite ». Sa page tarifaire plafonne les centres d'aide à l'image des marques à
3,10et illimités selon le forfait. - HaloPSA est conçu pour les MSP : clients, sites et utilisateurs, SLA par site, listes de KB par client et restrictions de client par agent, à un prix unique de
£69par agent, clients et utilisateurs du portail gratuits.
Des marques dans un seul compte, ou des comptes séparés ?
C'est la question à laquelle je répondrais avant de toucher le moindre paramètre, car elle coûte cher à inverser. Deux questions décident.

- Le client a-t-il besoin de sa propre facturation ou de la propriété juridique des données ? Si oui, donnez-lui son propre compte. Le guide des Workspaces de Freshdesk va lui-même dans ce sens, et c'est la seule configuration où les fiches de contacts partagées cessent d'être un sujet.
- Faut-il que les agents soient dans l'incapacité de voir les tickets des autres clients ? Si oui, budgétez le forfait avec mur strict : Enterprise dans Zendesk ou Freshdesk, n'importe quel forfait dans Help Scout, affectation de département dans Zoho Desk. Un filtre d'affichage n'est pas un mur.
Si les deux réponses sont non, une marque dans un compte est moins chère, plus facile à doter en personnel entre clients et vous donne un seul endroit d'où produire les rapports. La plupart des entreprises multi-marques arrivent là. La plupart des agences avec des clients sans lien entre eux et des contrats stricts, non.
Cette deuxième question est celle qui piège les gens. Un administrateur Zendesk dont les partenaires voulaient garder les données de leurs clients apportés à l'écart des agents offshore a constaté que les outils intégrés n'allaient pas aussi loin :
« Je ne trouve aucune solution clé en main simple... les marques et les organisations ne font pas l'affaire. Une deuxième instance ZD, en revanche, pourrait »
Si le contrat d'un client dit « uniquement ces agents, uniquement ces données », partez de comptes séparés et remontez à rebours. Mon article sur l'IA pour le support offshore couvre plus en détail la répartition entre onshore et offshore.
Comment configurer un helpdesk multi-clients en 7 étapes
Une fois que vous avez choisi un compte ou plusieurs, voici l'ordre dans lequel je procéderais. Les étapes 1 à 3 évitent la réponse envoyée de la mauvaise marque ; les étapes 4 à 7 gardent honnête le niveau de service de chaque client.
- Créez une unité cliente par client et nommez-la comme le client. Une marque, un produit, une Inbox ou un workspace chacun. Utilisez le nom public du client, car il apparaît dans les e-mails et les en-têtes du centre d'aide.
- Donnez à chaque client sa propre adresse de support et sa signature. Ajoutez ensuite la condition de marque à chaque trigger qui envoie des e-mails ou à chaque règle de routage de tickets. Envoyez un ticket de test vers chaque adresse.
- Modifiez l'accès par défaut avant d'ajouter des agents. Dans Zendesk, les nouveaux membres de l'équipe rejoignent toutes les marques sauf si vous changez cela. Décidez agent par agent quels clients il traite, et limitez les administrateurs au plus petit nombre possible, car dans la plupart des outils les administrateurs voient tout.
- Définissez les objectifs de SLA par client à partir du contrat. Les clients paient pour des délais de réponse différents. Utilisez des politiques de SLA par client (Help Scout par Inbox, Zendesk avec une condition de marque, Freshdesk par Workspace). Mon guide des bonnes pratiques de SLA couvre les objectifs, et les conditions de SLA Zendesk couvrent le filtre par marque.
- Construisez une base de connaissances séparée par client. Un centre d'aide par client, dont s'occupe quelqu'un qui connaît ce client. Une base de connaissances partagée est à l'origine de la plupart des mauvaises réponses entre clients, humaines ou IA. Mon article sur la gestion de la base de connaissances couvre la responsabilité.
- Donnez à chaque client son propre agent IA et testez-le sur les tickets passés de ce client. Jamais un seul agent IA pour plusieurs clients. Plus de détails dans la section suivante.
- Produisez des rapports par client, chaque mois. Filtrez par unité cliente pour le volume, la première réponse, la résolution et le CSAT, afin que la facturation et les revues de contrat reposent sur les mêmes chiffres. Étiquetez chaque ticket avec le client à sa création pour que les rapports résistent au déplacement d'un ticket.
Si vous ajoutez du personnel offshore ou en horaires décalés entre clients, mes articles sur le support en continu autour du globe et la passation de relais entre équipes de support couvrent le volet de la passation.
Où l'IA s'intègre quand chaque client est différent
L'IA est l'endroit où un helpdesk multi-clients gagne le plus et risque le plus. Le cas du volume est simple : un opérateur e-commerce multi-marques lors d'un appel commercial avec eesel traite plus de 500 tickets par jour, dominés par les remboursements, les désabonnements et le suivi de commande, sur plusieurs marques. Ces tickets se ressemblent chez tous les clients. Les réponses, non, car chaque client a son propre délai de remboursement, son transporteur et son ton.
C'est pourquoi je tiendrais trois règles :
- Un agent IA par client, avec uniquement les connaissances de ce client. Pas un seul agent avec une consigne « vérifie de quelle marque il s'agit ».
- Des actions par client. Le client A peut autoriser des remboursements automatiques sous
$50; le client B peut n'en autoriser aucun. L'autorisation doit vivre dans l'agent du client, pas dans un prompt partagé. - Prouvez-le d'abord sur l'historique de chaque client. Un déploiement qui marche pour un client ne vous dit rien sur le suivant.
Voici comment cela se traduit dans eesel. Je serai précis, car j'ai construit une partie de tout cela.
Chaque client a son propre agent dans un workspace. Que vous soyez sur Zendesk, Help Scout ou Front, chaque forfait eesel inclut des agents et des sièges illimités, et les agents de helpdesk tournent sous un seul compte, « chacun avec ses propres connaissances et instructions ». Pour Zendesk, « chaque marque se connecte séparément, et chacune peut aller vers un agent différent avec ses propres triggers et actions », et eesel importe les tickets et les articles du centre d'aide de cette marque uniquement (documentation eesel pour Zendesk). Freshdesk, Gorgias et Zoho Desk acceptent plusieurs comptes connectés par workspace, chaque automatisation appartenant à un compte. Un piège que je signalerais pour l'avoir construit : connectez-vous d'abord à Zendesk en tant qu'agent de la marque que vous connectez, sinon Zendesk vous envoie vers votre marque par défaut et c'est celle-là qui est connectée.

Les connaissances restent là où vous les mettez. Une intégration peut être retirée d'un agent et conservée pour d'autres. Si l'historique de tickets d'un client ne doit pas alimenter un agent, désactivez sa source Tickets ; dire à l'agent dans ses instructions d'ignorer les tickets passés ne l'empêche pas d'en tirer des enseignements. Vos données ne servent qu'à vos propres agents et ne sont pas utilisées pour entraîner les modèles sous-jacents (documentation de sécurité eesel).
Les actions sont par agent. « Chaque action s'exécute d'elle-même, vous demande d'abord, ou reste désactivée. Vous choisissez par agent » (documentation des actions eesel). La règle de remboursement du client A ne touche donc jamais le client B.
Testez chaque client avant sa mise en service. Le skill Simulation rejoue de vrais tickets passés et compare les réponses de l'agent à ce que votre équipe a réellement envoyé. Pour un BPO, c'est une vérification de mise en service par client que vous pouvez montrer au client, et mon guide sur l'analyse des erreurs du support explique que faire des ratés. La documentation recommande aussi de déployer une file ou une marque à la fois ; tout ce qui est en dehors reste avec votre équipe et ne coûte rien.
Scriptez-le si vous gérez de nombreux clients. Si vous intégrez un nouveau client toutes les quelques semaines, la CLI eesel vous permet de le faire depuis un terminal. eesel agents create crée un nouvel agent pour le nouveau client, et chaque commande accepte --agent <name> pour que vous puissiez mettre à jour les instructions ou les connaissances d'un client sans toucher aux autres. Définissez EESEL_API_URL et EESEL_API_TOKEN et les mêmes commandes tournent depuis un script ou un job de CI. Chaque workspace est aussi un serveur MCP, de sorte qu'un agent de code comme Claude Code ou Cursor peut piloter la même configuration. Pour une agence qui intègre ses clients toujours de la même manière, cela transforme une checklist en script.
Les tarifs sont mutualisés entre clients. Les tarifs d'eesel sont un forfait mensuel fixe de crédits où un ticket ou un chat vaut un crédit : Free avec 100 crédits, puis Teammate à partir de $299 pour 500 crédits jusqu'à $1,899 pour 5,000, sans frais par siège ni de plateforme et avec un dépassement optionnel à $0.80 le crédit. Comme les crédits sont au niveau du workspace, six petits clients puisent dans un seul forfait au lieu de six abonnements.
Ce qu'eesel ne fait pas, pour que vous puissiez vous organiser : il n'y a pas aujourd'hui de programme de revendeurs ni de marque blanche (une agence gérant 22 workspaces pour plus de 10 entreprises clientes en a demandé un à eesel, et je préfère le dire plutôt que laisser entendre le contraire). Les rôles d'équipe (Owner, Editor, Viewer) s'appliquent à tout le workspace, pas à l'agent d'un seul client, donc si un client a besoin de sa propre connexion avec ses propres autorisations, donnez-lui son propre workspace. Et plus tôt cette année, un prestataire de support externalisé pour locations de vacances qui utilisait eesel comme copilote a dit à l'équipe eesel que ses clients « partagent fréquemment des captures d'écran » que les agents devaient retranscrire à la main, donc si les tickets de vos clients contiennent beaucoup d'images, testez cela sur un échantillon avant de passer en totale autonomie. Mon article sur l'IA en marque blanche couvre plus largement la question des revendeurs.
Essayer eesel pour votre helpdesk multi-clients
Si vous assurez le support de plusieurs clients ou marques, eesel donne à chacun son propre coéquipier IA de helpdesk dans un seul workspace. Connectez chaque marque Zendesk séparément (ou plusieurs comptes Freshdesk, Gorgias ou Zoho Desk), entraînez chaque agent uniquement sur les tickets et le centre d'aide de ce client, réglez séparément ses actions et son ton, et rejouez ses tickets passés avant qu'il ne réponde à qui que ce soit. L'essai est gratuit avec 100 crédits, et chaque forfait inclut des agents illimités, donc ajouter votre prochain client ne coûte rien tant que ses tickets n'arrivent pas.

Comment empêcher les agents de voir les tickets d'un autre client ?