Gestão de
Limites Pix
A gestão de limites liderava o VoC, impactava o NPS e concentrava uma operação manual massiva. Mas ao aproximar, o problema ia além da UX ruim: era sintoma de uma política de risco confundida com limitação sistêmica — e de um produto que tratava como "gargalo operacional" algo que deveria ser alavanca de retenção.
Um produto com papel crítico na receita — e experiência que comprometia os dois.
A gestão de limites do Pix não era um produto secundário. Ela estava diretamente ligada à capacidade de transação dos clientes — e, por consequência, à receita da empresa. Ao mesmo tempo, liderava as queixas no VoC, impactava o NPS negativamente e concentrava uma operação manual que não parava de crescer.
O produto operava fortemente orientado por regulações. A cada nova norma do BACEN, ajustes eram implementados de forma reativa — sem necessariamente considerar o impacto na experiência ou na escalabilidade operacional. O resultado foi um sistema que cresceu em complexidade sem crescer em clareza.
O cenário no backoffice era crítico: mais da metade das solicitações de aumento de limite dependiam de análise manual. Apenas três analistas processavam milhares de pedidos por mês. A fila era fragmentada, distribuída informalmente e dependente de múltiplos sistemas externos abertos simultaneamente.
Estávamos tratando como política de risco o que era limitação sistêmica.
Quando o prazo regulatório estourava, o sistema reprovava automaticamente por timeout — mas para o cliente, aquilo parecia uma decisão de risco deliberada. A frustração crescia. A confiança diminuía. E os analistas recebiam chamados sobre negativas que não eram decisões, eram bugs operacionais.
- Sem visibilidade sobre as regras que determinavam o limite
- Negativas sem explicação ou caminho de reversão
- Modalidades distintas de limite vinculadas de forma opaca
- Comunicação insuficiente sobre o que era regulatório e o que era política interna
- Concorrentes com limites iniciais mais agressivos e jornadas mais claras
- Ausência de deduplicação de pedidos
- Múltiplos sistemas desconectados
- Fila sem priorização inteligente
- Nenhuma automação estruturante
- Analistas no limite com fila crescendo
O problema não era apenas usabilidade. Era estratégia. A fricção na gestão de limites não era só experiência ruim: era risco de churn, perda de principalidade e vulnerabilidade competitiva.
Não aprovar mais pedidos. Reduzir fricção, aumentar confiança e escalar com segurança.
O objetivo do projeto foi deliberadamente ampliado a partir de onde ele começou. A pergunta inicial era "como melhorar a jornada de solicitação de limite?" — mas ao estruturar o problema de forma sistêmica, ficou claro que responder só essa pergunta seria insuficiente.
As perguntas que guiaram o trabalho foram diferentes:
- Onde estamos perdendo competitividade em relação a concorrentes com políticas mais agressivas?
- Onde estamos gerando fricção desnecessária — não por risco real, mas por ineficiência operacional ou comunicação inadequada?
- O que é risco real e o que é gargalo sistêmico sendo percebido como decisão de risco pelo cliente?
- Como tornamos isso escalável sem depender de crescimento linear de analistas?
Liderança do discovery — estruturando o problema de forma sistêmica.
Atuei liderando o discovery da frente de Limites. Minha responsabilidade foi estruturar o problema de forma sistêmica e transformar dados dispersos — operacionais, regulatórios e de experiência — em direcionamento estratégico.
Mais do que propor melhorias visuais, precisava responder onde estávamos perdendo competitividade, onde gerávamos fricção desnecessária, o que era risco real versus gargalo operacional e como tornávamos tudo isso escalável.
O trabalho envolveu colaboração direta com a área de risco e fraude, compliance, backoffice operacional e squads de engenharia — além de leitura densa do framework regulatório do BACEN para limites Pix.
Quatro camadas cruzadas para revelar um padrão.
Estruturei o discovery utilizando abordagem de Atomic UX Research — organizando experimentos, fatos, insights e oportunidades de forma rastreável, para que as decisões estratégicas tivessem evidências claras por trás.
Dados operacionais
Volume de pedidos, SLA por tipo de solicitação, tempo médio por análise, taxa de aprovação por canal e perfil de cliente. Identificação dos gargalos quantificáveis antes de qualquer hipótese qualitativa.
Voz do cliente
Análise de NPS aberto e tags de reclamação. O padrão era claro: as palavras mais frequentes eram "demora", "sem explicação" e "não entendi". Não "processo lento" — mas "não entendo o motivo".
Observação direta do backoffice
Acompanhamento do trabalho dos analistas. Mapeamento dos sistemas abertos em paralelo, do fluxo de decisão e dos critérios informais que guiavam as análises onde a automação falhava.
Benchmark competitivo e leitura regulatória
Análise da política de limites de concorrentes diretos e sua comunicação ao cliente. Leitura das normas do BACEN para identificar onde havia margem real de flexibilização que não estava sendo usada.
Síntese e estruturação do roadmap
Organização das oportunidades em três frentes estruturantes com priorização baseada em impacto no cliente, viabilidade técnica e risco regulatório. Apresentação executiva com visibilidade clara dos gargalos antes invisíveis.
Três frentes estruturantes em vez de melhorias pontuais.
Em vez de propor melhorias incrementais isoladas, reorganizei as oportunidades em três eixos que atacam o problema em camadas diferentes — e que precisam evoluir juntos para que a mudança seja sustentável.
Experiência e educação do cliente
Tornar o sistema de limites transparente e compreensível. Separar as modalidades com clareza — limite Pix, limite noturno, limite por transação. Substituir negativas genéricas por orientação real: o que foi negado, por que, e qual o caminho para mudar. Comunicação proativa sobre regras regulatórias que antes chegavam ao cliente como surpresa.
Eficiência operacional
Unificar ferramentas do backoffice em uma interface consolidada. Implementar lógica de deduplicação para eliminar pedidos redundantes. Consolidar histórico do cliente. Criar priorização inteligente de fila. Reduzir a dependência de sistemas externos abertos em paralelo.
Evolução estrutural
Motor de regras automatizado para reduzir a dependência de análise manual em casos com critérios objetivos. Revisão estratégica da política de limites para alcançar paridade competitiva onde o risco real permitia. Base técnica para self-service do cliente em ajustes de limite dentro de parâmetros seguros.
O foco deixou de ser "aprovar mais pedidos" e passou a ser: reduzir fricção, aumentar confiança e escalar com segurança. Isso mudou completamente o critério de priorização das iniciativas.
De centro de custo a alavanca estratégica.
O discovery consolidou um roadmap priorizado para 2026 e trouxe visibilidade executiva para gargalos que eram tratados como "problemas operacionais normais". A gestão de limites foi reposicionada dentro da empresa.
De um centro de custo operacional e fonte de reclamação, passou a ser enxergada como alavanca de retenção, pilar de confiança e motor de eficiência escalável. Essa mudança de perspectiva teve impacto direto na alocação de recursos e prioridade do tema nas revisões de roadmap subsequentes.
O que esse projeto ensina sobre discovery em produtos financeiros complexos.
- Nem toda fricção é UX — parte dela é arquitetura de produto. A sensação de limite "opaco" não era só um problema de interface. Era uma consequência de como as regras estavam modeladas no sistema e comunicadas internamente.
- Observar o backoffice é tão importante quanto ouvir o cliente. Os analistas eram o espelho mais fiel dos gargalos reais — cada workaround deles era uma oportunidade de produto não capturada.
- Distinguir risco real de limitação sistêmica muda completamente as prioridades. Aprovar que algo "é política de risco" quando é timeout operacional é tratar sintoma como causa. O discovery mostrou onde essa confusão existia — e isso mudou o tom das conversas com a área de risco.
- Discovery sem síntese executiva não muda prioridade. A qualidade do trabalho de pesquisa precisava se traduzir em linguagem de negócio para ter impacto real no roadmap. A apresentação para o C-level foi tão importante quanto os artefatos de pesquisa.
- Autonomia do usuário e segurança não são opostos — são design. O desafio final era encontrar o equilíbrio certo: dar ao cliente controle real sobre seus limites dentro de parâmetros que o protegem, sem transformar isso em mais burocracia.
Ver outros projetos
Quatro cases do setor financeiro — cada um com um problema diferente.