EmitaZap: A melhor tela é a que não existe
Antecipar todos os cenários nunca foi tão importante, afinal a experiência inteira depende de como cada palavra é escrita.
Um fluxo sem interface não perdoa mensagem ambígua. Fui responsável por garantir que cada palavra trocada com o usuário fizesse o trabalho que, em outro produto, uma tela inteira faria.
Período
Abr/2026 - Jun/2026
Papel
Product Designer
Empresa
OpenMEI
Interface
Cenário
Analisando o uso do app pelo Mixpanel, encontrei algo simples: 73% de tudo que os MEIs faziam na plataforma se resumia a duas ações: emitir guia de serviço e pagar a guia do DAS. No mesmo período, outros mercados já vinham migrando para o WhatsApp, atrás de uma experiência mais direta e resolutiva, sem fricção de instalar mais um aplicativo.
Esses dois sinais juntos me levaram a uma pergunta simples: e se o nosso usuário não precisasse mais do aplicativo pra fazer a única coisa que ele realmente usa?
Responsabilidades
Essa demanda não veio de cima. Nasceu de uma conversa entre mim e a Product Manager, a partir de um padrão que identifiquei nos dados de uso. Fui responsável por validar a hipótese com pesquisa, desenhar o fluxo conversacional e escrever cada mensagem recebida pelo usuário, do texto de confirmação ao aviso de erro. Também apoiei a PM na conversa de precificação com os stakeholders, ainda que a decisão final do modelo de cobrança não tenha sido nossa.
Restrições
Duas restrições reais apareceram no caminho. A técnica foi que optamos por construir o fluxo no N8N, em vez de um sistema proprietário, para acelerar o desenvolvimento. A de posicionamento veio do fato de que o produto seria usado por contadores de marcas diferentes, então não podia carregar a identidade da OpenMEI, o que levou ao nome neutro e "white label" EmitaZap,
Por ser uma iniciativa nossa, e não um requisito top-down, o projeto rodou em paralelo aos outros times, sem concorrer por prioridade, o que na prática foi uma vantagem, já que não precisei justificar hipótese, só mostrar resultado pronto.
Equipe
Uma product manager, eu como designer de produto, um dev sênior de back-end e um dev pleno de back-end. Sem front-end dedicado, já que o produto inteiro roda dentro de uma conversa de WhatsApp.
Problema
Meia dúzia de ações escondidas atrás de um app inteiro
Não era bem um problema, era uma oportunidade mal aproveitada. 73% do uso da plataforma cabia em duas ações, mas o usuário ainda precisava abrir, navegar e aprender um aplicativo inteiro pra chegar nelas. Conversando com os usuários, ficou claro que muitos deles preferiam receber a guia e emitir a nota direto pelo WhatsApp, apenas o que realmente usavam, sem precisar de aplicativo nenhum.
Na prática, estávamos procurando uma forma de "matar" nosso próprio aplicativo, substituindo-o, pelo menos nessas duas tarefas, por uma experiência mais direta.
Processo
Validar rápido quando a tese já nasce certa
Diferente do BPO Financeiro, aqui a fase de pesquisa foi curta. Não porque foi rasa, mas porque a hipótese já nasceu de um padrão de dado real, extraído do próprio uso da plataforma. Isso mudou o papel da pesquisa: em vez de descobrir o problema, ela serviu para confirmar o que os números já indicavam e entender os detalhes que o dado sozinho não mostrava.
Validação
Conversei com 40 pessoas, entre usuários finais e contadores. A resposta foi quase unânime. Dos clientes finais, 92% preferiam resolver tudo pelo WhatsApp, a ponto de pagar mais por isso. Já entre os contadores, a preferência não era pelo canal, mas pela automação. Todos concordaram que, desde que o processo fosse automático, o meio era indiferente pra eles.
Protótipo
O maior desafio não foi relacionado ao fluxo, mas à linguagem. Sem tela pra esconder ambiguidade, cada frase precisa ser clara já na primeira leitura. Usei minha experiência com copywriting pra escrever mensagens diretas, sem duplo sentido e sem o vocabulário técnico que os desenvolvedores tendiam a usar, algo que também não fazia sentido pro ICP de cliente final, MEIs sem bagagem financeira ou técnica.
Construção
A proximidade com os desenvolvedores foi essencial nessa fase. Muita coisa que parecia resolvida no papel só revelava seus pontos cegos quando o fluxo rodava de verdade. Foi um trabalho de ida e volta constante, eu revisava o comportamento real da automação, eles apontavam limitações técnicas, e juntos ajustávamos tanto a lógica quanto a mensagem, sempre que uma implicava mudança na outra.
Ajustes
Testar um produto sem tela exige observar coisas que normalmente passariam despercebidas. O tempo entre mensagens, por exemplo, precisou de calibração fina, rápido demais soava como robô, devagar demais soava como travado. Os casos de erro também pediram atenção redobrada. Sem uma tela para cobrir todos os cenários, cada falha possível precisou da própria mensagem, testada e ajustada com base em como o usuário reagia de verdade.
Desafio
A negociação que veio depois do produto pronto
A parte mais difícil do projeto foi precificá-lo, não construí-lo. Usamos como referência concorrentes como a Contabilizei, que cobra por volta de R$ 60 por usuário só para disponibilizar uma funcionalidade parecida. A proposta original era mais simples que a dos concorrentes: cobrar cerca de R$ 100 extras do contador pelo acesso à funcionalidade, deixando livre pra ele decidir quanto repassar ao cliente final, um modelo ganha-ganha que beneficiava o contador tanto quanto, ou mais, do que a própria OpenMEI.
Os stakeholders gostaram do produto, mas não aprovaram esse modelo de cobrança. O EmitaZap entrou como funcionalidade gratuita, não como add-on pago. Não foi a decisão que defendemos, mas foi a decisão que ficou.
Resultado
Uma vitória quase completa
Redução de abandono no fluxo
Antes das mudanças, 58% dos usuários abandonavam o fluxo antes de concluir a ação, pediam a guia e desapareciam. Depois dos ajustes de copy e timing (incluindo o tempo de encerramento de 20s para 3min), essa taxa caiu para 22%. É a evidência direta de que o trabalho de linguagem não foi só polimento: resolveu um problema real de uso.
Adoção inicial entre contadores
Um mês após o lançamento, e sem divulgação direta para toda a base, 31% dos contadores já haviam adotado o EmitaZap, medido sobre a base total de contadores da plataforma.
Satisfação de quem já usa
CSAT da funcionalidade está em 86%, contra uma média de 61% da mesma funcionalidade oferecida por outros meios (fora do WhatsApp). A diferença é o próprio argumento do case: o canal e a linguagem conversacional não foram só uma aposta de posicionamento, mediram-se em satisfação real.
Projeção de receita não confirmada
A estimativa inicial, considerando uma base de 1.000 clientes e 40% de taxa de adoção, projetava cerca de R$ 40 mil de MRR com o modelo de cobrança original. Como esse modelo não foi aprovado, e o produto entrou como funcionalidade gratuita, essa projeção nunca chegou a ser testada, é apenas um retrato do valor que a funcionalidade deixou de capturar diretamente.
58% → 22%
Redução na taxa de
abandono do fluxo
31%
Contadores que adotaram no 1º mês
86%
CSAT no WhatsApp (61% em outros canais)
R$ 40 mil
MRR projetado
(nunca testado)
Aprendizado
A troca de mensagens continua
O maior aprendizado deste projeto não foi de produto, foi de processo: construir a partir da dor real do usuário, comprovada em dado de uso antes mesmo da pesquisa, tornou toda a validação mais rápida e a conversa com stakeholders mais simples, não precisávamos convencer ninguém de uma hipótese, só mostrar um resultado já pronto.
A exceção foi a precificação, que segue como conversa em aberto. Com a adoção crescendo mesmo sem divulgação ampla, o próximo passo é revisitar o modelo de cobrança com dado real de uso em mãos, não mais como projeção, mas como negociação apoiada em números que o próprio produto já gerou.
A validação da tese também abriu espaço pra pensar maior: se emitir guia e pagar DAS já não precisam de aplicativo, por que o restante da jornada do MEI precisaria? A V2, já em desenho, é o EmitaMEI, que expande o mesmo princípio para abertura de MEI, emissão de nota de produto e cancelamento, tudo dentro do WhatsApp.
