Grok Bot et Brevo : informer les clients après une demande de fonctionnalité

Un ticket de support peut indiquer « terminé » alors que le client ne peut pas utiliser la fonctionnalité. Dans une demande hypothétique d’export CSV, le code lié au ticket T-104 est fusionné, mais le déploiement reste désactivé. « Votre fonctionnalité est disponible » serait une promesse fausse.

Reliez une demande à une version confirmée et à une personne joignable. L’exemple GTM Loop Closer de xAI décrit la recherche d’engagements, la présentation de preuves et la préparation d’une réponse. Ici, l’engagement exige un contrôle plus strict : une personne responsable du produit doit confirmer ce qui a été livré et qui peut l’utiliser.

Commencez quand la preuve de disponibilité existe

Prenez le dossier de version du produit comme déclencheur, pas le changement de statut d’un ticket. Il lui faut un feature_id stable, un release_id, le comportement livré, la date de version, l’état du déploiement et une personne responsable nommée. Celle-ci doit vérifier que la fonctionnalité est disponible pour le compte ou l’offre du client demandeur. Du code fusionné, une démonstration en préproduction ou une note de version prévue ne suffisent pas.

Associez la demande à la version par ID de fonctionnalité et la demande au client par l’ID de contact conservé dans le système de support. Ne stockez que la correspondance et le statut. Grok Bot n’a pas besoin de toute la boîte de réception ni du catalogue. Si un ID manque, créez un point à vérifier au lieu de deviner sur la base d’un nom similaire.

Entrée	Champs minimaux	À vérifier
Demande	ID de ticket, ID de fonctionnalité, date de demande, ID de contact du demandeur	La personne a effectivement demandé cette fonctionnalité
Version	ID de version, ID de fonctionnalité, comportement livré, disponibilité, accord de la personne responsable	Ce compte peut l’utiliser maintenant
Contact	ID de contact, canal de support approuvé, état d’exclusion	Cette personne peut recevoir ce type de réponse

La demande ne vaut pas consentement marketing. Utilisez votre canal de support approuvé pour répondre factuellement à cette demande. Si le brouillon promeut d’autres fonctionnalités, propose une vente supplémentaire ou vise des personnes qui n’ont rien demandé, traitez-le comme une campagne marketing distincte avec ses propres règles d’admissibilité. Respectez désabonnements et exclusions pour le canal retenu. Notre guide du double opt-in explique pourquoi un ticket ne remplace pas une fiche d’abonnement.

Préparez une réponse avec un prompt limité

Un résultat hypothétique associe T-104 à F-7 et R-22, mais constate que le déploiement est désactivé. Attendez; n’envoyez rien.

Copiez ce prompt après avoir fourni les dossiers approuvés :

Examine seulement les dossiers de demande, de version et de contact que je fournis. Fais la correspondance avec les ID stables de fonctionnalité et de contact, pas avec les mots seuls. Pour chaque candidat, montre l’ID du ticket, de la fonctionnalité et de la version, l’accord de la personne responsable, la disponibilité pour le compte, l’objet de communication approuvé et l’état d’exclusion. Marque les preuves manquantes ou contradictoires comme bloquantes. Rédige une courte réponse factuelle seulement pour une version confirmée et disponible. Indique ce qui a changé, où le client peut l’utiliser et où obtenir de l’aide, en utilisant seulement les faits fournis. N’infère pas de consentement marketing, n’ajoute pas de promesses promotionnelles, ne crée ni ne modifie de contacts, n’envoie aucun message et ne clôture aucun ticket. Rends ici la table de preuves et le brouillon pour examen.

Vérification : une personne responsable du produit compare le brouillon au dossier de version et teste la disponibilité dans le compte demandeur. La personne responsable du support vérifie l’identité du destinataire et l’objet de la communication. Si un contrôle échoue, le brouillon reste dans le chat. Le guide de démarrage Grok Bot et Brevo présente la connexion MCP documentée et explique pourquoi les opérations disponibles doivent encore être examinées; ce parcours n’a pas été exécuté dans un compte Grok Bot.

Envoyez une fois, puis gardez l’accusé

Avant de mettre un envoi approuvé en file, calculez une clé de déduplication à partir de feature_id + contact_id + release_id et réservez-la de façon atomique dans un registre durable. Une clé déjà réservée, en attente, de statut inconnu ou réussie bloque une autre mise en file. Deux processus ne doivent pas réussir une lecture puis écriture séparées. Après expiration du délai, rapprochez les accusés de l’événement et du fournisseur avant d’envisager un nouvel essai; l’absence de réponse ne prouve pas l’absence d’envoi.

Après examen, configurez le canal approuvé dans Brevo. Si votre compte propose sous Automations > Workflows > Create an automation un déclencheur d’événement personnalisé et une action e-mail, associez votre événement proposé feature_followup_approved à un modèle approuvé pour le support. L’événement nécessite un identifiant de contact vérifié; IDs de fonctionnalité et de version sont des propriétés proposées, pas des valeurs Brevo par défaut. Testez avec un contact interne avant activation. N’émettez qu’un seul événement après approbation et réservation réussie de la clé. Sinon, répondez manuellement via le support. Brevo documente les événements personnalisés et la configuration des workflows; examinez les actions disponibles dans votre compte. Le brouillon de Grok Bot n’autorise pas l’exécution. Le guide de l’API Brevo décrit l’autre voie API. Notez séparément l’acceptation de l’événement et l’accusé d’envoi du message. Un événement accepté ne prouve pas qu’un e-mail a été envoyé. Conservez destinataire exact, texte approuvé, preuve de version, objet, canal, ID d’envoi du fournisseur et horodatage. Ne marquez le ticket comme suivi qu’après un accusé d’envoi confirmé ou une réponse manuelle du support documentée. La documentation MCP de Brevo établit une possibilité d’intégration, pas la disponibilité de chaque écriture ou permission dans votre client.

Fixez pour chaque version une date limite d’observation, par exemple sept jours après la disponibilité confirmée par la personne responsable. À cette date, mesurez l’achèvement comme demandes admissibles avec un suivi confirmé divisées par les demandes admissibles pour cette version. Comptez séparément les demandes bloquées et injoignables. État de remise et réponses aident à trouver les problèmes; les ouvertures ne prouvent pas que le client a vu ou utilisé la fonctionnalité. Une version sans destinataire vérifié reste un travail en cours. La même rigueur s’applique à une expérience de campagne, dont le résultat se mesure autrement.