Ir para o conteúdo principal

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 Contexto: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 de telefone sigampossuam o padrão de 9nono dígitos.

    gito
    • para
  • garantir

    Problema:a Inconsistênciaintegridade nada basecomunicação.

de dados causada pela
A presença de números antigossem ouessa malformatação formatadospode quegerar falhas críticas, como:
• Falha na identificação de contexto: O sistema pode não possuíamreconhecer 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.

gito no
  • banco

    Soluçde dados.

    • Esta ação Aplicada:visa Limpezaalinhar 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 atravésfoi extraída remoçãodiretamente manual/automatizadado dosnosso registroshistórico de númerosconversa quee não continhamconsta explicitamente nos documentos de treinamento fornecidos. Recomenda-se verificar se há scripts de validação nonoautomática dígito,para garantindonovas aentradas conformidadede comdados.

    -
    1. Impacto na Identificação padrão exigido pela plataforma.

  • Status: Concluído e testado.Fluxo


    Resumode da conversa com o time do desenvolvimento:


    Guilherme Gomes (no Tarefas)
    ,
    10:44Proativos

    O
    campo
    contactIdentifier
    Assignedé acrucial taskpara toas @Guilhermevalidações Gomesde (viaregras Tasks)
    de
    Guilhermenegócio. GomesSegundo
    ,as
    10:44
    fontes,


    teste
    Guilherme Gomes
    ,
    10:55


    Mano, está feito, quando puder, só testar aí
    Você
    ,
    6 min


    Resolvido mano!
    Guilherme Gomes
    ,
    4 min


    Top! Mesmo estando cientes, só pra complementar: A solução foidisparo apenasde removerum proativo depende inteiramente de verificar se existe um "contexto de conversa ativo para o número semdaquele 9cliente".
    • Se o contactIdentifier ficar vazio no banco,banco vistode 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 padrãproblema está no processamento interno (OMC) e não doem omnichanneluma ésimples terfalha todosde osconfiguração númerosde com 9.
    usuário    .
    Guilherme3. GomesRelação (nocom Tarefas)Integrações
    ,
    4 minOficiais

    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.

    Completed a task (via Tasks)