Sistema de tickets de suporte: como montar um que aguente

O que é, de facto, um sistema de tickets de suporte

Um sistema de tickets de suporte é, no fundo, aquilo que transforma uma conversa num registo. Um email, um chat, uma mensagem de WhatsApp e um formulário web chegam todos ao mesmo sítio, ganham um número, um responsável, um estado e um relógio, e permanecem ali até alguém os fechar.

Isto parece óbvio, até se comparar de facto com a caixa de entrada partilhada que está a substituir. Numa caixa de entrada, o estado de um pedido vive na cabeça de alguém, ou no facto de o tópico parecer lido. Num sistema de tickets, o estado é um campo, ponto final. Essa única mudança é o que torna possível o encaminhamento, os SLAs, os relatórios e qualquer tipo de resolução automatizada de tickets, porque um software consegue ler um campo e não consegue ler um palpite.

Aquilo que está realmente a pagar:

• Canais de entrada. Email, widget de chat, um portal de clientes, WhatsApp, telefone e, cada vez mais, uma API a partir da sua própria app.
• Um modelo de dados do ticket. Campos, estados, prioridade, tipo, etiquetas. É a parte que toda a gente subestima.
• Encaminhamento e SLA. Quem recebe, por que ordem e até quando.
• Uma camada de conhecimento. O centro de ajuda, mais as macros e respostas guardadas que os agentes realmente usam.
• Relatórios. Se consegue responder a "o que aconteceu no mês passado" sem exportar para Excel.
• Uma camada de IA, já padrão, e cobrada à parte.

O ciclo nesse diagrama é a parte que morde mais tarde. Os campos decidem o que se consegue reportar, e os relatórios são onde se descobre, seis meses depois, que nunca se capturou o único campo de que agora realmente se precisa.

O sinal de que já ultrapassou a caixa de entrada partilhada

O volume é, honestamente, o pior sinal a que atender aqui. Já vi equipas de duas pessoas com 40 emails por dia que genuinamente não precisavam de um desk, e equipas de cinco pessoas com 200 que precisavam de um desk um ano antes de o terem obtido. Os verdadeiros gatilhos são estruturais, não numéricos.

Precisa de um sistema de tickets de suporte no momento em que um pedido tem de sobreviver à ausência de uma pessoa, quando dois agentes continuam a responder ao mesmo cliente, quando alguém começa a pedir-lhe números que não consegue produzir, ou quando promete por escrito um tempo de resposta a um cliente. Este último é, de facto, a linha dura. Um SLA sem um registo com marca temporal não passa de um desejo.

Há também um gatilho mais silencioso, que é quando o fornecedor atual deixa de servir. Esta avaliação é a versão mais clara disso que já li:

"Zendesk is very configurable, though I struggle to think of what I like about Zendesk. I found the reporting tool in particular to be very difficult to use. Their AI offerings felt bolted on versus integrated, and their integrations didn't work particularly well. Support was not timely. Pricing was not competitive. This is why we moved to another tool."

Gail D., Senior Director of Customer Support, G2

Quatro razões distintas numa só frase, e nenhuma delas é "não consegue guardar um ticket". É isto que ultrapassar um desk realmente parece na prática, e vale a pena ler antes de se comprometer com uma plataforma pelos próximos cinco anos. Se já está nesse ponto, o nosso resumo de software de help desk e a comparação de software de ticketing são as shortlists por onde eu começaria.

Configure nesta ordem

Todas as implementações falhadas que já vi saltaram o passo dois e foram diretas para as automações. Esta é a ordem que eu seguiria, e o que decidir de facto em cada etapa.

Passo 1: canais, e um único sítio onde todos aterram

Ative os canais que consegue realmente ter equipa a vigiar, não apenas os da lista de funcionalidades. Cada canal que liga é uma fila que alguém tem de vigiar, e o custo por contacto varia imenso consoante o canal. Os números de 2021 da HDI colocam o self-help em 2,37 $ por ticket, o envio web em 15,07 $, o chat em 15,72 $, o email em 16,13 $, a voz em 17,19 $ e o atendimento presencial em 37,52 $, uma diferença que a própria fonte chama de "100X".

Aqui ficam duas regras práticas. Encaminhe tudo para uma única fila, mesmo que chegue de cinco sítios diferentes, porque uma segunda fila não passa de um segundo backlog que ninguém verifica numa sexta-feira. E no email, em particular, envie de imediato uma confirmação de receção com o ID do ticket no assunto: esse ID é o que mantém uma resposta ligada ao registo correto em vez de abrir um duplicado. Esse mecanismo é basicamente toda a diferença entre um tópico e um ticket, e explorámo-lo no nosso guia sobre software de help desk por email.

Passo 2: os campos, antes de tudo o resto

Os campos são o esquema de toda a sua operação. O conjunto padrão da Zendesk é Solicitante, Seguidor, Responsável, CC, Partilha, Assunto, Descrição, Estado, Tipo, Prioridade, Etiquetas, Estado de aprovação, Tipo de resolução, Nível de resolução e Grupo de canal, com o Assunto limitado a 255 carateres e a Descrição a funcionar também como primeiro comentário, segundo a documentação de campos de tickets. A Freshdesk vem com 11 campos predefinidos que não podem ser eliminados.

Duas armadilhas que vale a pena conhecer antes de começar a adicionar os seus próprios campos:

• Desativar um campo pode silenciosamente quebrar outra coisa. Desative o campo Prioridade da Zendesk e, nas próprias palavras da Zendesk, "os objetivos de SLA não se vão aplicar". Desative o Tipo e todos os tickets passam por defeito a Incidente.
• Editar uma dropdown destrói o histórico. A Freshdesk é direta quanto a isso: "Se alterar ou eliminar uma opção de uma dropdown que está em uso num ticket existente, o valor desse campo passará a null."

Os campos personalizados também são uma barreira de plano, algo que vale a pena saber antecipadamente. A Freshdesk oferece-os a partir do plano Growth com limites por tipo, 80 campos de texto de uma linha, 10 de várias linhas, 80 dropdowns, aumentando no Pro e Enterprise. Decida o punhado de campos que realmente vai usar em relatórios, nomeie-os uma vez só e resista à tentação de adicionar um campo novo para cada caso pontual. As etiquetas existem precisamente para a cauda longa, e as etiquetas de tickets são muito mais fáceis de podar depois do que uma dropdown sobre a qual alguém já construiu um fluxo de trabalho.

Passo 3: os estados, e as duas regras sobre fechar

Os estados são onde os fornecedores discordam silenciosamente entre si, e onde a maioria das filas acaba por apodrecer. O "aberto" de ninguém significa o mesmo que o seu.

A Zendesk funciona com seis estados (New, Open, Pending, On-hold, Solved, Closed), e três das suas regras costumam apanhar as pessoas desprevenidas. New é uma porta de sentido único, já que "depois de mudar o estado de New para outro, não é possível voltar a colocá-lo em New". On-hold permanece invisível para o cliente, que continua a ver Open. E "os tickets não podem, de todo, ser manualmente colocados em Closed": o fecho é uma automação, quatro dias após Solved por defeito, com um limite rígido em que os tickets fecham 28 dias após serem resolvidos, e qualquer regra que tente ir além disso "não será respeitada".

A Freshdesk mantém quatro estados e traça a linha de forma um pouco diferente: Resolved significa concluído "segundo o agente" e Closed significa concluído "segundo o cliente", com um fecho automático 72 horas após Resolved. O Jira Service Management usa dois nomes para um único estado, pelo que um "Waiting for Customer" interno é mostrado ao solicitante como "Requester Action Needed". A HubSpot nem sequer tem propriamente um campo de estado, apenas fases de pipeline a que, por defeito, se chama estados.

Aqui está a mesma conversa, contada em quatro desks diferentes. Escolha o seu:

A razão pela qual isto importa para além da curiosidade é que os seus relatórios herdam estas definições, sejam quais forem. Se "aberto" no seu desk incluir todos os tickets à espera de um cliente silencioso, o seu número de backlog é ficção, e mesmo assim alguém acabará por o avaliar em função dele.

Essa divisão não é hipotética, já agora:

"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."

Our Help desk ticketing system shows 200 open tickets but half of them have had no user response, Reddit

A solução é uma regra de fecho automático, mais a disciplina de realmente confiar nela. Um IT manager escreveu no r/ITManagers que fechar automaticamente tickets com mais de cinco dias "reduziu instantaneamente o backlog de um grupo em 54%". Nada piorou para os clientes também, já que uma resposta reabre o ticket de qualquer forma.

Passo 4: encaminhamento, prioridade e SLA são um único sistema

Trate estes três como definições separadas e, mais cedo ou mais tarde, vão colidir entre si. A prioridade alimenta a política de SLA, e o encaminhamento decide quem está de facto a vigiar o relógio.

Comece pela questão da prioridade, que tende a tornar-se política. Não deixe que os próprios solicitantes a definam. Este é o comentário mais votado sobre o tema, com 371 votos a favor, e envelheceu bem:

"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."

u/bitslammer, Reddit

Defina a prioridade você mesmo, a partir de regras, sobre coisas que consegue de facto observar: nível de plano, valor do pedido, palavra-chave, canal, ou um cliente que já respondeu três vezes. A Freshdesk fixa os seus quatro valores de prioridade precisamente porque estão "diretamente ligados à funcionalidade das Políticas de SLA", por isso, na prática, está a configurar o SLA quer queira quer não.

Depois vem o próprio SLA. Escolha objetivos que consiga cumprir na sua pior semana, não na melhor, defina o horário de funcionamento com honestidade, e lembre-se de que Pending existe para pausar o relógio enquanto é o cliente quem está a bloquear as coisas. As múltiplas políticas de SLA da Freshdesk começam no Pro, por isso no Growth o relatório de SLA integrado existe mas não é possível segmentá-lo por cliente ou produto. Se quiser a versão mais longa disto, escrevemos separadamente sobre gestão de SLA com IA e automações de escalonamento por SLA.

O encaminhamento em si é, honestamente, a metade fácil: competências ou grupos, um responsável de reserva para tudo o que não encaixe, e um alerta quando um ticket fica uma hora sem responsável atribuído. Se preferir que isto aconteça sem escrever você mesmo dezenas de regras, tanto o encaminhamento de tickets com IA como a priorização de tickets leem o texto do ticket em vez de funcionarem a partir de uma lista de palavras-chave, e a classificação de tickets etiqueta-o logo à entrada.

Passo 5: a base de conhecimento, e o número que ninguém publica

Todos os fornecedores lhe vão mostrar um gráfico de deflexão. O número honesto é menor do que isso. A base de dados de benchmarking da MetricNet coloca a taxa média de conclusão do self-service em 10,4%, variando entre zero em desks sem self-service e 55% no topo, e a sua medição anterior de 2018 foi de 8,9%, sendo a maioria desses incidentes autorresolvidos apenas reposições de palavra-passe.

Portanto, uma base de conhecimento vale a pena construir, claro, mas não vale a pena fingir que, sozinha, vai reduzir a sua fila para metade. Construa-a a partir dos tickets que realmente recebe, com as palavras que os clientes realmente usam. E planeie também a degradação, porque é praticamente universal:

"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."

Keeping a Knowledge Base Up to Date is a Nightmare, Reddit

Há duas coisas que realmente ajudam aqui. Faça da redação do artigo parte do próprio ato de fechar o ticket, não um projeto à parte de sexta-feira. E coloque uma camada de pesquisa sobre tudo, em vez de esperar que as pessoas naveguem para a encontrar, que é exatamente a ideia por trás de um chatbot de base de conhecimento com IA.

Se o seu conteúdo vive em cinco sítios diferentes, a questão da recuperação importa mais do que o tema do centro de ajuda escolhido, e uma base de conhecimento interna bem organizada é o que faz o resto realmente funcionar.

Passo 6: os relatórios, a camada que não se consegue corrigir depois

Este é o passo que as pessoas costumam deixar até ao fim do trimestre. Nessa altura já é tarde: um relatório só pode agrupar por um campo que já existia.

Pior ainda, o próprio construtor de relatórios acaba por ser uma barreira de plano, e o preço dessa barreira também não é pequeno.

Os próprios painéis em direto da Zendesk também estão a caminho do fim: estão limitados a contas que acederam ao Explore antes de 5 de maio de 2026, e a 25 de janeiro de 2027 os painéis em direto pré-construídos e a capacidade de os criar são removidos do Explore por completo.

Quando os relatórios nativos são fracos, a solução alternativa é sempre a mesma, e custa uma semana de trabalho de uma pessoa por mês:

"The reports and automations can be somewhat difficult to navigate. We ended up just exporting all of our tickets every month and creating our own reports through Power query in Excel."

Trent B., Director of Client Care, Capterra

Duas métricas que vale a pena entender bem, já agora. A resolução no primeiro contacto é uma métrica de qualidade, a resolução no primeiro nível é uma métrica de custo, e a HDI é explícita ao afirmar que as duas não são intermutáveis: a FLR líquida tem uma média de 74,3% e apenas 1,4% dos service desks ultrapassam 95%. E tenha cuidado também com a resolução de um único toque: a própria definição da Zendesk conta tickets "com uma única resposta do agente ou nenhuma resposta", o que significa que um ticket de spam que acabou de eliminar continua a contar como uma vitória.

Do lado da satisfação, o relatório de CSAT é um trabalho de configuração à parte, que vale a pena montar na mesma semana e não no trimestre seguinte.

A camada de IA é uma segunda tabela de preços

Todos os desks vendem agora IA por cima do lugar, e os medidores não concordam entre si de todo. A unidade influencia a fatura muito mais do que a tarifa, honestamente, por isso leia primeiro a unidade.

A diferença entre "resolvido" e "com envolvimento" é onde as faturas começam a ficar estranhas. O modelo de três níveis da Zendesk, em vigor desde 18 de maio de 2026, só fatura a resolução verificada, o que é de facto mais justo do que o que existia antes, embora a mudança não tenha sido popular entre todos os que viveram o modelo antigo:

"Complete trash lol, stuff I used to get free now counts as an AR. Most of the ARs are abandoned chats. There's no dispute resolution process. Complete scam. I used to like Zendesk but since trying the new bot and now this I have little good will left"

u/Kerrick, Reddit

As afirmações sobre o teto merecem o mesmo ceticismo, honestamente. A Zendesk anuncia, na sua página de serviço, que os agentes de IA conseguem "automatizar até 80% das interações", enquanto a leitura da MetricNet do setor é que as organizações líderes estão a automatizar até 50%. Ambas podem ser verdadeiras ao mesmo tempo, em filas diferentes, e é exatamente por isso que se deve testar na sua própria fila antes de assinar seja o que for. Escrevemos sobre o aspeto real de uma taxa de resolução por IA realista, e sobre o que um help desk de IA realmente faz, caso queira o panorama completo.

Mais uma coisa em que insistiria, por experiência e não por teoria. Pergunte o que a IA faz quando a base de conhecimento não tem resposta para algo. Já tivemos clientes pagantes, incluindo um fornecedor dinamarquês de energia solar, cujo bot preencheu essa lacuna a inventar afirmações e a enviá-las diretamente a pessoas reais. Um limite de confiança e um mecanismo de recusa a responder não são um extra agradável, são a diferença entre prevenir alucinações e gerar toda uma nova categoria de ticket.

O que custa um ticket depois de escalar

O volume não é, na verdade, o que torna o suporte caro. A escalada é.

A escada de custos da MetricNet coloca o nível 1 em 22 $, o suporte de desktop em 62 $, o nível 3 em 85 $, o suporte de campo em 196 $ e o suporte de fornecedor em 471 $, e a palavra-chave aqui é cumulativo: um ticket registado no nível 1 e escalado para o nível 2 custa "62 $ mais 22 $, num total de 84 $". São dólares de 2011, por isso devem ser tratados como proporções e não como uma cotação atual. A proporção é realmente o que importa, e é por isso que maximizar a resolução no primeiro nível é, no enquadramento da MetricNet, basicamente o mesmo que minimizar o custo total.

Dois números de apoio que vale a pena ter presentes aqui. Os salários e benefícios dos agentes representam mais de metade do custo de um service desk, e cerca de dois terços do custo total acabam por ser pessoal quando se contam supervisores, QA e formadores. E a utilização dos agentes tem uma média de 48%, com o aviso de que taxas a aproximarem-se de 60 a 70% produzem "uma rotatividade de agentes relativamente alta porque estão a exigir demasiado dos agentes".

Portanto, o argumento de negócio honesto para um sistema de tickets de suporte não é "poupa tempo em cada resposta". É que a estrutura impede que os tickets subam a escada logo à partida: melhor resolução de primeiro nível, menos reaberturas, menos transferências. O que também é válido para colocar a IA na faixa de nível 1 em vez de em tudo ao mesmo tempo, e é a razão pela qual a deflexão de tickets é medida em escaladas evitadas, não em mensagens enviadas.

Se as escaladas já são o seu problema, mais do que o volume, a gestão de escaladas é a parte da configuração em que eu trabalharia primeiro, antes de qualquer coisa na lista de compras de IA.

O que eu verificaria antes de assinar seja o que for

A demo vai mostrar-lhe a vista do agente. Estas são as coisas que não vai mostrar, e aplicam-se tanto se estiver a comprar o seu primeiro desk como se estiver a mudar para uma das alternativas à Zendesk.

1. Consigo construir o relatório de que preciso no plano que estou a comprar? Peça o plano exato, não o nome da funcionalidade. Guarde uma captura de ecrã da resposta.
2. O que fecha um ticket, e ao fim de quanto tempo? Confirme a janela de fecho automático e se uma resposta do cliente reabre o ticket ou cria um novo.
3. Quantos estados posso ter, e quantos aparecem? A Zendesk permite até 100 estados, mas o seletor mostra apenas os primeiros 10 ativos.
4. O que acontece a um valor de dropdown que retiro? Se a resposta for "o campo passa a null", planeie a sua taxonomia agora.
5. Qual é a unidade de IA, por escrito? Resolução, sessão, conversa com envolvimento ou interação. Depois pergunte o que conta como um chat abandonado.
6. O que faz a IA quando não sabe? Sem limite de confiança, não há acordo.
7. Onde ficam os meus dados, e consigo movê-los? O complemento de região da Zendesk é gratuito a partir do Suite Professional, mas "incluído mas não ativado automaticamente", e a Freshdesk só deixa escolher uma região no registo.
8. Consigo tirar o meu histórico? As exportações normalmente correm bem. Os campos personalizados saem sem etiqueta, o que se torna um problema real mais tarde.

Esse último ponto tem um custo que só se sente realmente na saída:

"I have exported my historical tickets to XML but not going to work. First my tickets are a mess. They are not properly organized, tagged, or anything. Lot of the info chatGPT would need to understand is in custom fields which are not labeled in any export."

u/ToastyPasta, Reddit

E uma nota honesta sobre o âmbito, já que a objeção é justa. Uma líder de CX numa marca de suplementos que processa cerca de 7.000 tickets por mês disse-nos claramente: "preciso de uma IA que trate apenas dos tickets em que confia e que deixe todos os outros em paz." Se um fornecedor não conseguir descrever como o seu sistema decide o que deixar em paz, essa é a resposta à pergunta seis.

Experimente a eesel no sistema de tickets de suporte que já usa

A maioria das equipas que lê isto não precisa, na verdade, de um desk novo. Precisa que o desk que já tem deixe de perder tickets de nível 1, e é esse o trabalho que a eesel faz, como um sistema de ticketing com IA sobreposto ao que já usa.

A eesel liga-se à Zendesk, Freshdesk, Gorgias, Help Scout e às restantes através das respetivas APIs, aprende com os seus tickets passados e com o seu centro de ajuda, e trata da faixa repetitiva por conta própria enquanto tudo o resto fica com os seus agentes.

Há duas coisas que a distinguem de qualquer IA já presente no seu plano. Consegue simular todo o processo contra o seu próprio histórico de tickets antes de um único cliente o ver. E o preço é de 0,40 $ por ticket tratado, sem taxa por lugar, sem mínimo, por isso uma implementação parcial custa apenas um valor parcial.

É também por isso que confio na ordem de configuração acima. Quando fizemos um teste com tráfego real para uma joalharia alemã na Zendesk e na Shopify, com cerca de 1.000 tickets por mês, a precisão da triagem saiu em 93% e a deteção de spam em 100%, enquanto apenas 12% dos rascunhos foram enviados tal como estavam. A triagem estava pronta, a redação de rascunhos não estava, e foi a simulação que nos disse qual era qual antes de qualquer cliente descobrir. Pode começar gratuitamente e apontá-la para a sua própria fila em poucos minutos.