MVP em produção com 12 clientes
Três meses depois do primeiro commit, a plataforma foi ao ar com 12 clientes pagantes. O objetivo não era faturamento: era ter gente de verdade usando para descobrir o que a gente tinha errado.
Performance Baseline
- Clientes no MVP
- 12
- Do primeiro commit ao ar
- 3 meses
Em fevereiro de 2026 a Atendus entrou em produção com 12 clientes pagantes.
Doze é um número escolhido, não um número atingido. Grande o bastante para ter variedade de negócio e casos que a gente não previu; pequeno o bastante para eu conseguir conversar com todos e atender pessoalmente quando quebrasse.
O que o MVP tinha
Deliberadamente pouco:
- WhatsApp como canal
- Um agente de IA por conta, configurável por um formulário
- Inbox com o histórico das conversas
- Transferência para atendimento humano
- Cadastro de informações da empresa para alimentar o agente
Não tinha múltiplos canais, não tinha base de conhecimento estruturada, não tinha agenda, não tinha múltiplos usuários. Tudo isso veio porque cliente pediu, não porque estava no plano.
O que os 12 clientes mostraram
Esta é a parte que justifica ter lançado cedo. Nenhuma das descobertas abaixo apareceu em reunião de planejamento.
“O agente responde bem, mas não fala como a gente”
Foi a reclamação número um, e por larga margem. O agente acertava a informação e errava o tom. Uma clínica achava informal demais; um e-commerce de moda achava robótico.
O formulário de configuração que a gente tinha feito era genérico demais — alguns campos e uma caixa de “descreva seu negócio”. A conclusão foi que personalização não é um campo de texto, é um conjunto de controles finos. Foi o que originou o construtor de agentes.
“Ele não sabe do produto X”
A gente tinha subestimado o volume e a especificidade da informação que cada empresa precisa que o agente saiba. Não é “descreva seu negócio em um parágrafo”: é catálogo de produto, tabela de preço, política de troca, procedimento, horário por unidade, exceção de feriado.
Enfiar tudo no prompt não funciona — estoura contexto, fica caro e a qualidade cai conforme o texto cresce. Isso virou o módulo de base de conhecimento.
“Meu cliente me chama no Instagram também”
Óbvio em retrospecto. O cliente final não escolhe canal pensando na nossa arquitetura: ele responde onde viu o anúncio. Ter só WhatsApp significava que o atendimento continuava fragmentado — que era exatamente o problema que a gente se propôs a resolver.
Felizmente a arquitetura já previa isso. Canal novo era Worker novo, não reescrita.
“Preciso que minha equipe inteira acesse”
O MVP tinha um usuário por conta. Cliente com três atendentes compartilhava senha — o que quebrava qualquer noção de quem respondeu o quê e é um problema de segurança que a gente não podia deixar em pé.
O caso que eu não tinha imaginado
Uma clínica perguntou se o agente podia marcar consulta. Na hora pareceu fora de escopo: somos plataforma de atendimento, não de agendamento.
Mas ao olhar as conversas ficou claro que boa parte do atendimento delas terminava em marcação. O agente respondia tudo direitinho e no final mandava “entre em contato para agendar” — desperdiçando justamente a conversa que estava funcionando.
Isso virou o módulo de agenda.
O que essa fase provou sobre a arquitetura
Todas essas demandas foram atendidas sem reescrever o núcleo. Cada uma virou um módulo novo ou um canal novo, encaixando no que já existia.
A aposta de dezembro — modular desde o primeiro dia, canal como plugin, configuração como dado — se pagou aqui. Se o núcleo soubesse que WhatsApp existe, adicionar Instagram teria sido refatoração. Se personalização fosse código nosso, cada cliente novo seria consultoria.
Foram cinco meses de ciclo entre esse feedback e a versão 2. É o que os próximos capítulos deste diário contam.