Reduzindo a maior barreira de ativação fiscal para usuários de serviços com pesquisa multi-fonte e quick win cirúrgico
Research-Led
Activation
Fiscal UX
NFS-e
Quick Win
Contexto
Para usuários de serviços, emitir uma NFS-e era uma das duas ações centrais de ativação — ao lado de criar uma venda. O fluxo de emissão tinha alto abandono, pré-requisitos ocultos e múltiplas fontes de atrito sobrepostas.
Problema
Usuários que queriam emitir sua primeira nota fiscal encontravam um fluxo que bloqueava antes mesmo de mostrar o próximo passo. A emissão dependia de pré-requisitos (certificado digital, credenciais da prefeitura) que o produto não comunicava antecipadamente.
Abordagem
Pesquisa multi-fonte estruturada — análise de tickets de suporte, observação de sessões de CS, entrevistas com usuários e mapeamento de fluxo — para identificar os bloqueios reais. Quick win cirúrgico para encurtar o caminho de emissão sem aguardar redesign completo.
Resultado
+13,5% NF-e emitidas · +4,3% NFS-e emitidas · +11% conversão de trial para emissão de nota.
Resultados
+13,5%NF-e emitidasCamada de otimização fiscal
+4,3%NFS-e emitidasFoco do quick win
+1,2%Total de NFS-eBase ampla
+11%Conversão trial → notaIndicador de ativação
Atuação
Participei de uma frente de pesquisa multi-fonte com foco específico no fluxo de emissão de NFS-e — incluindo análise de tickets, observação de sessões de CS e entrevistas com usuários em diferentes estágios de ativação fiscal. Com base nos achados, desenhei um quick win para encurtar o caminho de emissão e facilitar a primeira nota. Atuei em colaboração com outros designers e times de produto durante o projeto.
Estratégia
A tensão do case era de expectativa vs. realidade: o usuário chegava motivado para emitir sua primeira nota fiscal e era barrado por pré-requisitos técnicos que o produto não comunicava antecipadamente. Certificado digital, credenciais da prefeitura, configurações prévias — nenhum desses bloqueios era visível antes de o usuário entrar no fluxo e encontrar o erro.
O atrito não era de usabilidade — era de diagnóstico. Sem evidência sobre onde e por que os usuários abandonavam, qualquer intervenção seria especulação. A decisão de fazer pesquisa multi-fonte antes de qualquer decisão de design foi exatamente por isso: a pesquisa transformou “fluxo com alto abandono” em “usuários barrados por pré-requisito específico em etapa específica” — um problema muito mais acionável.
Processo
A pesquisa foi estruturada para triangular achados entre múltiplas fontes: o que os tickets de suporte diziam sobre os motivos de contato nos primeiros 30 dias, o que as sessões de CS revelavam sobre onde os usuários travavam, e o que as entrevistas mostravam sobre as expectativas dos usuários antes de tentar emitir.
A triangulação foi o mecanismo de confiança: qualquer achado que aparecia em apenas uma fonte era tratado como hipótese. Os que apareciam em duas ou mais fontes eram tratados como diagnóstico. Os pré-requisitos ocultos apareceram em todas as três fontes — com consistência suficiente para justificar intervenção imediata.
O quick win foi desenhado para atacar o ponto de maior abandono identificado na pesquisa: a descoberta tardia de pré-requisitos. A intervenção foi expor os pré-requisitos antecipadamente — com linguagem orientada a ação e caminho claro para resolução — antes de deixar o usuário entrar no fluxo de emissão.
Pesquisa multi-fonte antes do design
Triangulação como mecanismo de confiança
Quick win como velocidade deliberada
Colaboração cross-team
Diagnóstico
Pergunta: Quais são os motivos mais frequentes de contato de usuários de serviços nos primeiros 30 dias?
Achado principal: Pré-requisitos de NFS-e (certificado digital, credenciais da prefeitura) eram o principal driver de contatos nos primeiros 30 dias para usuários de serviços. O problema não era a emissão — era a chegada ao fluxo de emissão sem estar preparado.
Pergunta: Onde os usuários travam quando tentam emitir a primeira NFS-e com auxílio de CS?
Achado principal: Toda sessão de emissão de NFS-e com CS começava com as mesmas perguntas sobre pré-requisitos. O CS atuava como guia de configuração antes de guia de emissão — trabalho que o produto deveria fazer sozinho.
Pergunta: Qual era a expectativa do usuário ao tentar emitir a primeira nota, e o que o impediu?
Achado principal: Usuários esperavam emitir a primeira nota na mesma sessão em que criaram a conta. A descoberta de pré-requisitos técnicos foi consistentemente descrita como surpresa — não como obstáculo esperado.
Solução
Problema: O fluxo de emissão de NFS-e bloqueava o usuário com mensagem de erro após o usuário já ter preenchido campos e iniciado o processo — o pior momento para descobrir que falta algo.
Decisão de design: Verificação de pré-requisitos antes da entrada no fluxo de emissão, não durante. Para cada pré-requisito: status claro (atendido / não atendido) e caminho direto para resolução — sem deixar o usuário descobrir o que precisa fazer por conta própria.
Visuais: tela de verificação de pré-requisitos · estados atendido / não atendido · caminho para resolução
Resultado: Redução do abandono por descoberta tardia de pré-requisitos. Contribuição para +4,3% em NFS-e emitidas e +11% em conversão trial → emissão de nota.
Reflexão
O que este projeto realmente foi
Este case convence porque combina profundidade de pesquisa com ação prática. Mostra a capacidade de identificar fricção sistêmica — não por intuição, mas por triangulação de múltiplas fontes — alinhar múltiplos times em torno de um diagnóstico compartilhado e entregar resultados mensuráveis sem esperar o redesign completo.
O que permaneceu depois
A evidência de +11% em conversão trial → emissão de nota é especialmente significativa porque conecta diretamente ao critério de ativação: emitir uma nota fiscal era uma das duas ações que prediziam retenção de longo prazo. Cada ponto percentual aqui tem impacto direto em LTV e cancelamento.
O que eu faria diferente
O aprendizado mais importante: pré-requisitos técnicos ocultos são um problema de comunicação de produto, não de capacitação do usuário. A decisão de design não foi educar o usuário sobre NFS-e — foi tornar os pré-requisitos visíveis antes de deixar o usuário entrar no fluxo. Essa distinção — comunicar pré-condições vs. ensinar o usuário — é aplicável a qualquer fluxo que dependa de configuração prévia.
Vamos trabalhar juntos?
Disponível para full-time · remote · freelancer
Aberto a novos projetos, oportunidades e conversas.