O Diagnóstico de Sites SaaS que Sua Agência Pode Reutilizar sem Fazer os Clientes Parecerem Iguais

Resumo

Quantas vezes neste trimestre você fez exatamente a mesma chamada de descoberta—mesmas perguntas sobre o produto, o cliente, o concorrente—para dois clientes que insistiam que eram completamente diferentes? Você já sabe que as respostas serão diferentes, mas as tarefas que cada site SaaS precisa realizar não são. Todo site de produto SaaS é um pequeno conjunto de máquinas que executam as mesmas tarefas: explicar o que o produto faz, mostrar quanto custa, dizer aos desenvolvedores como integrar, responder às objeções que impedem uma compra e provar que a empresa é confiável. Um diagnóstico repetível que audita essas cinco tarefas sobreviverá ao contato com qualquer cliente, porque as tarefas não mudam. O sistema que você constrói em torno dele é o que permite passar de um projeto para o próximo sem começar do zero. Leva menos tempo do que o seu processo atual de descoberta, dá ao cliente uma razão clara para confiar em você e produz um entregável que não parece um modelo, porque as perguntas são padrão, mas as respostas são específicas.

Quantas vezes neste trimestre você fez exatamente a mesma chamada de descoberta—mesmas perguntas sobre o produto, o cliente, o concorrente—para dois clientes que insistiam que eram completamente diferentes? Você já sabe que as respostas serão diferentes, mas as tarefas que cada site SaaS precisa realizar não são. Todo site de produto SaaS é um pequeno conjunto de máquinas que executam as mesmas tarefas: explicar o que o produto faz, mostrar quanto custa, dizer aos desenvolvedores como integrar, responder às objeções que impedem uma compra e provar que a empresa é confiável. Um diagnóstico repetível que audita essas cinco tarefas sobreviverá ao contato com qualquer cliente, porque as tarefas não mudam. O sistema que você constrói em torno dele é o que permite passar de um projeto para o próximo sem começar do zero. Leva menos tempo do que o seu processo atual de descoberta, dá ao cliente uma razão clara para confiar em você e produz um entregável que não parece um modelo, porque as perguntas são padrão, mas as respostas são específicas.

'Os meus clientes são demasiado diferentes para um sistema'

Aplique o mesmo diagnóstico de cinco pontos em cada cliente antes de escrever uma palavra de texto ou abrir uma ferramenta de design. As diferenças que tornam os seus clientes especiais—setor, público, modelo de preços—assentam numa base comum. Um SaaS de folha de pagamento e uma ferramenta de agendamento de redes sociais não têm nada em comum exceto as cinco tarefas que cada página está a realizar. Se auditar essas tarefas, encontrará os mesmos padrões nos mesmos lugares.

Página ou secção	O que o seu cliente normalmente pede	O que está realmente a acontecer na página
Mostruário de funcionalidades	'Mostra todas as funcionalidades que construímos'	Mostrar o resultado que o utilizador obtém, não apenas a função. Elementos visuais como capturas de ecrã, GIFs ou vídeos devem demonstrar um momento em que o produto muda a forma como alguém trabalha.
Preços	'Torna os preços fáceis de ler'	O comprador é forçado a decidir qual plano é para ele. Os escalões devem ler-se como uma progressão que guia uma escolha, não uma lista plana de preços.
Documentação da API	'Os nossos desenvolvedores encontrarão isso na documentação'	Frequentemente o primeiro teste que um desenvolvedor realiza ao avaliar se o produto é confiável. A clareza aqui é uma funcionalidade, não um luxo.
Secção de FAQ	'Responder a perguntas para que as chamadas de suporte diminuam'	A última coisa que um comprador lê antes de clicar num botão. Deve lidar com objeções de preço e casos extremos, não apenas perguntas genéricas da empresa.
Prova social	'Coloca os logótipos'	A evidência de que as afirmações feitas anteriormente são verdadeiras. Logótipos e testemunhos são indicadores de confiança, não decoração.

Um diagnóstico não é um modelo. É um conjunto de perguntas que faz a cada página: isto faz com que o comprador entenda o que o produto faz, torna o próximo passo óbvio, responde à objeção que está atualmente a bloquear a venda? Quando faz estas perguntas com o cliente presente, o cliente vê-o como a pessoa que entende o mercado dele, em vez de ser a décima agência que mostrou uma apresentação de slides. A investigação sobre sites SaaS aponta para empresas como HubSpot, Slack e Zendesk como exemplos de secções de FAQ bem organizadas, e para Stripe, GitHub e Twilio como padrões de clareza na documentação. Nenhuma dessas empresas chegou lá tratando a FAQ como uma pilha de tickets de suporte. Trataram-na como uma superfície de conversão. Essa é a atitude que o seu diagnóstico precisa de trazer a cada cliente.

Considere um cliente que vende software de inventário e outro que vende software de folha de pagamento. O diagnóstico frequentemente revela as mesmas três lacunas: a página de funcionalidades menciona módulos em vez de resultados, a página de preços não justifica o salto entre planos, e a FAQ responde a perguntas de suporte em vez de hesitações de compra. Como já viu estas lacunas em ambos, sabe exatamente o que pedir na fase de design. O cliente vê um processo específico, não genérico. Escreva o diagnóstico como um PDF de uma página com uma pontuação de 1 a 5 para cada tarefa, e uma nota para cada uma. Partilhe com o cliente antes do início do design. Isto dá-vos um vocabulário comum e transforma a auditoria num entregável pelo qual pode cobrar. Este é o núcleo de um sistema repetível, e temos uma explicação separada de como configurar esse sistema aqui.

'Vai fazer o nosso trabalho parecer-se com o de toda a gente'

Padronize as perguntas que faz, não as respostas que entrega. O diagnóstico dá-lhe uma rubrica de pontuação, não um layout. A investigação sobre mostruários de funcionalidades SaaS mostra que usam elementos visuais como capturas de ecrã, GIFs ou vídeos—mas o conteúdo desses elementos visuais é diferente para cada produto. A funcionalidade de relatórios salariais numa ferramenta de RH e a funcionalidade de leitura de códigos de barras em software de inventário nunca serão iguais. O que permanece constante é a pergunta que coloca à sua mente estratégica: 'Esta página mostra o resultado, ou apenas a função?'

O formulário de admissão de um médico não torna todos os diagnósticos iguais; torna o médico fiável. O seu enquadramento é o formulário de admissão. O cliente continua a receber um site personalizado, mas você obtém um diagnóstico que é repetível. O que realmente fará o seu trabalho parecer genérico é a falta de um diagnóstico—porque sem ele, recorre à mesma imagem de destaque, ao mesmo layout de funcionalidades em três colunas, à mesma estrutura de página inicial que usou no último projeto apenas para ser rápido. O diagnóstico obriga-o a justificar a estrutura a partir das evidências, para que cada site seja estruturalmente diferente onde precisa de ser.

Na prática, isto significa que o diagnóstico pode dizer-lhe para começar a página de funcionalidades de um cliente com um vídeo de um assistente de importação e a de outro com um GIF de um construtor de relatórios por arrastar e largar. A estrutura da página permanece a mesma, mas os recursos, o texto e o ritmo são únicos. O cliente vê um trabalho personalizado; você vê um processo repetível. Quando apresenta o diagnóstico a um cliente, está a demonstrar que sabe o que todos os sites SaaS devem fazer. Essa é uma proposta mais forte do que 'vamos criar um design único.' O design é a consequência do diagnóstico, não o ponto de partida.

'Não temos tempo para auditar todas as páginas'

Faça a versão focada de 90 minutos, não uma auditoria completa. A maioria dos processos de descoberta das agências já é uma auditoria, apenas não estruturada. Passa quarenta e cinco minutos numa chamada de descoberta que cobre o contexto, concorrentes e 'o que você quer com isto,' e depois passa semanas a reagir. O diagnóstico inverte isso: você pontua as cinco tarefas, lista as correções de maior impacto e avança para o design. Poupa tempo porque deixa de refazer trabalho após a primeira revisão de design. As correções mais baratas são as que faz antes de alguém ver píxeis.

Aqui está uma divisão concreta de 90 minutos: bloco um (30 minutos) revê a página inicial e a página de funcionalidades para as cinco tarefas. Bloco dois (30 minutos) examina a página de preços e a FAQ. Bloco três (15 minutos) verifica se a documentação da API responde a 'posso extrair os dados,' e os últimos 15 minutos listam as principais correções e o responsável por cada uma. Não precisa de ler todas as páginas de cima a baixo; precisa de descobrir se a tarefa está a ser realizada. Se a página de preços não tiver FAQ, o design será aprovado mais rapidamente se detetar isso antes de criar o mockup da quarta coluna de preços. Se a documentação da API for escrita para um padrão interno em vez do padrão do desenvolvedor, fica a saber antes de dar instruções ao redator.

Num projeto, o diagnóstico revelou que o comprador-alvo tinha pavor da migração de dados. A FAQ que adicionámos para essa resposta custou duas horas de escrita. Sem o diagnóstico, esse medo ter-nos-ia acompanhado pelo design, pelo desenvolvimento e até à sobrecarga de suporte pós-lançamento. A versão de 90 minutos não é uma fase que precede o projeto; é a primeira fase do projeto. Também lhe dá uma forma honesta de estimar: sai da sessão com uma lista do que existe e do que não existe, para que a proposta que escreve seja baseada em evidências, não em suposições.

'O meu cliente não técnico não precisa de documentação da API'

Use uma árvore de decisão, não uma lista de verificação: se o produto tem uma API pública ou uma história de integração, a documentação da API é uma página central; se não, ignore-a conscientemente. A investigação sobre documentação de API é direta: empresas como Stripe, GitHub e Twilio definem o padrão de clareza na documentação porque os seus desenvolvedores são efetivamente os compradores. Se o seu cliente tem uma integração voltada para desenvolvedores, a documentação não é uma conveniência para o desenvolvedor; é um dispositivo de confiança que fica ao lado da página de preços. Um cliente não técnico pode nunca olhar para ela, mas o desenvolvedor que avalia uma compra certamente olhará.

A árvore de decisão faz parte do sistema. Quando o cliente diz 'não temos um público de desenvolvedores,' faça uma pergunta: 'alguma parte do seu processo de integração requer um desenvolvedor para ligar o produto a outro sistema?' Se sim, a documentação fica. Se não, ignore-a e coloque o esforço na FAQ e na prova social. Aplique a mesma lógica à prova social: para um cliente, uma linha de logótipos é suficiente; para outro, é necessário um testemunho detalhado com resultados mensuráveis. O diagnóstico diz-lhe qual, em vez de usar todos os logótipos que puder recolher. Essa escolha é o que torna o enquadramento repetível sem ser rígido. Se precisar de descobrir o que 'clareza' significa na prática, este guia sobre documentação de API percorre a estrutura.

'Mas o meu cliente quer uma lista de funcionalidades, não resultados'

Quando o cliente diz que quer mostrar as suas funcionalidades, peça-lhe para nomear a tarefa do utilizador que cada funcionalidade desbloqueia. A suposição comum é que o mostruário de funcionalidades é onde se ganha a venda. O diagnóstico sugere o contrário: num site SaaS típico, a página de preços é onde acontece a matemática mental final, e a FAQ é onde a última objeção é resolvida. O mostruário de funcionalidades é essencial, mas a sua tarefa é estreita—mostrar o momento em que o produto se torna valioso. Uma longa lista de funcionalidades com um parágrafo por baixo de cada uma não faz isso.

Os clientes resistem a isto porque uma lista parece tangível e fácil de aprovar. Mas uma página com cinquenta funcionalidades produz um visitante que apenas espreita, e um visitante que espreita a sua página de funcionalidades já desviou a atenção para a tabela de preços. A tarefa do seu sistema é deixar o cliente confortável com a troca: não está a remover funcionalidades, está a movê-las para onde serão lidas. Uma FAQ bem posicionada que diz 'integramos com as ferramentas que já utiliza' frequentemente faz mais trabalho do que uma página de funcionalidades que diz o mesmo sob o título errado. Esta é a nuance que a maioria dos artigos omite, e é exatamente o tipo de troca que um diagnóstico pode tornar explícita.

O diagnóstico também lhe dá uma razão defensável para contrariar o aumento do âmbito. Quando um cliente pede para adicionar outra linha de funcionalidades à página inicial, pode apontar para a tabela e dizer 'a tarefa dessa página é mostrar resultados, não catalogar funcionalidades.' Um construtor de páginas genérico poderia gerar uma grelha de funcionalidades, mas não pode decidir se a grelha deve ser substituída por um vídeo ou uma FAQ. Essa decisão é o produto real, e é a razão pela qual um enquadramento não mercantiliza o seu trabalho.

'Já temos um processo interno'

Se a sua agência tem um processo para a página inicial ou uma lista de verificação para a página de preços, a objeção geralmente é sobre não querer substituí-lo. Não é necessário. O diagnóstico de cinco tarefas não substitui o seu processo criativo; é uma interface que o alimenta. O problema com a maioria dos processos internos é que são invisíveis. Vivem na cabeça do designer sénior. O diagnóstico externaliza o processo para que um membro júnior da equipa possa fazer a primeira passagem, e você possa revê-la em minutos. Essa é a repetibilidade de que realmente precisa numa agência com múltiplos clientes.

Um processo visível também muda a conversa com os clientes. Em vez de 'temos um processo de design proprietário,' pode dizer 'executamos um diagnóstico contra as cinco tarefas que todos os sites SaaS têm de realizar, e depois desenhamos com base nos resultados.' A primeira frase é uma caixa preta que deixa os clientes nervosos. A segunda é um método claro que os convida a entrar. O diagnóstico torna-se parte da sua história de vendas, não apenas uma ferramenta de produção.

'O cliente diz que o site atual está bem'

O diagnóstico ainda funciona se o cliente não quiser mais do que uma renovação. Dá-lhe uma base de referência. Pontua o site atual e mostra que uma página específica está a falhar uma tarefa específica. Pode dizer: 'A sua página de FAQ está organizada, mas não responde à pergunta que a sua equipa de vendas ouve todas as semanas,' e essa é uma razão baseada em factos para mudar, não uma preferência estética. Esta é frequentemente a forma mais suave de iniciar um redesign: não está a dizer ao cliente que o site dele é feio, está a dizer-lhe que uma tarefa não está a ser cumprida.

Isto também o protege da falha comum em que um cliente insiste em manter um elemento amado da página inicial que prejudica a conversão. O diagnóstico dá-lhe o vocabulário para dizer 'esse elemento não está a realizar nenhuma das cinco tarefas,' e o cliente pode ver as evidências. A objeção deixa de ser uma questão de gosto.

O diagnóstico é o produto

A repetibilidade não consiste em espremer todos os clientes no mesmo modelo. Consiste em executar um processo padrão que revela o que é único em cada cliente. O diagnóstico de cinco tarefas leva menos de duas horas, dá à sua equipa uma linguagem comum e dá ao cliente uma lista clara de decisões. A agência que pode prometer um diagnóstico consistente pode conquistar um cliente numa semana e entregar num mês, não porque o trabalho é mais fácil, mas porque a descoberta é previsível. E quando o cliente perguntar por que precisa de fazer tantas perguntas, a resposta é simples: não está a fazer uma audição, está a diagnosticar.

Para uma análise mais aprofundada de como o mostruário de funcionalidades e a página de preços devem funcionar em conjunto, e por que os mitos em torno deles persistem, consulte este guia que desfaz mitos.