Gazprombank.Tech mostra como a personalização com IA elevou a recuperação de dívidas em 25%

A Gazprombank.Tech apresentou o sistema Next Best Action para cobrança de dívidas em atraso. A equipe eliminou um atraso de dados de três dias, conectou-se ao processo de negócio sem sobrecarga e passou a escolha do canal de contato para modelos uplift. No piloto, a taxa de acordos subiu 25%, as ligações de operadores caíram 73% e o custo de comunicação por cliente recuou 10%. Segundo a equipe, o projeto coube no ciclo de vida normal de um modelo, mas gerou um efeito perceptível já na primeira etapa da cobrança.

Processado por IA de Habr AI; editado por Hamidun News
Gazprombank.Tech mostra como a personalização com IA elevou a recuperação de dívidas em 25%
Fonte: Habr AI. Colagem: Hamidun News.
Ouvir artigo
Ficha técnica e números-chave
ParâmetroDados
Fonte originalHabr AI ↗
Editor-chefe
Dado-chave #1A taxa de acordos subiu 25% em relação à estratégia atual.
Dado-chave #2Em canais de comunicação específicos, o efeito rendeu de 15% a 32% de lucro adicional.
Dado-chave #3As ligações de operadores caíram 73%, e o custo de comunicação por cliente, 10%.

A Gazprombank.Tech contou como implantou o Next Best Action para lidar com dívidas em atraso. A equipe combinou uma nova arquitetura de dados com modelos uplift para escolher o melhor canal de contato para cada cliente e recuperar o dinheiro mais rápido, sem sobrecarregar o call center.

Onde os dias se perdiam

Antes do novo esquema, o banco seguia a lógica de uma plataforma de dados clássica: as fontes eram replicadas para um armazenamento operacional, passavam pelas camadas Stage e Core do data warehouse corporativo e depois chegavam às vitrines em Hadoop para treinar e pontuar modelos. A cadeia era confiável, mas lenta demais para a cobrança. A informação mais sensível, o próprio fato de o atraso ter ocorrido, chegava aos modelos com defasagem de até três dias. O cliente já tinha deixado de pagar, mas a resposta personalizada do banco só começava depois de amanhã.

Sobre isso ainda pesava a antiga lógica de comunicação. Os contratos eram distribuídos numa matriz de Balance at Risk: quanto maiores o risco e o saldo, mais contatos o cliente recebia. Em seguida vinha uma cascata fixa de ações: push, SMS, ligação de robô, ligação de operador. A abordagem funcionava por segmentos, mas não respondia à pergunta mais importante: qual canal vai funcionar para este cliente específico agora. Com isso, parte das pessoas era incomodada à toa, e o call center gastava recursos em ligações que poderiam ser evitadas.

Como o NBA foi montado

A equipe optou por não quebrar o sistema de negócio Collection, já bastante carregado, nem acrescentar a ele mais um processo pesado. Em vez disso, os desenvolvedores encontraram uma rotina automática já existente, disparada no momento em que surge o atraso, e se conectaram a ela via ETL Framework. Os eventos necessários eram marcados com tags e enviados imediatamente ao Hadoop e ao Data Factory, sem atrasos desnecessários. Assim, o banco passou a saber do atraso quase no instante em que ele ocorria, sem criar carga adicional no circuito principal.

Depois, mudou-se o próprio modelo de decisão. No lugar da segmentação, a equipe adotou First Best Action e Next Best Action: o sistema não apenas avalia o risco, mas recomenda o melhor próximo canal de contato. No piloto, foram testadas várias abordagens uplift: modelos solo, pares de modelos independentes e dependentes, e variantes multiclasse e multi-treatment. A avaliação não se baseou em uma única métrica bonita, e sim num conjunto de restrições: Gini, Balance at Risk, Qini, custo das comunicações, orçamento e disponibilidade de operadores do call center.

«Decidimos que não íamos escolher nada, e simplesmente escreveríamos

um otimizador».

O resultado é um otimizador que, em cada etapa do atraso, treina e ajusta um conjunto de modelos e depois escolhe a melhor opção para as restrições específicas do negócio. Na etapa inicial de First Best Action, o sistema recomenda diretamente se vale escrever ao cliente, enviar push, SMS ou transferir o caso a um robô ou a um operador. Além disso, o banco mantém modelos de controle de qualidade para ver não só a conversão final, mas também como os modelos uplift se comportam dentro de cada grupo.

O que o piloto mostrou

O piloto foi montado como um experimento justo. Cerca de 30% do fluxo foi direcionado ao circuito de teste, e o restante foi dividido entre a estratégia antiga e o novo sistema de recomendações. Os dados começaram a ser acumulados no fim de 2024, e depois foram necessários mais dois meses para o desenvolvimento e a entrada em produção. Segundo a equipe, o projeto coube no ciclo de vida normal de um modelo, mas gerou um efeito perceptível já na primeira etapa da cobrança.

  • A taxa de acordos subiu 25% em relação à estratégia atual.
  • Em canais de comunicação específicos, o efeito rendeu de 15% a 32% de lucro adicional.
  • As ligações de operadores caíram 73%, e o custo de comunicação por cliente, 10%.
  • A resposta dos clientes aumentou 5% nas ligações de operador e 11% nas de robô.
  • O efeito financeiro superou 3 bilhões de rublos em saldos preservados a cada 20 mil contratos em apenas um mês na etapa de First Best Action.

O que isso significa

O caso da Gazprombank.Tech mostra que, em processos sensíveis como a cobrança, ganha não a comunicação mais agressiva, mas a mais precisa. Se o atraso de dados é eliminado e o canal de contato é escolhido para cada cliente, a IA pode ao mesmo tempo elevar a recuperação, reduzir custos e não queimar a lealdade dos clientes com ligações desnecessárias.

Perguntas frequentes sobre a notícia

Onde os dias se perdiam?

Antes do novo esquema, o banco seguia a lógica de uma plataforma de dados clássica: as fontes eram replicadas para um armazenamento operacional, passavam pelas camadas Stage e Core do data warehouse corporativo e depois chegavam às vitrines em Hadoop para treinar e pontuar modelos. A cadeia era confiável, mas lenta demais para a cobrança. A informação mais sensível, o próprio fato de o atraso ter ocorrido, chegava aos modelos com defasagem de até três dias. O cliente já tinha deixado de pagar, mas a resposta personalizada do banco só começava depois de amanhã. Sobre isso ai

Como o NBA foi montado?

A equipe optou por não quebrar o sistema de negócio Collection, já bastante carregado, nem acrescentar a ele mais um processo pesado. Em vez disso, os desenvolvedores encontraram uma rotina automática já existente, disparada no momento em que surge o atraso, e se conectaram a ela via ETL Framework. Os eventos necessários eram marcados com tags e enviados imediatamente ao Hadoop e ao Data Factory, sem atrasos desnecessários. Assim, o banco passou a saber do atraso quase no instante em que ele ocorria, sem criar carga adicional no circuito principal. Depois, mudou-se o própri

O que o piloto mostrou?

O piloto foi montado como um experimento justo. Cerca de 30% do fluxo foi direcionado ao circuito de teste, e o restante foi dividido entre a estratégia antiga e o novo sistema de recomendações. Os dados começaram a ser acumulados no fim de 2024, e depois foram necessários mais dois meses para o desenvolvimento e a entrada em produção. Segundo a equipe, o projeto coube no ciclo de vida normal de um modelo, mas gerou um efeito perceptível já na primeira etapa da cobrança. A taxa de acordos subiu 25% em relação à estratégia atual. Em canais de comunicação específicos, o efeit

ZK
Zhemal Khamidun — CPO da Alpina Digital, gerente de produto do AlpinaGPT. Cria produtos de IA desde 2019. O Hamidun News é um projeto pessoal que virou um agregador em produção com mais de 6.000 leitores.
✦ Unified AI Workspace · Nomad

Test Frontier LLMs & Autonomous Agents in One Workspace

Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.

Try Nomad AI →Launch Nomad Agent
O que você acha?
Carregando comentários…