Solicitar diagnóstico operacional

Por que este cliente não foi cobrado hoje: o log de decisão e o "por que não"

revo360

Capa: por que este cliente não foi cobrado hoje, ao lado da tela Decisões de hoje do jacob labs, com as decisões do dia por ação e os motivos de nenhuma ação, marcada como simulação

Numa auditoria, ou na reunião mensal com o credor, a pergunta que dói não é “o que a cobrança fez”: o painel de acionamentos responde a essa. É “por que este cliente não foi cobrado neste dia?”. A maioria das operações responde com reconstrução: alguém abre a régua, o histórico de mailing e a blocklist, e deduz. A resposta chega dias depois e sem prova.

No revo360, a resposta sai do registro, em dois lugares. Nas campanhas, o jAcob grava, no momento em que decide, uma decisão por cliente, por ação e por dia, com o motivo de cada “não”. Na fila da equipe, o motor que executa a régua escrita em português grava, na mesma rodada, quem ficou de fora e por quê.

Uma decisão por unidade, por ação, por dia

O jacob labs registra uma decisão por unidade (cliente ou título), por ação e por dia, na mesma transação em que monta a fila, o plano, a terceirização e o lote. Não é um relatório montado depois: o log nasce junto com a decisão. O painel Decisões de hoje mostra o que foi decidido por grupo de credores, credor, braço do teste e ação; por que cada “não”; o que saiu de verdade; onde um teste interfere no outro; e a prova de que nada sumiu nem dobrou.

Infográfico: as seis perguntas que o log de decisão do jacob labs responde: o que foi decidido, por que não, planejado x executado, conflitos, a soma bate e por que este cliente

Tela do jacob labs: o painel Decisões de hoje, com as decisões do dia por ação (discador preditivo, SMS, e-mail, WhatsApp, ligação manual e nenhuma ação), o grupo de credores e o bloco Por que NÃO, com os motivos de nenhuma ação por classe

As decisões de um dia por ação, com “nenhuma ação” por último, e o bloco “Por que NÃO” com os motivos do catálogo por classe. Simulação; base de demonstração, dados fictícios; o nome do credor foi trocado por XPTO.

Vale saber: a árvore conta decisões, não pessoas. O mesmo cliente decidido para SMS e para WhatsApp aparece duas vezes.

O “por que não”, num catálogo fechado

Toda decisão de “nenhuma ação” carrega um motivo de um catálogo fechado, agrupado por classe: regime da régua, exclusão depois de alocado, capacidade e janela, governança do laboratório. Repique digital, voz segurada até o contato com a pessoa certa, em assessoria, promessa vigente, pagou recentemente: cada um é um código, com rótulo e classe, e não um texto livre.

O catálogo é fechado de propósito. Um motivo fora dele é recusado pelo registro, o plano é refeito sem log e o gerador de lotes barra o grupo que está em teste. Quando um teste vivo não tem log no dia, o painel abre com uma manchete crítica: nada sai sem atribuição.

É esse log que sustenta a intenção de tratar do teste champion x challenger: quem foi sorteado para um braço e depois não pôde ser acionado continua no braço, com o motivo registrado.

Planejado x executado, apurado em dois dias

Planejadas são as decisões com ação; executadas, as que viraram lote autorizado e processado, mailing efetivado ou histórico gravado, apuradas dois dias depois pela escada de atribuição. Hoje e ontem aparecem como “em apuração”, nunca como zero por cento executado, e a série dos últimos dias mostra onde planejado e executado se afastam.

Conflitos, e a prova de que a soma bate

Um cliente pode estar em no máximo um teste por camada. Conflito é a mesma unidade alocada em dois lugares: entre dois grupos de credores, entre o grupo de controle e um teste, ou entre um teste de régua e um teste de lote. O painel lista cada um com o tipo e desde quando existe, monta uma tabela cruzada por par de testes e não decide nada: mostra o desvio contra o esperado se os dois fossem independentes.

A soma bate é a prova por grupo: a população decidida é igual a champion mais grupo de controle mais testes; cada teste é a soma dos seus braços; as decisões com ação são iguais às planejadas da execução. Quando falta o dado da execução, a tela escreve “não conferido”. Nunca escreve “bate” sem conferir.

Quer ver o log de decisão sobre a sua carteira? Solicite um diagnóstico operacional.

“Por que este cliente”: o detalhe pelo hash

O detalhe se pede pelo hash da unidade ou pelo id do título, e devolve as decisões daquela unidade no dia e o histórico dos últimos 30 dias: braço, ação e o motivo de cada “não”. A unidade é um hash do documento com sal da instância, uma referência opaca; cliente e título são ids; nome, CPF e telefone não aparecem. O detalhe exige permissão própria, a exportação deixa linha na trilha e na auditoria, e a Môzi recebe só agregados.

Um ato só: reprocessar o dia

O painel é de leitura, com uma exceção: reprocessar o dia de um grupo. O ato simula e diz antes o que vai fazer, exige a credencial de uso único de quem assina e um motivo, cancela os lotes do jAcob do dia ainda não autorizados do grupo e refaz a alocação, a fila e os lotes; as rodadas anteriores ficam marcadas como substituídas, não somem. O agregado é fechado pelo ciclo da madrugada, e a tela não se atualiza sozinha.

Na fila da equipe: quem ficou de fora

O log do jacob labs é das campanhas. Na estação do negociador, a fila sai de outra régua: a que a equipe escreve em português, que a IA converte em regras uma vez, a pedido do supervisor, e que um motor determinístico executa a cada 15 minutos, sem modelo de linguagem (o passo a passo está em IA na operação de cobrança).

A pergunta “por que este contrato não está na fila?” tem duas telas irmãs, Quem ficou de fora: na fila de trabalho do Collection Omni Studio e na distribuição da carteira. Quem decide é o motor, e o diagnóstico é dele: o motivo é gravado na rodada de diagnóstico que o supervisor pede (na distribuição, a prévia), com a mesma lógica da rodada que monta a fila, e as telas só leem o último diagnóstico. Nada reavalia a régua para explicar, porque divergiria do motor no primeiro detalhe: dia útil, valor nulo, tolerância da promessa, um contrato por cliente.

Infográfico: os motivos de um contrato ficar fora da fila da equipe: guarda, trabalhado, exclusão, nenhum passo, teto e quase entrou, com o que cada um significa e o que a tela mostra

  • Guarda: contrato em assessoria, suspenso, com retorno marcado ou sem saldo não entra, diga a régua o que disser.
  • Trabalhado: já foi feito, está no intervalo, ou outro contrato do mesmo cliente já está na fila.
  • Régua: uma exclusão pegou o contrato, ou nenhum passo o pegou. A tela mostra o critério que decidiu, com o valor do contrato ao lado do que o passo pede.
  • Teto: um passo pegou, mas a posição passou do teto da equipe.
  • Quase entrou: o contrato cumpriu ao menos um critério de um passo e falhou em um só. É o buraco da régua.

Valor nulo nunca vira zero, e o atraso é o que o motor usou, em dias úteis. Os filtros são credor e equipe, a tela abre consultando o último diagnóstico, e o supervisor vê o detalhe só dos contratos que hoje estão com a equipe dele; a mesma leitura é uma aba no editor da régua. Na distribuição há ainda a lente “nenhuma régua pega”: o contrato que a régua de equipe nenhuma alcança, cruzando as prévias de todas as equipes da mesma rodada, com a barreira que o segura. Um contrato fica numa equipe só, e a soma das partes é a carteira.

O que muda na auditoria

  • “Por que não?” sai do registro, não da reconstrução, com motivo de catálogo fechado.
  • Planejado e executado são conferidos dois dias depois, e a soma bate ou a tela diz que não conferiu.
  • A régua da equipe se explica com o critério e o valor do contrato.
  • Sem dado pessoal no laboratório; na fila, o detalhe só para quem tem a equipe.

Solicite um diagnóstico operacional: mostramos o log de decisão e o quem ficou de fora sobre uma amostra da sua carteira.