O que as pessoas realmente querem dizer com "exemplos de sistemas de tickets"
Duas buscas diferentes chegam à mesma frase, e ambas são legítimas.
Algumas pessoas querem exemplos de sistemas: me diga as ferramentas, me mostre as telas, me diga qual se encaixa em uma equipe de suporte de 12 pessoas. Outras querem exemplos de tickets: como é um registro real assim que chega, e o que acontece com ele depois. Eu trabalho na fila de suporte do eesel, então me importo principalmente com a segunda opção, e tenho opiniões sobre isso. A comparação de ferramentas vem depois de saber como é um bom ticket, por isso o panorama de software de sistema de tickets faz mais sentido depois deste artigo do que antes dele.
Foi isso que três anos em filas ao vivo me ensinaram: o registro do ticket é onde as equipes de suporte perdem dinheiro silenciosamente. Não na resposta. No ticket que ficou em Pending por nove dias porque ninguém definiu quem o fecha, no campo de prioridade que todo solicitante marca como Urgent, nos dois tickets que eram o mesmo problema aberto por duas pessoas diferentes.
Essa diferença não é cosmética. O Zendesk vem com seis status (New, Open, Pending, On-hold, Solved, Closed). O Freshdesk vem com quatro que não podem ser excluídos, e no HubSpot não existe nenhum campo de status, porque ali um ticket é um registro de CRM avançando por um pipeline de suporte.
O Jira Service Management empilha três objetos: um tipo de solicitação sobre um tipo de trabalho sobre um fluxo de trabalho. Pule a camada de tipo de solicitação e o item de trabalho perde totalmente o acesso aos recursos de central de serviço.
Escolha o exemplo que combina com a sua fila
Seis dos oito exemplos abaixo, na forma em que realmente chegam. Clique neles antes de ler as versões longas.
Oito exemplos de sistemas de tickets, trabalhados do início ao fim
Cada um dos exemplos abaixo segue a mesma forma: o pedido tal como realmente chega, o registro que ele cria, o caminho de status e a armadilha que morde as equipes no terceiro mês.
1. "Onde está meu pedido?" em uma fila de e-commerce
O exemplo de maior volume em qualquer fila de varejo, e o menos interessante de responder. Um cliente cola um número de pedido, o agente abre a aba da transportadora, copia uma data de volta. No Gorgias, o pedido fica em um painel lateral ao lado da conversa, o que resume todo o argumento a favor de um helpdesk nativo de e-commerce em vez de um genérico.
O registro é enxuto: solicitante, número do pedido, uma tag, uma resposta pública. O status vai de New a Open a Solved e quase nunca é reaberto. Essa é a forma que faz as pessoas comprarem rastreamento de pedidos com IA, porque a resposta é uma consulta, não um julgamento. Se um tipo de ticket nunca precisa de uma opinião, ele não deveria precisar de um agente.
A armadilha está na medição. O Zendesk conta a resolução em um só toque como "tickets resolvidos ou fechados com uma única resposta do agente ou sem nenhuma resposta", segundo sua documentação de resolução em um só toque, então uma fila cheia desses tickets faz sua equipe parecer mais rápida do que realmente é.
2. Um reembolso fora do prazo de devolução
Este chega educado e se transforma em uma decisão de política. O cliente está 11 dias fora do prazo de devolução e tem um motivo razoável.
O registro ganha um status de aprovação, que assume quatro valores nos campos de tickets do Zendesk: Pending, Approved, Denied, Withdrawn. Muitas equipes adicionam um status personalizado como "Reembolso processado" para que o financeiro possa filtrar por ele depois. Vale saber antes de criar isso: o Zendesk permite até 100 status de ticket, mas "o seletor de status mostrará apenas os primeiros 10", segundo sua documentação de gestão de status, e um ticket resolvido com um status personalizado mantém esse rótulo depois de fechado.
O caminho de status desvia por Pending enquanto você espera fotos ou uma confirmação de pedido, e Pending é onde os tickets de reembolso vão morrer. O Freshdesk redefine um ticket para Open "toda vez que um cliente responde", o que é útil, mas nada resgata o ticket cujo cliente nunca mais responde. Automatizar a redação está tudo bem aqui, segundo nosso guia de automação de reembolsos. Automatizar a decisão da exceção não está.
3. Redefinição de senha e bloqueio por MFA
O ticket mais comentado em TI, e o de maior variação de custo. A mesma pergunta, seis portas de entrada:
Os números da HDI de 2021 colocam o autoatendimento em US$ 2,37 e o presencial em US$ 37,52, uma diferença que os autores da análise de custos da HDI descrevem como "mais de duas ordens de magnitude (100X)". Nada na resposta mudou. Só a porta pela qual o usuário entrou.
O problema é que o desvio não deixa a fila mais barata na média. A HDI é direta sobre isso em seu benchmark de autoatendimento: à medida que incidentes de baixo tempo de atendimento migram para o autoatendimento, "a complexidade média e o tempo médio de atendimento dos incidentes que continuam sendo tratados por agentes ao vivo aumentarão". Seu custo por ticket pode subir enquanto seu custo total cai. Planeje a conversa sobre relatórios antes que seu portal de autoatendimento entre no ar, ou a primeira revisão mensal vai parecer um fracasso.
Também vale a pena calibrar a ambição: o banco de dados de benchmark da MetricNet coloca a taxa média de conclusão do autoatendimento em 10,4%, contra apresentações de fornecedores que prometem 60 ou 80. Nosso guia de desvio de tickets usa esse mesmo número como base.
4. Solicitação de acesso e equipamento para novo funcionário
Um gestor registra uma linha ("novo funcionário na segunda, o kit de sempre") e cria uma semana de trabalho. Isso é uma solicitação de serviço, não um incidente, e a distinção sai cara: os dados de campo da MetricNet colocam o tempo de trabalho de um incidente entre 12,3 e 21,5 minutos contra 35,4 a 95,9 minutos para uma solicitação de serviço no estudo de volume da MetricNet.
O Jira Service Management modela isso corretamente. Um espaço novo vem com cinco tipos de trabalho (IT Help, Purchase, Change, Fault, Access) e dois tipos de solicitação prontos para uso, e os campos do tipo de solicitação vêm do seu tipo de trabalho. Ele também renomeia os status para o solicitante: internamente o ticket diz Waiting for Customer, e o portal mostra "Requester Action Needed" na configuração padrão do JSM. Um detalhe pequeno, uma grande diferença em quantas respostas de "alguma novidade?" você recebe.
Se essa forma domina a sua fila, leia em seguida os artigos sobre solicitação de acesso e solicitação de hardware, e trate o onboarding de RH como o mesmo padrão com aprovadores diferentes.
5. Um relato de bug que vira um escalonamento de engenharia
Um cliente encontra um defeito genuíno. O suporte o reproduz, vincula uma issue de engenharia, e agora fica com um ticket que não consegue fechar.
O campo Type do Zendesk carrega quatro valores (Question, Incident, Problem, Task) no conjunto de campos padrão, e é de mão única: uma vez definido, você não pode deixá-lo em branco de novo. Desativar o campo por completo faz todo ticket assumir Incident por padrão. O Jira Service Management, em vez disso, separa os dois eixos, mantendo o status para onde o trabalho está e a resolution para como ele terminou, com um valor de resolution Known error para o caso de causa documentada mais solução alternativa.
A armadilha aqui é o On-hold. É um status interno opcional que "o solicitante do ticket nunca vê", segundo a documentação do ciclo de vida do Zendesk; a visão dele continua mostrando Open. Então o ticket fica estacionado e o cliente pensa que está sendo tratado. Estabeleça um ritmo proativo de atualizações, e veja gestão de escalonamentos e triagem de relatos de bugs para o lado do roteamento.
6. Uma disputa de cobrança em um helpdesk centrado em CRM
"Vocês me cobraram duas vezes em junho" é um ticket de suporte que na verdade é um ticket financeiro, e é exatamente por isso que as equipes o tratam em um sistema com formato de CRM.
No HubSpot Service Hub o ticket é um objeto em um pipeline, e o Support Pipeline padrão tem quatro status: New, Waiting on contact, Waiting on us, Closed. Alguns comportamentos importam para uma disputa que fica indo e voltando entre equipes. A data de fechamento é bidirecional, então mover um ticket de volta para um estágio aberto limpa o valor. O Category é definido pela IA a partir da primeira mensagem e só existe no Enterprise. E hs_ticket_owner_type registra se um Human rep, Customer Agent ou Rule-based bot tocou no registro, o que é o primeiro rastro de auditoria honesto que já vi para tickets tratados por IA em um helpdesk convencional.
As metas de desvio devem ser modestas nessa forma. Nosso artigo sobre desvio de tickets do HubSpot traz o detalhe das restrições por plano, e CRM de atendimento ao cliente cobre quando o modelo centrado em CRM realmente vence.
7. Uma queda de serviço que chega como quarenta tickets
Uma falha, quarenta registros, e um campo de prioridade prestes a ser testado.
As cinco prioridades do Jira vêm com a redação própria da Atlassian, no esquema de prioridades do JSM, de Highest ("Este problema bloqueará o progresso") até Lowest. As quatro prioridades do Freshdesk estão "fixadas diretamente em nossos sistemas" porque as políticas de SLA dependem delas, segundo seu guia de campos de tickets. O Zendesk esconde uma dependência mais desagradável: desative o campo Priority e as metas de SLA param de se aplicar por completo.
Deixe os solicitantes definirem a prioridade sozinhos e o campo deixa de significar qualquer coisa:
"Dealt with this decades ago. It was scrapped quickly because as you might imagine it was abused to death. It really didn't bother me though. I still got the same number of tickets and just slogged through them. When people got mad because we were missing SLAs we just replied there was nothing we could do now that all tickets were priority."
371 votos positivos nesse comentário, o que mostra o quão comum é esse padrão. A prioridade deveria ser derivada de regras de impacto e urgência que você controla, não digitada por quem grita mais alto. O guia de gestão de SLA traz o lado da política, e priorização de tickets com IA cobre como derivá-la automaticamente.
8. Uma solicitação de funcionalidade que nunca será construída
O ticket mais educado da fila e o mais propenso a apodrecer. Alguém pede um modo escuro, o produto diz não, e o registro não tem para onde ir.
O Jira Service Management tem uma resposta clara: resolution Won't do, separada do status, e a chave do item de trabalho é exibida riscada assim que resolvida. O Zendesk e o Freshdesk, em vez disso, empurram você para Solved ou Resolved, o que silenciosamente codifica "fizemos a coisa" quando você não fez. O Freshdesk pelo menos é explícito sobre essa divisão: em suas próprias palavras, Resolved significa feito "segundo o agente" e Closed significa feito segundo o cliente, com fechamento automático após 72 horas.
O fechamento muitas vezes não cabe ao agente de qualquer forma. O Zendesk afirma claramente em sua documentação do ciclo de vida do ticket que "os tickets não podem ser definidos manualmente como Closed": uma automação padrão os fecha quatro dias depois de Solved, e com as automações de fechamento desativadas, entra em vigor um limite rígido de 28 dias que não pode ser alterado.
O mesmo ticket em seis sistemas reais
Agora a outra leitura da palavra-chave: sistemas de exemplo. Isto é o que um pedido idêntico custa e como ele se parece em seis das ferramentas que mais vejo em chamadas com clientes.
| Sistema | Um ticket é | Status prontos para uso | Preço de entrada | Unidade de cobrança de IA | Melhor encaixe de exemplo |
|---|---|---|---|---|---|
| Zendesk | Objeto de ticket com 15 campos padrão | 6 (mais até 100 personalizados) | US$ 19/agente/mês Support Team, US$ 55 Suite Team | Verified automated resolution, taxa não divulgada | Filas grandes multimarcas |
| Freshdesk | Ticket com 11 padrões que não podem ser excluídos | 4 | US$ 19/agente/mês Growth | Sessão, US$ 49 a cada 100 extras | Equipes médias que querem simplicidade |
| Zoho Desk | Ticket dentro de um departamento | 3 principais mais personalizados | US$ 0 Free (3 usuários), US$ 14 Standard | Zia, incluído conforme a edição | Equipes sensíveis ao custo |
| Help Scout | Conversa em uma caixa de entrada compartilhada | Active, Pending, Closed | US$ 0 Free (5 usuários), US$ 25/usuário/mês | Resolução, US$ 0,75 | Equipes pequenas, trabalho baseado em e-mail |
| Gorgias | Ticket vinculado a um pedido do Shopify | Open, Closed | US$ 40/mês (50 tickets), nunca por agente | Interação automatizada, US$ 1,50 | Exemplos de pedidos de e-commerce |
| Jira Service Management | Tipo de solicitação sobre tipo de trabalho sobre fluxo de trabalho | Duplo nome, definido pelo fluxo de trabalho | US$ 25/agente/mês Standard (1 a 15 agentes) | US$ 1 por resolução, mais US$ 0,30 por conversa assistida | TI interno e aprovações |
Os preços são tarifas de tabela anuais das páginas de preços de cada fornecedor, verificadas nesta semana. Dois deles merecem um alerta. O Jira Service Management anuncia uma média combinada de US$ 20 por agente, que é a tarifa para seu controle deslizante padrão de 75 agentes sob precificação progressiva por volume, não o que uma equipe de 10 agentes paga. E a unidade principal do Zendesk, a automated resolution, não tem nenhum valor em dólares divulgado em nenhum lugar da página de preços, o que transforma o orçamento da camada de IA em uma ligação de vendas.
Avaliações e grades de recursos não vão te dizer qual desses se encaixa. As formas de ticket acima vão. Uma fila de e-commerce que é 60% rastreamento de pedidos quer o modelo Gorgias; uma central de TI interna cheia de aprovações quer Jira Service Management.
Para o panorama mais amplo, melhores softwares de helpdesk percorre ferramenta por ferramenta, e exemplos de software cobre o lado voltado ao cliente.
Três exemplos de tickets dando errado
Os casos de falha são mais instrutivos do que o caminho ideal, e cada um deles pode ser corrigido com configuração em vez de mais pessoal.
O ticket que ninguém está esperando. Um líder de suporte contou sua fila e descobriu que o backlog era em grande parte ficção:
"I was going through our queue today and found 90 tickets where we responded, asked for more information from the customer but then never heard back from them. They just sit there inflating our numbers and that honestly doesn't look good for management. We have been called before for unresolved open tickets so this is a big deal."
90 dos 200 tickets abertos estavam esperando um cliente silencioso, então o número de abertos nunca foi o backlog real. Outro gestor de TI relatou ter reduzido o backlog de um grupo em 54% só com o fechamento automático de tickets com mais de cinco dias. Nosso artigo sobre limpeza de backlog é a versão longa dessa correção.
A base de conhecimento que ninguém atualiza. Todos os exemplos de autoatendimento acima presumem que existe um artigo e que ele está atualizado:
"I run a small team, and we have an internal wiki for processes, FAQs, and troubleshooting. The problem? No one updates it. People keep asking the same questions in Slack instead of checking the wiki."
As duas metades falham juntas: a base de conhecimento interna apodrece, e as pessoas passam a contorná-la. Treinar a IA com tickets passados, em vez de apenas com artigos, é a resposta prática, e nosso guia de treinamento da base de conhecimento cobre isso.
Os relatórios que você não consegue tirar da ferramenta. Um líder de suporte que já construiu dashboards em uma ferramenta de BI de verdade ainda assim não conseguiu tirar números básicos:
"I have never found anything as complex as Zendesk explore. I've worked with ThoughtSpot building dashboards, reports and exports but omg Zendesk, you are taking so much of my time!!!!!!!!"
Verifique a camada de relatórios com base nesses exemplos exatos antes de comprar, não depois. Relatórios do Zendesk e KPIs de atendimento ao cliente são as duas coisas para testar no primeiro dia de um teste.
O que uma camada de IA muda nesses oito exemplos
Não os oito, e esse é justamente o ponto. Os exemplos 1, 3 e a maior parte do 6 se repetem para sempre com uma resposta conhecida. Os exemplos 2, 5, 7 e 8 precisam de uma pessoa segurando a política.
Já vi de perto esse modo de falha. Um dos nossos próprios clientes, um fornecedor dinamarquês de energia solar, teve um bot que inventou alegações de assinatura e as enviou para pessoas reais quando sua base de conhecimento não tinha um artigo correspondente. Esse incidente é o motivo pelo qual toda implantação do eesel agora executa uma simulação sobre tickets históricos antes de responder ao vivo a qualquer pessoa. Um líder de CX de uma marca de suplementos no Gorgias colocou essa exigência melhor do que nossa própria documentação:
"The AI will never be able to answer 100% of the questions, but if it tries and just answers 'sorry I don't know this,' I cannot go and check all my 7,000 tickets to see if the AI actually made a good answer. I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."
Esse é um pedido justo, e ele se encaixa exatamente na lista de exemplos: dê à IA a forma do status de pedido, mantenha-a longe da queda de serviço. Quando o escopo está certo, os números são bons. O Gridwise resolveu 73% das solicitações de nível 1 em seu primeiro mês, depois de um teste de sete dias. Quando o escopo está errado, você acaba com a história do painel solar.
Leia alucinações de IA no suporte e transferência de IA para humano antes de escolher quais formas automatizar.
Classificação de tickets e marcação de tickets são os primeiros passos seguros em quase qualquer fila, porque uma tag errada não custa nada e uma resposta errada custa um cliente.
Experimente o eesel nos seus próprios exemplos de tickets
Se a sua fila se parece com a lista acima, a atitude útil não é trocar de helpdesk. É colocar uma camada de IA sobre o que você já tem e apontá-la para as duas ou três formas que se repetem.
O eesel se conecta ao Zendesk, Freshdesk ou Gorgias em poucos minutos, treina com seus tickets passados e sua central de ajuda, e depois simula sobre o volume histórico para que você veja as respostas que ele teria enviado antes que qualquer cliente as veja.
Você escolhe quais formas de ticket ele toca, então o exemplo 7 nunca chega até ele. A cobrança é de US$ 0,40 por ticket atendido, sem taxa por assento, então encaminhar 200 dos seus 1.000 tickets mensais custa US$ 80, não um novo nível de plano. Grátis para experimentar.
Comece pelo exemplo 1 ou pelo exemplo 3. São os de maior volume, menor risco e mais fáceis de comprovar em uma semana.
Perguntas frequentes
O que é um exemplo de sistema de tickets?
Quais são exemplos de sistemas de tickets?
Como um ticket de suporte se parece dentro do sistema?
Quais são exemplos de tickets de um sistema de tickets de TI?
Quanto custa um único ticket de suporte?
Qual é a diferença entre um incidente e uma solicitação de serviço?
A IA consegue lidar com esses exemplos de sistemas de tickets do início ao fim?
Article by
Riellvriany Indriawan
Riell is a designer and writer at eesel AI with about two years of experience researching CX platforms, AI chatbots, and helpdesk software. She combines her design background with a sharp eye for how these tools actually look and feel in practice — making her comparisons unusually visual and user-focused.
