Meta Muse pour ServiceNow : placer l'IA WhatsApp de Meta devant ServiceNow en 2026

En bref

"Meta Muse pour ServiceNow" se résume à un problème de siège, pas de tuyauterie. ServiceNow dispose déjà d'une application WhatsApp native qui parle directement à Meta, le canal existe donc. Mais Meta n'autorise qu'un seul agent IA par numéro WhatsApp, ce qui veut dire que Meta Business Agent et l'IA propre à ServiceNow (désormais sous la marque Otto) ne peuvent pas répondre tous les deux dessus. Muse lui-même est un agent grand public et Muse Spark un modèle sur lequel on construit, aucun des deux ne répond donc à vos clients tel quel.

La tuyauterie est plus conciliante que celle de la plupart des helpdesks que j'ai examinés. Meta a nommé ServiceNow comme partenaire de transfert dès 2025, et l'octroi OAuth par identifiants client de ServiceNow correspond à l'authentification des connecteurs de Meta dès qu'un admin active une propriété système. Le hic : le tout nouveau MCP Server de ServiceNow ne correspond pas du tout, car il ne gère que le flux de code d'autorisation, si bien que l'agent de Meta doit passer par l'API REST classique.

Côté coût, l'agent de Meta revient à environ 16 à 50 cents par conversation, tandis que ServiceNow facture son IA en assists à un tarif qu'il ne publie pas. Je construis les intégrations d'eesel et je préviens d'emblée : eesel n'a pas d'intégration ServiceNow native. Mon avis : la plupart des installations ServiceNow sont des services informatiques internes dont les employés n'écrivent jamais sur WhatsApp, cela ne concerne donc que les équipes de service client. Si c'est votre cas, eesel peut prendre l'unique siège IA du numéro et atteindre ServiceNow via son API REST.

Ce que "Meta Muse pour ServiceNow" signifie vraiment

La nomenclature 2026 de Meta demande un moment pour être démêlée, et je lis beaucoup de documentation d'API pour gagner ma vie. Trois produits Meta portent le nom Muse ou en sont proches, mais un seul parle à vos clients :

1. Muse, l'agent IA personnel lancé par Meta en septembre pour les courses du quotidien des particuliers. Il n'est pas conçu pour répondre aux clients d'une entreprise.
2. Muse Spark 1.3, le modèle, vendu via la Meta Model API. On peut construire un bot ServiceNow dessus, j'y reviens plus bas. La présentation de Muse Spark 1.3 détaille le modèle.
3. Meta Business Agent, que Meta a lancé en juin comme l'IA qui répond à vos clients sur WhatsApp, Messenger et Instagram. C'est le produit que pèse réellement une équipe ServiceNow.

La répartition en trois figure dans mon guide Meta Muse pour le support client. Cet article reste du côté ServiceNow : comment WhatsApp entre aujourd'hui dans ServiceNow, ce qui se passe quand l'agent de Meta prend le numéro, comment l'authentification s'articule et ce que coûte l'ensemble.

Vous êtes sur un autre helpdesk ? Les versions Salesforce et Jira Service Management sont les plus proches de celle-ci.

Il existe aussi des versions Zendesk et Freshdesk.

Avant la tuyauterie, un filtre honnête. La plupart des instances ServiceNow font de la gestion des services informatiques pour des employés, qui soumettent leurs demandes dans le portail, par e-mail ou dans Teams et Slack. Si cela décrit votre instance, vos demandeurs ne vous écrivent pas sur WhatsApp et cet article est surtout une curiosité. La question Meta ne devient réelle que pour les équipes Customer Service Management (CSM) dont les clients vivent déjà sur WhatsApp.

Comment WhatsApp atteint ServiceNow aujourd'hui

Contrairement à JSM, ServiceNow dispose d'un canal WhatsApp natif, et il va directement chez Meta. L'application du Store s'appelle Conversational Integration with WhatsApp, vendue par ServiceNow lui-même. Sa fiche du Store indique qu'elle "fournit un adaptateur WhatsApp natif pour une intégration directe avec la WhatsApp Cloud API, en remplacement de la solution actuelle reposant sur un tiers". La version 1.1.6 est sortie le 10 septembre 2026 pour les versions Brazil, Australia, Zurich et Yokohama.

L'essentiel de la configuration se fait côté Meta. D'après la documentation Conversational Interfaces de ServiceNow, vous créez une application développeur Meta, copiez son App Secret et l'ID du numéro de téléphone, puis générez un jeton d'accès d'utilisateur système dans Meta Business Manager. Ensuite, vous pointez le webhook de Meta vers le point de terminaison /api/sn_va_whatsapp/va_whatsapp_adapter de votre instance. La documentation CSM résume simplement le modèle de comptes : "Les clients doivent maintenir deux comptes distincts : un compte Meta et une instance ServiceNow."

Voici comment les options se comparent, toutes issues de fiches du ServiceNow Store consultées le 29 septembre 2026 :

ServiceNow lui-même considère désormais Twilio comme la route la plus faible. Sa documentation CSM dit que l'intégration Twilio "offre des fonctionnalités plus limitées que la Cloud API", sans sélecteurs de liste ni indicateurs de saisie, et qu'elle vous laisse gérer trois comptes (Twilio, Meta et ServiceNow) au lieu de deux. Les admins ont repéré l'empilement de licences il y a des années :

"Il faut aussi des licences pour integration hub, twilio, whatsapp, etc."

u/bigredsage, Reddit

Quand un chat arrive, deux choses peuvent y répondre. Otto (le renommage par ServiceNow de Virtual Agent et Now Assist) peut répondre en tant que bot, et si une personne est nécessaire, le chat tombe dans l'Agent WhatsApp Queue et les agents l'acceptent depuis leur boîte de réception Agent Workspace. Un détail de la documentation Brazil comptera plus tard : WhatsApp prend en charge Otto mais est marqué "Non" pour les réponses synthétisées, alors que Teams et Slack sont "Oui".

Le CSM propose aussi un second mode, et c'est celui qui compte ici. La documentation CSM décrit une intégration directe qui "achemine les conversations de messagerie directement vers les agents humains sans déflexion par virtual agent", et ajoute : "Cette approche est disponible pour WhatsApp." Retenez cela.

Ce qui se passe quand Meta Business Agent rejoint ce numéro

La documentation de Meta s'est beaucoup étoffée en septembre. Voici ce qui change quand votre numéro WhatsApp alimente déjà ServiceNow et que vous activez ensuite Business Agent.

Il répond en premier, et l'application ServiceNow passe en veille

Le Conversation Routing de Meta décide quelle application connectée répond à chaque message, et l'adaptateur WhatsApp de ServiceNow est l'une de ces applications. Quand vous activez Business Agent, "L'agent devient le seul primaire pour les points d'entrée de messagerie" et "Les anciennes destinations primaires passent en veille afin de conserver le contexte", d'après le guide de configuration du routage de Meta.

En clair : les nouveaux messages WhatsApp arrivent d'abord chez l'agent de Meta et non dans votre Agent WhatsApp Queue. Vous pouvez répartir par point d'entrée, par exemple en gardant ServiceNow comme primaire pour les messages directs pendant que l'IA prend les publicités click-to-WhatsApp. Cette configuration n'existe que dans Meta Business Suite : "Il n'existe pas d'API publique pour configurer le Conversation Routing."

Une IA par numéro, donc Otto doit s'effacer

Voilà la vraie décision dans une configuration ServiceNow. La présentation de la plateforme de Meta exige un numéro "n'exécutant pas déjà un autre agent IA", car "une intégration d'agent autorisé active bloque Meta Business Agent".

Meta ne précise cependant pas exactement ce qui compte, et la documentation de ServiceNow ne mentionne jamais Business Agent. La lecture sur laquelle je planifierais est qu'Otto qui répond sur le numéro compte comme un autre agent IA. Vous feriez donc tourner l'application WhatsApp de ServiceNow dans le mode direct de la section ci-dessus, avec les chats allant directement aux agents humains et sans étape de bot, ce qui laisse l'agent de Meta comme seule IA du numéro.

C'est un vrai compromis. Otto connaît votre base de connaissances, vos articles de catalogue et vos sujets, alors que l'agent de Meta ne connaît que ce que vous lui chargez. L'avis de la communauté sur Virtual Agent est d'ailleurs mitigé :

"Je pense que les gens s'attendent à un mini ChatGPT/copilot, mais d'après mon expérience il en est très loin. Il s'appuie fortement sur les articles de connaissance, les articles de catalogue et les sujets de virtual agent."

u/ultraviolencebby, Reddit

Il y a un contrepoint honnête d'une équipe de connaissance qui a réussi : "nous atteignons environ 70-80 % de déflexion grâce à la connaissance", selon u/Suspicious-Movie4993. Si vos chiffres Otto ressemblent à cela, céder le siège WhatsApp à Meta est un pas en arrière.

ServiceNow est un partenaire cité, mais personne n'a publié la documentation du transfert

Quand Business Agent transfère, le chat reste dans le même fil WhatsApp et seule la propriété passe à une autre application du numéro. Le guide du support client de Meta liste "Une destination dotée de personnel pour les conversations transférées" comme prérequis, et un transfert simple va à l'application que vous définissez comme "escalation partner", d'après la documentation du thread control.

ServiceNow a de l'avance ici. Quand Meta a présenté Business AI en octobre 2025 (l'ancien nom de Business Agent), elle a écrit qu'elle "s'associait activement avec des plateformes de premier plan, dont Salesforce, Microsoft Dynamics 365 Contact Center, ServiceNow, Zendesk, Gorgias et Klaviyo Service" pour les transferts. C'est plus qu'Atlassian ou Freshworks n'en ont obtenu.

Mais la piste se refroidit ensuite. L'annonce de lancement de juin cite "Shopify, Zendesk et Shopee", pas ServiceNow, et la documentation de ServiceNow ne mentionne ni Business Agent, ni transfert, ni conversation routing. Sa configuration associe un ID de numéro de téléphone WhatsApp à une identité de canal et ne dit rien sur le partage du numéro. D'après la documentation de routage de Meta, un transfert devrait arriver dans l'adaptateur ServiceNow comme une conversation entrante normale, mais je le testerais quand même sur un numéro de rechange avant qu'aucun client ne le voie.

Curieusement, le lien de ServiceNow chez Meta est une personne. La nouvelle Enterprise Platform de Meta, annoncée le 28 septembre, est dirigée par CJ Desai, qui "a passé près de huit ans chez ServiceNow, notamment comme President et COO".

Quelques autres détails du transfert méritent d'être connus :

• Le contexte voyage dans une note de 2 000 caractères. L'événement de transfert porte un champ de texte libre metadata que Meta suggère d'utiliser "pour transporter la référence du ticket ou de la commande". Rien dans la documentation de ServiceNow ne dit que l'adaptateur le lit.
• Vous ne contrôlez pas les déclencheurs. Le transfert se déclenche en cas de faible confiance, de problèmes d'intégrité ou quand un client demande une personne, et "Vous ne configurez pas les déclencheurs", d'après la page des capacités de Meta. Mon guide du transfert d'agent IA explique à quoi ressemble un bon transfert.
• La fenêtre de 24 heures s'applique toujours. La documentation CSM de ServiceNow dit que les messages initiés par l'agent doivent l'être "dans les 24 heures suivant le dernier message du client". Un transfert à 2 h du matin qui attend jusqu'à 10 h le lendemain, c'est bon, mais un transfert pris en charge deux jours plus tard est un fil mort.
• Les contacts clients ne reçoivent pas de notifications. La documentation dit : "Les consommateurs et les contacts clients sont considérés comme des invités et ne peuvent pas recevoir de notifications dans les canaux de messagerie." Un client CSM ne recevra donc pas de ping WhatsApp quand son cas est mis à jour. Seuls les employés dotés de comptes utilisateur en recevront.

Connecter l'agent de Meta à l'API de ServiceNow : l'auth convient, le serveur MCP non

Business Agent exécute des actions via des connecteurs, c'est-à-dire des API HTTP ou des serveurs MCP distants que vous définissez vous-même. La référence des connecteurs de Meta dit : "Actuellement, seuls OAUTH2_CLIENT_CREDENTIALS, API_KEY et NONE sont pris en charge." C'est exactement sur cette ligne que les versions Freshdesk et Gorgias de cette configuration ont buté, car toutes deux veulent de la Basic auth.

ServiceNow offre deux voies propres, arrivées toutes deux avec la version Washington DC :

• OAuth par identifiants client. La KB1645212 de ServiceNow dit : "À partir de la version Washington DC, ServiceNow prend en charge le type d'octroi Client Credentials pour les requêtes OAuth entrantes." Il "est désactivé par défaut", donc un admin crée la propriété système glide.oauth.inbound.client.credential.grant_type.enabled et la met à true. Chaque application qui l'utilise "doit être associée à un utilisateur d'intégration" dans le champ OAuth Application User, et le jeton provient de /oauth_token.do. Cela correspond à ce qu'attend le type OAUTH2_CLIENT_CREDENTIALS de Meta.
• Clés d'API REST. Le Developer Advocate de ServiceNow Chuck Tomasi a annoncé les clés d'API entrantes dans la même version. La clé se place dans un en-tête x-sn-apikey et s'exécute sous l'utilisateur que vous choisissez. La configuration API_KEY de Meta permet de nommer le champ d'en-tête, celle-ci correspond donc aussi.

Deux routes ne conviennent pas. La Basic auth, le choix par défaut de longue date, est ce que Meta marque comme non pris en charge, et le MCP Server de ServiceNow ne peut pas être un connecteur Meta aujourd'hui. La FAQ de la MCP Server Console de ServiceNow dit qu'il "utilise OAuth 2.0 avec Authorization Code Grant pour authentifier toutes les connexions" et que les identifiants client "ne sont pas pris en charge actuellement pour les connexions à la MCP Server Console. C'est sur la feuille de route du produit." Le connecteur de Meta ne peut pas mener à bien un flux de code d'autorisation, la nouvelle porte IA vers ServiceNow reste donc fermée pour l'instant. Mon article sur l'intégration MCP de ServiceNow couvre ce que ce serveur fait pour des clients comme Claude.

Les outils que vous définiriez, et trois pièges

Une fois l'auth réglée, le connecteur se résume à une poignée d'appels REST. L'exemple de Meta est un outil create_support_ticket dont l'agent remplit le résumé à partir du chat, et ses macros peuvent lier le numéro de téléphone WhatsApp et l'ID de conversation à des champs pour que l'agent ne les devine pas. Pour ServiceNow, cela donne :

1. Créer l'enregistrement. POST /api/now/table/incident sur la Table API pour un service informatique, ou POST /api/sn_customerservice/case sur la CSM Case API pour le service client.
2. Consulter le statut. Un GET sur le cas, pour que l'agent puisse répondre à "y a-t-il du nouveau sur ma réparation ?" sans transfert.
3. Ajouter une mise à jour visible par le client. Écrire dans comments, pas dans work_notes. D'après la référence de la Case API, les rôles clients externes "ne peuvent définir que les champs comments et state" par défaut, et les work notes sont le champ interne.

Les pièges viennent tous des pages de ServiceNow elles-mêmes :

• La Case API ne vous dit pas quand vous vous trompez. Elle "n'effectue pas de validation des paramètres", donc un nom de champ mal orthographié est ignoré en silence. Utilisez le point de terminaison d'essai d'outil de Meta et vérifiez l'enregistrement, pas seulement le 200.
• Il n'existe pas de valeur de canal pour WhatsApp. Le contact_type de la Case API accepte chat, email, phone, social et web. Choisissez-en un et étiquetez la source ailleurs, sinon vos rapports mélangeront WhatsApp au chat web.
• Les limites de débit arrivent sous forme de 429. La KB3046852 liste des règles de limite de débit définies par l'admin, la surcharge de nœud et un plafond de 300 secondes par transaction. Un connecteur qui réessaie à l'aveugle pendant un pic du lundi matin ne fait qu'aggraver les choses.

Meta signale le risque d'échec silencieux dans son propre guide : "Un ticket en échec est invisible : l'agent a déjà dit qu'un collègue allait prendre contact, le client attend, et personne ne s'en aperçoit avant qu'il réécrive, plus agacé." Avec une Case API qui ignore les champs erronés, cet avertissement vaut double.

Ce que ça coûte : Meta Business Agent face à l'IA propre de ServiceNow

La comparaison devient délicate ici, car ServiceNow ne publie de montants en dollars pour rien de tout cela.

Un chiffre avantage ServiceNow. Un article de la communauté ServiceNow sur le changement de licences d'avril 2026 dit que Virtual Agent "a désormais des conversations illimitées" dans les nouveaux niveaux ITSM. Le bot classique par sujets est donc couvert, et seuls les sujets Now Assist adossés à un LLM consomment des assists.

L'agent de Meta est la seule ligne ici avec un prix que l'on peut mettre aujourd'hui dans un tableur, même si les premiers utilisateurs de Business Agent ont remarqué à quelle vitesse ce prix s'additionne :

"Ma crainte est que le coût par message soit incroyablement élevé, environ 5 cents par message."

u/Aromatic-Surround167, Reddit

Côté ServiceNow, la douleur vient du package plutôt que de l'unité. Un admin CSM a décrit son renouvellement : "Nous avions un AI starter pack avec 25 sièges CSM Pro Plus. Nous sommes passés à 50. Nous avons 900 sièges au total sur CSM Pro. Leur nouveau modèle ? Tous les sièges doivent être du même type", d'après u/12_barrelmonkeys. Mon décryptage des tarifs de l'IA ServiceNow et le guide des types de licences approfondissent ce point.

Le 1er octobre touche les réponses de vos agents, pas l'IA

La plupart des équipes ServiceNow sur WhatsApp ressentiront un changement différent du prix de l'IA. À partir du 1er octobre 2026, Meta facture les messages de service au message après 1 000 gratuits par numéro de téléphone et par mois. La page de tarifs de Meta dit que chaque message est facturé "soit comme message Meta Business Agent soit comme message de service, jamais les deux".

L'application native de ServiceNow fonctionne sur votre propre compte Meta, ces frais de messages de service arrivent donc directement sur votre facture Meta, sans BSP intermédiaire pour les absorber ou les majorer. Chaque réponse qu'un agent envoie depuis Agent Workspace après le transfert en compte pour une. Choisir l'agent de Meta n'y échappe pas, cela change seulement qui rédige les premières réponses. Mon explicatif sur les tarifs de l'API WhatsApp contient tout l'historique des tarifs, et l'article sur les changements de politique de Meta couvre ce que Meta a fait aux bots tiers.

Construire son propre bot ServiceNow sur Muse Spark

La troisième route saute Business Agent et construit directement sur le modèle. C'est la plus proche de mon métier, voici donc ce qu'elle implique en pratique.

Côté modèle, Muse Spark 1.3 coûte 1,25 $ en entrée et 4,25 $ en sortie par million de tokens au niveau standard (documentation de la Meta Model API). Le niveau contributeur, moins cher, est exclu pour le support, car les conditions de Meta disent : "Vous ne devez pas soumettre d'informations sensibles, confidentielles ou personnelles aux Discounted Services." Un cas ServiceNow contient des noms et des e-mails, plus des numéros de compte. Mon avis sur Muse Spark 1.3 couvre les points forts du modèle.

Côté ServiceNow, tout le reste est à votre charge :

1. Le côté WhatsApp. L'adaptateur de ServiceNow possède le webhook du numéro, donc un bot maison soit le remplace, soit se place derrière une Custom Chat Integration. Ni l'un ni l'autre n'est un travail de week-end.
2. L'auth. Identifiants client avec un utilisateur d'intégration dédié et des scopes d'authentification d'API restreints, renouvelés toutes les 30 minutes. Honnêtement la partie facile.
3. La connaissance. Articles de connaissance, articles de catalogue et cas résolus, gardés synchronisés avec la Table API.
4. La boucle. Lire le cas, rédiger un commentaire ou une work note, définir la catégorie et le groupe d'affectation. Pour une première version, je la livrerais en n'écrivant que des work notes, ce qui signifie que rien n'atteint un client sans une personne.
5. Escalade et tests. Votre propre seuil de confiance, plus un rejeu de vrais cas avant toute mise en production. Mon guide construire ou acheter détaille la liste complète.

Un fil de 2026 montre le genre de bug dans lequel vous vous engageriez, même au sein de la pile de ServiceNow. L'agent personnalisé d'un admin fonctionnait bien dans AI Agent Studio et ne plantait que sur le canal WhatsApp :

"L'AI Agent fonctionne correctement quand il est testé directement dans AI Agent Studio. Un plan d'exécution est créé et le Work Order Agent peut s'exécuter. Cependant, quand j'invoque le même AI Agent depuis WhatsApp, il ne s'exécute pas correctement."

u/Affectionate_Bet971, Reddit

La cause probable, d'après les réponses du fil, est que le canal WhatsApp s'exécute sous un contexte utilisateur différent de votre session admin, sans les rôles dont l'agent a besoin. La même question de contexte utilisateur s'applique à tout bot que vous construisez. D'autres modèles reçoivent le même traitement dans ChatGPT pour ServiceNow, Claude pour ServiceNow et Grok pour ServiceNow.

Là où l'agent de Meta s'arrête pour une équipe ServiceNow

Rien de tout cela n'est caché et tout figure dans la documentation de Meta, mais cela pèse plus lourd sur une équipe ServiceNow :

• Il ne répond que dans les applications de Meta. Votre instance reçoit aussi le portail, l'e-mail, Teams et Slack. Business Agent n'en couvre aucun, vous finiriez donc avec deux IA et deux jeux de règles. Mon article sur le chatbot ServiceNow couvre ces canaux.
• Votre historique de cas n'est pas une source de connaissance. Le guide de support de Meta vous dit d'"exporter les principaux motifs de votre helpdesk pour le dernier trimestre" et de rédiger les entrées de FAQ à la main. Votre base de connaissances et des années de cas résolus restent hors de portée.
• Il ne connaît pas votre structure. La valeur de ServiceNow, c'est la structure : catégories, groupes d'affectation, SLA, approbations, la CMDB. L'agent de Meta voit un chat, pas un cas, à moins que votre connecteur ne le lui apprenne.
• Les secteurs réglementés sont exclus. Les entreprises de la finance, de la santé, du secteur public, de l'alcool ou des jeux d'argent ne peuvent pas utiliser la Platform.
• La précision demande toujours un ancrage. Le centre d'aide de Meta avertit : "Certains messages IA peuvent être inexacts ou inappropriés."

Un commentateur de r/WhatsappBusinessAPI a bien résumé la limite :

"Si vous regardez de près l'agent IA actuel, il ne peut faire des choses qu'à l'intérieur de Meta, mais rien à l'extérieur."

u/Ok_West333, Reddit

C'est le recadrage que je laisserais à une équipe ServiceNow : l'agent de Meta est une porte d'entrée pour WhatsApp, tandis que ServiceNow est l'endroit où vit le travail, et l'IA qui mérite sa place est celle qui peut y lire et y écrire.

Quelle configuration convient à votre équipe ServiceNow

Voici comment je choisirais, selon qui écrit et la façon dont travaille votre équipe.

La plupart des équipes ServiceNow sont dans la première ligne, et la question WhatsApp ne se pose jamais pour elles. Pour les équipes CSM, je consacrerais le temps aux deuxième et quatrième lignes. Si vous comparez des outils IA pour l'instance elle-même, mon comparatif de la meilleure IA pour ServiceNow et le guide ajouter de l'IA à ServiceNow sont de bonnes lectures suivantes.

La liste des alternatives à ServiceNow Virtual Agent aide si c'est Otto que vous remettez en question, et la meilleure IA pour le support WhatsApp couvre WhatsApp sur l'ensemble des helpdesks.

Essayer eesel pour WhatsApp sur ServiceNow

D'abord la réponse directe : eesel n'a pas d'intégration ServiceNow native, et je préfère que vous l'appreniez par moi plutôt que sur un écran de configuration. Ce qu'il a, ce sont les deux pièces dont cette configuration a réellement besoin.

eesel est un coéquipier IA de helpdesk qui répond lui-même sur WhatsApp, il peut donc prendre l'unique siège IA du numéro à la place de l'agent de Meta ou d'Otto. Il atteint ServiceNow via Network Access : vous autorisez le domaine de votre instance, ajoutez l'en-tête x-sn-apikey pour une clé d'API ServiceNow, et l'agent peut créer des cas, lire leur statut et publier des commentaires via l'API REST. L'identifiant est stocké comme en-tête et jamais montré à l'IA, et les Action Permissions permettent de régler chaque écriture sur "ask" pour qu'une personne l'approuve d'abord.

Il apprend de votre centre d'aide et des conversations passées, et suit des instructions en langage courant sur les demandes qu'il peut traiter. La tarification est un forfait mensuel fixe de crédits, où un chat compte pour un crédit quel que soit le nombre de réponses, il n'y a donc pas de calcul d'assists.

Si vous préférez scripter, la CLI eesel vous permet, ou à un agent de code comme Claude Code ou Cursor, de vérifier eesel status, de lire eesel activity et de traiter eesel approvals depuis un terminal, sur le même coéquipier que vous configureriez dans le tableau de bord. Un webhook depuis un flow ServiceNow peut le réveiller quand un cas change.

Essayez eesel gratuitement avec 100 crédits et sans carte, et voyez comment il gère vos conversations WhatsApp avant que le changement de tarifs du 1er octobre n'arrive.