Priorize chamados de suporte pelo que realmente se repete
5 min de leitura
A maior parte da priorização começa pelos chamados que um PM leu recentemente, ou por aqueles escalados com alarde. Isso não é o mesmo que saber o que é de fato mais comum, e significa que um problema discreto, porém frequente, pode perder sempre para um raro, porém barulhento. Um PM que abre a fila de suporte numa segunda de manhã tem muito mais chance de agir sobre o chamado escalado por um gerente de contas no fim de semana do que sobre o fato de trinta outros usuários terem relatado em silêncio, ao longo do mês, uma versão menor do mesmo atrito de fundo.
Atenção
Um chamado de que você se lembra e um chamado que se repete são sinais diferentes. O de que você se lembra pode ser só o que foi escalado, e não o que afeta mais usuários.
O chamado de que você se lembra nem sempre é o que vale a pena consertar primeiro. O que não para de se repetir é.
Por que ler chamados em ordem não revela a frequência real
Ler uma fila de suporte dá impressões, não contagens. Um problema relatado por quinze usuários diferentes de quinze jeitos não parece um padrão quando você lê um chamado de cada vez, parece quinze reclamações separadas. O esforço mental de manter uma contagem corrente em dezenas de chamados, cada um com redação diferente, é exatamente o tipo de contagem em que um revisor humano é ruim e tende a subestimar.
Imagine a fila de suporte de um fluxo de integração em que um usuário, uma conta enterprise, escala com alarde uma etapa confusa da configuração. Esse chamado recebe atenção rápido. Enquanto isso, na mesma semana, trinta usuários do plano gratuito abrem chamados em silêncio sobre a mesma etapa, em trinta formulações diferentes, nenhum escalado, nenhum alarmante sozinho. Lidos na ordem de chegada, o chamado barulhento da enterprise domina o modelo mental do PM sobre o que está quebrado, enquanto o problema de maior frequência, que afeta muito mais usuários, fica sem ser reconhecido como padrão em trinta chamados separados.
Antes: folhear os chamados recentes, priorizar os que parecem mais urgentes ou foram escalados, seguir em frente.
Depois: colar um lote de chamados no Claude, pedir que os agrupe em temas ordenados por quantos chamados cabem em cada um e priorizar pela frequência real.
Um processo para transformar chamados em temas ordenados
- 1
Reúna um lote de verdade, não um punhado
Puxe chamados de uma janela definida, uma semana ou um mês inteiros, e não o que estiver na sua caixa de entrada. Uma amostra parcial pende para o que chegou mais recentemente.
- 2
Peça temas agrupados por frequência, não um resumo
Um resumo comprime o que foi dito. Peça especificamente chamados agrupados em temas recorrentes, com a contagem de quantos chamados caem em cada grupo.
- 3
Peça um chamado representativo por tema
Um exemplo real ancora cada tema em algo concreto e é útil depois, quando você precisa justificar uma prioridade com um caso de verdade, e não só com uma contagem.
- 4
Priorize por contagem e depois confira com a gravidade
A frequência diz o que é comum, não necessariamente o que é mais custoso. Com a lista ordenada, confira se um tema de menor frequência ainda merece subir pela gravidade.
Aqui estão 30 chamados de suporte sobre o nosso fluxo de integração. Agrupe-os nas três reclamações mais comuns e diga-me quantos chamados caem em cada grupo.
”Depois de ordenados os temas, vale checar se cresceram ou encolheram em relação a um período anterior, já que um tema que cresce rápido semana a semana é um tipo de urgência diferente de um que é um zumbido baixo e constante há meses.
Aqui está a mesma divisão por temas do mês passado. Compare as duas e diga-me quais temas estão crescendo como parcela do total de chamados, e não só quais têm a maior contagem bruta neste mês.
”
Dentro do Claude Tutorial
Ordenar pela frequência real em vez da recência é transferível.
Agrupar relatos dispersos em temas contados, em vez de priorizar o que você viu mais recentemente, vale muito além dos chamados de suporte. O app tem uma lição completa sobre isso, com prática que se aplica a qualquer feedback sobre o qual você precisa agir.
Quando frequência e gravidade apontam em direções diferentes
Às vezes o tema mais comum não é o mais danoso. Um incômodo menor relatado com frequência e um bug raro que bloqueia a conta merecem lugar na lista, só não necessariamente em ordem de frequência. Tratar a frequência como única entrada corre o risco de subpriorizar sistematicamente os problemas raros, porém graves, que não geram muitos chamados simplesmente porque os usuários afetados não conseguem avançar o bastante no produto para abrir um.
Dica
Peça ao Claude que sinalize quais temas envolvem usuários totalmente bloqueados e quais apenas incomodados. Um problema bloqueante com menos relatos ainda pode superar um tema maior, mas de baixa gravidade.
Dos três temas que você encontrou, quais envolvem usuários completamente impedidos de concluir a integração, e quais só incomodados pelo atrito? Quero pesar a gravidade junto com a frequência antes de fechar a prioridade.
”Também vale checar se um tema de baixa frequência e alta gravidade pode estar subnotificado justamente por ser grave, já que um usuário que encontra um bloqueio sério cedo na integração pode abandonar o produto por completo em vez de gastar tempo abrindo um chamado.
Este problema bloqueante gerou só 3 chamados, o que parece pouco para algo tão grave. Há algum motivo para um problema bloqueante como este ser subnotificado em comparação com um mais leve que ainda deixa os usuários continuarem?
”Continue lendo
- Escrevendo um documento de roadmap que explica os trade-offs: transformando uma lista ordenada de temas numa decisão de roadmap que os stakeholders consigam acompanhar.
- Escrevendo um PRD a partir de um pedido de funcionalidade de uma linha: o que fazer quando um tema revela uma funcionalidade que vale especificar.
- Afiando um PRD antes de enviá-lo para revisão: pegando casos extremos para os quais um tema como este pode apontar antes da revisão.