Tickets de suporte vs. pedidos: em que confiar?

Um quadro de pedidos de funcionalidades captura o que usuárias pedem quando têm tempo de sentar e descrever o que querem. Um ticket de suporte captura onde usuárias estão travadas agora mesmo, frequentemente irritadas, frequentemente sem o vocabulário para descrever de forma limpa o pedido subjacente. Os dois são sinal real, e equipes que olham só para um dos dois acabam resolvendo com confiança o problema errado, porque cada canal super-representa sistematicamente um tipo diferente de usuária e um tipo diferente de necessidade. Priorizando pedidos de funcionalidades cobre classificar o que já está no quadro; isto é sobre a lacuna entre o que chega ao quadro e o que só aparece como ticket de suporte.

Por que o mesmo problema subjacente apareceria em um canal e não no outro?

Porque os dois canais têm custos de ativação diferentes, e o tamanho desse custo decide quem o supera. Registrar um pedido de funcionalidade exige iniciativa: uma usuária precisa acreditar que o pedido vale a pena articular, achar o quadro, e escrever algo coerente, o que seleciona usuárias engajadas e pacientes já investidas no produto. Registrar um ticket de suporte exige quase nenhuma iniciativa em comparação, frequentemente só um clique em “ajuda” no meio de uma tarefa, o que significa que captura usuárias frustradas no momento, incluindo aquelas que nunca se dariam ao trabalho com um quadro de pedidos. Uma lacuna real no produto pode ser invisível no quadro de funcionalidades e barulhenta no suporte simplesmente porque as usuárias que a encontram são as menos propensas a registrar um pedido formal.

O volume de tickets para uma funcionalidade ausente significa a mesma coisa que a contagem de votos para ela?

Não, porque medem populações diferentes sob condições diferentes. Um pedido de funcionalidade com cem votos representa cem pessoas que tiraram tempo para achar e apoiar um pedido existente, o que é um sinal forte de demanda durável e ponderada. Cem tickets de suporte sobre a mesma lacuna subjacente, registrados no mesmo período, provavelmente representam usuárias esbarrando em uma parede no momento, algumas das quais esqueceriam completamente assim que a fricção imediata passasse. Tratar os dois como sinal equivalente de “cem pessoas querem isso” superpondera o volume de tickets, porque tickets são baratos de gerar e votos não.

O que significa quando uma funcionalidade tem tickets de suporte mas quase nenhum voto no quadro?

Frequentemente, que o pedido existe mas as usuárias que o encontram não sabem que o quadro existe, não acreditam que votar mudaria algo, ou encontram o problema raro demais para se dar ao trabalho de trocar de canal para registrá-lo formalmente. Essa é exatamente a população que um quadro de pedidos perde estruturalmente, e uma contagem baixa de votos aqui é prova de uma lacuna de medição, não de demanda baixa. Tratem um cluster de tickets de suporte em torno de uma funcionalidade ausente como o próprio sinal que vocês mesmos registram no quadro em nome das usuárias, em vez de desconfiar dos tickets, para que não fique invisível para quem prioriza só a partir de contagens de votos.

Quadro se lê como baixa prioridade:
"Export to CSV": 4 votos em 6 meses

Suporte conta uma história diferente:
"Export to CSV": 31 tickets no mesmo período, cada um
de uma conta diferente, cada um fechado com "não
suportado no momento, vamos repassar o feedback"

Um pico de tickets de suporte sempre significa que o problema subjacente é uma funcionalidade ausente?

Não, e é aqui que os dois canais podem enganar na direção oposta. Um pico de tickets é tão frequentemente causado por uma interface confusa em torno de uma funcionalidade já existente, um bug, ou uma mudança que saiu sem explicação adequada, nada disso resolvido construindo algo novo. Ler cada pico de tickets como “usuárias querem uma funcionalidade que não temos” produz um roadmap cheio de coisas que na verdade eram lacunas de documentação ou problemas de usabilidade disfarçados. O ticket de suporte diz onde está a fricção; não diz sozinho se a solução é uma funcionalidade nova, uma mudança de interface, ou um artigo de ajuda melhor, e confundir isso desperdiça tempo de engenharia na solução errada.

Como os dois sinais deveriam realmente ser combinados ao decidir o que construir?

Usem tickets para achar onde está a fricção, e usem o quadro de pedidos, mais contato direto onde o quadro está fraco, para confirmar como o resultado realmente desejado se parece. Um cluster de tickets identifica um problema real, sentido; raramente especifica a solução com precisão suficiente para construir contra ela, porque uma usuária frustrada em uma conversa de suporte descreve sintomas, não especificações. O quadro de pedidos, quando tem votos suficientes sobre o mesmo problema subjacente, tende a carregar mais do detalhe de “o que realmente satisfaria isso”, porque escrever um pedido já é um ato de especificar o que se quer, não só relatar o que está errado.

Agentes de suporte deveriam registrar tickets como pedidos de funcionalidades eles mesmos?

Sim, e essa é a correção de maior alavancagem para a lacuna entre os dois canais. Uma agente que reconhece um ticket como um pedido de funcionalidade disfarçado, em vez de simplesmente resolvê-lo e seguir em frente, pode registrá-lo no quadro em nome da cliente, o que fecha diretamente a lacuna de medição em vez de exigir que a cliente descubra e use um segundo canal. Isso só funciona se registrar levar segundos, não minutos, para a agente, para que a fricção de fazer isso seja menor que a fricção de simplesmente fechar o ticket e passar para o próximo.

FAQ

Votos de pedidos de funcionalidades deveriam alguma vez ser descontados se todos vêm de uma única conta ou equipe? Sim, ponderem por contas ou organizações distintas em vez de contagem bruta de votos, porque cinco votos de cinco pessoas na mesma empresa representam as prioridades de uma única cliente, não cinco confirmações independentes de demanda.

Vale a pena construir uma funcionalidade que aparece muito em tickets mas tem quase nenhum voto? Frequentemente sim, desde que o volume de tickets venha genuinamente de contas distintas e a necessidade subjacente esteja confirmada em vez de assumida; tratem a contagem baixa de votos como um artefato de medição do custo de ativação do quadro, não como prova de que a demanda não é real.

Como distinguir de relance um ticket de confusão de interface de um ticket genuíno de funcionalidade ausente? Vejam se a resolução envolve explicar uma capacidade existente ou pedir desculpas por uma ausente. Um padrão de resoluções “ah, na verdade está bem ali” aponta para um problema de interface ou descobribilidade; um padrão de “ainda não suportamos isso” aponta para uma lacuna real.

Essa distinção importa tanto assim com um volume de suporte muito pequeno? Menos mecanicamente, já que um punhado de tickets é fácil de ler individualmente sem precisar de análise agregada, mas o viés subjacente, tickets super-representam usuárias frustradas e sub-representam as pacientes, está presente em qualquer escala e vale a pena ter em mente mesmo quando vocês leem cada ticket sozinhas.

As afirmações técnicas deste artigo não foram revisadas de forma independente. Se algo estiver errado, avise a gente e vamos corrigir.

Relacionado na changeloop: Documentação para desenvolvedores, Comparativo de ferramentas de changelog