Toda equipe de SaaS coleta feedback; poucas coletam de um jeito que sobrevive ao planejamento do roteiro. Feedback espalhado entre tickets de suporte, ligações de vendas, threads no Slack e um Typeform esquecido não é sinal, é anedota, e roteiros feitos de anedotas acabam feitos para quem gritou por último. A solução não é mais feedback. É um lugar, um processo e um ciclo visível.
Uma porta de entrada: o quadro público de feedback
O passo central é consolidar: um único quadro público onde os usuários enviam pedidos, veem o que os outros enviaram e votam. Isso resolve três coisas de uma vez:
A deduplicação acontece no envio. Um usuário prestes a pedir exportação em CSV encontra o post que já existe, com 40 votos, e soma o seu, em vez de criar o ticket número 41 que alguém vai ter de juntar aos outros depois.
Os votos transformam anedotas em números. “Vários clientes querem isso” vira “63 usuários votaram, 12 comentaram com o seu caso de uso”.
A visibilidade alinha expectativas. Os usuários veem o que está planejado e o que não está, e os tickets do tipo “alguma novidade sobre…?” diminuem sem alarde.
Deixe o quadro fácil de achar: um link na navegação do app ou no menu de ajuda, não uma página escondida no rodapé. Cada barreira no envio (uma conta separada, um formulário longo) afasta justamente os usuários quietos e representativos que você mais precisa ouvir.
Estruture os envios com leveza
Peça um título e uma descrição, e resista à vontade de exigir mais campos. Um campo vale a pena: categoria ou tipo (pedido de funcionalidade, bug ou integração), porque ele direciona a triagem. Deixe os detalhes para os comentários. Os comentários sob um pedido costumam valer mais que o próprio pedido: é ali que se acumulam casos de uso, soluções de contorno e casos-limite, escritos por quem esbarrou neles.
Faça a triagem em um quadro, não em uma planilha
Feedback sem fluxo de trabalho vira um pântano. O modelo que funciona é um conjunto de colunas no estilo kanban pelas quais cada post passa, por exemplo: Novo → Em análise → Planejado → Em andamento → Lançado, com a saída Não planejado.
Duas regras fazem isso funcionar:
Todo post novo recebe um status dentro de um prazo definido (uma semana é realista). Mudar o status custa pouco e comunica mais do que uma resposta.
“Não planejado” é uma resposta de verdade. Dizer não à vista de todos, com uma frase de justificativa, gera mais confiança do que deixar os pedidos apodrecendo em “Novo” para sempre — e impede que o mesmo pedido seja rediscutido em cinco posts novos.
Se a sua ferramenta de feedback expõe as colunas por API, dá até para mostrar os itens “planejados” e “em andamento” dentro do seu app, não só no quadro.
Leia os votos com critério, não com aritmética
A contagem de votos é o começo da priorização, não o fim. Três correções a aplicar:
Pondere por segmento. Dez votos do seu perfil de cliente ideal podem pesar mais que cem de usuários de um plano que você está deixando de lado. Com o feedback ligado a usuários identificados, você vê quem está pedindo.
Diagnostique antes de construir. Um pedido é uma solução proposta para um problema que ninguém mencionou. “Adicionem pastas” pode querer dizer “não consigo achar as coisas”, e talvez a busca resolva isso melhor. Procure nos comentários o problema por trás do pedido.
Preste atenção ao silêncio. Quem vota é um grupo autosselecionado de usuários avançados. Combine o quadro com os sinais passivos que representam todos os outros: buscas sem resultado na sua central de ajuda, pontos de abandono no onboarding.
Feche o ciclo, em público e com cada pessoa
O ciclo é o que separa um sistema de feedback de uma caixa de sugestões. Ele tem dois níveis:
Em público: quando algo for lançado, mova o post para Lançado e coloque nele o link da entrada do registro de alterações que anunciou a novidade. Quando o registro de alterações e o quadro de feedback ficam no mesmo sistema, esse link não custa nada e o retorno se acumula: usuários que veem pedidos sendo lançados enviam pedidos melhores.
Com cada pessoa: quem votou merece saber que aquilo que pediu agora existe. Um aviso de lançamento para quem votou transforma os seus usuários mais engajados no megafone dos seus lançamentos.
Um antipadrão que merece nome: lançar algo que o quadro pediu e nunca marcar como lançado. Você pagou o custo inteiro de ouvir e não levou crédito nenhum.
Moderação e tom
Um quadro público é público. Decida de antemão como lidar com duplicados (junte-os e mantenha os votos), posts fora do tema e posts hostis (modere o comportamento, nunca a crítica). Nos posts que pedem resposta, responda como equipe, com voz oficial: uma resposta da equipe, assinada e identificada, é lida de um jeito muito diferente de um comentário qualquer.
Ferramentas: o que importa de verdade
Seja qual for a escolha — uma ferramenta dedicada de feedback ou o módulo de feedback de uma plataforma de conteúdo mais ampla —, os recursos que importam na prática são: envios públicos com votos e comentários, colunas de triagem, usuários identificados, uma API para que os dados de feedback cheguem aos seus próprios painéis e às telas do seu app, e um registro de alterações ao lado para fechar o ciclo. Os quadros de feedback do Kookee cumprem esses requisitos e já vêm com o resto do conteúdo do produto (registro de alterações, roteiro, central de ajuda), e é exatamente isso que deixa barato fechar o ciclo. Ferramentas avulsas também funcionam, se você estiver disposto a costurar o ciclo por conta própria.
Lançar sem frontend não é problema: um portal hospedado com o quadro e o roteiro começa a coletar no primeiro dia, e mais tarde você renderiza o quadro e um roteiro só de leitura dentro do seu app, com o SDK ou com os componentes React. As leituras funcionam pela API, enquanto envios, votos e comentários ficam no portal, onde cada pessoa conta uma vez e onde a moderação acontece.
Um sistema para começar esta semana
Crie um quadro público com votos e de 4 a 6 colunas de triagem.
Preencha o quadro com os dez pedidos que você já conhece dos tickets de suporte.
Coloque um link para ele no seu app e anuncie o quadro no seu registro de alterações.
Faça a triagem toda semana; dê um status a cada post; diga “não planejado” em voz alta.
Lance algo que veio do quadro, marque como lançado e coloque o link da entrada do registro de alterações.
Rode esse ciclo por um trimestre e a conversa sobre o roteiro muda: menos “acho que os usuários querem”, mais “isto é o que 60 usuários identificados pediram, este é o problema por trás, e isto é o que respondemos a eles”.