O Erro Mais Comum em SaaS de Billing
O pagamento do cliente falhou. O que seu sistema faz?
Se a resposta é "bloqueia o acesso imediatamente" — você está destruindo receita.
A grande maioria das falhas de pagamento são involuntárias: cartão expirado, limite temporário, problema no gateway. O cliente quer continuar pagando. Mas se você corta o acesso no primeiro segundo, a mensagem que ele recebe é: "você não importa".
Resultado? Churn. Suporte desnecessário. Receita perdida que nunca precisava ser perdida.
Como os Grandes SaaS Lidam com Isso
Fui estudar o que Spotify, Netflix, Slack e Notion fazem quando um pagamento falha:
| Empresa | Abordagem |
|---|---|
| Spotify | 3-7 dias de acesso normal após falha no pagamento |
| Netflix | 3 avisos antes de suspender, ~7 dias de grace period |
| Slack | Degrada features gradualmente (read-only) antes de cortar |
| Notion | 100% read-only por 30 dias antes de qualquer corte |
O padrão é claro: ninguém corta no primeiro dia. Todos usam alguma combinação de:
- Grace period — acesso normal por X dias após a falha
- Degradação progressiva — features limitadas antes do bloqueio total
- Comunicação multicanal — email + in-app + WhatsApp/push
- Cancelamento só depois de muito tempo — 30+ dias
Isso tem nome: dunning. É o processo de recuperar pagamentos falhos antes que virem churn.
O Fluxo de Dunning Que Implementei
Depois de estudar esses exemplos, desenhei um fluxo de 4 fases para o Sistema Reino:
Fase 1: Grace Period (Dia 0-7)
O pagamento falhou, mas o acesso continua 100% normal. O cliente recebe:
- Email no dia 0: "Houve um problema com seu pagamento"
- WhatsApp no dia 1: mensagem empática + link/PIX pra pagar
- Banner amarelo no sidebar: "Pagamento pendente — regularize em X dias"
- Email no dia 3: lembrete com link de pagamento
O cliente nem percebe que algo mudou no sistema — só vê os avisos. Isso dá tempo pra resolver sem fricção.
Fase 2: Read-Only (Dia 7-14)
Se não pagou em 7 dias, o acesso degrada para somente leitura:
- Pode consultar todos os dados normalmente
- Não pode criar, editar ou deletar nada
- Banner vermelho: "Acesso limitado — somente leitura"
- Email + WhatsApp: "Seu acesso foi limitado, regularize"
Isso é poderoso porque o cliente vê seus dados ali, sabe que estão seguros, e sente urgência pra resolver. É muito diferente de um paywall que esconde tudo.
Fase 3: Bloqueio Total (Dia 14-30)
Agora sim, paywall. O cliente precisa pagar pra acessar qualquer coisa. Mas ainda recebe comunicação:
- Email: "Acesso suspenso, seus dados estão seguros"
- Página de paywall com opção de pagamento direto
Fase 4: Cancelamento Automático (Dia 30+)
Após 30 dias sem pagamento, a assinatura é cancelada automaticamente no gateway. Email final: "Sua assinatura foi cancelada. Volte quando quiser."
Isso faz a higiene da base — sem assinaturas zumbis penduradas indefinidamente.
A Cadência Completa
| Dia | Canal | Acesso | Ação |
|---|---|---|---|
| 0 | Normal | "Houve um problema" | |
| 1 | WhatsApp + PIX | Normal | Mensagem empática |
| 3 | Email + WhatsApp | Normal | Lembrete |
| 5 | Normal | Urgência | |
| 7 | Email + WhatsApp | Read-only | "Acesso limitado" |
| 10 | Read-only | Reforço | |
| 14 | Bloqueado | "Acesso suspenso" | |
| 30 | Cancelado | "Assinatura cancelada" |
Diferenciação por Método de Pagamento
Um detalhe importante: a mensagem muda conforme o tipo de pagamento.
- Cartão de crédito: "Parece que houve um problema com seu cartão. Atualize seus dados de pagamento."
- PIX/Boleto: "Seu pagamento está pendente. Aqui está o código PIX atualizado."
Parece óbvio, mas muitos SaaS mandam a mesma mensagem genérica pra todo mundo.
Decisão Arquitetural: Calcule, Não Armazene
A tentação é criar um novo status tipo grace_period ou read_only no banco. Não faça isso.
O que fiz: mantive o status past_due (que o próprio gateway já envia) e calculo o nível de acesso dinamicamente baseado em quantos dias se passaram desde o início do dunning.
past_due + 0-7 dias → acesso normal (grace)
past_due + 7-14 dias → read-only
past_due + 14+ dias → bloqueado
past_due + 30+ dias → canceladoVantagens:
- Zero estados novos — compatível com qualquer gateway (Stripe, Asaas, etc.)
- Sem migrations complexas — só precisa de um campo
dunning_started_at - Menos bugs — menos estados = menos transições = menos edge cases
Por Que Isso Importa: Os Números
Segundo a ProfitWell, 20-40% do churn em SaaS é involuntário — causado por falhas de pagamento, não por decisão do cliente.
Um fluxo de dunning bem implementado tipicamente recupera 50-70% desses pagamentos. Isso significa que se você tem 100 clientes inadimplentes por mês, está perdendo 50-70 deles desnecessariamente por não ter grace period.
A conta é simples: se seu ticket médio é R$50/mês e você perde 50 clientes/mês por involuntary churn, são R$2.500/mês de receita recuperável. R$30.000/ano. Só implementando um fluxo que leva um dia pra construir.
Checklist: Implemente Antes de Precisar
Se seu SaaS ainda não tem dunning, aqui vai o mínimo viável:
- Grace period de 7 dias — não corte acesso imediatamente
- Email no dia 0 — avise que o pagamento falhou
- Banner in-app — impossível de ignorar
- Diferenciação cartão vs. PIX/boleto — mensagem certa pro contexto certo
- Read-only antes de bloquear — degrada, não mata
- Cancelamento automático após 30 dias — higiene da base
- Tracking — saiba quantos você recuperou vs. perdeu
O custo de implementar é baixo. O custo de não ter é perder clientes que queriam continuar pagando.
Pagamento falhou ≠ cliente quer sair. Trate inadimplência como um problema a resolver, não como uma sentença.
