CheckNumber.AI · 6 min read
Após uma verificação de suporte ao RCS: preparando o lançamento do seu negócio
Transforme os resultados da lista de RCS em um plano de lançamento: verifique a prontidão do remetente, teste o fallback de SMS e meça a entrega separadamente.
Uma verificação de suporte ao RCS ajuda você a planejar quais contatos podem ser adequados para mensagens ricas. Antes do lançamento, verifique a disponibilidade do seu próprio remetente nas redes pretendidas, teste a mensagem e seu fallback de SMS, e colete os resultados de entrega do seu provedor de mensagens.
Comece com a mensagem que seu cliente precisa
Uma atualização de entrega é um ponto de partida útil. Seu cliente precisa de uma janela de chegada e de uma maneira de alterar as instruções de entrega. O RCS pode apresentar essas opções como conteúdo mais rico; o SMS precisa comunicar as informações essenciais em texto. O requisito de negócio é o mesmo, independentemente do canal que o transporta.
Nosso Verificador do RCS ajuda a identificar números com um sinal de suporte ao RCS em uma lista carregada. Use essa observação para estimar um público para a versão rica e preparar uma alternativa adequada. Mantenha a data da observação ao lado do número para que uma campanha posterior não herde silenciosamente uma suposição antiga.
Decida qual parte da mensagem é essencial antes de organizar um teste de lançamento. Se a data de entrega mudar, ambas as versões devem transmitir a nova data. Um cartão rico bem elaborado faz pouco por um cliente que recebe um fallback de texto desatualizado.
Conecte o arquivo de suporte ao seu remetente real
O suporte no nível do número e a prontidão de um remetente comercial respondem a perguntas diferentes. O CheckNumber fornece uma observação para planejamento. Seu provedor de mensagens estabelece se o seu agente específico pode atender ao destino pretendido e se o conteúdo solicitado é suportado.
A orientação de envio do RCS for Business do Google identifica falhas separadas para dispositivos não suportados, agentes que não foram lançados na rede de um destinatário e recursos de mensagem que um dispositivo não pode usar. Uma observação positiva na lista, portanto, deixa uma questão real de lançamento: este remetente pode entregar esta versão da mensagem através da sua rota configurada?
Peça ao seu provedor para confirmar o status de lançamento do agente para os mercados e redes em questão. Teste com a configuração de remetente de produção pretendida para a campanha, em vez de presumir que uma demonstração de desenvolvimento prova o mesmo alcance. Onde um ambiente de teste for diferente, anote essa diferença antes de julgar o resultado.
Nosso verificador pode incluir contexto de sistema documentado, mas não detecta a operadora do número. Obtenha informações de rede e remetente através das ferramentas apropriadas do provedor de mensagens. Isso dá a cada decisão uma fonte utilizável sem tentar estender a exportação da lista para um relatório de configuração de remetente.
Torne o fallback uma mensagem completa para o cliente
Prepare a versão SMS enquanto escreve a versão RCS. Mantenha a referência do pedido, a janela de chegada alterada e a próxima ação útil. Substitua qualquer interação rica por uma alternativa de texto que sua jornada de cliente existente possa lidar. Revise como a mensagem é lida por conta própria; o destinatário não deve precisar do cartão rico ausente para entendê-la.
O fallback também precisa de um originador funcional. A documentação de fallback de RCS da AWS, por exemplo, exige um número de telefone ou ID de remetente dedicado e elegível para o destino; sua configuração de pool e conta determina qual identidade pode ser usada. Outras implementações de provedores precisam de suas próprias verificações. Confirme os requisitos equivalentes no serviço escolhido, em vez de tratar “fallback ativado” como a configuração completa.
Use contatos de teste que exercitem os caminhos importantes: uma mensagem rica bem-sucedida, um destino não suportado e um dispositivo temporariamente inalcançável onde seu provedor suporte um teste adequado. Verifique o remetente visível, o texto, o link de destino e o resultado final da entrega. Uma solicitação de envio aceita por si só não pode dizer se o cliente recebeu uma mensagem útil.
Escolha o que acontece com uma atualização não entregue
Uma mensagem promocional atrasada e uma atualização de entrega expirando precisam de tratamentos diferentes. Defina um tempo de vida útil para as informações do cliente e, em seguida, concorde sobre como seu sistema de envio lida com mensagens ainda pendentes naquele momento. O Google documenta a expiração e revogação de mensagens em conexão com o fallback; a implementação pertence à sua pilha de mensagens.
Analise um atraso na entrega durante o teste. Se o SMS já entregou a janela de chegada revisada, o que impede que uma atualização de RCS antiga na fila confunda o cliente? Verifique a expiração real, a revogação e o comportamento de eventos do provedor antes de escolher o tempo. Não infira o cancelamento bem-sucedido apenas porque um temporizador de aplicativo foi disparado.
Este exercício também esclarece quais eventos seu aplicativo deve reter. Preserve a referência da mensagem do sistema de envio e o resultado do canal para que uma notificação de entrega posterior possa ser vinculada à mesma atualização. Sua equipe pode então investigar uma mensagem atrasada sem precisar executar novamente a verificação de público para responder a uma pergunta não relacionada.
Mantenha as observações de planejamento e os resultados de entrega separados
Uma entrega de lançamento útil contém o público verificado, a data da verificação, a cobertura confirmada do remetente, as versões de mensagem testadas e o comportamento de fallback escolhido. Registre quais incertezas restantes exigem uma verificação do provedor antes de expandir o público.
Após o lançamento, meça a entrega, as falhas, a expiração e o fallback a partir da telemetria de mensagens. Mantenha as respostas e as ações concluídas do cliente em suas próprias colunas. A contagem de números suportados é um insumo de planejamento; a contagem de atualizações de entrega entregues é um resultado operacional. Mostrar ambos permite que a equipe identifique se um problema surgiu antes do envio, em uma rota ou na experiência da mensagem.
Comece com uma atualização completa para o cliente e seu fallback, depois leve a mesma preparação para o próximo tipo de mensagem. Use a documentação do CheckNumber para preparar a verificação de suporte e leve o arquivo de público resultante para os testes de remetente que determinam sua prontidão para o lançamento.
