Padronização de Numeração e Impacto no Fluxo de Proativos
Inconsistência de Padronização Telefônica:
Ausência do Nono Dígito no Banco de Dados
Introdução
No ecossistema de atendimento Omnichannel, a precisão dos dados cadastrais é fundamental para a automação de processos, especialmente no que diz respeito ao Karoo Bot e ao disparo de mensagens proativas. Recentemente, foi identificado um problema técnico onde mensagens não estavam sendo processadas corretamente devido a inconsistências na formatação dos números de telefone no banco de dados.
Descrição do Problema
O problema central residia na existência de registros duplicados ou mal formatados, especificamente números de telefone sem o nono dígito. Conforme discutido em nosso histórico de conversa, o padrão do sistema Omnichannel exige que todos os números possuam o nono dígito para garantir a integridade da comunicação.
A presença de números sem essa formatação pode gerar falhas críticas, como:
• Falha na identificação de contexto: O sistema pode não reconhecer um "contexto de conversa ativo" se o número estiver formatado incorretamente, o que é o requisito básico para o envio de proativos.
• Erros de Rescheduling: Se o sistema não valida o número corretamente, ele pode falhar ao colocar o proativo em stand by ou ao calcular o tempo de espera do cron (60 minutos para Karoo Chat e 15 minutos para Karoo Bot).
Análise e Solução
De acordo com o relato técnico em nosso histórico de conversa, a solução aplicada foi a limpeza e remoção de números sem o nono dígito no banco de dados.
Esta ação visa alinhar a base de dados ao comportamento esperado do motor de envio. Quando um canal está operando corretamente (status "open"), o sistema prioriza o envio de proativos pelo mesmo canal do reativo. Contudo, se a informação do destinatário (o número) estiver fora do padrão, o disparo pode ser interrompido ou resultar em um erro 400 (bad request), similar ao que ocorre quando não há canais válidos vinculados.
Recomendações e Melhores Práticas
Para evitar que este problema retorne e para garantir a saúde da operação, as seguintes diretrizes das fontes devem ser seguidas:
1. Padronização na Origem: Garantir que integrações externas (como eContador, Immobile ou Google Agenda) enviem os números já formatados com o nono dígito para evitar que a operação seja rejeitada pelo endpoint.
2. Uso de Números Exclusivos: Para clientes com alto volume de conversas, o aconselhamento é utilizar um número exclusivo para proativos e outro para atendimento, minimizando o risco de denúncias e bloqueios.
3. Monitoramento de Status: Manter a atenção ao status dos canais no Configurador. Proativos só são disparados se o cron identificar canais válidos com status "open".
Nota Informativa: A informação específica sobre a solução técnica de remoção dos números sem o "9" no banco de dados foi extraída diretamente do nosso histórico de conversa e não consta explicitamente nos documentos de treinamento fornecidos. Recomenda-se verificar se há scripts de validação automática para novas entradas de dados.
-
-
1. Impacto na Identificação e Fluxo de Proativos
O campo
contactIdentifier é crucial para as validações de regras de negócio. Segundo as fontes, o disparo de um proativo depende inteiramente de verificar se existe um "contexto de conversa ativo para o número daquele cliente".• Se o
contactIdentifier ficar vazio no banco de dados, o sistema perde a referência necessária para consultar a tabela talk_context ou validar se o número já está em atendimento.• Isso impossibilitaria o funcionamento correto do reagendamento, pois o sistema não conseguiria identificar a "última interação da mensagem trocada" para respeitar os tempos de 15 ou 60 minutos.
2. Conflito de Integridade e Erros de Plataforma
O erro mencionado (Karoo One Chat com Erro 500 e Karoo Enterprise com 10404) indica uma falha crítica na camada de aplicação do OMC ao lidar com dados nulos/vazios onde se espera uma chave única.
• Conflito de Gravação: Como você descreveu, ao tentar salvar um segundo contato com o campo vazio, ocorre um conflito. Em sistemas de banco de dados, campos de identificação costumam ter restrições de unicidade (unique constraints).
• Diferença de Retorno: Nas fontes, erros de configuração de integração (como falta de canal
whatsappweb ou token inválido) costumam retornar 400 Bad Request. Os erros 500 e 10404 reportados na issue são mais graves e confirmam que o problema está no processamento interno (OMC) e não em uma simples falha de configuração de usuário.3. Relação com Integrações Oficiais
A issue destaca que o problema ocorre em contas que possuem apenas integrações oficiais e nenhum canal web.
• As fontes indicam que, para integrações externas (eContador, Immobile, etc.), o sistema busca especificamente por canais ativos.
• Se o
contactIdentifier (que deveria mapear a origem da integração oficial) é apagado, o fluxo de consulta de canais válidos descrito no treinamento (como o status "open" no /connections/:senderId) pode ser quebrado, impedindo que o cron de envio identifique o destinatário correto.4. Paralelo com a Lógica Bimer
Em integrações como a do Bimer, a identificação é feita via CPF/CNPJ para buscar o
idpessoa.• Se o OMC falha em manter o identificador do contato, processos automatizados de consulta — como a chamada para
api/pessoas?cpfCnpj='documento' — perderiam sua "âncora" de dados, resultando em falhas similares às descritas quando não há cadastro ou o título não é listado.Observação: As informações sobre a issue OMC-1636, os códigos de erro 500/10404 e o comportamento específico do campo contactIdentifier ao editar contatos não constam nas fontes de treinamento fornecidas; elas foram extraídas diretamente da sua consulta para esta análise.