Estratégia de cobrança versionada: quatro olhos, congelamento e rollback
Pergunte a uma área de cobrança quem mudou a régua no mês passado, o que mudou e com que base. Na maioria das operações, a resposta é um campo de configuração sobrescrito: sem histórico, sem comparação com a versão anterior e sem carimbo de quem mudou. Para uma cobradora pequena, isso é um incômodo. Para um banco, é um problema de governança: mudar a estratégia de cobrança é um ato com efeito financeiro e regulatório.
O jacob labs trata a estratégia de cobrança como se trata código num banco: cada mudança é uma versão, com diff, revisão de outra pessoa, publicação assinada e caminho de volta.
A estratégia como objeto, e não como campo
No jacob labs, a estratégia de cobrança pertence a um grupo de credores e existe como um objeto com versão, impressão digital (hash), estado, diff e trilha. A champion é a versão que vale: tudo o que o jAcob faz de madrugada, da fila do discador aos lotes do dia, sai dela.
A partir do momento em que é validada, a versão é um retrato imutável: o grupo, o número, a versão de origem, o texto em português com a sua impressão digital, as regras compiladas, quem escreveu, quem validou, quem aprovou, quem publicou, com datas, vigência e motivo.
Do rascunho à champion
Rascunho: a régua em português
A equipe escreve a régua em português, na própria tela: custo de cada contato, faixas de atraso, canais e cadência por faixa, horário, quem não é acionado, prazos de negativação e jurídico, terceirização, descontos. A IA compila o texto em regras com formato versionado, e o motor lê as regras, não o texto. O compilador só usa nomes de um catálogo fechado e sinais que a instância realmente mede.
Validada: a lista inteira de erros
Antes de propor, a versão passa por um validador que devolve a lista inteira de erros e avisos. Erro barra a proposta; aviso alerta.
A validação de uma versão: 0 erros e 17 avisos, cada um com o código e a explicação, antes de propor. Base de demonstração; o nome do credor foi trocado por XPTO.
Em aprovação: o aprovador lê o diff
O aprovador não lê regra compilada: lê o diff contra a versão anterior, chave a chave, com o que foi adicionado, removido e alterado.
O diff da versão 3 contra a 2: uma chave alterada, o máximo de telefones por cliente por dia, de 3 para 1. Base de demonstração; o nome do credor foi trocado por XPTO.
Quem propõe não aprova. O quatro olhos é configurável por instância e por grupo: nasce ligado na versão do credor, e a trilha de quem desenhou, aprovou, ligou e encerrou é obrigatória mesmo com ele desligado. O grupo pode exigir que um dos aprovadores represente o credor. E silêncio não aprova: a proposta expira pelo prazo de aprovação, 48 horas por padrão, e volta ao estado anterior.
Quer ver a sua régua com essa governança? Solicite um diagnóstico operacional.
Champion: publicar é ato assinado
Todo ato com efeito (publicar, ligar um teste, promover, abortar, rollback, ligar o grupo de controle) exige uma credencial de uso único: quem assina informa login e senha na hora, a credencial vale por no máximo dois minutos, nasce amarrada ao objeto e ao que está sendo assinado, e é consumida na própria transação. Com os quatro olhos ligados, o assinante tem de ser outra pessoa que não o proponente.
A assinatura de um ato: o que vai acontecer, quem será avisado, a credencial de quem assina e o motivo, que vai para a trilha. Base de demonstração; teste simulado.
O congelamento da virada do mês
Fim e começo de mês são os dias em que a cobrança menos pode errar. Por isso existe o congelamento: N dias no fim e N no início de cada mês, configuráveis, em que ninguém publica nem liga teste. Há também congelamentos avulsos, por grupo ou de todos, com motivo e vigência. As regras valem dentro de cada procedimento do banco de dados, não só na tela.
A governança da instância: quatro olhos, congelamento no fim e no início do mês e prazo de aprovação. Base de demonstração.
O rollback: um ato só
Quando uma versão publicada dá errado, o caminho de volta não pode depender de reescrever a régua às pressas. O rollback de emergência é um ato só, com motivo e assinatura, que deixa trilha. Ele é o único atalho do processo: ignora o congelamento e o quatro olhos, porque existe para a emergência.
A trilha que o auditor lê
A trilha registra cada passo de cada versão: criada, validada, proposta por uma pessoa, aprovada por outra, publicada ou designada challenger de um teste, sempre com o motivo.
As versões de um grupo e a trilha de uma delas, com quem fez cada ato, quando e por quê. Base de demonstração; o nome do credor foi trocado por XPTO; o teste da versão é simulado.
Sem o laboratório, nada muda
Uma preocupação comum de quem liga um módulo novo é o efeito colateral. O jacob labs foi construído para não ter nenhum: uma instância sem o módulo, com ele desligado ou sem teste vivo, produz a mesma fila, o mesmo plano e os mesmos lotes, só com os carimbos de versão preenchidos. E toda chave nova da régua, quando ausente, mantém o comportamento de hoje: chave nova nunca cria mensagem, só segura ou escolhe.
Os painéis do revo360 Analytics em 2 minutos, do Cockpit ao jacob labs, onde a régua de cobrança vira estratégia versionada. Base de demonstração, dados fictícios.
O que a governança muda na prática
- “Quem mudou a régua?” passa a ter resposta. A trilha diz quem propôs, quem aprovou, quem publicou e quando.
- A mudança é revisada antes de valer. O aprovador lê o diff, e quem propõe não aprova.
- A virada do mês fica protegida. Ninguém publica nem liga teste no congelamento.
- O erro tem volta. O rollback é um ato só, assinado.
- A mudança pode ser testada antes. Uma versão nova pode entrar como challenger num teste champion x challenger antes de virar champion.