Base de conhecimento SaaS: o que fazer quando a busca não encontra respostas

Para founders e equipes de suporte e produto, uma busca frustrada na base de conhecimento é um ponto de partida para investigar. Antes de escrever outro artigo, descubra onde a pessoa parou: na busca, na compreensão da resposta ou na execução da tarefa. Cada falha pede uma correção diferente.

Imagine este caso hipotético: um cliente procura “segunda via boleto”. A base tem um artigo chamado “Documentos financeiros”, mas ele não aparece na pesquisa. O suporte conhece a página e envia o link. O cliente abre, segue as instruções e descobre que o menu citado só aparece para o administrador da conta.

Há pelo menos dois problemas nesse caminho. O conteúdo usa um nome diferente daquele que o cliente procura. E a orientação omite uma condição de acesso. Publicar mais uma página sobre cobrança, sem investigar esses pontos, pode manter a dificuldade.

Identifique o que aconteceu depois da busca

“Não encontrei a resposta” pode descrever situações diferentes. Separe o que foi observado da explicação que ainda precisa ser testada.

• A consulta retornou zero resultados. Verifique se o conteúdo existe, está publicado, foi indexado e pode ser visto naquele idioma e perfil. Depois teste os termos que a pessoa usou. A ausência de resultados ainda não comprova uma lacuna de conteúdo.
• Apareceram resultados, mas ninguém clicou. Examine os títulos, os trechos exibidos e a ordem dos resultados. Talvez nenhum pareça responder à pergunta. A pessoa também pode ter encontrado a informação no próprio trecho ou abandonado a tarefa por outro motivo.
• A pessoa abriu um artigo e continuou sem conseguir fazer o que precisava. Siga as instruções no produto. A página pode estar desatualizada, pressupor uma permissão, omitir uma restrição do plano ou descrever uma ação indisponível.

Os nomes dos indicadores exigem cuidado. Na documentação de buscas do Helpjuice, “Found Answer” indica que houve pelo menos um resultado, e “Bounced” inclui buscas sem resultados ou sem clique. Essas definições não comprovam a conclusão de uma tarefa.

Use os dados disponíveis como pistas. Um clique mostra que alguém abriu a página; para saber se conseguiu resolver o problema, é preciso observar a tarefa ou obter uma confirmação específica.

Corrija o caminho inteiro no exemplo do boleto

Considere um SaaS fictício em que administradores conseguem baixar um boleto já emitido na área de cobrança. Os nomes de telas e as regras abaixo são apenas um exemplo editorial; devem ser substituídos pelo funcionamento real do produto.

Antes

Título: Documentos financeiros

Abertura: “Nesta seção, você encontra os documentos financeiros da sua organização.”

Caminho de ajuda: Central de ajuda → Conta → Documentos financeiros.

O título identifica uma categoria interna, mas não deixa claro que a página responde à busca por uma segunda via. A abertura também não informa quem pode executar a ação.

Depois

Título: Como baixar a segunda via de um boleto

Abertura: “Administradores podem baixar novamente um boleto já emitido em Configurações → Cobrança → Boletos. Abra a cobrança desejada e selecione Baixar boleto. Se você não vê o menu Cobrança, peça ao administrador da conta para baixar o documento.”

Caminho de ajuda: Central de ajuda → Cobrança → Como baixar a segunda via de um boleto. Na tela de cobrança, ofereça também um link para essa orientação.

O restante do artigo precisa tratar as exceções reais. Um boleto vencido pode exigir outro procedimento. Uma conta que paga por cartão pode não ter boletos disponíveis. Explique essas situações conforme as regras do produto, com um próximo passo que a pessoa realmente possa executar.

Preserve os termos usados na interface dentro das instruções. O título pode falar em “segunda via”, enquanto os passos apontam para o botão “Baixar boleto”. Se a busca permitir sinônimos ou termos alternativos, teste também “boleto”, “baixar boleto” e “cópia do boleto”. Evite repetir palavras artificialmente no texto.

Se “Documentos financeiros” também cobre notas fiscais e recibos, mantenha uma página de visão geral e organize os caminhos para cada tarefa. Antes de renomear ou dividir páginas, confira os links existentes e preserve os endereços úteis ou configure redirecionamentos quando a ferramenta permitir.

Decida quem precisa corrigir a falha

Abra o artigo por um link direto usando uma conta de teste com as mesmas permissões do perfil afetado. Se ele responde à pergunta e a tarefa funciona, mas a consulta continua sem encontrá-lo, investigue publicação, indexação, idioma, filtros e configuração da busca. Nesse caso, editar o texto pode ser insuficiente.

Se o artigo só funciona para administradores, explicite essa condição e ofereça um caminho válido para outros perfis. Não torne conteúdo restrito público apenas para fazê-lo aparecer na busca.

Se a ação depende de um plano, a orientação deve explicar a disponibilidade e as alternativas existentes. Se a função não existe ou está com defeito, encaminhe o problema para produto ou engenharia e deixe claro o que o usuário pode fazer agora. Uma página de ajuda não torna disponível uma ação que o produto não oferece.

Crie um artigo novo quando a tarefa é suportada e falta uma orientação adequada. Atualize o existente quando ele já cobre a intenção, mas usa termos pouco reconhecíveis ou omite passos. Essa decisão evita acumular páginas semelhantes com instruções divergentes.

Teste sem depender de um painel de analytics

Escolha uma pergunta recorrente em conversas de suporte às quais sua equipe já tem acesso autorizado. Remova os dados pessoais e transforme-a em uma tarefa curta: “Você precisa baixar novamente o boleto deste mês”. Use uma conta de teste e documentos fictícios.

Peça a alguém que não escreveu o artigo para começar no ponto em que o cliente normalmente procura ajuda. Não envie o link da resposta nem dite as palavras da busca. Observe o termo escolhido, o resultado reconhecido e o primeiro ponto em que a pessoa fica sem saber o que fazer.

Registre apenas o necessário: tarefa, perfil de acesso, tipo de falha e se a ação foi concluída sem orientação adicional. Faça a correção e repita o teste, de preferência com outra pessoa. No exemplo, a evidência procurada é simples: o administrador encontra a página e baixa o documento fictício; o perfil sem acesso entende a restrição e identifica a quem pedir ajuda.

Esse teste pequeno ajuda a encontrar falhas concretas. Ele não estima sozinho a taxa de sucesso de todos os clientes nem demonstra redução de tickets.

Se houver logs de busca, agrupe padrões e minimize o que é armazenado ou compartilhado. Não copie consultas contendo nomes, e-mails, identificadores de cobrança ou outros dados sensíveis para uma pauta editorial quando uma descrição da intenção basta.

Comece por uma pergunta que continua voltando

A orientação da Featurebase sobre autoatendimento recomenda partir das perguntas dos clientes, usar linguagem clara e manter uma saída para o suporte. Aplique isso a uma tarefa específica e confira o resultado no produto.

Na próxima vez que alguém disser que a busca não ajudou, tente reproduzir o caminho antes de aumentar a base. A correção pode ser um título reconhecível, um passo ausente, uma condição de acesso visível ou um ajuste no produto. Termine quando houver um próximo passo válido para aquele usuário, inclusive quando ele precisar da ajuda de outra pessoa.