5 IAs para cobrança: o que cada uma faz — e com quem cada uma fala
“IA para cobrança” virou uma coisa só no discurso do mercado. Na prática são problemas diferentes, e um agente genérico não resolve nenhum deles direito: decidir quem trabalhar numa carteira de milhões de reais é estatística; negociar com um devedor é conversa; apoiar quem negocia é síntese somada ao trabalho chato de registrar o que foi feito; medir a qualidade de um atendimento é julgamento com critério; explicar por que o número do mês caiu é análise — e executar a decisão que veio dessa análise é outra coisa ainda.
No REVO360 essas cinco tarefas têm cinco agentes, e o que separa um do outro não é a tecnologia — é com quem cada um fala.
| Fala com | Entrega | |
|---|---|---|
| jAcob | a carteira | quem trabalhar primeiro, por qual canal, a que hora e com quanto de desconto |
| Sarah | o cliente final | negocia no WhatsApp, do primeiro “olá” até o boleto emitido |
| Simmone Copilot | o operador | o raio-X do devedor — e tabula, agenda e registra a ocorrência por ele |
| Simmone QA | o supervisor | nota de 0 a 100, com justificativa, dos atendimentos |
| Môzi | o gestor | duas caras: a que lê o painel e explica, e a que opera o sistema pelo chat |
Só uma das cinco conversa com o cliente. As outras quatro são proibidas disso — não por política de uso, mas por desenho: elas não têm por onde. Vale começar por aí, porque é a primeira pergunta que todo mundo faz.
1. jAcob — a IA que fala com a carteira
O jAcob (C.O.R.E., de Credit Optimization & Recovery Engine) é a única das cinco que não conversa com ninguém. Ele lê a carteira inteira e responde a pergunta que antecede todo o resto: numa carteira que tem mais dívida do que operador, o que se trabalha primeiro?
Para cada contrato ele estima duas probabilidades:
- probabilidade de cura — a chance de aquele contrato voltar à normalidade dentro de uma janela de tempo definida;
- propensão a pagar — a chance de haver pagamento dentro dessa janela.
E só. Tudo o que a operação vê depois — persona do devedor, canal sugerido, melhor horário, desconto máximo, ordem de execução por valor esperado — não é saída de modelo. É regra determinística aplicada sobre essas duas probabilidades.
Essa separação parece um detalhe técnico e é o contrário disso: é o que torna o motor auditável. Quando alguém pergunta “por que este contrato está no topo da fila?”, a resposta tem duas metades verificáveis — a probabilidade veio do modelo, a posição veio de uma regra que está escrita e pode ser lida. Modelo que decide sozinho, do score à ação, é modelo que ninguém consegue explicar ao credor numa reunião.
Como ele é construído, em termos práticos:
- Feature store point-in-time. As características de cada contrato são materializadas na data do snapshot, e o rótulo só entra quando maturou. É o cuidado que evita o erro clássico do ML em cobrança — treinar com informação que, na vida real, ainda não existia no momento da decisão. Modelo com esse vazamento parece excelente no papel e falha na produção.
- Validação out-of-time e calibração. O modelo é testado num período posterior ao do treino, e a probabilidade passa por calibração — sem isso, um score 82 não significa “82 em cada 100 pagaram”, significa apenas “está mais para cima na fila que o 40”.
- Registro versionado de modelos. Cada versão fica guardada com o campeão apontado. Trocar de modelo é uma decisão registrada, não um arquivo sobrescrito.
- Monitoramento contínuo. Um monitor mede desvio de distribuição, defasagem e prevalência real, e avisa quando o modelo começa a se descolar da carteira que está vendo agora.
O que o jAcob não faz: não fala com cliente, não decide sozinho o que a operação executa e não funciona onde não há história. Numa carteira nova, sem casos maturados suficientes para treinar, ele roda apenas a régua de melhor horário e canal — que é determinística — e o aprendizado de máquina entra quando a base existir. Preferimos dizer isso do que entregar um número bonito construído sobre nada.
Escrevemos um artigo inteiro sobre esse ponto — o que dá e o que não dá para prever numa carteira: Machine learning na cobrança.
Um parêntese honesto: a Hestia não é IA
No meio do caminho entre o jAcob e a Sarah existe a Hestia, o motor que dispara as campanhas em lote nos horários certos. Ela aparece muito no produto e não é inteligência artificial — é um agendador determinístico: roda a consulta cadastrada, respeita dia útil, feriado e janela de horário, e só executa lote que foi testado.
Podíamos contar seis IAs. São cinco. A régua “inteligente” é do jAcob; a Hestia é o relógio, e um relógio muito bom não vira IA por conveniência de marketing.
2. Sarah — a IA que fala com o cliente
A Sarah é a única que conversa com o devedor. Ela recebe a conversa roteada pelo WhatsApp, entende o cliente, apresenta a dívida com o valor daquele dia, negocia desconto e parcelamento dentro das regras do credor, fecha o acordo e emite o pagamento — PDF do boleto, linha digitável e PIX. Sem operador, a qualquer hora.
Abaixo está uma negociação inteira, como o cliente a vê no aparelho dele.
Passo 1 — ela abre, se identifica e pede o CPF. Devolve o documento mascarado: prova que consultou o cadastro sem expor o número inteiro.
Passo 2 — contrato, credor, dias de atraso e o valor atualizado na hora da conversa, não o que estava na carteira quando o arquivo entrou.
Passo 3 — à vista com desconto, ou parcelado. O cliente pede uma data fora do prazo; ela recusa, explica até quando a condição vale e devolve a escolha.
Passo 4 — fecha, registra o acordo e entrega o meio de pagamento na mesma conversa.
O passo 3 é o que mais surpreende quem assiste pela primeira vez: a Sarah diz não. E aqui está o princípio que sustenta a coisa toda:
Nenhum valor monetário vem do modelo. A IA não calcula desconto, não inventa parcela e não escolhe data. Ela seleciona entre as opções que o sistema calculou a partir da régua do credor. Se a condição vale até o dia 01, não existe caminho pelo qual a conversa produza o dia 03.
É a diferença entre uma IA que negocia e uma IA que improvisa. Operação de cobrança não sobrevive à segunda: um desconto alucinado vira acordo assinado, e acordo assinado é compromisso com o credor.
Como ela é construída: uma máquina de passos e campos a preencher — apresentar-se, mostrar o débito, negociar, aplicar desconto, confirmar, gerar acordo, gerar boleto, enviar. Cada passo tem sua instrução, o que fazer se der errado e quando entregar para um humano. O contexto vem de duas fontes: o playbook do agente e os documentos do próprio contrato. E se o modelo falhar por qualquer motivo, a conversa vai para um atendente — nunca vaza erro técnico para o cliente.
O que a Sarah não faz: não aparece para o operador (ela é autônoma, e quando precisa faz a transferência), não altera regra de crédito e não é a Simmone — que é a próxima.
3. Simmone Copilot — a IA que fala com o operador
A Simmone Copilot é a contraparte de dentro. Ela nunca fala com o cliente — ela trabalha ao lado de quem fala, na tela dele.
O OMNI Studio em ambiente de demonstração: fila, conversa e ficha na mesma tela — e a IA-Simmone no canto superior direito, esperando ser chamada.
Ela faz duas coisas, e a segunda é a que muda o dia do negociador.
Antes do contato, ela prepara. Lê dados do cliente, do credor e do contrato, o score de propensão do jAcob, as últimas ocorrências, os acordos, os boletos, as parcelas em aberto e até os anexos, e devolve um raio-X: quem é aquele devedor, o que o modelo prevê e qual o caminho mais provável de acordo. O operador tem segundos entre uma chamada e outra, e o histórico completo de um contrato não se lê em segundos.
Depois do contato, ela registra. Faz a tabulação do atendimento, cria a ocorrência e marca o agendamento do retorno. Esse é o trabalho que todo mundo subestima e ninguém gosta de fazer: terminada a ligação, o operador ainda precisa escolher o tipo de ocorrência, escrever o que aconteceu e agendar o retorno — e é justamente aí, com a próxima chamada esperando, que a tabulação vira “cliente pediu retorno” e o dado da operação apodrece. Relatório de cobrança é feito de tabulação; tabulação apressada é relatório errado.
O que a Simmone Copilot não faz: não fala com o cliente e não tira a decisão do operador — o que ela registra está na tela dele, para conferir e corrigir antes de valer.
4. Simmone QA — a IA que fala com o supervisor
Monitoria de qualidade em cobrança tem um problema aritmético: um monitor humano ouve algumas dezenas de atendimentos por mês, numa operação que faz dezenas de milhares. A amostra é minúscula, e o critério muda conforme quem ouviu e o dia que teve.
A Simmone QA é a analista de qualidade e monitoria da operação. Ela lê o que foi tabulado — texto de WhatsApp ou áudio transcrito — e devolve nota de 0 a 100 mais a justificativa da nota, com o mesmo critério, para todos os atendimentos do lote.
Repare no encaixe: a Simmone Copilot registra o atendimento, e a Simmone QA avalia o registro. Mesma família, lados opostos do mesmo evento.
Três decisões de projeto que importam mais do que parecem:
- A saída é estruturada, não texto livre. O modelo é obrigado a responder no formato
nota+razão. Não há como a avaliação virar um parágrafo simpático sem número, nem o número aparecer sem fundamentação. - A rubrica não é do modelo. O critério de avaliação vem do playbook configurado pela operação. Muda a política de atendimento, muda a rubrica — sem reescrever a IA.
- A nota fica registrada no contrato, junto com o texto avaliado. Uma nota que ninguém consegue rastrear até o atendimento que a gerou não serve para conversa de feedback.
O uso mais útil não é premiar ou punir. É que, com todos os atendimentos pontuados sob o mesmo critério, dá para separar problema de pessoa de problema de régua — um operador com nota baixa é treinamento, uma carteira inteira com nota baixa é abordagem errada.
O que a Simmone QA não faz: não fala com o cliente, não apoia em tempo real (isso é a Simmone) e não define sozinha o que é um bom atendimento. Ela é avaliação retrospectiva, com o critério que a operação escreveu.
5. Môzi — a IA que fala com o gestor
A Môzi tem duas caras, e vale separar: uma lê, a outra faz.
Môzi Data Science — a que lê
Um dashboard mostra números. Ele não diz por que mudaram, nem o que fazer a respeito. O gestor abre o painel, vê que a recuperação caiu, e começa a garimpar filtro por filtro atrás do motivo — quando tem tempo.
A Môzi Data Science lê exatamente o que está na tela e devolve a história por trás: manchete, narrativa, o que melhorou, o que piorou, quem é o ofensor, e um plano de ação amarrado a reais. Ela está embutida nos painéis, no mesmo lugar onde o dado já está — não é um relatório que chega por e-mail no dia seguinte.
- A leitura. Recebe os números agregados do painel — sem dado pessoal — e produz a análise, com regras de fidelidade que a proíbem de afirmar o que não está ali. Inclui um bloco de objeções, que é a Môzi bancando o advogado do diabo contra a própria leitura: onde este número pode estar enganando.
- A causa-raiz. Compara duas fotos da carteira em momentos diferentes e persegue a cadeia estoque → tratamento → execução → recuperação até isolar o ofensor, com o impacto estimado em reais. Precisa de pelo menos duas fotos para comparar: numa instância recém-implantada ela espera a série se formar, e avisa em vez de inventar.
A mesma leitura vale para o resultado de qualquer consulta do sistema: o grid de uma pesquisa vira conversa, e o cálculo roda sobre a planilha inteira — não sobre um resumo dela. É o que permite analisar centenas de milhares de linhas sem que o dado precise caber num prompt.
Môzi Copilot — a que faz
O Môzi Copilot é um chat que opera o sistema. Não é um assistente que explica onde fica o botão: ele tem hoje mais de setenta ferramentas ligadas à base do cliente, em frentes como consulta de carteira, propostas de exceção, templates de comunicação, perfis de e-mail e de SMS, higienização de contatos, montagem de mailing, devolução de contratos, régua do jAcob e cadastro de usuários, credores e equipes.
Veja o que acontece quando alguém digita uma frase vaga — “Preciso higienizar minha carteira”. A gravação abaixo é a conversa acontecendo, sem corte no meio:
Môzi Copilot em ambiente de demonstração — credores e números fictícios. Acelerado 2×: a resposta real levou cerca de 30 segundos, o tempo de ela consultar a base antes de falar.
Ele não respondeu com um texto explicando como higienizar. Ele montou a tela do trabalho — e, antes disso, foi conferir de que problema você estava falando. Escolhido o critério, o formulário chega completo:
O mesmo copiloto, um passo adiante — já com os credores da base e a contagem de cada um.
São quatro coisas acontecendo aí, e nenhuma delas é “responder bonito”:
- Traduziu a intenção em uma operação concreta. “Higienizar a carteira” virou levantar clientes sem CPC — o recorte que faz sentido antes de gastar dinheiro enriquecendo contato.
- Já foi buscar o dado real. A lista de credores não é um campo em branco esperando você digitar: veio da base, com a contagem de clientes ativos de cada um ao lado. Dá para escolher sabendo o tamanho do que se está pedindo.
- Ensinou o critério em vez de escolher por você. As três definições possíveis de “sem CPC” estão lado a lado, em português, com a consequência de cada uma — inclusive a observação de que cerca de 90% dos contatos efetivos vêm de quem já tomou 15 ou mais tentativas. Os parâmetros vêm preenchidos com valores de partida, não vazios.
- E se recusou a rodar pela metade. O botão Levantar está desligado, e ao lado dele está o motivo: “Falta: Credores a incluir”. Ele não assumiu “todos” para ser prestativo — assumir “todos” ali seria varrer dezenas de milhares de clientes que ninguém pediu.
Esse último ponto é o resumo da postura. Cerca de um terço das ferramentas do copiloto escreve no sistema, e a regra da casa é a mesma em todas:
Toda ação que grava roda primeiro em simulação. A Môzi devolve o plano — o que vai ser criado, alterado ou enviado, e em quantos registros — e só executa depois da sua confirmação. Feita a ação, ela devolve os links das fichas que mexeu, para você conferir o que aconteceu.
E ela não tem poder próprio: entra na base com a sua identidade e a sua permissão. O que o seu login não pode fazer no REVO360, o copiloto não faz por você — a autorização é verificada no banco, não no chat. Uma IA operadora sem essa amarra seria uma escada para qualquer permissão do sistema.
O que a Môzi não faz: não negocia com o cliente, não afirma o que não está no painel que leu, e não grava nada sem que alguém tenha visto o plano e dito sim.
Por que cinco, e não uma só
A pergunta razoável, depois de tudo isso, é por que não fazer um agente único que faça as cinco coisas. A resposta tem três partes:
Porque os limites são o produto. A Sarah não poder inventar um valor não é uma limitação a ser removida na próxima versão — é o motivo de ela poder falar com o cliente sem supervisão. A Simmone Copilot não alcançar o cliente é o que permite que ela seja franca com o operador sobre a situação do contrato. O Môzi Copilot mostrar o plano antes de gravar é o que deixa uma IA operar o sistema sem virar aposta.
Note que “limite” aqui não quer dizer “faz pouco”: o Môzi Copilot faz muita coisa. Quer dizer que cada uma tem uma coisa que não pode fazer, e essa coisa é escolhida. Um agente único não tem como ter esses limites, porque cada capacidade nova é uma porta a mais na mesma sala.
Porque a natureza do trabalho é diferente. Priorizar carteira é problema estatístico e precisa de modelo calibrado, validado fora do tempo do treino e monitorado. Negociar é problema de linguagem. Tratar um como o outro produz o pior dos dois: modelo estatístico que conversa mal e conversador que estima mal.
Porque erro concentrado é erro caro. Cinco agentes com escopo definido falham de formas pequenas e localizadas. Um agente onisciente falha de uma vez só, e na cobrança isso tem nome: acordo que não devia existir, feito em nome do seu credor.
Se você quer ver as cinco funcionando sobre uma carteira parecida com a sua, é disso que tratam nossas demonstrações — sem slide de arquitetura, com a tela aberta.