IOSOR Guias
Catálogo de modelos antes do canal Live
Caminho do comprador: modelos aprovados devem existir antes de qualquer badge Live em classes ricas ou SMS — catálogo primeiro, volume depois.
Um badge Live em uma classe de mensagem sem um catálogo de modelos aprovado é queima de pré-pago com chip verde. Os compradores precisam de um catálogo nomeado de modelos de produção antes que as vendas digam Live para classes ricas ou SMS. Esta página é esse caminho do comprador — não uma imersão profunda em cofre nem uma lista de compras de API de SMS geral.
O catálogo é a porta Live para classes de mensagem
Live significa que a classe pode aceitar volume pré-pago com status honesto. Catálogo significa que cada ID de modelo de produção está listado, aprovado, sob propriedade e mapeado para uma classe de unidade antes do envio. Failover e pista podem parecer prontos, mas o Live no WhatsApp, RCS ou SMS com modelo permanece bloqueado até que a linha do catálogo exista.
O que uma linha de catálogo aprovada carrega
| Campo | Por que os compradores se importam |
|---|---|
| ID do modelo + versão | O mesmo objeto que produto e finanças conciliam |
| Classe de mensagem (OTP, alerta, aviso) | Impede sangramento de classe no texto de marketing |
| Estado de revisão | Apenas aprovado — rascunho nunca roda no Live |
| Classe de unidade | Segmento, sessão ou unidade de modelo antes do débito |
| Proprietário + regra de desativação | Quem conserta a rejeição e |
Canal Live versus catálogo Live são chips diferentes
Um canal pode estar Em configuração enquanto os modelos são rascunhados. Um catálogo pode ser aprovado para OTP enquanto os modelos de marketing continuam em rascunho. Não colapse os chips: canal pronto ≠ 'qualquer modelo pode enviar'. A retenção pré-paga falha fechada em IDs desconhecidos — reserva pré-paga antes do primeiro débito.
Caminho do comprador antes de qualquer badge Live
- Liste os modelos do primeiro mês por classe de mensagem.
- Envie para revisão; aguarde por 'Aprovado', não por 'parece bom'.
Checklist do comprador para catálogo de modelos
- Cada ID de modelo tem uma classe de unidade atribuída?
- O proprietário do catálogo está definido para cada linha?
- Os rascunhos foram removidos da produção?
Comece com a IOSOR
Abra o console da IOSOR e verifique seus IDs de modelo ativos com os status do catálogo aprovado antes de tentar qualquer transição de canal Live. Certifique-se de que cada classe de mensagem tenha um mapeamento de modelo explícito e uma classe de unidade verificada anexada ao seu portão de débito.
- Validacao de variaveis de modelo antes do envio para evitar rejeicoes silenci…
- Verificação de ativos de cabeçalho Rich Media antes da submissão de templates
Conclusão IOSOR
A prontidão do canal e a aprovação do catálogo de modelos operam em portões de execução distintos. Marcar um canal como operacional sem IDs de modelo explícitos e aprovados no catálogo faz com que os sistemas de retenção pré-paga falhem ao processar cargas não mapeadas, independentemente do status do gateway subjacente.
Este guia foi útil?
Guias relacionados
- Gerenciamento de reenvios em massa de templates durante sequências de recuperação
Aprenda a verificar sistematicamente os corpos dos templates modificados após atualizações de políticas de operadoras no ecossistema IOSOR para manter altas taxas de entrega.
- Verificação de ativos de cabeçalho Rich Media antes da submissão de templates
Aprenda a validar imagens de cabeçalho e URLs de documentos no IOSOR para evitar a rejeição de templates. Garanta que seus ativos cumpram os padrões de conformidade.
- Sincronização de modelos de mensagens aprovados em ambientes de subcontas
Domine a orquestração de modelos aprovados dentro de um ecossistema CPaaS white-label. Aprenda a manter um isolamento de dados rigoroso enquanto garante a conformidade das subcontas e a implantação rápida via provisionamento JIT.