SaaS Conversion Playbook — Auditoria de Onboarding, Paywall e Ativação

Transforma a descrição de um produto (URL, pitch ou telas) num relatório operacional de conversão: classificação de playbook, telas a criar/reescrever, paywall, gatilhos in-app, lifecycle de e-mail e backlog de 4 semanas. Não implementa código — entrega spec pronta para handoff.

Governança Global

Segue GLOBAL.md, policies/source-driven.md, policies/handoffs.md e policies/evals.md. Toda métrica-alvo citada vem de references/playbook.md; não inventar número fora dessas faixas. Hipótese sem evidência direta do produto recebe o rótulo HIPOTESE — nunca vira fato no relatório.

Fronteira com skills vizinhas:

• 01-po-feature-spec decide se cobrar e qual a proposta de valor — esta skill decide como o funil converte visitante em pagante, dado que a decisão de produto já existe
• 63-mobile-paywall-checkout é a UI/UX de checkout mobile (Play Billing, Stripe, estados de pagamento) — esta skill decide a estratégia de onboarding/paywall/lifecycle que antecede o checkout; a 63 implementa a tela, esta skill diz quando ela aparece e o que ela precisa comunicar
• 59-closed-loop-revenue fecha o loop de atribuição de mídia paga com receita — esta skill cobre o funil de produto (onboarding → ativação → paywall), não aquisição paga
• 21-data-analytics define taxonomia de evento de produto em geral — esta skill usa esse padrão para os eventos específicos de ativação/paywall/trial listados aqui

Quando Usar

• auditar o onboarding, paywall ou funil de trial de um produto existente
• desenhar do zero as telas de ativação e conversão de um SaaS novo
• decidir entre freemium, trial com/sem cartão, hard paywall ou reverse trial
• diagnosticar por que trial-to-paid ou free-to-paid está abaixo do benchmark
• escrever copy de paywall, e-mail de trial ou fluxo de cancelamento

Quando Não Usar

• decidir preço, tiers ou proposta de valor do zero — isso é 01-po-feature-spec
• implementar a tela de checkout mobile (Play Billing/Stripe/estados de pagamento) — 63-mobile-paywall-checkout
• instrumentar atribuição de campanha paga ou reconciliar receita com ads — 59-closed-loop-revenue
• definir taxonomia geral de evento de produto fora do funil de conversão — 21-data-analytics

Entradas Esperadas

• URL, pitch, prints de tela ou descrição textual do produto
• modelo comercial atual (free permanente, trial com/sem cartão, hard paywall, usage, ainda não cobra)
• plataforma (web, iOS/Android, ambos), ticket aproximado e se a compra é solo ou com comitê
• resposta candidata a "que ação na primeira sessão faria o usuário voltar amanhã" (candidato a aha)

Se qualquer um desses faltar, usar references/intake.md — no máximo 5 perguntas por turno, nunca bloquear o relatório: assumir e marcar HIPOTESE.

Saídas Esperadas

Relatório markdown (ou PDF se pedido) seguindo references/report-schema.md:

• veredito em uma página com frase-prova do aha e 5 mudanças priorizadas por vazamento
• classificação Playbook A/B (ou híbrido) com justificativa
• evento de ativação proposto + como instrumentar
• telas a criar/reescrever com objetivo, copy e evento de analytics cada
• paywall completo (headline, timeline honesta, planos, downsell, FAQ)
• matriz de gatilhos in-app e sequência de lifecycle de e-mail
• backlog de 4 semanas e lista explícita do que fica fora de escopo

Fluxo Obrigatório

1. Coletar o sistema. Aceitar URL, pitch, print, lista de telas ou "é um SaaS de X". Havendo URL, abrir e extrair proposta, planos, signup e onboarding visível antes de perguntar qualquer coisa que já esteja ali.
2. Fechar lacunas com references/intake.md — no máximo 5 perguntas, não bloquear o relatório.
3. Classificar A ou B com a regra de references/playbook.md: o aha é um plano revelado (A) ou um artefato criado (B)? Escrever a frase-prova ("o aha é X"). Híbrido = playbook dominante + 2 empréstimos do outro, nunca metade de cada.
4. Diagnosticar a barreira de decisão antes de propor persuasão. Nomear o comportamento desejado, o ponto da jornada e a evidência disponível. Se a barreira ainda não estiver clara, usar COM-B (capacidade, oportunidade, motivação) para localizar o bloqueio; usar Fogg (motivação, facilidade, prompt) como checagem rápida da ação proposta. Tratar esses modelos como hipóteses de trabalho, não como prova sobre um usuário individual. Escolher no máximo um mecanismo psicológico por recomendação e explicar como ele reduz uma barreira real.
5. Aplicar a salvaguarda ética. A comunicação deve ajudar a pessoa a decidir com informação suficiente: preço e renovação visíveis, urgência e escassez verificáveis, opção de recusar/cancelar clara, e nenhuma culpa, ameaça ou perda fabricada. Defaults só são aceitáveis quando a escolha continua explícita e reversível. Não usar vieses para esconder custo, restringir saída ou pressionar alguém em situação vulnerável. Para cada hipótese, definir uma métrica de resultado e ao menos um guardrail de dano (por exemplo, reembolso, cancelamento precoce, reclamação ou suporte).
6. Mapear funil atual vs. canônico — toda recomendação tem tela, gatilho, copy e evento.
7. Escrever o relatório no schema de references/report-schema.md, no idioma do usuário (default pt-BR), adaptando assets/copy-bank.md ao vocabulário real do produto. A seção de paywall usa references/paywall-flow.md para decidir momento, número de páginas e alavanca dominante antes de preencher os 14 blocos. Quando o pedido é só o paywall, entregar no formato "Entrega" daquele arquivo em vez do relatório completo.
8. Checkpoint antes de entregar: reler as métricas-alvo citadas contra a tabela de references/playbook.md — todo número fora dessas faixas ou sem rótulo HIPOTESE volta pra correção antes do relatório sair. Confirmar que nenhuma tela ficou sem evento de analytics.
9. Oferecer o próximo passo (wireframe da tela 1, ou o backlog priorizado) — não implementar código a menos que o usuário peça explicitamente.

Regras de Diagnóstico

• Não prescrever quiz de 6-12 telas para ferramenta B2B; não prescrever cadastro seco sem diagnóstico para app de resultado pessoal — ver tabela comparativa em references/playbook.md.
• Oferta comercial já na sessão 1; hard paywall só depois do reveal/aha, nunca antes.
• Downsell no ponto de saída é estender o trial (ex: 7→14 dias), não "50% OFF eterno".
• Paywall de feature usa a copy da tarefa específica + preview real — nunca "Upgrade to Pro" genérico.
• Aftercare é obrigatório depois de trial ou pagamento confirmado; dashboard vazio pós-checkout é defeito.
• Toda tela do relatório tem objetivo, headline, CTA, critério de saída e evento de analytics — sem exceção, mesmo quando a tela é simples.
• Escolher o modelo comercial pela conta de R/1K (visitante→registro × registro→pago × ARPU), nunca por uma percentagem isolada fora de contexto.

Anti-Padrões

• Entregar relatório genérico sem o nome real do produto e sem vocabulário específico dele
• Tour linear de 12 telas, e-mail bloqueante de verificação, plano exigido no signup, countdown falso
• Prompt nativo de permissão de push na abertura, sem pre-permission explicando o porquê antes
• Chat ao vivo como alavanca default em produto consumer de ticket baixo
• Prometer lift percentual específico como garantia deste relatório — benchmarks são faixa, não promessa
• Copiar duração de trial do concorrente sem calcular contra o TTV (time-to-value) do próprio produto
• Usar escassez, aversão à perda, defaults ou progresso incompleto para pressionar sem base real, ocultar condições, dificultar recusa/cancelamento ou explorar vulnerabilidade

Evidência de Conclusão

• classificação A/B/híbrido justificada com frase-prova do aha
• toda métrica-alvo citada rastreia para uma faixa de references/playbook.md, com HIPOTESE explícito onde não há dado direto do produto
• cada tela recomendada tem objetivo, copy, critério de saída e evento nomeado
• paywall cobre os 14 blocos de references/playbook.md, sem os itens da lista de proibidos
• backlog de 4 semanas começa por ativação, não por redesign de marca

Handoff

Recebe de

• 01-po-feature-spec — proposta de valor e decisão de que o produto cobra por assinatura

Entrega para

• 63-mobile-paywall-checkout — decisão de modelo comercial e momento do paywall, para a UI de checkout mobile implementar
• 21-data-analytics — lista de eventos de ativação/paywall/trial para entrar na taxonomia geral
• 13-marketing-copy ou 50-direct-response-copy — copy de paywall e e-mail como ponto de partida para variações e testes A/B
• 82-retention-loops — o que acontece depois que o trial converte (hábito, ativo durável, D7/D30)
• 83-growth-action-plan — quando o pedido é o plano de 4 semanas completo; ela consome este playbook para as seções de funil, paywall e eventos

Integração com Pipeline

01 po-feature-spec (decide cobrar) -> 73 saas-conversion-playbook (desenha o funil) -> 63 mobile-paywall-checkout (implementa a UI) -> 21 data-analytics (instrumenta).

Recursos

• references/playbook.md — classificação A/B, telas de onboarding, 14 blocos de paywall, 8 gatilhos in-app, modelos comerciais com R/1K, lifecycle e métricas-alvo com benchmark
• references/paywall-flow.md — paywall como fluxo: momento, arquitetura (1/2/3–4 páginas, feature-gate, win-back), três alavancas, padrões nomeados, casos (ANALOGIA), ordem de teste
• references/report-schema.md — estrutura obrigatória do relatório, seção a seção
• references/intake.md — perguntas mínimas e tabela de inferência permitida
• assets/copy-bank.md — frases prontas em PT-BR para adaptar ao vocabulário do produto

Fontes

Conteúdo consolidado a partir de material de benchmark de conversão SaaS fornecido pelo usuário (pesquisa própria de mercado sobre onboarding, paywall e lifecycle de assinatura), adaptado ao formato e às convenções deste kit.

O diagnóstico comportamental COM-B e Fogg foi inspirado em conceitos resumidos pela skill marketing-psychology (Corey Haines, MIT License; consultada em 2026-10-19). Esta skill usa uma seleção própria, com salvaguardas de escolha informada; não incorpora o catálogo nem a redação da fonte.

references/paywall-flow.md e as variações de copy de paywall/downsell (2026-09-27) vieram da skill paywall-flow-design de um pacote consolidado pelo usuário, que resume o estudo da Mobbin com Jonathan Parra sobre 2995 paywalls. A skill saas-conversion-audit do mesmo pacote era idêntica a esta (mesmo playbook, intake e copy) e não trouxe nada novo.