Skip to content
Documentation Wasel

08 — Messagerie Sortante

1. Objectif métier

Section titled “1. Objectif métier”

Envoyer les bons messages au bon moment, avec un suivi d’état clair.

Ce module couvre:

  • envoi texte,
  • envoi image,
  • envoi template,
  • envoi planifié,
  • annulation d’un planifié,
  • suivi des statuts d’envoi.

Objectif final:

  • fiabilité opérationnelle,
  • réduction des erreurs de communication,
  • meilleure maîtrise des relances.

2. Qui utilise ce module (admin/operator)

Section titled “2. Qui utilise ce module (admin/operator)”
  • admin: définit les règles de ton, fréquence, conformité, priorités.
  • operator: exécute les envois individuels et vérifie les résultats.

3. Prérequis

Section titled “3. Prérequis”

Avant envoi sortant:

  • canal WhatsApp actif,
  • contact existant ou numéro destinataire valide,
  • templates approuvés disponibles (si template),
  • règles internes de communication validées.

Préparer des standards:

  • modèles de message par cas d’usage,
  • règles d’horaires d’envoi,
  • procédure de contrôle des messages failed.

Contraintes métier importantes:

  • image: lien HTTPS obligatoire,
  • template: statut approuvé obligatoire,
  • certains templates exigent des composants explicites,
  • l’annulation ne s’applique qu’aux envois planifiés encore en attente.

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

Section titled “4. Procédure pas-à-pas (orientée actions produit)”
  1. Choisir le type d’envoi.
  • text pour message simple,
  • image pour visuel,
  • template pour communication normalisée,
  • planifié si envoi différé.
  1. Choisir le destinataire.
  • contact existant,
  • ou numéro direct.
  • Si le numéro n’existe pas encore, une fiche contact minimale peut être créée automatiquement.
  1. Préparer le contenu.
  • Message court et actionnable.
  • Vérifier variables/composants si template.
  1. Envoyer et contrôler l’état.
  • États utiles: queued, sending, sent, failed.
  • Vérifier apparition dans la conversation.
  1. Cas image: contrôler la validité du média.
  • URL HTTPS accessible publiquement.
  • Légende utile, courte et compréhensible.
  1. Cas template: vérifier conformité avant envoi.
  • Template approuvé et disponible.
  • Si le modèle nécessite des composants (header/boutons/média), les fournir explicitement.
  • Vérifier la consommation de quota template.
  1. Cas planifié: définir date/heure avec attention.
  • Vérifier le fuseau de référence.
  • Lister les envois à venir pour contrôle.
  • Ajuster/annuler si le contexte client change.
  1. Suivre le traitement automatique des planifiés.
  • Les messages planifiés sont traités régulièrement par lots.
  • Vérifier chaque jour les planifiés échoués.
  1. Annuler proprement un planifié devenu inutile.
  • Annulation possible uniquement si statut encore pending.

5. Scénarios concrets (minimum 2)

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

  • Scénario A (support proactif):

    • envoi texte de suivi,
    • statut sent confirmé,
    • conversation mise à jour immédiatement.

  • Scénario B (envoi image produit):

    • image HTTPS valide,
    • légende courte,
    • confirmation côté client,
    • correction rapide si échec média.

  • Scénario C (rappel planifié):

    • message planifié la veille,
    • contrôle file des “à venir”,
    • annulation si le client a déjà répondu.

6. Erreurs fréquentes et résolution

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

  • Problème: envoi image échoue.

  • Cause fréquente: URL non HTTPS ou inaccessible.

  • Résolution: fournir une URL HTTPS valide et retester.

  • Problème: template refusé à l’envoi.

  • Cause fréquente: template non approuvé ou paramètres manquants.

  • Résolution: choisir un template approuvé et compléter les paramètres requis.

  • Problème: quota template atteint.

  • Résolution: prioriser les envois critiques et planifier la suite avec l’admin.

  • Problème: message planifié envoyé à une mauvaise heure.

  • Cause fréquente: repère horaire mal interprété.

  • Résolution: vérifier systématiquement heure + fuseau avant validation.

7. Bonnes pratiques et limites

Section titled “7. Bonnes pratiques et limites”
  • Relire chaque message sortant avant envoi.
  • Réserver les communications massives au module campagnes.
  • Surveiller quotidiennement les messages failed.
  • Pour les planifiés, faire une revue avant exécution si contexte mouvant.

Limites:

  • un planifié pertinent aujourd’hui peut devenir hors contexte demain,
  • les quotas template imposent une priorisation,
  • un canal partiellement configuré génère des échecs d’envoi.

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

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

Types d’envoi:

  • text,
  • image,
  • template.

Statuts message:

  • queued,
  • sending,
  • sent,
  • failed.

Statuts planification:

  • pending,
  • sent,
  • failed,
  • cancelled.

Règles de temps:

  • un envoi planifié est normalisé pour traitement cohérent,
  • les heures sans fuseau explicite sont interprétées selon le contexte organisationnel défini.

9. Liens vers modules liés

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