10 — Templates Automatiques

1. Objectif métier

Automatiser les rappels clés pour réduire les oublis et améliorer la régularité opérationnelle.

Ce module permet de configurer des règles d’envoi template basées sur des déclencheurs métier.

Objectif pratique:

sécuriser les rappels récurrents,
diminuer la charge manuelle,
garder une trace des envois automatiques réussis/échoués.

2. Qui utilise ce module (admin/operator)

admin: configure les règles (trigger, décalage, activation, périmètre), suit les résultats.
operator: surveille les effets terrain, remonte les anomalies, ajuste avec l’admin.

3. Prérequis

Avant activation d’une règle automatique:

template approuvé disponible,
cas d’usage clair (ex: rappel avant rendez-vous),
fuseau organisationnel validé,
règles de consentement/opt-out appliquées,
responsable de surveillance désigné.

Contraintes importantes:

un template nécessitant des composants runtime n’est pas compatible avec cette automation,
une règle inactive n’enverra rien,
les contacts opt-out sont exclus des envois automatiques.

4. Procédure pas-à-pas (orientée actions produit)

Définir le cas d’usage métier.

Exemple prioritaire: rappel avant rendez-vous.

Choisir le déclencheur.

Déclencheurs configurables: avant rendez-vous, après création contact, après commande.
Vérifier les déclencheurs effectivement exploités dans votre environnement.

Régler le décalage horaire (hours_offset).

Valeur négative: intention “avant l’événement”.
Valeur positive: intention “après l’événement”.
En exploitation actuelle, privilégier les rappels avant rendez-vous avec offsets négatifs simples.

Sélectionner le template.

Statut approuvé obligatoire.
Éviter les templates qui exigent des composants saisis à l’envoi.

Définir le périmètre (si nécessaire).

Limiter à certains types d’activités selon votre stratégie.

Activer la règle.

Vérifier qu’elle apparaît bien active.

Exécuter un test contrôlé.

Créer un cas de test réel.
Vérifier le timing d’envoi et le contenu reçu.

Contrôler le journal d’automatisation.

Vérifier sent / failed.
Vérifier qu’un même événement n’est pas traité deux fois.

Ajuster et industrialiser.

Ajuster offset si nécessaire.
Étendre progressivement après validation réelle.

5. Scénarios concrets (minimum 2)

Scénario A (rappel rendez-vous):
- règle active à -24h,
- envoi automatique observé,
- journal sent,
- pas de doublon.
Scénario B (contact opt-out):
- rendez-vous existe,
- règle active,
- envoi volontairement ignoré (conformité),
- journal conforme au comportement attendu.
Scénario C (pilotage multi-activité):
- règle limitée à un périmètre donné,
- test sur périmètre autorisé et non autorisé,
- validation du ciblage.

6. Erreurs fréquentes et résolution

Problème: aucun envoi automatique observé.
Causes fréquentes: règle inactive, template non approuvé, dépendances canal manquantes.
Résolution: contrôler chaque dépendance dans l’ordre.
Problème: timing perçu comme décalé.
Cause fréquente: offset mal choisi ou fenêtre d’exécution mal comprise.
Résolution: recalibrer offset et retester sur cas réel.
Problème: règle créée mais template incompatible.
Cause fréquente: template demandant des composants non fournis automatiquement.
Résolution: choisir un template compatible automation.
Problème: attente sur des triggers non encore exploités.
Résolution: aligner la promesse métier sur les triggers réellement actifs dans votre contexte.

7. Bonnes pratiques et limites

Commencer par une seule automation critique.
Utiliser des offsets lisibles (-24h, -2h) avant d’affiner.
Vérifier le journal chaque semaine.
Ne pas empiler plusieurs règles redondantes sur le même événement.

Limites importantes:

l’exécution est périodique (pas en continu instantané),
la fenêtre de déclenchement est tolérante pour éviter les manques,
en l’état, les rappels avant rendez-vous sont le cas le plus fiable à industrialiser.

8. Référence rapide (champs/statuts/modes)

Déclencheurs configurables:

before_appointment,
after_contact_created,
after_order.

Paramètre clé:

hours_offset (décalage horaire de la règle).

États règle:

is_active = true/false.

Journal d’automatisation:

sent,
failed.

Garde-fou anti-doublon:

une même règle ne traite pas deux fois le même événement métier.