IOSOR Guide
Catalogo dei modelli prima del canale Live
Percorso acquirente: i modelli approvati devono esistere prima di qualsiasi badge Live su classi di messaggi rich o SMS; prima il catalogo, poi i volumi.
Un badge Live su una classe di messaggi senza un catalogo di modelli approvato è una spesa prepagata bruciata con un chip verde. Gli acquirenti necessitano di un catalogo denominato di modelli di produzione prima che le vendite dichiarino Live per le classi rich o SMS. Questa pagina rappresenta tale percorso acquirente — non un'analisi approfondita di un vault né una lista della spesa API SMS generale.
Il catalogo è il gate Live per le classi di messaggi
Live significa che la classe può accettare volumi prepagati con uno stato onesto. Catalogo significa che ogni ID di modello di produzione è elencato, approvato, posseduto e mappato a una classe di unità prima dell'invio. Failover e pista potrebbero sembrare pronti, eppure Live su WhatsApp, RCS o SMS con modello rimane bloccato finché la riga del catalogo non esiste.
Cosa contiene una riga di catalogo approvata
| Campo | Perché importa agli acquirenti |
|---|---|
| ID modello + versione | Stesso oggetto che prodotto e finanza riconciliano |
| Classe di messaggio (OTP, alert, notice) | Evita la contaminazione della classe nel testo di marketing |
| Stato di revisione | Solo approvato: le bozze non vanno mai in Live |
| Classe di unità | Segmento, sessione o unità di modello prima dell'addebito |
| Proprietario + regola di ritiro | Chi corregge |
Canale Live e catalogo Live sono chip differenti
Un canale può trovarsi in configurazione mentre i modelli vengono abbozzati. Un catalogo può essere approvato per OTP mentre i modelli di marketing rimangono in bozza. Non unire i chip: canale pronto ≠ «qualsiasi modello può inviare». Il blocco prepagato fallisce in modo chiuso su ID sconosciuti — riserva prepagata prima del primo addebito.
Percorso acquirente prima di qualsiasi badge Live
- Elenca i modelli del primo mese per classe di messaggi.
- Invia per la revisione; attendi «Approvato», non «sembra a posto».
Checklist dell'acquirente per il catalogo di modelli
- Ogni ID modello ha una classe di unità assegnata?
- Il proprietario del catalogo è definito per ogni riga?
- Le bozze sono state rimosse dalla produzione?
Inizia con IOSOR
Apri la console IOSOR e verifica i tuoi ID modello attivi rispetto agli stati del catalogo approvati prima di tentare qualsiasi transazione sul canale Live. Assicurati che ogni classe di messaggio abbia un abbinamento di modelli esplicito e una classe di unità verificata associata al proprio blocco di addebito.
- Validazione dei payload delle variabili di modello prima dell'invio per evita…
- Verifica degli asset di intestazione Rich Media prima dell'invio dei template
Sintesi IOSOR
La prontezza del canale e l'approvazione del catalogo dei modelli operano su barriere di esecuzione distinte. Contrassegnare un canale come operativo senza ID modello espliciti e approvati nel catalogo causa il blocco dei sistemi di addebito prepagato su payload non mappati, indipendentemente dallo stato del gateway sottostante.
Questa guida ti è stata utile?
Guide correlate
- Gestione dei re-invii massivi di template durante le sequenze di ripristino
Impara a verificare sistematicamente i corpi dei template modificati in seguito agli aggiornamenti delle policy degli operatori nell'ecosistema IOSOR per mantenere alti tassi di consegna.
- Verifica degli asset di intestazione Rich Media prima dell'invio dei template
Impara a convalidare le immagini di intestazione e gli URL dei documenti in IOSOR per evitare il rifiuto dei template. Assicurati che i tuoi asset rispettino gli standard di conformità.
- Sincronizzazione dei modelli di messaggi approvati in ambienti di sub-account
Padroneggia l'orchestrazione dei modelli approvati all'interno di un ecosistema CPaaS white-label. Impara a mantenere un isolamento rigoroso dei dati garantendo al contempo la conformità dei sub-account e una rapida implementazione tramite il provisioning JIT.