O gargalo não era criatividade. Era dependência estrutural
Antes do projeto, o time de CRM dependia da esteira de tecnologia para alterar banners, ajustar ofertas, testar mensagens e reorganizar partes da experiência dentro do app. Em outras palavras, a área que precisava responder rápido ao comportamento do cliente operava no tempo do deploy.
Esse modelo criava um custo de oportunidade relevante. Quando a campanha finalmente entrava no ar, o contexto já podia ter mudado. O que deveria ser reação virava atraso. O que deveria ser personalização virava distribuição genérica de mensagem.
Para o perfil de cliente do banco, isso tinha um efeito ainda mais sensível. Parte relevante da base usa aparelhos com menor performance e apresenta menor familiaridade com interfaces digitais. Receber uma comunicação genérica, fora de contexto ou pouco clara não significa apenas menor conversão. Significa aumento de ruído, perda de confiança e mais dificuldade para seguir na jornada.
A operação também precisava equilibrar dois fatores que normalmente entram em conflito: tornar a experiência mais personalizada sem transformar o app em um ambiente pesado, lento ou instável. O problema não era apenas vender mais crédito. Era construir uma lógica de relevância que funcionasse em tempo real, sem sacrificar simplicidade nem performance.
A lógica de decisão saiu do app e foi para onde ela fazia mais sentido
A resposta foi separar personalização de deploy.
A MATH estruturou uma arquitetura server-side que permitiu ao CRM operar mudanças de conteúdo, ofertas e módulos do app sem depender de novas publicações na loja. Em vez de sobrecarregar o dispositivo do usuário com regras, SDKs e lógicas locais, a tomada de decisão passou a acontecer no servidor, de forma mais controlada, leve e rápida.
Esse desenho foi especialmente importante para o contexto do banco. Como parte da base acessa o aplicativo em aparelhos mais limitados, manter a experiência enxuta não era apenas uma escolha técnica. Era uma condição para a personalização funcionar sem aumentar atrito.
A segunda camada da solução foi o real-time decisioning. A arquitetura passou a reagir ao comportamento do usuário quase em tempo imediato. Isso permitiu, por exemplo, alterar a oferta exibida a partir de um abandono de fluxo, de uma navegação incompleta ou de um contexto específico de jornada. A comunicação deixou de ser fixa. Passou a responder ao momento.
A terceira camada foi a modularização. A MATH criou uma estrutura de telas e componentes que podiam ser configurados e injetados pelo CRM sem alteração no código-fonte central da aplicação. Na prática, isso mudou a divisão de trabalho: a engenharia deixou de ser acionada para pequenas trocas de conteúdo e pôde concentrar energia em infraestrutura, performance e evolução estrutural do produto.
A quarta camada foi o uso combinado entre dado e sensibilidade operacional. A tecnologia não foi desenhada para automatizar oferta de forma cega, mas para reduzir distância entre comportamento, contexto de vida e próxima melhor ação. O sistema passou a apoiar uma personalização que funciona mais como orientação do que como pressão comercial.
O ganho não veio apenas de exibir mensagens diferentes. Veio de permitir que o negócio reagisse no tempo da jornada sem tornar o aplicativo mais pesado para quem já enfrenta barreiras digitais.
O que mudou quando relevância e velocidade passaram a andar juntas
O resultado mais visível foi de receita. A originação de crédito nos canais digitais saiu de R$ 4,8 milhões para mais de R$ 85 milhões, um crescimento de 18 vezes. Esse salto mostra que a personalização, neste caso, não operou como refinamento cosmético da experiência. Ela mudou a capacidade da operação de transformar presença digital em ativação comercial.
O segundo resultado foi retenção. O aumento de 4,6 pontos percentuais indica que a experiência passou a sustentar mais permanência e recorrência, algo particularmente importante em um cenário em que adquirir clientes novos tende a custar cada vez mais.
O terceiro resultado foi produtividade. O time de CRM multiplicou sua capacidade de entrega em 6 vezes porque deixou de depender de uma cadeia longa entre ideia, priorização técnica, desenvolvimento e publicação. A operação comercial ganhou autonomia real para agir.
O quarto resultado foi técnico. Todo esse avanço foi entregue sem deteriorar a performance da aplicação. Isso importa porque confirma a escolha arquitetural: personalizar mais não exigiu tornar o app mais pesado, mais lento ou mais frágil.
Ao final, o banco ganhou mais do que um mecanismo de oferta. Ganhou uma forma de fazer o aplicativo responder melhor ao usuário sem depender da lentidão estrutural de um modelo centrado em deploy.
