Produto SaaS
Lançamento de funcionalidade: como comunicar para a base sem ruído
Nem toda funcionalidade nova pede campanha. Uma matriz simples ajuda o dono a decidir onde gastar a atenção da base, qual canal usar e qual evento de uso indica adoção em 30 dias.
Para decidir se uma novidade merece campanha, veja qual tarefa ela muda, para quais clientes e quanta instrução exige. Ajustes pequenos podem ficar no changelog; mudanças que pedem uma ação precisam chegar ao segmento afetado. O aviso deve deixar claro o que o cliente pode fazer com o recurso.
Comece pela tarefa que muda, não pela funcionalidade
Descreva o lançamento pela tarefa que o cliente passa a executar, e não apenas pelo que a equipe construiu. O handbook do GitLab é uma referência: a empresa diz medir resultados, não só lançamentos, e pede instrumentação das métricas de sucesso. Adaptamos essa ideia à decisão de comunicação apresentada aqui.
Antes de decidir o nível do aviso, responda a quatro perguntas: quem usa hoje o fluxo que mudou, qual tarefa fica mais curta ou possível, o que o cliente precisa fazer para começar e qual ação dentro do produto mostra que ele começou. Se não houver resposta para a última, ainda não dá para planejar a comunicação.
Uma matriz de três níveis
Uma forma de avaliar é classificar cada novidade em impacto (quanto muda a tarefa), público (quantos clientes e que perfil) e esforço (quanta instrução ou configuração o cliente precisa). A tabela abaixo é um ponto de partida para adaptar, sem pesos universais. O evento de adoção descreve um uso real do produto, e a classificação depende de a equipe conseguir registrar esse evento.
| Nível | Perfil do lançamento | Canal | Mensagem | Evento de adoção em 30 dias |
|---|---|---|---|---|
| 1: changelog | Ajuste pequeno, impacto baixo, sem ação do cliente | Changelog e nota na versão | O que mudou, em duas linhas | Opcional: acesso à tela alterada, lembrando que acesso não prova que a tarefa foi feita |
| 2: aviso segmentado | Muda a tarefa de um grupo específico, exige pouca instrução | E-mail ou aviso dentro do produto, só para o segmento | Qual tarefa melhora e como ativar, com um passo claro | Primeira execução da tarefa com o novo recurso, medida sobre as contas do segmento avisado |
| 3: campanha | Muda o uso de boa parte da base ou exige configuração relevante | Sequência de e-mails, aviso no produto, material de apoio e contato do time de contas | Contexto, instrução passo a passo e onde pedir ajuda | Uso repetido do recurso por contas do segmento, em mais de um dia, com a janela e o denominador definidos antes |
Os níveis não são rígidos, e há um requisito antes de classificar o lançamento: se o recurso exige ação do cliente para funcionar, ou se o uso errado pode causar problema, a novidade merece pelo menos um aviso segmentado, mesmo quando os demais critérios sugerem um aviso menor. Do mesmo modo, uma novidade pequena para a base inteira pode ficar no nível 1, e uma grande para poucos clientes pode pedir um contato direto em vez de campanha. O ponto é que a decisão fique registrada antes do envio, com o evento de adoção definido.
Segmente pelo uso atual e meça pelo evento
A Salesforce, no material do Trailhead sobre retenção, trata a comunicação com clientes existentes como parte da jornada, com campanhas de onboarding, upsell e renovação, e recomenda focar nos benefícios para que a mensagem não pareça mais um pitch. O material trata de campanhas de nutrição, não de avisos de funcionalidade, então a aplicação aqui é nossa: o cliente que já usa o fluxo afetado recebe a instrução, e quem nunca o usou talvez precise de outra mensagem, ou de nenhuma.
Considere um exemplo hipotético de SaaS de gestão de contratos: uma exportação de relatórios em PDF com o logo do cliente. O aviso vai para contas que já geram relatórios todo mês e explica como enviá-los sem refazer a formatação. O evento de adoção é a primeira exportação com logo; quem não usa esse fluxo acompanha a novidade pelo changelog. O exemplo não descreve uma função disponível em todos os produtos ou planos.
Abertura de e-mail e clique são sinais de interação com a mensagem, mas nenhum dos dois indica que o conteúdo foi lido ou compreendido, nem que o cliente passou a usar o recurso. Por isso eles servem como apoio para diagnosticar o aviso, e a adoção deve ser medida por um evento de uso no produto. Se quiser aprofundar a leitura do uso, o texto sobre taxa de uso de produto SaaS ajuda a separar o que a métrica indica do que ela não prova. Para clientes recém-chegados, o aviso do lançamento deve conversar com o que já foi tratado no onboarding, para não competir com ele.
Como ler os 30 dias
Defina a janela e o grupo antes: por exemplo, contas do segmento avisado que executaram o evento ao menos uma vez nos 30 dias seguintes ao envio, divididas pelo total de contas daquele segmento no dia do envio. Se o uso aparecer, ainda não dá para dizer que foi o aviso que causou, porque parte dos clientes descobriria o recurso sozinha. Uma comparação possível, quando o volume permitir, é manter um subgrupo sem aviso, mas isso só faz sentido se o recurso estiver disponível para todos e a decisão for aceitável para a operação. Se a diferença entre os grupos for pequena ou o volume for baixo, o resultado fica inconclusivo, o que não prova que o aviso tenha o mesmo efeito que o silêncio.
Ao revisar os últimos cinco lançamentos, ligue cada aviso a um evento que mostre uso no produto. Se esse registro não existe, a prioridade pode ser instrumentar a medição antes de investir em outra campanha para a base.
