A Brazilian fintech shares three years of lessons automating customer support with AI, achieving 66% resolution without human intervention.
Adapted from @joaoavf# Construíndo um Atendimento ao Cliente IA nativo Há quase 3 anos estamos automatizando o atendimento ao cliente da Picnic. Fizemos de tudo: usamos ferramentas prontas, construímos nossos próprios agentes pra depois jogar fora e recomeçar do zero. Hoje, 66% das conversas são resolvidas sem intervenção humana e com 90% de avaliações positivas. O objetivo deste texto é compartilhar a nossa trajetória e principais aprendizados na esperança de que isso seja útil para alguém que está vivendo uma situação similar. # A nossa história até aqui ## Por que decidimos apostar em atendimento com IA? Não apostamos em IA apenas para cortar custos. Acreditamos que ela seria a forma de oferecer a melhor qualidade de atendimento em escala. Pelos seguintes motivos: 1. Contexto altamente individualizado e preciso: com acesso aos dados certos, a IA pode consultar os tickets que você já abriu, entender como você usa o produto e combinar uma série de informações que seria impraticável um humano consumir de forma a oferecer um atendimento ágil. 1. Manter consistência com humanos é zero trivial: cada pessoa tem uma personalidade, uma forma de responder e conhecimentos específicos. Garantir que o seu time de suporte está bem alinhado é um desafio e tanto, especialmente quando o produto é complexo como a Picnic. 1. Melhorias que se acumulam: conseguimos incorporar uma melhoria à operação inteira e saber que isso irá se juntar a outras melhorias sendo feitas. ## Nosso primeiro agente de atendimento de IA Começamos via uma plataforma que consultava uma série de documentos e dava respostas com base nisso. A IA resolvia um percentual relativamente pequeno do volume, e em alguns dos casos as respostas mais atrapalhavam do que ajudavam. Mas, quando funcionava era a coisa mais linda do mundo. Nesse momento, os principais problemas que a gente tinha não eram da IA, e sim falta de processos, ferramentas e métricas. A gente não tinha uma área de suporte organizada, e assim começamos a usar o Zendesk para organizar o fluxo de atendimento e criar uma forma de fazer melhorias contínuas. ## Construindo internamente Existiam alguns problemas com as nossas respostas de IA que não estavam fáceis de resolver. Em uma das tentativas de entender por quê, fizemos a mesma pergunta sobre a Picnic para nossa IA e para o na época recém-lançado GPT-5. Nossa IA errou e o GPT-5 acertou buscando no nosso help center, sem nenhuma configuração específica sobre a Picnic. Fizemos mais alguns testes e decidimos que usar um modelo mais livre seria superior à nossa solução no momento. E por entendermos que ter IA integrado no produto era algo central na nossa visão, decidimos fazer a nossa própria solução. Em outubro de 2025, depois de 6 semanas de trabalho, lançamos a Nick V1, nossa agente de suporte feita em casa. Ela resolveu alguns dos problemas crônicos que tínhamos: fechar tickets antes de o problema do usuário ter sido resolvido de fato, não escalar para humanos em situações que precisavam disso e falhar na busca de contexto em tickets que a IA deveria conseguir resolver. ## Construindo com ferramentas A Nick V1 respondia com base na nossa documentação, mas não tinha acesso a ferramentas para consultar o saldo, verificar transações ou buscar contexto sobre o cliente. Ela podia explicar como o produto funcionava, mas não conseguia investigar o que estava acontecendo naquela conta. Com o lançamento de novos modelos (Opus 4.5), a nossa experiência com o Claude Code mudou o que a gente esperava da Nick. Queríamos que ela também pudesse buscar contexto, usar ferramentas e tomasse decisões. E decidimos jogar a Nick V1 fora, para reconstruí-la com mais liberdade e autonomia. A Nick V2, poderia em uma mesma conversa: consultar o perfil do cliente, verificar transações, checar o estado de uma operação e buscar informações na central de ajuda. Tudo isso em poucos segundos e de uma forma que era bastante fácil continuar melhorando o atendimento. Em julho, aposentamos a Nick V1 e passamos todo o atendimento para a V2. Ainda temos trabalho a fazer, mas em boa parte dos tickets que eu leio, fico satisfeito com o resultado e em alguns casos fico bem impressionado com o quão longe a IA vai em diagnosticar o problema e ajudar o usuário. # Principais aprendizados ## 1. Ter processos, métricas, prazos e donos Um dos nossos problemas era ter tickets em que não estava claro quem precisava fazer alguma coisa. O cliente ficava esperando, e a gente demorava para perceber. Organizar a operação permitiu responder perguntas básicas: quais tickets graves estão sem resposta? Todos têm dono e prazo? Quantos estão com parceiros e há quanto tempo? Quais categorias concentram mais problemas? Essa visibilidade foi essencial para melhorar o atendimento. Sem ela, a gente tinha muita dificuldade em diagnosticar e priorizar os principais problemas. Com ela, conseguimos ter muito mais impacto no nosso trabalho. ## 2. Confiar na IA e dar ferramentas Nossa forma de construir mudou quando paramos de tentar definir cada passo do que a IA deveria fazer. Hoje, damos à Nick ferramentas, instruções e limites, e deixamos que ela escolha como resolver o caso. Se uma busca não funciona, ela pode tentar outra. Se a documentação não basta, pode consultar os dados do cliente. Ela não precisa acertar o caminho inteiro antes de começar; pode decidir o próximo passo a partir do que encontrou. Isso simplifica muito o nosso trabalho e permite que a IA resolva um escopo ainda maior de problemas. ## 3. Usar skills para organizar a complexidade Nosso system prompt estava ficando gigantesco. Cada novo problema trazia mais instruções, exceções e regras. Ficava extremamente difícil controlar efeitos colaterais. Separar por skills ajudou bastante. Login, PIX, cartão e KYC têm procedimentos próprios, carregados conforme o caso. Conseguimos detalhar uma investigação sem colocar todas as instruções de todos os assuntos no mesmo prompt. Isso também tornou a Nick mais fácil de manter. Se precisamos mudar como ela trata um problema de cartão, sabemos onde estão aquelas regras e quais outros casos precisamos testar. ## 4. Compartilhar workflows entre humanos e agentes Uma das melhores decisões que tivemos foi usar os mesmos fluxos automatizados para o time humano e para a Nick. Um humano pode acionar uma macro no atendimento. A Nick pode identificar que aquele procedimento se aplica e encaminhar o caso para o mesmo workflow. A partir dali, ambos usam a mesma execução. Isso evita manter duas versões do mesmo processo. Se mudamos o procedimento para acionar um parceiro, por exemplo, não precisamos atualizar uma automação para humanos e outra para a IA. O conhecimento operacional fica no fluxo compartilhado. Por exemplo: se o cartão físico não chegou, a Nick consulta o pedido, verifica o prazo e pede a confirmação do endereço quando cabe uma reemissão. Depois, aciona a mesma macro que um atendente humano usaria para solicitar isso ao parceiro. ## 5. Usar evals para garantir qualidade Durante um período, parecia que consertávamos uma coisa e quebrávamos outra. Testar a pergunta que tinha dado errado não bastava: ela podia melhorar enquanto outros atendimentos pioravam. Por isso, uma mudança precisa começar com uma definição do que queremos corrigir e do que deve continuar funcionando. Rodamos os casos na versão anterior e depois na nova, comparando o comportamento. As evals precisam olhar além do texto da resposta. A agente consultou os dados necessários? Escolheu o fluxo certo? Escalou quando deveria? Uma mensagem bem escrita pode esconder uma decisão errada. Por exemplo: se o cliente pede um comprovante, não basta a Nick responder “vou enviar”. A eval precisa verificar se ela realmente acionou a ferramenta para enviar o arquivo. ## 6. Usar agentes para ajudar a melhorar os próprios agentes Hoje, faço uma revisão semanal com uma skill que analisa os atendimentos e ajuda a identificar oportunidades de melhoria. Isso permite investigar mais conversas do que eu conseguiria revisar sozinho. Mas encontrar uma resposta ruim não significa que precisamos adicionar uma instrução ao prompt. O problema pode estar nos dados, numa ferramenta, no produto ou numa regra que contradiz outra. Criamos uma skill chamada CX Improve para conduzir essa investigação, definir evals e testar uma correção com escopo limitado. A ideia é melhorar o comportamento sem acumular um remendo para cada ticket. Às vezes, a mudança necessária é remover uma contradição, não escrever mais uma regra. -- Espero que tenha sido útil! E muito agradecimentos a todos que participaram desse processo, e em especial ao @pury_br, que foi quem arquitetou a maior parte desse sistema.
