Un prompt peut-il remplacer Mara ?

Construis un outil d’email de lifecycle auto-hébergé pour un seul produit : un endpoint qui accepte des événements produit (une inscription, un essai qui approche de sa fin, une fonctionnalité utilisée) liés à un contact. Définis quelques séquences comme de simples fichiers de config — un événement d’entrée, puis des étapes avec une période d’attente et une instruction en langage simple sur ce vers quoi cet email devrait pousser le lecteur. Sur un planning, trouve les contacts dus pour leur prochaine étape, et rédige cet email avec une API LLM, à partir de tes propres notes de voix de marque et de l’activité récente de ce contact. Chaque brouillon atterrit dans une file de validation — rien ne s’envoie sans qu’un humain clique sur approuver. Envoie le courrier approuvé via un vrai prestataire transactionnel, enregistre les webhooks de bounce et de plainte dans une liste de suppression vérifiée avant chaque envoi futur, et mets un lien de désabonnement en un clic fonctionnel dans chaque pied de page. Plafonne le nombre d’emails qu’un contact peut recevoir sur toutes les séquences dans une courte fenêtre, appliqué avant la rédaction, pas après.

Ne construis pas de tests de variantes A/B, d’analyse de réponses, ni de créateur de séquences visuel — ça fait tourner un programme pour un produit avec un seul opérateur qui approuve tout, et c’est le périmètre honnête. Sois direct dans le README sur le fait qu’un nouveau domaine d’envoi a besoin d’une vraie période de chauffe avant un vrai volume, et que le courrier d’un domaine froid atterrit en spam, quelle que soit la qualité de la copie.