Formulário de feedback de trial SaaS — capture o bloqueador de conversão enquanto ainda há tempo de endereçar

Para quem é este modelo

Feedback de trial é o formulário que a maior parte dos times de SaaS envia tarde demais. O default é pedir feedback no fim do trial — o dia antes de expirar, ou o dia depois de converter pra pago — e nesse momento o usuário ou decidiu converter ou decidiu não, e o feedback que você recebe é pós-racionalização em vez de sinal acionável. Os times que de fato movem taxa de conversão trial → pago enviam o prompt de feedback deles mid-trial, tipicamente dia 3-7 num trial de 14-dias ou dia 7-14 num trial de 30-dias, quando o usuário teve tempo suficiente pra formar uma opinião mas ainda tem tempo de endereçar os bloqueadores que ele revela. Os campos que preveem conversão: "você já encontrou valor?" (o sinal binário de ativação — usuário que não encontrou valor no mid-trial tipicamente não converte sem intervenção), "o que está bloqueando a compra?" (a objeção específica que pode ser exibida pro seu time de suporte ou venda pra outreach), "percepção de preço" (o preço está dentro do orçamento — o campo mais-subvalorizado em feedback SaaS porque usuário que acha seu preço alto demais cancela silenciosamente em vez de responder a outreach), e status de decisor pra B2B (o sinal de handoff pro time de venda que determina se a conversa precisa escalar). Stripe, Vercel, Linear, Notion, Figma, Datadog, PostHog, os trials de Anthropic Claude Pro e Max, os trials de Cursor Pro, os trials de GitHub Copilot todos rodam variante desse padrão. Este modelo te dá a estrutura mid-trial mais uma versão end-of-trial que captura por que trials não converteram — os dois juntos fecham o loop de feedback na transição economicamente mais-valiosa em SaaS.

De prompt mid-trial a outreach qualificado em 24 horas

O prompt de feedback dispara na marca de mid-trial — dia 3-5 pra um trial de 14-dias, dia 7-10 pra um trial de 30-dias, escalado apropriadamente pra janela de trial mais curta ou mais longa. O gatilho pode ser e-mail, modal in-app, ou ambos (o modal in-app converte mais alto; o e-mail captura usuário que não logou recentemente). O formulário é 5-8 perguntas numa página única, com lógica condicional pra que usuário que se auto-identifica como "tendo encontrado valor" veja um conjunto diferente de perguntas de follow-up que usuário que se auto-identifica como "ainda não encontrando valor." A pergunta de ativação é o primeiro campo — um binário ou escala de 3-pontos que classifica o usuário em encontrou-valor / no-caminho / bloqueado. Usuários que reportam status bloqueado veem follow-up sobre o bloqueador específico (qual feature, qual workflow, qual integração) e o score estilo-NPS de probabilidade-de-conversão. Usuários que reportam status encontrou-valor veem follow-up sobre percepção de preço e contexto de decisor. Percepção de preço é um campo estruturado (tipicamente "dentro do orçamento," "no limite superior," "acima do orçamento mas justificaria por X," "acima do orçamento e não consigo justificar") porque a versão open-text dessa pergunta é ignorada por usuário que não quer negociar. Status de decisor é capturado como "sou o decisor," "estou recomendando pra um decisor," ou "esse é um trial pessoal." Ao enviar, o dado roteia simultaneamente pra product analytics pra tracking de cohort (usuário que reportou status bloqueado e não converteu forma uma cohort que o time de produto aprende com), pra CRM (RD Station — dominante pra B2B brasileiro, HubSpot, Salesforce, Pipedrive, Brevo) pra gatilho de outreach do time de venda quando os critérios batem (decisor = sim + provável-de-converter alto + bloqueador específico que venda pode endereçar), e pro sistema de trial-management pra qualquer oferta in-trial disparada pela resposta (ex.: extensão de trial pra usuário que reporta precisar de mais tempo, downgrade de tier de preço pra usuário que reporta preço como o bloqueador).

O que está incluído

Cada campo abaixo está aqui porque time experiente de conversão de trial aprendeu que prevê a decisão trial-pra-pago. Personalize os campos conforme sua duração de trial e seu ICP, mas mantenha ativação, percepção de preço, e status de decisor porque esses são os três sinais preditivos que a maior parte dos times sub-captura.

Feito pras categorias SaaS onde conversão de trial é a alavanca dominante de receita

• B2B SaaS (o caso de uso primário)

  A categoria onde conversão trial-pro-pago mais diretamente move receita. Taxas padrão de conversão de trial B2B SaaS rodam 15-25% pra produto self-serve, 25-40% pra trial assistido-por-venda; mover esses por mesmo 2-3 pontos percentuais impacta materialmente a trajetória de crescimento da empresa. O prompt de feedback de trial no mid-trial revela os bloqueadores de conversão a tempo de endereçá-los — outreach do time de venda pra usuário de alto-fit que reportou um bloqueador específico que venda consegue resolver tipicamente sobe conversão 5-15% pra cohort respondente. Os campos que importam pra B2B especificamente: status de decisor (pra que o time de venda saiba se esperar uma conversa multi-stakeholder ou um solo trial-user comprando pessoalmente), tamanho do time (pra que o moção de venda case — SMB vs. mid-market vs. enterprise), preferência de tier de preço (a âncora mental do usuário pro que ele pagaria), e o bloqueador específico de feature. Stripe, Notion, Linear, Figma, Vercel, Datadog, PostHog, Snowflake, MongoDB Atlas todos rodam variante. Pra B2B SaaS brasileiro (RD Station, Pipefy, Conta Azul, Bling, Omie, Movidesk, Octadesk, ContaWise), o mesmo padrão aplica com o contexto adicional brasileiro de que conversão pra pago frequentemente envolve um path assistido-por-venda mesmo pra produto que parece self-serve, porque comprador B2B brasileiro espera conversa humana pra compra acima de certo limiar (tipicamente R$2k+/mês).

• Ferramentas de dev (frequentemente free-tier-pra-pago em vez de trial limitado em tempo)

  Modelo diferente de SaaS trial limitado em tempo. A maior parte das ferramentas de dev tem um tier grátis com limite de uso, e o "trial" é o período quando um usuário está se aproximando ou batendo nesses limites — que é quando o prompt de feedback deveria disparar. Limites de tier grátis do Vercel antes de exigir pago, limites de minuto de GitHub Actions, créditos grátis de API Anthropic Claude, créditos grátis de API OpenAI, limite de tier grátis do Cursor, limites do GitHub Copilot Free tier, limites de evento do PostHog free tier, limite de processamento do Stripe antes da taxa escalar. O feedback no momento "se aproximando do limite" revela se o usuário está batendo limite porque está obtendo valor (sinal positivo — provável de converter) ou porque está testando sem intenção genuína (sinal negativo — improvável de converter sem intervenção). Os campos pra ferramenta de dev diferem em vocabulário: linguagem e framework, escala de projeto, tamanho do time, disposição pra upgrade vs. workaround, preferência de modelo de preço (por-usuário vs. uso-baseado vs. fixo). Pra trial de ferramenta de dev especificamente, a pergunta open-text "o que te desbloquearia pra fazer upgrade" tende a ser incomumente de alto-sinal porque usuário desenvolvedor articula o atrito específico dele melhor que outras personas.

• Assinatura consumidor com trial

  Netflix, Spotify, Apple Music, Disney+, Apple TV+, Apple Fitness+, Amazon Prime, Audible, Kindle Unlimited, Calm, Headspace, MasterClass; no Brasil Globoplay, HBO Max Brasil, Disney+ Brasil, Spotify Brasil — todos usam trial grátis limitado em tempo (tipicamente 7, 14, ou 30 dias) que converte pra pago automaticamente a menos que o usuário cancele antes do fim do trial. O prompt de feedback de trial aqui é menos sobre influenciar a decisão de conversão (assinatura consumidor converte automaticamente) e mais sobre (1) reduzir churn involuntário de usuário que teria querido cancelar mas não notou o fim do trial, e (2) reunir feedback de qualidade-de-conteúdo e qualidade-de-descoberta que informa decisão de produto. Prompts mid-trial em assinatura consumidor são frequentemente gateados pra usuário engajado (o usuário usou o produto N vezes) pra que o feedback reflita experiência real em vez de aleatoriedade de janela-de-trial. Pra assinatura consumidor brasileira, o mesmo padrão aplica com prompt em português e feedback de disponibilidade-de-conteúdo sendo especialmente importante porque direito de streaming brasileiro difere do dos EUA.

• SaaS vertical (produto específico de indústria)

  Feedback de trial pra SaaS vertical captura bloqueador específico-de-indústria que SaaS horizontal não exibe. Um SaaS vertical pra restaurante captura "integra com meu PDV?" como o bloqueador dominante; um SaaS vertical pra clínica captura "integra com meu prontuário eletrônico?" como o bloqueador dominante; um SaaS vertical pra construção captura "funciona com a ferramenta de gestão de projeto que já usamos?" O bloqueador-de-integração é tão frequentemente o sinal dominante de feedback de trial em SaaS vertical que o formulário deveria exibi-lo como um campo estruturado com as integrações comuns nomeadas como opção multi-select. Pra SaaS vertical brasileiro, as âncoras de plataforma locais importam: PDV (Stone POS, Linx, Sischef, Saipos) pra restaurante; prontuário (Tasy, MV, Memed, iClinic, Doctoralia) pra clínica; construção (Sienge, Builders 360, Construmanager) pra construtora.

• Produtos de IA com crédito de trial ou período de trial

  A categoria SaaS de crescimento mais-recente pra dinâmica de trial. Anthropic Claude Pro e Max trial, Cursor Pro trial, GitHub Copilot trial, Perplexity Pro trial, Gemini Advanced trial, ChatGPT Plus trial, os trials de produto de IA de idioma local. O feedback pra produto de IA difere em conteúdo de outro SaaS porque a percepção de valor é incomumente pessoal — "o modelo pareceu inteligente na minha tarefa" vs. "o modelo não entendeu o que eu estava perguntando" é um sinal mais importante que paridade de feature. Os campos que importam: caso de uso principal (escrita / código / pesquisa / atendimento ao cliente / análise de dado), percepção de performance do modelo (como a IA comparou com expectativa), caso específico de falha (onde o modelo não foi bem), e o intent de integração (API / web / extensão / mobile). Pra trial de produto de IA brasileiro, performance específica-de-idioma é crítica — "quão bem o modelo respondeu em português?" é uma pergunta separada de "quão bem o modelo respondeu em inglês?" porque a maior parte dos modelos foundation ainda tem performance mais forte em inglês que em português.

• Software enterprise (trial mais longo, decisão multi-stakeholder)

  Dinâmica de trial diferente de SaaS self-serve. Trial enterprise tipicamente roda 30-90 dias (vs. 7-14 pra self-serve), envolve múltiplo stakeholder do lado-comprador (o usuário avaliando, o gerente do usuário, o time de TI/segurança, procurement), e exige um processo mais estruturado de trial-management. O prompt de feedback pra trial enterprise é tipicamente menos uma pesquisa self-serve e mais um check-in estruturado de account-management — o customer-success manager envia o formulário como parte de touchpoint semanal de status-de-trial. Os campos que importam: status de stakeholder (qual cargo está respondendo — avaliador, decisor, revisão de TI/segurança, procurement), caso de uso específico validado (ou não), status de revisão de segurança/conformidade (passou / em progresso / bloqueado / não iniciado), requisito de integração avaliado (passou / em progresso / bloqueado / não iniciado), e prazo pra decisão. Pra SaaS enterprise brasileiro (TOTVS, Senior Sistemas, Linx pra varejo, portfólio Movile), a mesma dinâmica enterprise-trial aplica com item específico brasileiro de conformidade (status de revisão LGPD, conformidade fiscal pra fornecedor SaaS) adicionado à checklist.

Ajuste o formulário pra sua duração de trial, seu ICP, e sua moção de conversão

Comece com o timing. Prompt mid-trial no dia 3-5 de um trial de 14-dias, dia 7-10 de um trial de 30-dias, dia 15-30 de um trial enterprise de 90-dias. Prompt end-of-trial no dia 12-13 de um trial de 14-dias, dia 28-29 de um trial de 30-dias, dia 85-90 de um trial enterprise de 90-dias. Envie os dois — o mid-trial captura o sinal in-window que influencia conversão, o end-of-trial captura o sinal pós-decisão de por-que-não-converteu. Decida se o prompt é só-e-mail, só-in-app, ou ambos. A abordagem dupla (e-mail mais in-app) converte mais alto porque e-mail alcança usuário que não logou essa semana e in-app alcança usuário ativamente engajado. Personalize a pergunta de ativação pro seu produto — "você completou X?" é mais específico que "você encontrou valor?" e produz sinal mais acionável quando X é o evento-chave de ativação do seu produto. Personalize a pergunta de percepção de preço pra seus tiers de preço — exiba o tier específico que você espera que o usuário escolha e pergunte se bate com o orçamento dele. Pra B2B, o campo de status de decisor é não-opcional — a moção de outreach do time de venda depende inteiramente de se o usuário está comprando pessoalmente, recomendando pro time dele, ou avaliando em nome de um processo maior de procurement. Adicione lógica condicional de save-attempt pra usuário que reporta "não vai converter" — exiba extensão de trial pra usuário que precisa de mais tempo, downgrade de tier pra usuário que reporta preço como o bloqueador, ajuda-de-integração pra usuário que reporta integração como o bloqueador. Envie as respostas pra product analytics, pra CRM (RD Station como destino dominante pra B2B brasileiro), e pro sistema de trial-management. Traduza o formulário pros idiomas dos seus usuários de trial.

Perguntas frequentes sobre feedback de trial SaaS

Modelos relacionados