Comment Notis utilise Mailgun pour des réponses e-mail IA dans le bon fil

Un assistant IA peut faire du travail utile et donner quand même l’impression d’être cassé si sa réponse atterrit dans un nouveau fil d’e-mails. L’utilisateur doit retrouver sa demande d’origine, se rappeler ce qu’il a demandé et reconstituer la conversation. C’est une façon étonnamment coûteuse de livrer un paragraphe et un fichier.

Chez Notis, l’e-mail est l’une des interfaces pour parler à l’assistant. Notre implémentation du canal e-mail utilise Mailgun pour envoyer les réponses, conserver les références de réponse et gérer les médias. Le plus intéressant, c’est le passage de relais entre un travail terminé et une conversation que quelqu’un peut poursuivre.

Cet article décrit une implémentation, ce n’est pas un benchmark de délivrabilité. Nous avons vérifié le chemin d’envoi ; nous n’y accolons pas de chiffres inventés de volume, d’arrivée en boîte de réception ou de productivité.

Une réponse d’assistant n’a pas le même rôle qu’une newsletter

Je suis Flo, le fondateur de Notis. Nous construisons un assistant à qui on peut demander du travail par messages, à la voix et depuis notre app Desktop ou web. Le produit est allé bien au-delà de la prise de notes. La réponse peut donc contenir une recherche, un document, une demande de précision ou le résultat d’une action menée via un outil connecté.

Dans ce contexte, une réponse par e-mail fait partie de l’interface du produit. Son rôle est de rendre le travail à la personne qui l’a demandé, avec assez de contexte pour qu’elle puisse continuer.

Une notification de cycle de vie a un autre rôle. Elle peut expliquer un événement lié au compte ou l’état d’une automatisation. Nous utilisons Customer.io pour ces communications opérationnelles. Mailgun gère le chemin des e-mails conversationnels décrit ici. Garder cette distinction claire rend l’architecture plus facile à comprendre et les messages qui en sortent plus faciles à évaluer.

Un workflow concret : demande, résultat, suite

Prenons une demande à titre d’illustration : « Compare ces deux pages produit publiques et dis-moi ce qui a changé. » C’est un exemple de workflow, pas la transcription d’un vrai client.

L’assistant traite la demande avec les informations et les outils dont il dispose. La couche de livraison des e-mails a ensuite une responsabilité plus étroite : envoyer la réponse à la bonne personne et préserver son lien avec la conversation d’origine.

Une réponse utile peut contenir un court résumé, un lien vers le document terminé et une mention claire de tout ce que l’assistant n’a pas pu vérifier. Si l’utilisateur répond « Concentre-toi sur les différences de prix », il doit avoir l’impression de poursuivre la même tâche.

Notre implémentation d’envoi reporte les références de réponse de l’e-mail dans le message sortant. Ça aide les clients de messagerie à rattacher la réponse à la conversation. Ça ne nous permet pas de contrôler le comportement de regroupement en fils de chaque client de messagerie, mais ça donne au client la relation dont il a besoin, au lieu de compter uniquement sur un objet qui a l’air familier.

Ce dont Mailgun est responsable dans ce flux

Mailgun est le service de livraison derrière ce chemin du canal e-mail. Notre code assemble le destinataire, l’expéditeur, l’objet, le contenu du message et les en-têtes pertinents, puis soumet le message via le point de terminaison de l’API européenne de Mailgun.

La documentation de l’API d’envoi de Mailgun décrit les champs texte, HTML, pièce jointe et en-têtes personnalisés qui permettent ce type de composition. Ce sont des briques utiles pour un assistant, parce que le résultat n’est pas toujours du texte brut.

Nous avons aussi un utilitaire Mailgun partagé pour les flux d’e-mails liés aux canaux, y compris les messages de connexion et de vérification. Centraliser cette opération d’envoi donne à ces flux un endroit commun pour assembler un message et gérer une requête qui échoue.

La frontière importante, c’est la responsabilité. Mailgun transporte l’e-mail. Notis décide de ce que signifie la réponse, à qui elle appartient et quel travail elle représente. Un envoi d’e-mail réussi ne peut pas prouver que l’analyse de l’assistant était juste.

Pourquoi le point de terminaison européen est un détail de configuration précis

Notre implémentation soumet les e-mails via le point de terminaison européen de Mailgun. Mailgun documente ses points de terminaison régionaux dans sa présentation de l’API.

C’est une affirmation précise sur ce chemin de livraison. Ce n’est pas une promesse que chaque service de Notis traite chaque information dans une seule région. Je préfère nommer la configuration réelle plutôt que de l’étirer en slogan de sécurité.

Si tu es fondateur et que tu implémentes quelque chose de similaire, note la région d’envoi à côté de la configuration du domaine et du responsable opérationnel. Quand un message échoue, ces détails sont plus utiles qu’une case générique « e-mail » dans un schéma d’architecture.

La livraison a besoin de sa propre définition de « terminé »

Il y a plusieurs événements que l’on appelle à la légère « envoyé ». L’assistant peut finir de générer une réponse. L’application peut soumettre cette réponse à une API d’e-mail. Le système destinataire peut accepter le message. L’utilisateur peut ensuite le trouver et ouvrir le résultat lié.

Ces événements répondent à des questions différentes.

Notre utilitaire partagé considère une réponse positive de l’API Mailgun comme un succès pour son opération de soumission. Ça ne doit pas être présenté comme la preuve que le destinataire a lu la réponse. De même, une tâche d’agent terminée ne prouve pas automatiquement que son résultat est parvenu à l’utilisateur.

Pour évaluer une interface e-mail, je testerais ces frontières séparément : le bon destinataire, la relation de réponse préservée, un message lisible, un résultat accessible et une réaction utile en cas d’échec de livraison. Ce sont des critères d’évaluation, pas l’affirmation que nous avons publié une mesure pour chaque étape.

Séparer les notifications de compte de la conversation

Un utilisateur qui demande un document à un assistant ne fait pas la même chose que quelqu’un qui reçoit une notification de compte. La réponse conversationnelle doit permettre d’examiner facilement le résultat et d’y répondre. La notification de compte doit rendre évidents l’état du compte et toute action nécessaire.

Notre architecture reflète cette distinction : Mailgun pour ce chemin de conversation par e-mail, Customer.io pour les messages opérationnels de cycle de vie. La prospection menée par le fondateur est encore un autre workflow. Cet article parle des réponses de l’assistant, pas d’un système d’envoi de campagnes.

Cette séparation aide aussi au débogage. « L’e-mail a échoué », c’est vague. « L’assistant a terminé la tâche, mais sa réponse dans la conversation n’a pas été acceptée pour livraison » donne à quelqu’un un problème sur lequel enquêter.

Construis le chemin de retour avant d’ajouter des fonctions e-mail

Ma recommandation, si tu construis un assistant accessible par e-mail, est simple : déroule une conversation complète avant d’ajouter un nouveau modèle. Commence par une demande, renvoie quelque chose d’utile, puis réponds-y en te mettant à la place de l’utilisateur.

Arrives-tu encore à savoir à quelle demande correspond la réponse ? Peux-tu ouvrir le résultat ? Une tâche inachevée a-t-elle l’air inachevée ? La suite de la conversation a-t-elle un endroit clair où aller ?

Mailgun nous donne les briques de livraison pour ce chemin de retour. Le travail produit, c’est de rendre l’ensemble de l’échange compréhensible. Un assistant ne devrait pas obliger quelqu’un à jouer les détectives pour retrouver ce qu’il a terminé.