Cas d’usage typiques
- Attente d’une date connue : l’utilisateur annonce « je reçois ma paye jeudi » → planifier une relance pour jeudi, qui survivra aux messages envoyés entre-temps.
- Fin de soirée : l’utilisateur dit « bonne nuit » → mettre la conversation en pause et planifier une reprise le lendemain à l’heure de contact optimale.
- Reprise après une absence : programmer une relance à une heure précise pour recontacter un utilisateur silencieux.
- Scénario conditionnel : déclencher une relance uniquement lorsqu’un accomplissement, un palier ou une variable spécifique est atteint.
Quand envoyer la relance
L’action détermine la date d’exécution selon le mode choisi. Quatre modes existent, évalués par ordre de priorité : le premier mode renseigné l’emporte sur les suivants.Variable utilisateur (priorité la plus haute)
La relance est planifiée à la date contenue dans une variable de l’utilisateur. La variable doit contenir une date au format ISO 8601 UTC (par exemple
2025-01-20T14:30:00Z).Pratique pour relancer à une échéance déduite de la conversation et stockée au préalable dans une variable (par exemple via une action d’extraction d’information).Heure précise
La relance est planifiée à une heure de la journée au format
HH:mm (UTC). Le système vise la prochaine occurrence de cette heure dans une fenêtre de 24 h : si l’heure est déjà passée aujourd’hui, la relance part demain à cette heure.Heure de contact optimale
La relance est planifiée au moment où l’utilisateur est historiquement le plus actif. Le Délai minimum garantit un écart plancher : la relance ne partira jamais avant ce délai, même si l’heure optimale tombe plus tôt.Sans données d’activité suffisantes, le système retombe sur un report de +8 heures.
Si plusieurs modes sont renseignés, l’ordre de priorité est strict : Variable utilisateur > Heure précise > Heure de contact optimale > Délai spécifique.
Contenu de la relance
Instruction
Texte optionnel injecté dans la génération pour guider ce que le créateur doit dire dans la relance (le ton, l’angle, l’objectif). Si l’instruction est laissée vide, l’IA détecte qu’il s’agit d’une relance et improvise. L’instruction supporte les jetons dynamiques (par exemple{{USERINFO_Firstname}}, {{USER_Name}}, {{CREATORPERSONA_CustomperType}}), résolus juste avant l’envoi.
Utiliser le ThinkingAgent
Détermine comment l’instruction est traitée :- Désactivé (par défaut) : l’instruction est transmise directement à l’agent de rédaction. Plus fidèle à l’instruction et plus économique en tokens.
- Activé : l’instruction passe par le pipeline complet (réflexion stratégique via le ThinkingAgent ou le ReplyAgent). Plus contextuel, mais plus coûteux.
Options de comportement (flags)
Les flags définissent comment la relance réagit aux événements entre sa planification et son exécution. Par défaut, une relance créée par stratégie active les trois flags ci-dessous.| Option | Effet |
|---|---|
| Conserver même si l’utilisateur répond | La relance n’est pas annulée lorsque l’utilisateur envoie un message. Sans ce flag, toute réponse de l’utilisateur annule la relance en attente. |
| Relance indépendante | La relance n’affecte pas la séquence automatique : elle n’incrémente pas l’index de palier et ne déclenche pas la planification du palier suivant. |
| Respecter la pause | Si une pause est active à l’échéance, la relance est reportée à la fin de la pause au lieu d’être annulée. |
Comportement à l’exécution
Avant de créer la nouvelle relance, l’action annule les relances non-persistantes déjà en attente pour l’utilisateur. Une relance existante portant le flag Conserver même si l’utilisateur répond est préservée.Il ne peut exister qu’une seule relance active par utilisateur à la fois. Programmer une relance via cette action remplace donc la relance automatique en attente (sauf si celle-ci est persistante).
Combiner pause et relance
Pour les scénarios d’attente (paye, indisponibilité, fin de soirée), combinez dans la même règle une mise en pause de la conversation et une relance programmée à la fin de cette pause. La relance, marquée Conserver et Respecter la pause, garantit une reprise à l’échéance même si l’utilisateur a envoyé des messages entre-temps.Conditionner une règle sur l’état des relances
Plusieurs conditions de stratégie permettent de réagir à l’état des relances d’un utilisateur :| Condition | Vrai quand |
|---|---|
| A une relance en attente | Une relance est actuellement planifiée pour l’utilisateur. |
| Pas de relance en attente | Aucune relance n’est planifiée. |
| Index planification ≥ / ≤ / = | Le palier courant de l’utilisateur atteint, ne dépasse pas, ou égale une valeur. |
Annuler les relances
L’action complémentaire “Annuler les relances” supprime toutes les relances en attente de l’utilisateur — y compris les persistantes — et remet l’index de palier à zéro. Utile pour reprendre la main et stopper net toute reprise automatique sur un utilisateur.Voir aussi
- Relances — Le système de relance automatique par paliers.
- Réponses automatiques — Le job déclenché par chaque relance.