Fevereiro de 2026. A Gepy passou a rodar oficialmente dentro da Fucape Business School. Não como protótipo. Não como demonstração. Como sistema em uso real, com usuários reais, tomando decisões reais a partir dele.
O que eu imaginava que aconteceria e o que de fato aconteceu são histórias completamente diferentes. Este post é sobre a segunda.
O que eu achava que sabia
Antes de rodar o MVP, eu tinha passado meses pesquisando o problema. Conversas com gestores, leitura de estudos sobre captação no ensino superior, análise de ferramentas concorrentes. Achei que entendia bem o que as instituições precisavam.
Estava errado. Não completamente, mas errado o suficiente para que o produto precisasse de ajustes que eu não havia previsto.
Pesquisa te diz o que as pessoas acham que fazem. Produto te mostra o que elas realmente fazem.
A primeira semana de uso real derrubou três premissas que eu tinha como certas. Vou detalhar cada uma.
Premissa 1: WhatsApp como canal principal
Eu sabia que o WhatsApp era importante. Construí o módulo omnichannel da Gepy com foco nele. O que eu não havia previsto é que o volume de mensagens era três vezes maior do que qualquer estimativa que eu tinha feito.
Em uma semana, o time de captação da Fucape gerou mais de 800 interações via WhatsApp. Minha arquitetura inicial de organização de conversas quebrou no terceiro dia.
Premissa 2: O CRM como destino final
Imaginei que o fluxo seria: lead entra, vai para o CRM, é trabalhado, converte. Linear, limpo, previsível.
Na prática, o fluxo era caótico. Leads entravam por canais diferentes, eram respondidos por pessoas diferentes, voltavam dias depois com contexto diferente. O CRM não era o destino, era uma das paradas de um processo muito mais não-linear do que eu havia desenhado.
O que mudei
Redesenhei a visão de pipeline para ser mais flexível. Em vez de etapas fixas, passei a trabalhar com estados que o lead pode entrar e sair de forma não sequencial. Parece um detalhe técnico. Na prática, mudou completamente como o time usa a ferramenta.
- Etapas deixaram de ser obrigatórias em sequência
- Qualquer usuário pode mover um lead para qualquer estado com justificativa
- O histórico de movimentação virou o dado mais valioso do sistema
Premissa 3: Automação como prioridade
Aqui foi o erro mais caro. Investi tempo significativo no módulo de automação antes de entender bem o processo manual. Resultado: automatizei partes do processo que não eram gargalo e deixei os gargalos reais sem solução.
Sistema antes de automação. É o princípio que eu repito sempre e que eu mesmo violei na pressa de entregar funcionalidade.
O que funcionou melhor do que esperava
Nem tudo foi surpresa negativa. Duas funcionalidades performaram muito acima do que eu havia estimado.
O dashboard de dados, que eu considerei quase um item secundário no MVP, virou a funcionalidade mais usada. Toda manhã, antes de qualquer outra coisa, o coordenador de captação abre o dashboard. Isso me ensinou algo sobre o valor do dado em tempo real que nenhum benchmarking havia me mostrado.
E o módulo financeiro, que eu havia planejado para uma versão futura, foi solicitado na segunda semana. Não como funcionalidade secundária, como necessidade urgente. Isso acelerou o roadmap em pelo menos dois meses.
O que vem a seguir
Estou no segundo mês agora. O produto está mais maduro, mas os aprendizados não pararam. A cada semana, uma nova camada do problema aparece.
É isso que significa ter um laboratório real. Não é confortável. É, sem dúvida, o melhor ambiente possível para construir produto.
Continuarei documentando o processo aqui. Se você é gestor de uma instituição de ensino e quer conversar sobre o que estou construindo, o formulário de interesse da Gepy está aberto.