Email automation et templating

[chaibax]

Hello,

Je vous propose d'inscrire tout nouveau membre (a qui on a créé un email @beta.gouv) sur une liste dédiée sur le compte sendinblue de beta. Cela nous permettra de :

1. créer sans compétence technique et sans coder des scénarii d'email pour les nouveaux membres (par exemple). On pourrait en 1 minute traiter cette demande de Benjamin : #191
2. séparer l'email transactionnel de création de la boite email (avec le mot de passe) de l'email de bienvenue. Ce dernier mérite vraiment un email à lui tout seul.

Dans une deuxième étape ,cela pourrait permettre aussi :

• d'avoir des templates d'emails transactionnels qui claquent, s'affichent bien sur tout les clients email, et qui peuvent être modifiés/améliorer sans compétence technique. Idem pour le sujet du mail, etc Pour cela, on passerait par l'api d'envoi sendinblue plutôt que par un SMTP .
• d'avancer sur l'automatisation de l'envoi de la NL en passant par Sendinblue pour la partie envoi
• de permettre au membre de gérer facilement leur préférence d'inscription, etc
• d'avoir une meilleure vue du niveau d'engagement de la communauté vis-à-vis de nos emails en général (via de vraies statistiques)
• d'envoyer des emails personnalisés et automatisé selon qu'un membre ai ou pas un email beta, une fiche github, une date de fin ok, etc

Je comprends qu'il n'est pas forcément évident de voir l'avantage d'un vrai outil d'emailing vs une mailing liste ovh, ni d'ouvrir certaine partie du code (format des emails, sujet, etc) à des non dev. Mais tout cela permet de se focus sur la partie métier de l'app secrétariat et sous-traiter une partie du reste à un outil saas , certes externe, mais spécialisé.

[alemangui]

Hello Chaïb,

Techniquement je ne vois pas de souci, SendInBlue a l'air d'avoir les API nécessaires pour créer des contacts et ajouter des contacts aux listes.

Pour être sur d'avoir compris le besoin, l'idée serait d'avoir une liste de mails "nouveaux membres" qui permettrait d'envoyer des emails systématiques (par ex. un email de bienvenue, rappel d'engagement) ainsi qu'éventuellement des emails pertinents (comme des sessions embarquement, etc). Ces emails seraient envoyés manuellement (dans le sens ou quelqu'un devra cliquer sur un bouton pour les envoyer).

Sauf erreur de ma part, il y a donc deux types d'emails :

Emails transactionnels déclenches après X temps de l'arrivé (bienvenue, rappel d'engagement)

Prenant #191 comme exemple, vu qu'on parle d'envoyer un email après deux mois après l'arrivé de chaque membre, je ne vois pas comment la création d'une liste vous permettrait de le traiter en 1 minute : il faudrait faire chaque jour une sub-liste des gens qui sont arrivés deux mois auparavant et envoyer l'email (mais je rate peut être une feature d'automatisation de SendInBlue).

Il me semble plus facile que l'envoi soit automatisé. Par exemple, nous pouvons utiliser un template existant que vous aurez créé chez SendInBlue pour que vous ayez le suivi de ces emails et que vous puissiez modifier le template si besoin, sans vous embêter à envoyer manuellement l'email chaque jour.

Emails transactionnels liés à des événements

Si - par ex - une session d'embarquement est organisée vous pourriez envoyer un email à tous les gens de cette liste une seule fois, et donc je vois plus clairement l’intérêt d'avoir la liste sous le coud.

Par contre, a-t-on besoin de mettre à jour de cette liste ? çad est-ce qu'on doit aussi enlever des contacts après un certain moment (puisqu'ils ne sont plus considérés comme des nouveaux membres) ? Ici pareil je rate peut être une feature de SendInBlue qui vous permettrait de mettre à jour la liste ou d'envoyer seulement à une liste filtrée par date-range de création ?

[chaibax]

Hello @alemangui .

C'est bien ca l'idée, balancer via l'api un nouveau membre, et ensuite gérer les déclancheur sur sendinblue.

Emails transactionnels déclenches après X temps de l'arrivé (bienvenue, rappel d'engagement)

Pour le #191 , c'est bien une fonctionnalité de base du marketing automation (chez sendinblue ou ailleurs) : envoyer un email selon certains critères a un certains moment pour une certains personnes. Tout ca, avec un éditeur graphique

Je sais très bien faire et je le fais souvent sur les startups que j'accélère.

Emails transactionnels liés à des événements

L'idée, a moyen terme, c'est d'avoir, par exemple, un flag embarquement_session . On le balancerait, en tant qu'attribut du contact, sur sendinblue. Cet attribut permettrait de créer un déclencheur, et d'envoyer un email ou autre.

Les possibilités sont nombreuses.

Pour ce qui est de la MAJ de la liste, il y a des conditions de sorties à paramétrer pour chaque scenario, afin de ne pas le jouer plusieurs fois pour une même membres .

[LucasCharrier]

Hello @chaibax, attends tu déjà un format particulier pour les contacts à envoyer à la liste SendInBlue ? Il y a possibilité d'envoyer les différents champs d'une fiche membre :

fullname: Elodie Viplot
role: Intrapreneuse
missions:
  - start: 2018-01-01
    end: 2020-09-01
    status: admin
    employer: Dinum
startups:
  - Egalim

Pour fullname je peux le scinder en firstname et lastname en séparant à partir du premier espace par exemple.

[chaibax]

Hello @LucasCharrier . Pas de format particulier, du texte pour tour. La date est déjà au bon format coté sendinblue.

J'ai crée les champs sur sendinblue, pour récupérer les valeurs :

NOM_COMPLET ROLE MISSION_START MISSION_END MISSION_STATUS MISSION_EMPLOYER

Ces deux derniers champs permettant d'envoyer du contenu spécifique (dans l'email de bienvenue par exemple)

La donc d'ajout de contact sendinblue est ici : https://developers.sendinblue.com/reference#createcontact L'id de la liste où seront ajoutés les contact est : 14 (en prod). J'ai fait une liste pour nos test , id:15

Ça donnerait ça :

const fetch = require('node-fetch');

let url = 'https://api.sendinblue.com/v3/contacts';

let options = {
  method: 'POST',
  headers: {Accept: 'application/json', 'Content-Type': 'application/json'},
  body: JSON.stringify({
    attributes: {NOM_COMPLET: 'Elodie Viplot', ROLE: 'Intrapreneuse'},
    listIds: [14],
    updateEnabled: false,
    email: 'chaib@yopmail.com'
  })
};

fetch(url, options)
  .then(res => res.json())
  .then(json => console.log(json))
  .catch(err => console.error('error:' + err));

Pour ce qui est de la propagation d'une MAJ de fiche sur sendinblue, laissons ça à une prochaine issue :)

[jdauphant]

Pour ce ticket, on devient dépendant d'un service SaaS pour le fonctionnement de l'application si on envoit les emails transactionnels par l'API de sendinlue.

Ce n'est pas recommandé, il est préférable d'utiliser des standards quand il sont disponible comme SMTP comme l'implementation actuelle.

Concernant le reste : "templates d'emails transactionnels qui claquent, s'affichent bien sur tout les clients email, " -> on n'a pas forcément de besoins d'email qui claquent, un email simple HTML s'affiche sur tous les clients "d'avancer sur l'automatisation de l'envoi de la NL en passant par Sendinblue pour la partie envoi" -> on n'a pas besoins de ça

je ne vais pas répondre à tous les arguments mais à quels besoins et problèmes utilisateurs on répond aussi ?

[LucasCharrier]

Laa PR sur cette tache consistait dans un premier temps à régler ce soucis là : #191 (Envoyer un mail deux mois après l'arrivée pour rappeler l'engagement)

Avec les arguments ci-dessus avancé par @chaibax :

créer sans compétence technique et sans coder des scénarii d'email pour les nouveaux membres (par exemple). On pourrait en 1 minute traiter cette demande de Benjamin #191

C'est en effet plus simple, ensuite de gérer les templates d'email, la fréquence, etc depuis une interface, mais ça me semble nécessaire de pouvoir facilement envoyé des emails a la communauté selon certains critères sans avoir à passer par le code.

Mais en effet il ne me semble pas adéquat d'envoyer le reste des emails via SIB comme tu la mentionné @jdauphant .

[jdauphant]

Il faut voir la fréquence de mise à jour, est-ce que ça le coup de complexifier l'app et introduire une dépendance SaaS au lieu de juste faire la tache Benjamin #191. (est-ce que ce cas d'usage est si fréquent ?) Sachant que pour SendInblue, il faut embarquer la personne, qu'elle comprenne comment ça fonctionne sur SendInblue (on a déjà embarqué un certain nombre de personne sur Github).

Pour gérér le contenu des templates, les gens sont déjà autonome par les PRs pour le moment dans l'app, on peut simplifier encore plus en mettant bien chaque template dans un fichier.

On peut bien évidemment exporter des données dans SendInblue mais il ne faut pas que ça créé une dépendance forte (on peut faire un dépendence faible) ou juste permettre un export csv compatible avec SendInBlue ou utilisable avec d'autres outils.

[LucasCharrier]

Yes, je n'ai pas une vision précise de qui envoie des emails, quels types d'emails et à quelle fréquence. Ça me semble pratique si en effet on veut faire des séquences d'email qu'on compte changer de temps en temps, mais je n'ai pas de réel vision sur le besoin. A voir avec @chaibax.

[jdauphant]

J'ai l'impression qu'un export des données est suffisant pour les usages exceptions, pouvoir visualiser et exporter en csv, Un tableau de visualisation http://tabulator.info/ avec toutes les données et les filtres pourraient faire l'affaire -l'export est gérer par tabulator) et aussi couvrir d'autres cas d'usage. Et pour le use case de Benjamin, on l'automatise dans l'app, on peut aussi faire en sorte que ça soit plus simple d'automatiser ça dans le code.

[jdauphant]

PS : Benjamin a envoyé l'email à la main du coup, ça a pris moins de temps que d'écrire le code voir même que de le faire avec Sendinblue

[LucasCharrier]

Si il doit tous les mois récupérés les emails des nouvelles personnes concernés remplir son emails avec les champs personnalisés correspondant, ça me semble quand même un peu laborieux, et je vois l'intérêt d'automatiser un peu le process. Mais oui du coup ça peut être fait en code si on ne part pas sur Send In Blue, à voir s'il y un désir de tester différents type d'email, à des fréquences différentes, même si ça ne me semble pas être le cas. Je laisse en standby #191, voir si @chaibax souhaite rajouter quelque chose la dessus.

[jdauphant]

Je ne suis pas sûr qu'on ai tous les éléments partagés. On a peut être besoins d'un échange à l'oral.

[chaibax]

Yes, le plus simple c'est d'en parler de vive voix.

[chaibax]

On ne va pas passer par l'app secretariat mais remonter directement la liste des membres (info public) sur Sendinblue via Zapier.