Como Criar um Sistema de Helpdesk com Tickets: Pedidos, Estados, Atribuição e Email

Um sistema de helpdesk com tickets transforma pedidos dispersos — emails, mensagens, «perguntas rápidas» no corredor — em tickets: um registo por problema, com um responsável, um estado, uma prioridade e a conversa completa. Para o construir precisa de uma forma de criar tickets, de uma fila partilhada com filtros, de atribuição, de uma conversa que separe respostas públicas de notas internas e de notificações para que ninguém fique à espera sem saber. Um construtor de aplicações com IA consegue montar uma primeira versão sólida para um balcão interno de TI, RH ou instalações numa tarde. O apoio ao cliente final, com encadeamento de emails, prazos de resposta e relatórios, exige mais cuidado — e é aí que os produtos de helpdesk já estabelecidos justificam a sua mensalidade.

O que o sistema precisa

Dados

Guarde os registos de data da primeira resposta e da resolução desde o início. São a base de todos os relatórios, e não os consegue reconstruir mais tarde.

Páginas

• Solicitante: um formulário de «submeter um pedido» com categoria e anexos, uma lista de «os meus pedidos», e a conversa de cada ticket.
• Agente: a fila (os meus tickets, sem responsável, todos os abertos), filtros e pesquisa, a vista do ticket com controlos para responder, adicionar nota, estado, prioridade e responsável.
• Administrador: categorias, equipas, agentes, respostas predefinidas e um relatório simples.

Permissões

Os solicitantes veem apenas os seus próprios tickets e apenas as respostas públicas. Os agentes veem os tickets da sua equipa e as notas internas. Os responsáveis e os administradores veem tudo e gerem as definições. Uma nota interna que chega a um cliente é o desastre clássico dos helpdesks, por isso aplique isto no servidor, e não apenas escondendo um separador. Veja controlo de acesso por funções.

Decisões e compromissos

Formulário, email ou ambos

Um formulário web é o mais simples e dá dados limpos: categoria, prioridade e campos obrigatórios. A entrada por email — as pessoas escrevem para suporte@ e um ticket aparece — é o que os clientes esperam, mas exige um fornecedor de email que consiga receber mensagens e enviá-las para a sua aplicação, além de um encadeamento que associe as respostas ao ticket certo (normalmente um número de ticket no assunto ou um endereço de resposta único). Comece pelo formulário; acrescente o email quando o fluxo de trabalho estiver provado. Enviar email a partir da sua aplicação cobre a parte de saída.

Atribuição

Opções: os agentes escolhem da fila sem responsável; distribuição por rotação dentro de uma equipa; ou atribuição por categoria. Escolher da fila funciona para equipas pequenas. A atribuição automática ajuda quando os tickets ficam sem dono.

Prioridades e prazos de resposta

Defina duas ou três prioridades com um prazo para a primeira resposta («urgente: 1 hora, normal: 1 dia útil»). Mostrar o tempo que falta em cada ticket é mais útil do que um relatório mensal que ninguém lê. Os horários de trabalho complicam as contas — decida cedo se os prazos contam noites e fins de semana.

Fusões e duplicados

O mesmo problema reportado três vezes é comum. Uma ação de «fundir com o ticket n.º» poupa aos agentes responder à mesma coisa repetidamente; vale a pena construí-la cedo.

Um primeiro prompt que funciona

Crie um helpdesk interno de TI para uma empresa de 60 pessoas. Os colaboradores submetem pedidos com um formulário: assunto, categoria (hardware, software, acessos, rede, outro), prioridade (baixa, normal, urgente), descrição e anexos. Cada ticket recebe um número e os estados novo, aberto, a aguardar solicitante, resolvido, fechado. Os agentes de TI veem uma fila com separadores para sem responsável, meus e todos os abertos, filtros por categoria, prioridade e estado, e pesquisa. A página do ticket mostra a conversa com respostas públicas e notas internas claramente separadas; os colaboradores nunca veem notas internas. Os agentes podem atribuir, alterar estado e prioridade, usar respostas predefinidas e fundir duplicados. Registe os tempos da primeira resposta e da resolução e mostre o tempo desde a última atualização em cada ticket. Os colaboradores têm uma página «os meus pedidos». Funções: colaborador, agente, administrador. Guarde tudo numa base de dados. Interface simples, densa e rápida — a rapidez antes da decoração.

Passos de construção

1. Modelo de ticket e formulário. Submeter, listar, abrir um ticket, responder.
2. Fila e filtros. Sem responsável, meus, todos os abertos; filtrar e pesquisar; ordenar por prioridade e antiguidade.
3. Funções e login. Solicitante, agente, administrador — com as notas escondidas dos solicitantes no servidor.
4. Controlos de atribuição, estado e prioridade, com um registo de atividade de cada alteração.
5. Notificações. Enviar email ao solicitante nas respostas públicas e ao agente nas novas atribuições, através do seu próprio fornecedor de email.
6. Respostas predefinidas e fusão.
7. Prazos de resposta e um relatório básico: tickets abertos por antiguidade, tempo da primeira resposta, tickets por categoria.
8. Entrada por email, depois de tudo o resto funcionar, com o encadeamento testado a fundo.
9. Piloto com uma equipa durante duas semanas antes de passar toda a gente para o novo sistema.

Erros comuns

• Notas internas visíveis para os solicitantes porque apenas estavam escondidas na interface.
• Estados e categorias a mais. Os agentes escolhem o primeiro que parece próximo. Comece com cinco de cada, no máximo.
• Sem registos de data para a primeira resposta e a resolução. Vai querer os números no dia em que alguém perguntar «estamos a ficar mais rápidos?».
• Respostas por email que criam novos tickets em vez de se associarem ao existente. Teste respondendo a partir de uma aplicação de email no telemóvel, que muitas vezes muda o assunto.
• Toda a gente atribuída, ninguém responsável. Um responsável por ticket; use observadores para os restantes.
• Anexos com URLs públicos. As capturas de ecrã de mensagens de erro costumam conter dados privados. Mantenha os ficheiros privados e sirva-os apenas a quem pode ver o ticket.

Quando um produto pronto é a melhor escolha

Para o apoio ao cliente através de email, chat e redes sociais — com acompanhamento de prazos de resposta, inquéritos de satisfação, macros, relatórios e integrações — um produto de helpdesk dedicado é quase sempre o melhor investimento. Estes produtos passaram anos a tratar do encadeamento de emails, do spam, do encaminhamento e dos relatórios, e essa não é a parte do seu negócio que o diferencia. O nosso guia de alternativas ao Zendesk compara as opções.

Uma construção própria serve bem os balcões internos (TI, RH, instalações, pedidos financeiros), fluxos de trabalho de nicho em que um ticket é na verdade um trabalho com passos específicos, e equipas que querem pedidos ligados a outros dados que já guardam. Também evita preços por agente quando muitas pessoas tratam ocasionalmente de tickets. O guia de ferramentas internas cobre essa categoria de forma mais ampla.

Construir com a Mythex

Na Mythex descreve o helpdesk no chat, revê-o numa pré-visualização em tempo real e publica-o para a sua equipa. Os tickets ficam numa base de dados Postgres que o agente adiciona quando os dados precisam de ser guardados, e os anexos vão para o armazenamento de ficheiros do projeto. Os logins dos solicitantes e dos agentes, bem como todo o email de entrada e saída, usam os seus próprios fornecedores — a Mythex não tem produto próprio de login ou de email para utilizadores finais; o receituário de envio de email mostra a abordagem. Os colegas podem ajudar a construir através de um espaço de trabalho partilhado, sem taxas por lugar na própria Mythex.

Para um prompt inicial, experimente os modelos fila de pedidos internos ou gestor de erros, e combine o helpdesk com uma base de conhecimento para que as perguntas frequentes se respondam sozinhas.

Perguntas