Skip to content
Documentation Wasel

09 — Templates WhatsApp

1. Objectif métier

Section titled “1. Objectif métier”

Concevoir et maintenir un portefeuille de templates WhatsApp fiable pour les usages répétitifs:

  • notifications utiles,
  • messages marketing,
  • authentification,
  • communication standardisée à grande échelle.

Ce module vise la qualité et la gouvernance:

  • moins de rejets,
  • moins d’échecs à l’envoi,
  • meilleure lisibilité pour les équipes.

2. Qui utilise ce module (admin/operator)

Section titled “2. Qui utilise ce module (admin/operator)”
  • admin: crée, soumet, synchronise, suit la santé, nettoie le portefeuille.
  • operator: utilise les templates approuvés en exploitation.

3. Prérequis

Section titled “3. Prérequis”

Avant de créer un template:

  • cas d’usage métier défini,
  • catégorie choisie (MARKETING, UTILITY, AUTHENTICATION),
  • contenu validé (ton, conformité, clarté),
  • exemples prêts pour les variables.

Préparer une convention de nommage:

  • nom interne lisible pour l’équipe,
  • nom WhatsApp strict en minuscules avec underscores.

Contraintes importantes:

  • exactement un composant BODY obligatoire,
  • placeholders séquentiels ({{1}}, {{2}}, …),
  • exemples obligatoires dès qu’il y a des variables,
  • composant BUTTONS limité à 10 boutons maximum.

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

Section titled “4. Procédure pas-à-pas (orientée actions produit)”
  1. Définir l’objectif du template.
  • Quel moment client ?
  • Quelle action attendue ?
  • Quel niveau de sensibilité ?
  1. Nommer le template correctement.
  • Nom interne métier (ex: Relance panier J+1).
  • Nom WhatsApp normalisé (ex: relance_panier_j1).
  1. Construire les composants.
  • BODY obligatoire.
  • Ajouter HEADER, FOOTER, BUTTONS seulement si utile.
  • Éviter la complexité inutile.
  1. Vérifier les variables et exemples.
  • Placeholders en ordre sans trou.
  • Fournir des exemples complets pour chaque placeholder.
  • Pour header média (image/vidéo/document), préparer un exemple média valide.
  1. Vérifier les boutons.
  • URL nécessite une URL valide.
  • PHONE_NUMBER nécessite un numéro.
  • Pour URL dynamique, prévoir les exemples correspondants.
  1. Soumettre à validation.
  • Suivre l’état (pending, approved, rejected, etc.).
  • Corriger rapidement en cas de rejet.
  1. Synchroniser régulièrement les statuts.
  • Mettre à jour les états réels.
  • Archiver les modèles disparus côté source.
  1. Tester avant diffusion large.
  • Envoi interne réel.
  • Vérifier rendu client final.
  • Vérifier compréhension et lisibilité.
  1. Piloter la santé templates.
  • Suivre volume envoyé, taux d’échec, erreurs fréquentes, date de dernière synchro.
  • Supprimer les templates obsolètes après analyse d’impact.

5. Scénarios concrets (minimum 2)

Section titled “5. Scénarios concrets (minimum 2)”

  • Scénario A (Utility opérationnel):

    • template de confirmation,
    • variables simples,
    • validation,
    • test interne,
    • mise en production.

  • Scénario B (Authentication OTP):

    • template d’authentification,
    • format strict,
    • surveillance renforcée des rejets/échecs.

  • Scénario C (hygiène portefeuille):

    • revue mensuelle,
    • archivage des inactifs,
    • réduction du portefeuille à l’essentiel.

6. Erreurs fréquentes et résolution

Section titled “6. Erreurs fréquentes et résolution”

  • Problème: template rejeté.

  • Cause fréquente: contenu non conforme, exemples incomplets, placeholders incohérents.

  • Résolution: corriger structure et exemples, puis resoumettre.

  • Problème: template introuvable en exploitation.

  • Cause fréquente: statut non synchronisé.

  • Résolution: relancer la synchronisation puis vérifier l’état courant.

  • Problème: envoi échoue alors que le template existe.

  • Cause fréquente: template non approuvé, quota atteint, composants runtime manquants.

  • Résolution: vérifier état, quota, et paramètres d’envoi.

  • Problème: multiplication de templates quasi identiques.

  • Résolution: imposer une nomenclature stricte et une revue mensuelle.

7. Bonnes pratiques et limites

Section titled “7. Bonnes pratiques et limites”
  • Créer peu de templates, mais excellents.
  • Faire relire chaque template avant soumission.
  • Réutiliser les modèles qui fonctionnent bien au lieu de dupliquer.
  • Analyser les échecs par code d’erreur pour améliorer la qualité.

Limites:

  • des templates trop complexes augmentent les rejets,
  • un portefeuille trop large devient ingérable,
  • sans synchronisation régulière, l’équipe envoie parfois avec de mauvais statuts.

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

Section titled “8. Référence rapide (champs/statuts/modes)”

Catégories:

  • MARKETING,
  • UTILITY,
  • AUTHENTICATION.

Composants:

  • HEADER,
  • BODY,
  • FOOTER,
  • BUTTONS.

Statuts fréquents:

  • pending,
  • approved,
  • rejected,
  • paused,
  • disabled,
  • archived.

Indicateurs de santé:

  • total envoyés,
  • total échoués,
  • taux d’échec,
  • top erreurs,
  • répartition des statuts,
  • dernière synchronisation.

9. Liens vers modules liés

Section titled “9. Liens vers modules liés”