Ticket de atendimento: o que é, ciclo de vida e como organizar um sistema de tickets

Ticket (ou chamado) é o registro individual de uma solicitação de cliente dentro de um sistema de tickets: uma unidade rastreável que agrupa a conversa, o contexto, o responsável e o status daquela demanda até a resolução. O e-mail perguntando sobre a fatura, a mensagem no WhatsApp reclamando de um pedido, a dúvida no chat — cada uma vira um ticket com número próprio, dono definido e histórico completo.

Se você chegou aqui procurando "o que é ticket de atendimento" em uma frase: é a diferença entre responder mensagens e gerenciar demandas. Uma caixa de entrada compartilhada responde mensagens. Um sistema de tickets garante que nenhuma demanda se perca, que dá para saber quem está cuidando de cada uma, há quanto tempo, e o que já foi dito antes.

Por que "ticket" e não só "e-mail respondido"

Um ticket carrega coisas que uma conversa solta não carrega:

Identidade: um número único (#4821) que cliente e time usam para se referir ao caso.
Estado: aberto, em andamento, resolvido — em qualquer momento, alguém consegue dizer onde o caso está.
Dono: um atendente responsável. "Todo mundo viu" é o jeito mais rápido de ninguém responder.
Prazo: tickets se conectam a SLA — tempo de primeira resposta e tempo de resolução deixam de ser sorte e viram compromisso medível.
Histórico: transferências, notas internas, anexos e respostas anteriores ficam no mesmo lugar. O cliente não precisa recontar a história a cada contato.

É isso que o mercado chama de sistema de tickets (ou help desk): a camada de organização por cima dos canais. O canal pode ser e-mail, chat, WhatsApp ou telefone — o ticket é o que unifica.

O ciclo de vida de um ticket

Todo ticket percorre um caminho parecido, independentemente da ferramenta. O modelo básico tem três macro-etapas — aberto → em andamento → resolvido — que na prática se desdobram em estados mais finos:

1. Aberto (novo)

O ticket acabou de entrar e ninguém assumiu. É o estado mais perigoso do ciclo: é aqui que o relógio do SLA de primeira resposta está correndo e é aqui que chamados se perdem em operações desorganizadas. A meta de uma boa triagem é tirar tickets do estado "novo" rápido — nem que seja só para atribuir dono e prioridade.

2. Em andamento

Um atendente assumiu e está trabalhando no caso. Dois sub-estados merecem existir separados, porque medem coisas diferentes:

Pendente (aguardando cliente): a bola está com o cliente — você pediu um print, um número de pedido, uma confirmação. A maioria das operações pausa o relógio de SLA aqui.
Em espera (aguardando terceiro): a bola está com alguém interno ou externo — time técnico, financeiro, fornecedor, transportadora. O cliente não tem culpa dessa espera, então muitos times não pausam o SLA neste estado, de propósito, para manter a pressão de resolver.

Misturar os dois num status genérico "pendente" esconde o problema real: você para de enxergar se a demora é do cliente ou da sua operação.

3. Resolvido

O atendente entregou a solução e comunicou o cliente. Boa prática: resolvido não é fechado. O ticket fica num período de carência (48 horas a 7 dias são janelas comuns na prática do mercado) em que o cliente pode responder e reabrir sem burocracia. É também o momento de disparar a pesquisa de CSAT — a satisfação se mede quando a experiência ainda está fresca.

4. Fechado

Passou a carência sem retorno, o ticket fecha em definitivo. Se o cliente voltar depois disso, abre-se um novo ticket vinculado ao anterior — o que, inclusive, mantém honestas as suas métricas de reabertura e FCR.

Prioridades: menos níveis, critérios mais claros

Quase todo sistema oferece quatro níveis — baixa, normal, alta e urgente — e quase toda operação erra do mesmo jeito: deixa a prioridade virar opinião. Se cada atendente decide "no feeling", em duas semanas metade da fila está marcada como urgente e a classificação não significa nada.

A correção é definir critérios objetivos por nível. Um exemplo copiável para começar:

Prioridade	Critério	Exemplo
Urgente	Cliente sem conseguir usar o produto/serviço, ou impacto financeiro imediato	Cobrança duplicada, sistema fora do ar, pedido extraviado com evento amanhã
Alta	Funcionalidade importante degradada, ou prazo do cliente em risco	Nota fiscal não emitida, entrega atrasada sem previsão
Normal	Dúvida ou solicitação sem bloqueio	"Como altero meu plano?", troca de tamanho dentro do prazo
Baixa	Sugestão, feedback, pedido sem prazo	"Seria legal ter relatório em PDF"

Prioridade deve conversar com SLA: urgente com primeira resposta em 1 hora e normal em 8 horas úteis, por exemplo. Prioridade sem prazo associado é etiqueta decorativa.

Triagem e categorização: onde a fila vira operação

Triagem é o ritual de olhar tudo que entrou, classificar e distribuir. Boas práticas que separam filas saudáveis de caos:

Triagem contínua, não em lote. Esperar "a hora de olhar a fila" cria picos de espera. O ideal é regra automática de roteamento na entrada (por canal, assunto, cliente) e um humano cobrindo o que a regra não pegou.
Categorize na entrada, não no fechamento. Categoria preenchida na pressa de fechar o ticket tende a virar "outros" — e aí o relatório de motivos de contato não serve para nada.
Taxonomia curta e de dois níveis. Algo como Financeiro > Cobrança indevida, Pedido > Atraso na entrega, Produto > Dúvida de uso. Mais de ~25 categorias no total, ninguém usa direito; menos de 8, o relatório não diz nada.
Um dono por ticket, sempre. Transferiu? O novo atendente vira o dono. Precisa de ajuda sem transferir? Adicione participante, não duplique o chamado.
Mescle duplicados na hora. Cliente que manda e-mail e WhatsApp sobre o mesmo assunto gera dois tickets — mesclar cedo evita duas pessoas respondendo coisas diferentes.

Em ferramentas como o ClickDesk, boa parte disso deixa de ser disciplina manual: regras de roteamento distribuem tickets na entrada, funis kanban com SLA mostram visualmente o que está estourando prazo, macros padronizam respostas recorrentes e campos personalizados obrigam a categorização antes de resolver — no e-mail, no chat e no WhatsApp oficial, tudo na mesma fila.

Campos que valem registrar em cada ticket

Todo campo é um atrito para o atendente — então registre o que gera decisão, não o que enfeita relatório. O conjunto mínimo que se paga:

Assunto claro — "Cobrança duplicada no pedido #3391", não "problema".
Categoria/motivo de contato — é daqui que sai o relatório que orienta melhorias de produto e da base de conhecimento.
Prioridade — pelos critérios objetivos definidos acima.
Canal de origem — e-mail, chat, WhatsApp, telefone; essencial para dimensionar o time por canal.
Cliente vinculado (PF ou PJ) — sem isso, não existe histórico unificado nem visão de quantos chamados aquele cliente já abriu.
Identificador do negócio — número do pedido, contrato ou fatura, conforme o seu contexto. É o campo que mais economiza ida-e-volta.
Motivo de resolução — resolvido, sem resposta do cliente, duplicado, improcedente. Fechamentos diferentes contam histórias diferentes nas métricas.

Campos específicos do seu negócio (transportadora, versão do produto, unidade/filial) entram como campos personalizados — e os melhores sistemas permitem torná-los obrigatórios por formulário, para que a informação venha estruturada já na abertura.

Sinais de que sua operação precisa de um sistema de tickets

Alguém já respondeu "esse e-mail ninguém viu?" numa reunião.
Dois atendentes responderam o mesmo cliente com informações diferentes.
Você não sabe dizer quantos chamados entraram no mês passado, nem sobre o quê.
Cliente recontando o problema do zero a cada contato.
Prazo de resposta depende de quem está de plantão.

Se marcou dois ou mais, a caixa de entrada compartilhada já custou mais do que uma ferramenta custaria. Veja como funciona uma operação de tickets completa — e-mail ilimitado, funis com SLA, roteamento e CSAT nativo — em /produto/atendimento, e teste na prática com 14 dias grátis, sem cartão.