Do chat com o cliente à issue no Jira e de volta: um processo de escalonamento de bugs em que suporte e engenharia confiam
O suporte escala um bug, a engenharia recebe um relato vago e o cliente não fica sabendo de nada até tentar de novo. Este processo em 4 etapas resolve cada repasse, com um modelo de relatório de bug, regras de status e uma mensagem para o dia em que a correção for lançada.
Conteúdo
- Como um bug se perde entre o suporte e a engenharia
- Etapa 1: prove que é um defeito antes que ele chegue à engenharia
- Etapa 2: uma issue no Jira por bug, com cada ticket afetado vinculado
- Etapa 3: deixe o status do Jira voltar para o suporte
- Etapa 4: avise cada cliente afetado assim que a correção estiver no ar
- Como rodar o processo no Deskwoot
- Quanto custa e por onde começar
Você escala um bug e não recebe retorno nenhum. A engenharia reclama que o suporte manda dúvidas que nunca foram bugs. Depois aparecem 3 issues no Jira para um único defeito, e ninguém consegue dizer ao cliente quando a correção vem.
Este guia traz um processo em 4 etapas, com um repasse claro em cada uma, além de 5 perguntas de triagem, um modelo de relatório de bug e uma mensagem para o dia em que a correção for lançada.
Como um bug se perde entre o suporte e a engenharia
Uma cliente escreve no chat do seu site: o PDF da fatura que ela exporta do seu app para iPad termina antes da última página. Seu agente testa, vê a mesma coisa e posta no canal da engenharia: "Exportação de PDF quebrada no iPad?" Alguém reage com um emoji.
Nas 2 semanas seguintes, mais 4 clientes relatam o problema, 2 agentes abrem 3 issues no Jira entre eles, e ninguém no suporte sabe dizer se vem uma correção. Quando ela sai, os clientes descobrem ao tentar de novo.
A Tray.ai, que vende software de automação, descreve esse desfecho no seu guia de escalonamento para a engenharia: "o cliente continua descobrindo pelas notas de versão, ou perguntando", porque "ninguém ficou responsável por avisar".
A engenharia tem a queixa oposta. A Zenatta, uma consultoria que monta centrais de suporte no Zoho, escreve em um estudo de caso no seu site que um "backlog do Jira cheio de dúvidas de suporte que nunca foram defeitos vira ruído que a engenharia aprende a ignorar".
Cada uma das 4 etapas abaixo termina em um repasse claro, e elas funcionam com qualquer help desk que se conecte ao Jira.
Etapa 1: prove que é um defeito antes que ele chegue à engenharia
Muitos escalonamentos que irritam os desenvolvedores dão errado aqui: o cliente não encontrou uma configuração ou quer algo que o produto nunca fez.
A própria equipe de suporte da Atlassian tem uma regra simples na sua política de correção de bugs do Cloud: "Vamos tentar reproduzir o bug para confirmá-lo e, se conseguirmos, registramos o relato para você." Copie essa regra. Se ninguém no suporte consegue reproduzir o problema, ele não está pronto para o Jira.
5 perguntas antes de qualquer escalonamento
Antes de escalar, o agente responde a 5 perguntas no ticket:
- Consigo reproduzir, e em qual dispositivo, navegador, versão do app ou conta?
- Isso é um comportamento documentado, segundo a central de ajuda ou as notas de versão?
- O Jira já tem isso? Pesquise o texto do erro e o nome do recurso.
- Quem tem o problema? Uma conta, um plano, todo mundo no Android?
- O que isso bloqueia, e existe uma solução de contorno?
Para onde vai cada relato
Depois, classifique o relato pelo que ele de fato é:
| Na verdade é | Exemplo | Para onde vai |
|---|---|---|
| Uma dúvida sobre como usar o produto | "Onde eu mudo o rodapé da fatura?" | Responda e mande o link do artigo de ajuda |
| Um problema de configuração ou de dados em uma conta | Alíquota de imposto errada nas faturas de um cliente | O suporte resolve |
| Um pedido de recurso | "O PDF pode mostrar nosso logo em todas as páginas?" | Sua lista de feedback do produto, nunca o backlog de bugs |
| Um defeito que você consegue reproduzir | O PDF termina antes da última página no iPad | Etapa 2 |
| Uma queda que muitos clientes percebem ao mesmo tempo | Ninguém consegue fazer login | Etapa 2 na hora; reúna os clientes afetados desde o primeiro relato |
Prioridade nos termos da engenharia
Para a prioridade, use a escala da engenharia. Se não houver uma, pegue emprestada a da Atlassian:
- Prioridade 1 quando "os usuários não conseguem fazer o seu trabalho e não há solução de contorno disponível".
- Prioridade 3 quando um recurso "não funciona como esperado, mas há uma solução de contorno disponível".
O suporte descreve o impacto nesses termos, e a engenharia define a ordem do trabalho a partir daí.
Etapa 2: uma issue no Jira por bug, com cada ticket afetado vinculado
Pesquise no Jira antes de criar qualquer coisa. Uma segunda issue para o mesmo defeito divide os comentários e a contagem de clientes entre 2 lugares, e alguém vai ter que fechar uma delas como duplicada.
O guia da Tray.ai resume a meta assim: "uma issue por bug, com cada ticket afetado vinculado a ela". Esses vínculos também são o seu argumento: segundo o guia, o número de clientes e a receita por trás deles "é o que faz um bug ganhar prioridade".
Um relatório de bug que os desenvolvedores conseguem usar
Um estudo que vale conhecer aqui é "What Makes a Good Bug Report?" ("O que faz um bom relatório de bug?"), de Zimmermann e colegas (IEEE Transactions on Software Engineering, 2010). Ele se baseia em 466 respostas de uma pesquisa com desenvolvedores e pessoas que relatam bugs no Apache, no Eclipse e no Mozilla.
- Dos desenvolvedores que já tinham usado passos para reproduzir, 83% os colocaram entre os 3 itens que mais os ajudaram.
- Dos que já tinham recebido relatos incompletos, 74% citaram isso entre os 3 problemas que mais atrasaram correções.
Os itens que os desenvolvedores mais valorizavam eram também os mais difíceis de fornecer para quem relatava o bug. O suporte pode fechar essa lacuna, porque o agente ainda consegue perguntar ao cliente enquanto o chat está aberto.
Use sempre as mesmas seções:
| Seção | O que entra | Exemplo |
|---|---|---|
| Título | O defeito em uma linha, sem nome de cliente | O PDF da fatura termina antes da última página no app para iPad |
| Problema | O que dá errado, em 1 ou 2 frases | Faturas com mais de 1 página perdem a última página na exportação |
| Passos para reproduzir | Numerados, a partir de um começo limpo | 1. Abra uma fatura com 12 itens. 2. Toque em Exportar PDF. 3. Abra o arquivo. |
| Esperado | O que deveria acontecer | Os 12 itens em 2 páginas |
| Real | O que acontece, com o texto do erro copiado palavra por palavra | O PDF termina depois do item 9 |
| Ambiente | Dispositivo, sistema, versão do app, navegador | iPad Air, iPadOS 18, app 4.2.1 |
| Impacto | Quantos clientes, o que bloqueia, a solução de contorno | 5 contas até agora; por enquanto elas exportam pelo app web |
| Já tentado | O que o suporte descartou | Reinstalou o app; mesmo resultado em 2 contas de teste |
Mantenha os dados dos clientes fora do Jira
Deixe de fora o nome, o e-mail, o telefone e o número do pedido do cliente, a não ser que um desenvolvedor precise de um deles para reproduzir o bug.
Se o seu help desk coloca no Jira um link de volta para o ticket com o título do ticket, dê aos tickets o nome do problema, nunca o do cliente.
O Jira costuma ser lido por mais gente do que a sua ferramenta de suporte. E a cópia que fica lá também está fora do lugar onde você atende pedidos de exclusão e de acesso aos dados.
Se o GDPR, o regulamento de proteção de dados da União Europeia, se aplica a você, isso também é o princípio da minimização de dados do artigo 5(1)(c). O resumo da Comissão Europeia diz que os dados pessoais devem ser "adequados, pertinentes e limitados ao que é necessário para a finalidade".
Esta é uma informação geral, não um parecer jurídico.
Etapa 3: deixe o status do Jira voltar para o suporte
Depois que a issue existe, o suporte nunca deveria precisar perguntar "alguma novidade sobre isso?" num chat da equipe. O status tem que chegar ao ticket sozinho.
No Zendesk, isso exige uma pós-função (post function) adicionada ao workflow do Jira. O artigo de ajuda do Zendesk descreve o resultado: "o Jira pode adicionar automaticamente uma nota interna ao ticket vinculado do Zendesk, avisando o agente. O agente pode então avisar o cliente."
Seja qual for a ferramenta que você usa, faça um teste com uma issue fictícia.
Concluído nem sempre quer dizer lançado
Combine com a engenharia qual status do Jira significa que os clientes já têm a correção. Em muitas equipes, Concluído quer dizer que o código foi mesclado ou testado, e o lançamento sai dias depois.
Se o seu workflow tem um status como Lançado ou Implantado, esse é o gatilho da etapa 4, e o suporte precisa saber o nome exato dele.
Concluído e Lançado costumam ficar os dois na mesma categoria de status do Jira, a de itens concluídos. Por isso, uma regra que só observa a categoria não percebe a passagem de Concluído para Lançado.
Leve a contagem para o planejamento
Uma vez por semana, o líder do suporte deve levar à engenharia o número de tickets abertos que esperam por cada issue. No planejamento, "14 contas relataram o APP-482" vai mais longe do que "os clientes não param de perguntar sobre isso".
Etapa 4: avise cada cliente afetado assim que a correção estiver no ar
Espere até a correção chegar às mãos dos clientes e então teste você mesmo, no mesmo ambiente da etapa 1.
Escreva para todos que relataram o bug, incluindo os clientes que só disseram "aqui também". Descreva o problema com as palavras deles e diga o que fazer agora:
Oi, uma atualização rápida sobre os PDFs de fatura do app para iPad que terminavam antes da última página. Corrigimos isso na versão 4.2.2, que já está na App Store.
Depois de atualizar, exporte a fatura de novo e todas as páginas vão estar lá. Se algo ainda parecer errado, responda aqui com um print da tela.
A janela de 24 horas do WhatsApp
A Meta só permite texto livre até 24 horas depois da última mensagem do cliente (a janela de atendimento ao cliente). Depois disso, a empresa só pode enviar modelos de mensagem aprovados.
A maioria das correções leva mais de um dia, então deixe aprovado um modelo para avisos de correção antes de precisar dele.
Como rodar o processo no Deskwoot
O Deskwoot é o nosso help desk e cuida das etapas 2 a 4 a partir do ticket: o item de trabalho interno que a sua equipe separa de um chat com o cliente (veja como criar um ticket a partir de um chat).
O cliente nunca vê o ticket nem a issue do Jira.
Um relatório de bug rascunhado a partir do chat
Rascunhar relatório de bug com o Copilot escreve o título e a descrição a partir do ticket, do chat dele e dos comentários da sua equipe.
O Copilot lê o chat com "name withheld" (nome omitido) no lugar do nome do cliente. Ele também tem a instrução de deixar de fora dados de contato e números de pedido, a não ser que um desenvolvedor precise de algum deles.
Nada vai para o Jira até o agente conferir o rascunho e clicar em Criar issue, e a issue sai pela própria conta Atlassian dele. Um rascunho entra na contagem das suas conversas de IA.
Linhas de status e 2 regras prontas
Cada mudança de status no Jira escreve uma linha em cada ticket vinculado, como "A issue APP-482 do Jira mudou para Em andamento". Uma busca por APP-482 na lista de tickets encontra todos os tickets vinculados para a sua contagem semanal.
A página de configurações do Jira oferece 2 regras prontas para você conferir e salvar:
| Regra | Quando roda | O que faz |
|---|---|---|
| Issue criada ou vinculada | Uma issue é criada a partir do ticket ou vinculada a ele e ainda não está concluída | Define um status de ticket que você escolhe, por exemplo um status seu chamado Aguardando a engenharia |
| Issue concluída | A issue entra na categoria Concluída vindo de outra categoria | Define um status de ticket, devolve o ticket para quem vinculou a issue e adiciona uma nota privada: "A issue vinculada foi concluída. Confira a correção e avise o cliente." |
Se no seu Jira o Concluído vem antes do lançamento, troque as condições de categoria da segunda regra pelo nome do status, por exemplo Status da issue é Lançado. O artigo de ajuda sobre o Jira traz os detalhes.
Uma atualização para todos os clientes afetados
Com 2 ou 3 clientes afetados, use Responder ao cliente em cada ticket. Com mais, use um tracker, um ticket sem cliente para um problema que muitos clientes têm em comum, e vincule a ele os chats afetados, os tickets e a issue do Jira.
Quando a correção estiver no ar, Atualizar clientes vinculados envia o seu texto a cada cliente no próprio chat dele, até 500 clientes de uma vez. Na mesma etapa, ele pode resolver os chats e tickets vinculados.
As atualizações de tracker nunca saem como modelos do WhatsApp. Numa caixa de entrada do WhatsApp Cloud API, abra os chats que estão fora da janela de 24 horas e envie um modelo aprovado pela caixa de resposta.
Quanto custa e por onde começar
Tickets, trackers e a integração com o Jira fazem parte do plano Enterprise: US$ 12 por agente por mês, ou US$ 9,60 com pagamento anual (preços).
Comece pequeno:
- Conecte o Jira.
- Crie um status de ticket para o trabalho que espera pela engenharia.
- Salve as 2 regras prontas.
O próximo bug que chegar pelo chat é o seu teste. Crie sua conta e o seu novo workspace ganha 7 dias de Enterprise sem cartão de crédito, para até 30 assentos, contando o seu.
Quando os 7 dias acabarem, você escolhe um plano ou continua trabalhando no plano gratuito Hacker com 1 agente.
