Rappels, jalons et règles de notification
Pourquoi ce système existe
Un workspace où personne ne passe pendant trois mois perd de sa valeur. Un jalon comme la 1 000ᵉ mise à jour collectée est une bonne occasion de ramener l’app dans la conversation de l’équipe. Et quand un membre d’équipe génère son premier rapport, un court e-mail de confirmation aide à ancrer l’habitude.
Pour que ces e-mails ne paraissent ni arbitraires ni pressants, ils passent par un système de règles : événement → condition → destinataire → limite. Chaque élément est modifiable.
Les trois blocs
Événements (business events)
Les événements sont ce qui se passe dans votre workspace. Picasi connaît quatre types :
- Mises à jour collectées — chaque fois que de nouvelles mises à jour entrent dans le workspace.
- Rapport créé — quand un rapport est généré.
- Rapport planifié créé — quand quelqu’un configure un nouveau rapport automatisé.
- Utilisateur inactif — vérifié quotidiennement ; marque les utilisateurs qui n’ont pas ouvert l’app depuis X jours.
Les événements seuls n’envoient aucun e-mail. Ce sont seulement des déclencheurs.
Règles de notification
Une règle relie un événement à un e-mail. Elle définit :
- Quel événement la règle regarde
- Sous quelles conditions (p. ex. seulement à la 1 000ᵉ mise à jour, seulement pour les rapports hebdomadaires, seulement pour le rôle propriétaire)
- Qui reçoit l’e-mail (utilisateur déclencheur, propriétaire d’équipe ou tous les membres)
- Combien de fois la règle peut se déclencher au maximum (aucune limite, une fois par utilisateur, une fois par équipe)
À la première configuration du workspace, Picasi crée sept règles par défaut. Elles couvrent trois cas :
- Jalons : à 100, 1 000 et 5 000 mises à jour collectées, un e-mail de félicitations part vers le propriétaire d’équipe.
- Première utilisation : au premier rapport généré et au premier rapport planifié, un e-mail de confirmation part vers l’utilisateur déclencheur.
- Réactivation : après 5 et 14 jours d’inactivité, un rappel part vers l’utilisateur concerné.
Modèles d’e-mail
Chaque type d’e-mail a un modèle. Ce que dit le modèle est fixe — seul est configurable le fait qu’il soit envoyé ou non (via la règle).
Quand chaque e-mail a du sens
Les e-mails de jalon fonctionnent comme un petit crochet pour amorcer une conversation d’équipe « nous avons désormais X mises à jour » — utile pour la visibilité interne de l’outil.
Les e-mails de première utilisation fonctionnent comme boucle de retour : « le rapport que vous venez de lancer est bien terminé ». Pour les utilisateurs moins expérimentés, une confirmation qu’ils ont travaillé correctement.
Les e-mails d’inactivité ont deux buts :
- Après 5 jours : rappel amical « X nouvelles mises à jour vous attendent ».
- Après 14 jours : coup de coude plus ferme, plus un lien pour ceux qui veulent vraiment sortir de la liste.
Ce que vous ne pouvez pas changer
- Les sept règles par défaut ne peuvent pas être supprimées — uniquement désactivées. Raison : elles définissent l’état par défaut attendu du workspace.
- Le texte et la mise en page des e-mails sont fixes. Seuls les paramètres de la règle (destinataire, conditions, limite) sont modifiables.
- Les envois de rapports ne font pas partie de ce système. Qui reçoit un rapport planifié par e-mail est configuré directement sur le rapport — pas via des règles de notification.
Ce que les destinataires peuvent changer
Chaque e-mail de jalon ou de rappel contient un lien de désinscription en bas de page. Un clic désinscrit l’adresse e-mail de tous les e-mails de jalon et de rappel à travers tous les workspaces — le destinataire ne verra plus ces e-mails, quelles que soient les règles actives dans quel workspace.
Les e-mails de rapport ne sont pas affectés par cette désinscription. Qui veut aussi sortir de ceux-là doit être retiré comme destinataire du rapport planifié.