Product Thinking · Weni by VTEX · 2021 — 2024

Weni Chats

Módulo de atendimento humano construído do zero. Conduzi o discovery, defini a estratégia e coordenei a migração de 100% da base de clientes, eliminando uma dependência externa que limitava o crescimento do produto.

Empresa Weni by VTEX
Período 2021 — 2024 (3 anos)
Papel Product Manager — do zero ao lançamento
Time Backend, Frontend, UX/UI

100%

da base de clientes
migrada para o novo produto

300%

de crescimento em
usuários simultâneos

600+

entrevistas e sessões
de teste com usuários

01

Uma plataforma de IA que precisava de um lado humano

A Weni é uma plataforma SaaS de automação conversacional: empresas a utilizam para criar agentes de IA e chatbots que atendem clientes via WhatsApp, Telegram, Instagram, SMS e outros canais digitais. O produto funcionava bem para automação — mas havia um problema estrutural no momento em que o bot precisava passar a conversa para um humano.

O handoff bot → humano era gerenciado por um software terceirizado, integrado à plataforma via parceria. Esse software cumpria seu papel, mas trazia consequências cada vez mais graves: era difícil de escalar, gerava custos crescentes e estava fora do controle do time de produto. Qualquer melhoria dependia de um terceiro. Qualquer instabilidade era um risco que não podíamos mitigar.

À medida que a base de clientes crescia, a insustentabilidade ficava mais evidente. Foi nesse contexto que fui contratado para encontrar uma solução.

02

Dependência crítica, sem saída clara

O desafio inicial não era de produto — era estratégico. Antes de definir o que construir, precisávamos entender se deveríamos construir. Três caminhos estavam na mesa:

A Manter o software terceirizado e gerenciar as consequências conhecidas — custos, limitações de escala e dependência de roadmap alheio.
B Buscar outro produto no mercado e substituir uma dependência por outra, com os riscos de integração e adoção envolvidos.
C Construir um produto próprio do zero, com controle total sobre evolução, custos e experiência do usuário. escolhido

A fase de discovery nos mostrou que a opção C era a única que resolvia o problema de forma estrutural — e que o time tinha capacidade de executá-la. A decisão foi tomada com clareza sobre os riscos: construir do zero leva tempo, e nesse período os clientes ainda dependem da solução legada.

O problema real não era apenas técnico. Era operacional: os agentes de atendimento passavam grande parte do dia dentro de um software que não era da Weni, criando uma barreira de experiência e limitando o potencial de evolução do produto como um todo.

03

Mais de 600 conversas antes de escrever uma linha de código

Trabalhei com discovery contínuo desde o início, o que significava estar em contato constante com clientes, não apenas numa fase inicial de pesquisa. Queria entender as dores reais do trabalho de atendimento e já antecipar como as necessidades evoluiriam com o tempo.

Ao longo do projeto, foram realizadas mais de 600 entrevistas e sessões de teste com usuários reais — agentes de atendimento, supervisores e gestores de operações de customer service. Esse volume não foi acidental: o produto precisava funcionar bem em contextos de alta pressão, onde cada segundo conta e a interface precisa ser intuitiva sem treinamento extenso.

As descobertas moldaram diretamente as decisões de produto: a arquitetura de filas, o sistema de transferência entre atendentes, a visibilidade do histórico de conversa e a integração nativa com os canais já usados pelos clientes da Weni.

Paralelamente ao discovery, montei e organizei o time de engenharia e design — backend, frontend e UX/UI — estruturando o processo de desenvolvimento para manter velocidade sem abrir mão da qualidade.

04

Uma central de atendimento humano nativa da plataforma

O Weni Chats foi construído como um módulo nativo da plataforma Weni: uma workspace de atendimento humano onde agentes recebem conversas transferidas pelos bots, gerenciam filas, colaboram em equipe e acessam o histórico completo do cliente — tudo sem sair do ecossistema Weni.

Algumas decisões centrais que moldaram o produto:

Lançamento via MVP segmentado. Em vez de tentar migrar todos os clientes de uma vez, lançamos um MVP funcional para metade da base primeiro. Essa decisão foi deliberada: queria aprender com clientes reais antes de comprometer todos. O MVP precisava ser simples, mas não podia ser fraco — tinha que ser bom o suficiente para que os clientes escolhessem ficar.

Estratégia de migração com gestão de risco. A migração da base completa exigiu planejamento cuidadoso de rollout. Trabalhamos com cohorts de clientes, monitorando estabilidade e adoção antes de avançar para o próximo grupo. Realocamos recursos de infraestrutura em nuvem para garantir performance com o crescimento de usuários simultâneos, e revisamos fluxos e design com base no feedback contínuo.

Experiência operacional como prioridade. O produto precisava funcionar bem para quem o usa oito horas por dia. Priorizamos clareza, velocidade e confiabilidade sobre features avançadas — e isso foi fundamental para a adoção.

05

De ferramenta de nicho a rotina diária

Ao final do primeiro ano após o lançamento, 100% da base de clientes havia migrado para o Weni Chats, incluindo os clientes mais complexos, com operações de maior volume e múltiplos atendentes simultâneos.

A migração foi completa, mas o dado mais significativo foi o que ela revelou sobre o comportamento dos usuários. A plataforma Weni, que antes era usada principalmente por alguns funcionários para configurar e gerenciar os bots, passou a fazer parte da rotina diária da maioria dos usuários de cada cliente. As visitas diárias médias por cliente cresceram mais de 300%.

Esse crescimento mudou o tipo de produto que a Weni é: o que antes era uma ferramenta de back-office usada por poucos especialistas tornou-se uma plataforma operacional presente na rotina de toda a equipe de atendimento. Isso tem implicações diretas em retenção, expansão de receita e posicionamento competitivo.

A dependência do software terceirizado foi eliminada, reduzindo custos e devolvendo ao time de produto o controle total sobre a evolução do módulo de atendimento.

06

O que esse projeto me ensinou

A decisão de construir do zero parece óbvia em retrospecto, mas não era no início. Um dos aprendizados mais valiosos foi sobre como enquadrar decisões estratégicas: apresentar as três opções explicitamente, com seus trade-offs, foi o que permitiu ao time e à liderança alinharem expectativas antes de começar e sustentar o compromisso durante os momentos mais difíceis da execução.

Outro aprendizado importante foi sobre migração como produto. A migração também é um problema de produto, não apenas de engenharia. Os clientes precisam ver valor suficiente para mudar um hábito consolidado, o que exigiu tanto a qualidade técnica do novo produto quanto uma estratégia de comunicação e suporte que tornasse a transição segura para eles.

Por fim, a escala do discovery confirmou algo que já acredito sobre produto: contexto acumulado vale mais do que intuição. Mais de 600 conversas parecem excessivo até que você precisa defender uma decisão difícil com uma base de evidências, e percebe que cada entrevista, por mais incremental que pareça, contribuiu para aquilo.

Product Discovery SaaS B2B Migração Atendimento ao Cliente Omnichannel Escalabilidade Cross-functional MVP
← Todos os cases

Próximo case

Weni Insights →