Linear no atendimento ao cliente: transforme tickets em relatórios de bug e avise os clientes quando a correção sair

Um cliente relata um bug na segunda-feira. Seu agente posta no canal dos desenvolvedores, alguém abre uma issue no Linear, e o ticket fica parado. Na sexta-feira, mais 20 clientes já relataram o mesmo bug.

A correção saiu na quarta-feira, e ninguém avisou esses clientes. Este guia mostra como passar bugs ao Linear, manter os duplicados numa única issue e avisar os clientes quando a correção estiver no ar.

Em resumo

• Pesquise antes de criar. Procure primeiro uma issue que já exista no Linear, pela chave ou por palavras do título.
• Escreva o relatório para um desenvolvedor. Passos para reproduzir, resultado esperado e real, ambiente, impacto. Nada de nomes ou dados de contato de clientes.
• Um bug, uma issue, muitos tickets. Todo ticket sobre o mesmo bug fica vinculado à mesma issue. O número de tickets vinculados mostra à engenharia o tamanho do problema.
• Deixe o status voltar para o ticket. Os agentes não deveriam ter que conferir o Linear ou colar atualizações à mão.
• Avise o cliente quando a correção estiver no ar. Done no Linear e no ar para os seus clientes podem ser 2 dias diferentes.

O Deskwoot, o help desk que nós desenvolvemos, cuida dos vínculos e do status com a sua integração com o Linear. Todo o resto deste guia funciona com as ferramentas que você já usa.

Por que bugs se perdem entre o help desk e o Linear

O suporte vive no help desk, e a engenharia vive no Linear. Um relatório de bug passa de um para o outro uma vez, e depois disso os 2 registros vão se distanciando.

Ninguém cuida do caminho de volta

O agente que criou a issue segue para os próximos 40 tickets. O desenvolvedor fecha a issue e também segue em frente. Se nada levar o status de volta ao ticket, o cliente descobre ao tentar de novo.

O Linear conta como a própria equipe de suporte evita isso num post sobre como a equipe de Customer Experience trabalha no Linear.

Quando uma issue é marcada como Done, a conversa de suporte vinculada reabre com uma nota, e a equipe de suporte então entra em contato com o cliente para contar da correção e confirmar que ela funciona.

Atualizações de status à mão

Sem um vínculo, alguém do suporte abre o Linear toda manhã, confere uma lista de issues e cola o status nos tickets. Isso toma tempo, fica para trás nos dias corridos e já está errado à tarde.

O mesmo bug, 20 vezes

Quando os agentes não veem o que a engenharia já sabe, cada um cria a própria issue. Aí os desenvolvedores perdem tempo juntando duplicados, e o tamanho real do problema fica escondido em 5 issues com 1 ou 2 relatos cada.

Antes de criar uma issue

Nem todo ticket que diz "está quebrado" é um bug. A engenharia logo deixa de confiar nos relatos do suporte se metade deles acaba sendo dúvida sobre como um recurso funciona.

3 perguntas para fazer primeiro

1. Você consegue reproduzir? Teste você mesmo, no mesmo plano, navegador ou versão do app que o cliente usa.
2. É assim que deveria funcionar? Confira sua central de ajuda e a documentação do produto. Se o comportamento está documentado, é uma dúvida sobre o recurso, e talvez o cliente precise de uma explicação melhor.
3. Já existe uma issue? Pesquise no Linear pelas palavras que um desenvolvedor usaria num título, como "exportação" ou "CSV", e pela tela onde o problema acontece.

Se a terceira resposta for sim, vincule o ticket a essa issue e acrescente o que houver de novo como comentário. Crie uma issue nova só quando nada corresponder.

O que torna um relatório de bug útil para os desenvolvedores

As diretrizes da Mozilla para escrever relatórios de bug foram feitas para o Firefox, e valem para qualquer equipe de software. O resumo deve explicar o problema, não a correção que você sugere, e o relatório deve separar fatos de suposições.

Um modelo que seus agentes podem copiar

• Título: o que dá errado e onde. "Exportação CSV perde a última linha quando há um filtro" é melhor que "Exportação quebrada".
• Passos para reproduzir: numerados, o mais curtos possível, e se o problema acontece sempre ou só às vezes.
• Resultado esperado: o que deveria ter acontecido.
• Resultado real: o que de fato aconteceu, com o texto exato do erro ou uma captura de tela.
• Ambiente: plano, navegador ou versão do app, dispositivo e o horário em que aconteceu, para os desenvolvedores encontrarem o caso nos logs.
• Impacto: quantos clientes relataram, se estão bloqueados e qualquer solução de contorno que você encontrou.
• O que o suporte já tentou: limpar o cache, outro navegador, outra conta.

No post de CX do próprio Linear, os bugs que a equipe de suporte registra a partir do Slack levam as palavras exatas do cliente e um link de volta para a conversa original. Coloque os dois nos seus relatórios também. A citação mostra aos desenvolvedores o que o cliente viu, nas palavras dele.

Deixe os dados pessoais de fora

Tudo o que você cola no Linear fica no Linear. Quando um cliente pede mais tarde que você apague os dados dele, o seu help desk não alcança essa cópia.

Então escreva "um cliente do plano anual" em vez de um nome, e deixe de fora e-mails, telefones e números de pedido de que os desenvolvedores não precisam. Se eles precisarem olhar a conta, podem seguir o link de volta para o ticket.

Um bug, uma issue, muitos tickets

O hábito mais útil de todo este guia: cada ticket sobre o mesmo bug fica vinculado à mesma issue do Linear. Os desenvolvedores ganham um só lugar para trabalhar, e você ganha um só lugar para olhar quando a correção chegar.

Deixe o número falar

Uma issue com 20 tickets vinculados se defende sozinha numa reunião de planejamento. Peça aos agentes um comentário curto na issue quando um novo relato trouxer algo novo, como outro navegador ou um cliente totalmente bloqueado.

Pule comentários que só dizem "+1". O ticket vinculado já entra na conta.

Duplicados que passam mesmo assim

Alguns vão passar. No Linear, um desenvolvedor marca uma issue como duplicada da outra. Desde maio de 2026, isso dá à issue um status próprio, Duplicate, e o Linear move os anexos e os pedidos de clientes dela para a original, como explica o changelog do Linear.

Quando a issue de um ticket passar para Duplicate, vincule esse ticket também à issue original. Senão, o ticket fica acompanhando uma issue em que ninguém vai trabalhar de novo.

Onde os novos relatos chegam no Linear

Uma equipe do Linear pode ativar a Triage, uma caixa de entrada especial dessa equipe. Issues criadas por uma integração, ou por alguém de fora da equipe, chegam lá primeiro. Alguém da equipe aceita, recusa, marca como duplicada ou adia cada uma.

Pergunte aos seus desenvolvedores se eles usam a Triage e quem confere essa caixa. Um relatório limpo, com o impacto no topo, é aceito mais rápido.

Clientes informados sem colar atualizações

Os clientes não precisam de cada mudança de status. Eles precisam saber que você confirmou o bug, que alguém está cuidando dele e que você vai escrever quando ele for corrigido.

Ligue os status do Linear ao que o ticket faz

Os status padrão do Linear são Backlog, Todo, In Progress, Done e Canceled, e cada equipe pode criar os seus. Uma correspondência simples para o lado do ticket:

• Triage, Backlog ou Todo: o ticket espera pelo desenvolvimento. Pause o relógio de SLA dele, para que o prazo não estoure enquanto a engenharia trabalha.
• In Progress: ainda não há nada para contar ao cliente.
• Done: o ticket volta para um agente, que confere se a correção está no ar.
• Canceled ou Won't fix: o agente escreve uma resposta honesta, com uma solução de contorno, se houver.
• Duplicate: vincule o ticket à issue original e continue esperando.

Done nem sempre quer dizer no ar

O Linear diz isso com todas as letras na documentação de Releases: o status Done de uma issue nem sempre significa que a correção chegou aos seus clientes. O pull request pode estar parado em staging, ou uma correção no app mobile pode esperar a próxima versão do app.

Então quem recebe o ticket de volta confere a correção em produção, ou pergunta ao desenvolvedor, antes de escrever ao cliente.

Quanto tempo os clientes podem esperar

Peça aos seus desenvolvedores as metas deles e compartilhe com a sua equipe. O Linear publica as próprias metas num post sobre a sua política de zero bugs: 48 horas para bugs de alta prioridade e 7 dias para o resto.

Os números da sua equipe serão outros. Eles ajudam os agentes a criar expectativas honestas, mas uma meta não é uma data para passar ao cliente.

A mensagem quando você confirma o bug

"Obrigado pela descrição clara. Conseguimos reproduzir o problema, e nossos desenvolvedores já estão com ele na lista. Vou escrever para você aqui assim que a correção estiver no ar, então você não precisa ficar conferindo."

Dê uma data só quando os seus desenvolvedores tiverem se comprometido com uma. Uma data perdida custa mais confiança do que nenhuma data.

A mensagem no dia da correção

"Boa notícia: desde hoje de manhã, a exportação CSV volta a trazer todas as linhas, também com filtros. Você pode tentar mais uma vez e me dizer se funciona para você? Obrigado por avisar, a sua descrição nos ajudou a encontrar o problema rápido."

Cite o problema que o cliente relatou e peça que ele confirme. Uma resposta de "agora funciona" fecha o ticket de verdade.

Como funciona no Deskwoot

O Deskwoot é o help desk que nós desenvolvemos. Com o Linear conectado, os agentes criam ou vinculam issues a partir do ticket, e o status da issue volta sozinho para o ticket.

Configure

1. Ative os tickets em Configurações > Tickets. Tickets e Linear fazem parte do plano Enterprise.
2. Clique em Conectar Linear em Configurações > Integrações > Linear. Você precisa da permissão Gerenciar integrações.
3. Um admin do workspace do Linear permite o Deskwoot e escolhe as equipes que ele pode ver. Depois, escolha a Equipe para novas issues.

Os agentes não precisam de conta no Linear, porque o Deskwoot entra como um app. O guia de ajuda do Linear mostra cada passo.

O que seus agentes ganham

• Criar ou vincular a partir do ticket. Vincule uma issue pela chave, como ENG-123, ou clique em Criar issue. Rascunhar relatório de bug com o Copilot escreve o relatório. O Copilot é instruído a deixar de fora o nome e os dados de contato do cliente, e o agente confere o texto.
• O status no ticket. Cada mudança de status escreve uma linha em cada ticket vinculado. Uma busca pela chave encontra todos os tickets vinculados, e essa é a sua lista para o dia da correção.
• 2 regras prontas. Uma define um status do ticket quando uma issue é criada ou vinculada, por exemplo um status que pausa o SLA. A outra devolve o ticket, com uma nota, para quem vinculou a issue assim que ela estiver concluída.
• Bugs conhecidos. Quando um cliente relata um problema, o Copilot pesquisa as issues abertas da equipe para novas issues e das equipes vinculadas aos seus tickets. Ele é instruído a citar uma data de correção só quando a issue tem uma que ainda está por vir.

Os clientes nunca veem a issue nem as linhas de status.

Quanto custa

O Enterprise custa US$ 12 por agente por mês, ou US$ 9,60 com pagamento anual, então 10 agentes pagam US$ 120 por mês. Conectar o Linear não custa nada a mais (veja os preços).

Os planos Hacker, Startup e Business não incluem o Linear, e cada workspace do Deskwoot conecta um workspace do Linear.

Teste com um bug

Escolha o bug aberto com mais tickets por trás. Crie sua conta, conecte o Linear, vincule esses tickets à issue dele e salve a regra pronta para issues concluídas. O teste de 7 dias do Enterprise não pede cartão, cobre até 30 assentos, contando o seu, e inclui o Linear.