IOSOR

IOSOR Guides

Catalogue de modèles avant le passage du canal en mode Live

Parcours acheteur : des modèles approuvés doivent exister avant tout badge Live sur les classes de messages riches ou SMS. Le catalogue d'abord, le volume ensuite.

Un badge Live sur une classe de message sans catalogue de modèles approuvé équivaut à brûler du crédit prépayé avec un jeton vert. Les acheteurs ont besoin d'un catalogue nommé de modèles de production avant que les ventes ne déclarent le mode Live pour les classes riches ou SMS. Cette page représente ce parcours acheteur — ce n'est pas une plongée en profondeur dans un coffre ni une liste de courses d'API SMS générale.

Le catalogue est la porte Live pour les classes de messages

Le mode Live signifie que la classe peut accepter du volume prépayé avec un statut honnête. Le catalogue signifie que chaque ID de modèle de production est répertorié, approuvé, attribué et associé à une classe d'unité avant l'envoi. La bascule et la piste de décollage peuvent sembler prêtes, mais le mode Live sur WhatsApp, RCS ou SMS thématisés reste bloqué tant que la ligne de catalogue n'existe pas.

Ce que contient une ligne de catalogue approuvée

Champ Pourquoi les acheteurs s'en soucient
ID de modèle + version Le même objet que le produit et la finance réconcilient
Classe de message (OTP, alerte, avis) Empêche la dérive de classe dans le texte marketing
État de révision Approuvé uniquement — le brouillon ne va jamais en Live
Classe d'unité Segment, session ou unité de modèle avant le débit
Propriétaire + règle de retrait Qui répare le rejet et quand l'ID expire

Canal Live et catalogue Live sont des jetons différents

Un canal peut être en cours de configuration pendant que les modèles sont rédigés. Un catalogue peut être approuvé pour les OTP tandis que les modèles marketing restent à l'état de brouillon. Ne fusionnez pas les jetons : canal prêt ≠ « n'importe quel modèle peut envoyer ». La retenue prépayée échoue sur les ID inconnus — réservation prépayée avant le premier débit.

Parcours acheteur avant tout badge Live

  1. Listez les modèles du premier mois par classe de message.
  2. Soumettez à révision ; attendez « Approuvé », pas « ça a l'air bien ».

Liste de contrôle de l'acheteur pour le catalogue de modèles

  • Chaque ID de modèle a-t-il une classe d'unité assignée ?
  • Le propriétaire du catalogue est-il défini pour chaque ligne ?
  • Les brouillons ont-ils été supprimés de la production ?

Commencez avec IOSOR

Ouvrez la console IOSOR et verifiez vos identifiants de modeles actifs par rapport aux statuts du catalogue approuve avant de tenter toute transition de canal en direct. Assurez-vous que chaque classe de message possede un mappage de modele explicite et une classe d'unite verifiee rattachee a sa barriere de debit. Executez une seule transaction de test par classe pour confirmer que les webhooks DLR capturent l'identifiant exact du catalogue sur les accuses de reception avant de lever les restrictions de production.

À retenir — IOSOR

L'aptitude des canaux et l'approbation du catalogue de modeles reposent sur des verifications d'execution distinctes. Marquer un canal comme operationnel sans identifiants de modeles approuves et explicites dans le catalogue provoque l'echec des systemes de retenue pre gagnes sur des charges utiles non mappyees, quel que soit l'etat de la passerelle sous-jacente.

Associez chaque classe de message de production a un identifiant de modele approuve et a une balise de debit verifiee avant d'ouvrir les vannes du trafic. Ne confondez pas l'etat de connexion du canal avec l'autorisation du modele, et ne permettez jamais a des identifiants de modeles brouillons ou rejetes de tenter un envoi en direct.

Ce guide vous a-t-il aidé ?

Guides associés