Participez aux tests de LadVen OSDemander une demo
Aller au contenu principal

Modèles de message

Un modèle de message est une ébauche d'e-mail avec des variables que l'automatisation remplit et envoie en votre nom. Lorsqu'il se déclenche, le robot prend le modèle, y insère les données d'un objet CRM précis (nom du client, intitulé et champs disponibles) et envoie l'e-mail prêt à l'emploi. Cela permet de garder un style uniforme dans les communications externes et de ne pas rédiger manuellement des e-mails répétitifs.

remarque

Le contexte du modèle ne se limite pas aux ventes : l'objet CRM peut être une affaire commerciale ou une demande de service. Dans les exemples suivants, « affaire » désigne ces deux types d'objet. Pour les vérifications sûres, utilisez Delivery window — demo (demande de service) et Rebranding — demo (affaire commerciale) ; n'insérez ni vrais contacts, ni montants, ni identifiants.

Les modèles se configurent à l'adresse /crm/email-templates.

À quoi servent les modèles de message

Carte conceptuelle du processus ; ce n’est pas une capture UI ni une preuve d’état.

Modèles d’e-mail pour robots CRM et workflows : statut, objet et usage de chaque modèle.

Les modèles sont utiles partout où le portail envoie des e-mails à votre place selon des règles d'automatisation :

  • accusé de réception d'une demande ;
  • e-mail au passage d'une affaire à une étape (par exemple, « facture envoyée ») ;
  • rappel au client selon la planification du robot ;
  • réponse type avec les coordonnées ou un lien.

Le modèle sépare le texte de l'e-mail de la logique d'automatisation : le robot décide quand envoyer, et le modèle définit quoi écrire.

Où configurer

Carte conceptuelle du processus ; ce n’est pas une capture UI ni une preuve d’état.

Ouvrez /crm/email-templates. La liste affiche tous les modèles avec leur objet et leur état (actif ou archivé), et la recherche se fait par nom, objet ou texte. La création et la modification nécessitent les droits correspondants ; sans eux, les modèles sont accessibles en lecture seule.

De quoi se compose un modèle

Carte conceptuelle du processus ; ce n’est pas une capture UI ni une preuve d’état.

Un modèle est constitué de plusieurs champs :

  • nom — le nom interne par lequel le modèle est choisi dans l'action du robot ;
  • objet — l'objet de l'e-mail ;
  • version texte et/ou version HTML — le contenu même de l'e-mail.

Pour un modèle actif, l'objet et au moins une version du contenu (texte ou HTML) sont obligatoires. Le nom sert à la recherche et au choix, il n'est pas visible par le destinataire.

Variables

Carte conceptuelle du processus ; ce n’est pas une capture UI ni une preuve d’état.

Dans l'objet et le texte, vous pouvez utiliser des variables — des jetons comme {{ opportunity.title }} ou {{ name }}. Lors de l'envoi, le portail y insère les données réelles de l'affaire pour laquelle le robot s'est déclenché. Ainsi, un même e-mail s'adapte à chaque destinataire sans modification manuelle.

N'utilisez que les variables réellement présentes dans le contexte de l'affaire : un jeton inconnu restera vide ou sera mal substitué.

Aperçu

Carte conceptuelle du processus ; ce n’est pas une capture UI ni une preuve d’état.

Avant utilisation, faites passer le modèle par l'aperçu : le portail insère le contexte de l'affaire et montre à quoi ressembleront l'objet et le texte avec des valeurs réelles. L'aperçu est le principal moyen d'attraper une faute de frappe dans un jeton avant que l'e-mail ne parte chez le client.

À l'aperçu, vérifiez non seulement le texte, mais aussi la substitution : toutes les variables se sont-elles bien développées, n'y a-t-il pas de jetons « nus » dans l'e-mail final.

Brouillons, modèles actifs et archivés

Carte conceptuelle du processus ; ce n’est pas une capture UI ni une preuve d’état.

Un modèle peut être brouillon, actif ou archivé. Un brouillon peut être enregistré incomplet, mais n'est pas proposé au robot et n'envoie aucun e-mail. Un modèle actif est disponible pour être choisi dans l'action du robot et est réellement utilisé pour l'envoi. Un modèle archivé est conservé pour l'historique, mais n'est pas proposé dans l'automatisation. Archivez les modèles obsolètes plutôt que de les supprimer, afin de ne pas perdre le texte et de ne pas casser les robots qui y faisaient référence.

Comment le modèle est utilisé dans l'automatisation

Carte conceptuelle du processus ; ce n’est pas une capture UI ni une preuve d’état.

Le modèle n'envoie pas d'e-mails de lui-même — il se rattache à l'action « envoyer un e-mail » d'un robot CRM. Le robot se déclenche sur un événement de l'affaire, prend le modèle actif par son nom, insère les variables et envoie l'e-mail. C'est pourquoi l'ensemble ne fonctionne que lorsqu'il y a à la fois un modèle actif et un robot activé avec cette action.

États et limites

Carte conceptuelle du processus ; ce n’est pas une capture UI ni une preuve d’état.

  • modèle archivé — non proposé dans l'action du robot ;
  • brouillon — non proposé au robot et jamais envoyé ;
  • un modèle actif sans objet ni contenu texte/HTML — impossible de l'enregistrer comme actif ;
  • l'aperçu ne s'est pas exécuté — vérifiez les jetons et le contexte ;
  • un jeton « nu » est resté dans l'e-mail — la variable n'existe pas dans le contexte de l'affaire ;
  • absence de droits de gestion — les modèles sont accessibles en lecture seule.

Bonnes pratiques

Carte conceptuelle du processus ; ce n’est pas une capture UI ni une preuve d’état.

  • Donnez aux modèles des noms clairs pour les choisir facilement dans le robot.
  • Vérifiez toujours la substitution des variables à l'aperçu.
  • N'utilisez que les variables disponibles dans le contexte de l'affaire.
  • Archivez les modèles obsolètes au lieu de les supprimer.
  • Gardez la version HTML soignée : l'e-mail sera vu par un destinataire externe.

Erreurs fréquentes

Carte conceptuelle du processus ; ce n’est pas une capture UI ni une preuve d’état.

Faute de frappe dans un jeton. La variable ne se développe pas, et le client reçoit un e-mail avec un {{ ... }} « nu ».

Activer un modèle sans aperçu. Une erreur dans l'objet ou la substitution part immédiatement à tous les destinataires du robot.

Supprimer au lieu d'archiver. Les robots qui faisaient référence au modèle cessent d'envoyer des e-mails.

Mettre dans le modèle des données absentes du contexte. Le jeton reste vide, l'e-mail paraît inachevé.

Comment vérifier le résultat

Carte conceptuelle du processus ; ce n’est pas une capture UI ni une preuve d’état.

  • l'aperçu affiche un objet et un texte corrects avec les données insérées ;
  • l'e-mail final ne contient aucun jeton non développé ;
  • le modèle actif est disponible pour être choisi dans l'action du robot ;
  • le robot avec l'action « envoyer un e-mail » envoie l'e-mail selon ce modèle ;
  • les modèles archivés ne gênent pas et ne sont pas proposés dans l'automatisation.

Scénarios liés

Scénarios liés — Repère conceptuel, pas une capture d’interface ni une preuve d’état. Repère conceptuel, pas une capture d’interface ni une preuve d’état.