o que é este texto. um olhar de construção pública sobre um projeto. um time de produto de uma fintech série b tinha uma funcionalidade de ia que se saía bem em demo e não saía do lugar. reconstruímos como uma funcionalidade em produção em 5 semanas. foi para 100% dos usuários, e os tickets de suporte nessa funcionalidade caíram 60% após o lançamento.
o protótipo já existia. uma pessoa responsável por produto o construiu no lovable num fim de semana. parecia real. saiu-se bem na reunião geral. depois ficou parado por quatro meses, porque parecer real e ser confiável são dois trabalhos diferentes.
aviso antes de começar: o cliente é anônimo. a implantação de 5 semanas e a queda de 60% nos tickets são os números entregues no projeto, não projeções. não citamos o nome porque o contrato pede isso. o que importa aqui é a construção, não o logotipo.
#por que um bom protótipo trava antes da produção?
porque o protótipo responde a uma pergunta diferente da que a produção responde. o protótipo prova que a ideia funciona uma vez, com uma entrada limpa, com o fundador conduzindo. a produção precisa funcionar com a entrada bagunçada, às 2h da manhã, sem ninguém olhando, e ser defensável quando um cliente contesta o que a funcionalidade disse. é aí que a maioria dos builds em v0 e lovable morre. não porque a ideia estava errada. porque não havia um caminho da demo até algo em que você pode colocar seu nome.
como levar um protótipo de ia até a produção?
comece pelo problema real, não pela interface da demo. reconstrua a funcionalidade dentro do seu próprio produto com respostas em streaming, um conjunto de testes que confere as respostas contra casos conhecidos e corretos, registro de auditoria e revisão humana onde importa. para este time de fintech, esse caminho levou 5 semanas e cortou os tickets da funcionalidade em 60%.
#o que construímos de fato?
não partimos da caixa de chat do protótipo. partimos da fila de suporte deles. os três tickets de maior volume sobre essa funcionalidade apontavam para a mesma coisa: os usuários não conseguiam uma resposta clara sem enviar e-mail ao suporte. então construímos a funcionalidade para responder essas três perguntas primeiro, dentro do próprio produto e do próprio design system deles, não um widget colado por fora.
- respostas em streaming para a funcionalidade parecer imediata em vez de um indicador de carregamento. a resposta vai aparecendo enquanto se forma.
- um conjunto de testes que roda a funcionalidade contra respostas conhecidas e corretas a cada mudança, para que um ajuste num prompt não quebre outro caso silenciosamente.
- registro de auditoria em cada resposta, para que, quando um cliente conteste o que a funcionalidade disse, o suporte consiga puxar a entrada e a saída exatas.
- ux integrada ao produto construída dentro do design system deles, para que pareça parte do produto, não uma janela de chat colada por cima.
we are
reconstruímos um protótipo travado numa funcionalidade lançada, com streaming, conjunto de testes, registro de auditoria e ux nativa integrada ao produto.
we aren't
não colamos uma caixa de chat genérica em cima do produto e chamamos isso de funcionalidade de ia.
#por que os tickets de suporte caíram 60%?
porque construímos a funcionalidade de trás para frente, a partir dos tickets. as três perguntas que geravam mais volume de suporte são as três que a funcionalidade agora responde no produto, antes de o usuário precisar mandar e-mail para alguém. o registro de auditoria nos diz quais perguntas a funcionalidade resolve e quais ainda chegam a uma pessoa. esse mesmo registro foi como soubemos que a queda de 60% era real, e não uma variação sazonal. ela foi medida por tipo de ticket, contra as oito semanas antes do lançamento.
o conjunto de testes é o motivo pelo qual a queda se manteve. antes do lançamento, cada mudança rodava contra as respostas conhecidas e corretas. um ajuste de prompt que consertava um caso e quebrava outros dois era pego antes de chegar a um usuário. essa é a diferença entre uma demo que funciona uma vez e uma funcionalidade que funciona sempre. times de produto chamam isso de lançar. concordamos. mais sobre como abordamos o trabalho de produto está aqui.
#quanto tempo levou para lançar?
cinco semanas, do protótipo a 100% dos usuários. a primeira semana foi o registro de auditoria e o conjunto de testes, porque você não consegue melhorar o que não consegue medir. as semanas dois e três reconstruíram as três respostas de maior volume de tickets dentro do produto. a quarta semana foi a ux do design system e o streaming. a quinta semana foi um lançamento em etapas, dez por cento dos usuários de cada vez, observando o registro de auditoria em busca de qualquer coisa que os testes tivessem deixado passar. sem lançamento no big bang. sem reconstrução de um trimestre inteiro.
passou de algo que demonstrávamos para algo que lançamos, e a fila de suporte é como sabemos que funcionou.
isso é o que a maioria dos nossos estudos de caso de construção pública têm em comum. o ganho não é o modelo. são as partes chatas ao redor dele: o conjunto de testes, o registro de auditoria, os pontos de revisão, o lançamento que dá para acompanhar. é isso que transforma um protótipo em algo que você pode colocar diante de cada usuário. se você tem um build em v0 ou lovable parado na demo sem caminho adiante, é exatamente essa lacuna que fechamos. conte o que você está construindo.