Uma excelente assistência começa com uma excelente documentação dos tickets. Com a Trupeer, pode poupar horas na documentação de suporte ao começar com um ticket de cliente gratuito e um modelo de resolução, personalizando-o com as suas orientações de marca e transformando tickets resolvidos em estudos de caso em vídeo para a base de conhecimento de suporte.

A maioria das equipas de suporte tem um sistema de tickets cheio de tickets e não faz ideia do que está realmente a correr mal. Tudo é categorizado como Outros, as notas de resolução dizem "resolvido" e o relatório mensal mostra volume e nada mais.

Este é um problema de design do campo, não de reporting. Este modelo cobre as duas metades de um ticket: o registo que captura, que determina o que pode aprender, e as respostas que envia, que determinam a experiência do cliente.

Transferir o modelo de ticket e resolução

Gratuito, editável, sem marca de água. Se já tiver uma ferramenta de helpdesk, use a lista de campos e a redação das respostas e ignore o registo.

Como personalizar este modelo na Trupeer

Passo 1: Abrir a secção de Modelos

Vá à secção de Modelos no menu principal.

Passo 2: Selecionar e abrir um modelo

Clique em qualquer modelo com que queira trabalhar para o abrir.

Passo 3: Expandir a visualização do modelo

Se necessário, expanda a visualização do modelo para ver o layout completo e os detalhes com clareza.

Passo 4: Editar o modelo

Clique em Editar para começar a modificar o modelo selecionado.

No editor, pode:

• Adicionar novas secções

• Definir ou atualizar regras de formatação

• Adicionar um logótipo e ajustar a sua posição e definições relacionadas

Passo 5: Guardar o seu modelo personalizado

Depois de fazer todas as alterações necessárias, clique em Guardar para guardar o modelo atualizado como seu.

Passo 6: Pré-visualizar e afinar o modelo

Quando quiser ver como fica o seu modelo personalizado, abra a Pré-visualização.

A partir do ecrã de pré-visualização, pode continuar a fazer ajustes diretamente, se necessário, garantindo que o modelo aparece exatamente como o quer.

Com um ticket de cliente e um modelo de resolução, pode:

• Poupar horas a escrever: Ignore a página em branco com uma estrutura criada para documentação de tickets.

• Uniformizar a qualidade do suporte: Os campos integrados garantem que cada ticket captura informação essencial.

• Manter-se fiel à marca: Aplique o seu logótipo, fontes e cores usando o kit de marca da Trupeer.

• Construir uma KB mais forte: Os tickets resolvidos tornam-se futuros artigos de ajuda e runbooks.

• Identificar tendências: Tickets uniformizados facilitam a identificação de problemas recorrentes.

• Atingir equipas globais: Traduza modelos de tickets para 65+ idiomas com um único clique.

As duas metades de um modelo de ticket

O registo. O que é capturado: quem, o quê, quando, o nível de urgência, qual a categoria, o que foi resolvido. Esta metade é invisível para o cliente e determina tudo o que pode aprender mais tarde.

As respostas. O que o cliente recebe em cada fase: confirmação, atualizações, aviso de escalonamento, resolução e acompanhamento. Esta metade é a que eles usam para o avaliar.

As equipas tendem a investir na segunda metade e a negligenciar a primeira, razão pela qual o reporting de suporte tantas vezes produz gráficos de volume e nenhuma perceção. Ambas estão neste modelo.

Os campos do formulário do ticket

Cada campo deve merecer o seu lugar. Cada um que adiciona abranda a entrada de tickets, e os campos que ninguém usa acabam preenchidos com lixo.

Capturado na entrada

Capturado no fecho

Estes dois últimos campos de entrada e de base de conhecimento são os mais frequentemente em falta, e ambos são os que fazem a diferença entre uma fila e um sistema que melhora.

Categorização que funciona mesmo

Categoria é o campo que decide se os dados do seu ticket valem alguma coisa, e quase sempre está mal.

• Duas camadas, não quatro. Categoria e subcategoria. Hierarquias mais profundas geram etiquetagem inconsistente, porque os agentes param de ler para além do segundo menu pendente.

• Entre oito e quinze categorias de topo. Menos e tudo é Outros. Mais e ninguém consegue encontrar a opção certa.

• Nomeie as categorias pelo que o cliente experienciou, não pela estrutura interna da sua equipa. "Não consigo iniciar sessão" em vez de "Plataforma de identidade".

• Sem Outros. Ou, se for mesmo necessário, reveja-a mensalmente e transforme os itens recorrentes em categorias reais. Um grupo Outros acima de cinco por cento significa que a sua taxonomia está errada.

• Categorize no primeiro contacto, e deixe o agente alterá-la no fecho se se verificar que é outra coisa. A categorização retrospetiva é sempre feita às pressas e quase sempre está errada.

• Revise a taxonomia trimestralmente. As categorias ficam desatualizadas à medida que o produto muda.

Um conjunto inicial viável para a maioria das equipas de suporte: acesso e início de sessão, faturação e pagamentos, configuração e configuração, como faço eu, não está a funcionar como esperado, problema de dados, integração, desempenho, pedido de funcionalidade, bug, alteração de conta, cancelamento.

Códigos de resolução

O equivalente do lado do fecho e, ainda assim, ainda mais frequentemente negligenciado. As notas de resolução escritas como texto livre não podem ser contadas.

Dois destes são ouro para diagnóstico. Uma taxa elevada de documentação fornecida significa que o seu conteúdo de ajuda existe e não é encontrado. Uma taxa elevada de solução alternativa fornecida significa que está a acumular problemas não resolvidos que vão voltar.

Prioridade e como defini-la

A prioridade deve ser derivada, não escolhida. Se os agentes puderem selecioná-la livremente, vão marcar tudo como alta, porque cada cliente é urgente para si.

Impacto é quantas pessoas são afetadas e o quão mal. Um utilizador com incómodo é baixo. Uma equipa inteira bloqueada é alto.

Urgência é a rapidez com que precisa de ser resolvido. Um problema cosmético é baixo, independentemente de quantas pessoas o veem. Um prazo bloqueado é alto.

Publique a matriz e os objetivos de resposta para cada nível, para que a prioridade seja um cálculo e não uma negociação.

O ciclo de vida do ticket

O estado de espera pelo cliente precisa de uma janela de fecho automático definida, normalmente de cinco a dez dias úteis, com um lembrete antes. Sem isso, os tickets ficam abertos para sempre e as métricas de tempo de resolução tornam-se sem sentido.

Modelos de resposta por fase

A redação que os clientes realmente veem. Mantenha cada uma curta e substitua os placeholders por valores reais, em vez de os deixar genéricos.

Confirmação

Obrigado por entrar em contacto. A sua referência é [ID] e estou a analisar isto agora. Voltarei a falar consigo até [time] com uma atualização, mesmo que eu não tenha uma resposta completa até lá.

A última parte é importante. Prometer uma atualização em vez de uma resolução é uma promessa que consegue cumprir.

Atualização de estado

Uma breve atualização sobre [ID]. Já [what you have done] e agora estou [what is next]. Espero ter isto resolvido até [time]. Não é necessário nada da sua parte nesta fase.

Envie isto antes de o cliente procurar. Uma atualização sem ser solicitada vale mais do que uma resposta rápida a um pedido.

Pedido de informação

Para avançar, preciso de [specific thing]. Assim que a tiver, devo conseguir [outcome]. Se eu não receber resposta até [date], vou fechar o ticket e pode responder a qualquer momento para o reabrir.

Peça uma coisa. Três pedidos numa única mensagem produzem, de forma fiável, uma resposta.

Aviso de escalonamento

Escalenei isto para [name or team] porque [reason]. Eles vão contactar até [time]. A sua referência mantém-se em [ID] e vou ficar em cópia.

Diga porquê. O escalonamento sem motivo parece que está a ser passado de mão em mão.

Resolução

Isto já está resolvido. A causa foi [cause] e eu já [what you did]. Agora deve ver [expected outcome]. Se acontecer novamente, responda a esta mensagem e ela voltará diretamente para mim.

Nomeie a causa. "Já está resolvido" deixa os clientes sem confiança de que vai continuar resolvido.

Acompanhamento da resolução

A verificar [ID] a partir de [date]. Está tudo a funcionar como esperado? Se não, basta responder aqui.

Dois a três dias mais tarde, e apenas para o que for significativo ou recorrente.

Interrupção ou problema generalizado

Estamos cientes de [issue] a afetar [scope] e estamos a trabalhar nisso agora. Vou atualizar até [time], independentemente do progresso. Não precisa de fazer nada.

De forma proativa, para todos os afetados, antes de entrarem em contacto consigo.

Pedido de desculpa após falha de serviço

Você tinha razão ao abrir este caso e peço desculpa. [O que correu mal] e isso é da nossa responsabilidade. Já [action taken] e [what prevents recurrence]. Se houver mais alguma coisa em aberto, diga-me e eu trato disso.

Específico, sem defensiva, e indica o que impede que volte a acontecer.

O relatório de resolução

Para qualquer coisa significativa, o registo de fecho precisa de mais do que uma nota. O modelo inclui um relatório de resolução que cobre:

Referência e datas do ticket. O que o cliente reportou, pelas suas palavras. O que estava realmente a acontecer, que muitas vezes é diferente. Causa raiz. O que foi feito para corrigir. Se foi usada uma solução alternativa e se o problema subjacente se mantém. Tempo até à primeira resposta e até à resolução. Se voltou a ocorrer. O que foi alterado para evitar que volte a acontecer, ou uma nota de que nada foi. Artigo da base de conhecimento criado ou atualizado.

Este último par é o que transforma um ticket resolvido numa melhoria. A maioria das notas de fecho fica pelo que foi feito, o que só ajuda a próxima pessoa se ela encontrar o ticket.

O que os dados do ticket permitem fazer

Assumindo que os campos são preenchidos corretamente:

• Encontrar as cinco categorias principais por volume e corrigir a maior. Normalmente, a maior é um problema de documentação ou de produto, e não de suporte.

• Comparar volume com código de resolução. Alto volume com um código fornecido por documentação é encontrabilidade de conteúdo, não capacidade de suporte.

• Monitorizar a taxa de solução alternativa, que é o seu backlog oculto.

• Ver a taxa de reabertura por agente e por categoria. Reaberturas altas significam que os tickets estão a ser fechados em vez de resolvidos.

• Observar a mistura de canais ao longo do tempo. Crescimento no telefone muitas vezes significa que o autoatendimento falhou nalgum ponto.

• Fazer referência cruzada por conta. Um cliente a abrir tickets repetidamente na mesma categoria é um problema de formação ou de configuração, não azar.

• Acompanhar a primeira resposta versus resolução separadamente. Têm causas diferentes e correções diferentes.

Nada disto é possível sem uma categorização disciplinada na entrada, razão pela qual este campo recebe mais atenção neste modelo.

Help desk, service desk e modelos de tickets

A lista de campos e a redação das respostas nesta página funcionam para os três. Os service desks que seguem ITIL vão precisar de adicionar referências de alterações e de problemas, e a distinção entre incidente e pedido importa lá de uma forma que não importa para o suporte ao cliente.

Como configurar isto

1. Defina as categorias primeiro, com as pessoas que as vão usar. Oito a quinze, duas camadas, nomeadas pelo que o cliente experienciou.

2. Decida os campos necessários na entrada, e mantenha a lista curta. Cada campo abranda a primeira resposta.

3. Construa a matriz de prioridade e publique-a com objetivos de resposta.

4. Defina os códigos de resolução antes do go-live, não depois de seis meses de texto livre.

5. Defina a janela de fecho automático para a espera pelo cliente.

6. Carregue os modelos de resposta como respostas pré-definidas e edite a redação para soar como a sua equipa.

7. Forme especificamente em categorização. É o campo que mais frequentemente é feito mal e o que mais importa.

8. Revise o grupo Outros mensalmente no primeiro trimestre.

9. Reporte por categorias e códigos de resolução, não apenas por volume.

10. Volte a rever a taxonomia trimestralmente.

Boas práticas

• Categorize no primeiro contacto e corrija no fecho.

• Mantenha os campos necessários na entrada no mínimo que torna o ticket viável.

• Derive a prioridade do impacto e da urgência em vez de deixar os agentes escolherem.

• Use códigos de resolução, não texto livre, para tudo o que quer contar.

• Prometa uma atualização em vez de uma resolução.

• Envie atualizações antes de o cliente procurar.

• Nomeie a causa na mensagem de resolução.

• Defina uma janela de fecho automático na espera pelo cliente.

• Registe se um artigo da base de conhecimento foi criado.

• Reporte por categoria e código de resolução.

Erros comuns

• Uma categoria Outros que absorve um terço dos tickets.

• Hierarquias de categorias com quatro níveis que os agentes deixam de ler.

• Categorias nomeadas pela estrutura interna em vez dos sintomas do cliente.

• Prioridade escolhida livremente, por isso tudo fica alto.

• Notas de resolução em texto livre sem nada que possa ser contado.

• Sem acompanhamento de soluções alternativas, por isso os problemas não resolvidos desaparecem.

• À espera do cliente sem fecho automático, inflacionando indefinidamente as contagens de tickets abertos.

• Mensagens de resolução que dizem resolvido sem dizer o que estava errado.

• Sem acompanhamento de problemas significativos.

• Reporting apenas por volume, que mostra o quão ocupado está e nada sobre o porquê.

• Categorização retrospetiva no fim do mês.

Transforme tickets resolvidos em coisas que os clientes conseguem resolver sozinhos

Abra o modelo na Trupeer AI, aplique o seu kit de marca para que tudo o que é dirigido ao cliente corresponda e edite qualquer secção diretamente. A configuração está no guia do modelo.

Volte a ver a tabela de código de resolução. Quando é fornecida documentação, significa que a resposta existia e não foi encontrada. Quando é resolvido pelo suporte, repetidamente, na mesma categoria, significa que a resposta ainda não existe. Ambos são problemas de conteúdo que aparecem como volume de suporte, e ambos são resolvidos da mesma forma.

Quando um agente resolve algo pela quarta vez, registe-o uma vez. A Trupeer AI gera o artigo escrito e um passo a passo em vídeo narrado a partir da mesma passagem, para que o próximo cliente possa ver a correção em vez de abrir um ticket. Traduza-o para 65+ idiomas e mantenha o conjunto na sua base de conhecimento para que seja encontrável no momento em que alguém ficar bloqueado. Use as mesmas gravações para formação de agentes.

Registe. Dê marca. Traduza. Trupeer.

Perguntas Frequentes

Existe um modelo gratuito de sistema de tickets?

Sim. A versão em Excel funciona como um registo completo de tickets para equipas pequenas sem uma ferramenta de helpdesk, com categorias, prioridade, códigos de resolução e separadores de reporting. Se já tiver um sistema de helpdesk, pegue na lista de campos e nos modelos de resposta e ignore o registo.

Existe um modelo de ticket de help desk em Word?

Sim. O ficheiro Word contém o formulário de entrada do ticket, o relatório de resolução e todos os modelos de resposta, para que possa imprimir o formulário ou copiar a redação nas suas respostas pré-definidas do helpdesk.

Existe um modelo de ticket de serviço em Excel?

Sim, e o Excel é a versão que a maioria das equipas considera útil. Uma linha por ticket com campos de entrada e fecho, menus pendentes para categoria, prioridade e código de resolução, além de separadores que resumem o volume por categoria e tipo de resolução.

Existe um modelo de ticket de serviço em Word?

Sim. A versão em Word inclui um ticket de serviço imprimível adequado para assistência no terreno ou suporte presencial, com linhas de assinatura para trabalho concluído e aceitação do cliente.

Existe um modelo de formulário de ticket de serviço de TI?

Sim. A versão de TI do formulário de entrada adiciona referência de ativo ou dispositivo, sistema afetado e um campo de referência de alteração para service desks que executam um processo formal de alterações.

Existe um modelo HTML ou Bootstrap gratuito para sistema de tickets de suporte?

Não, e vale a pena ser direto sobre isso. Estas consultas são para código front-end para construir uma interface de tickets, o que é um ativo de desenvolvimento web e não um documento. Procure um tema de dashboard de administração Bootstrap ou use uma plataforma de helpdesk existente, uma vez que construir um sistema de tickets a partir de um modelo é normalmente mais caro do que parece quando se considera a autenticação, o encaminhamento de email e a lógica do SLA. O que esta página lhe dá é o design dos campos e a redação das respostas, que precisaria independentemente de a interface ser construída em qualquer lugar.

O que é um modelo de resolução de ticket?

Duas coisas, dependendo do contexto. A mensagem de resolução enviada ao cliente a explicar o que estava errado e o que foi feito, e o registo de resolução capturado internamente com o código de resolução, a causa raiz e o tempo até à resolução. Ambas estão incluídas aqui, e a segunda é a que torna os dados do seu ticket utilizáveis.

Que campos deve ter um ticket de suporte?

Na entrada: ID do ticket, data, canal, requerente, conta, produto ou serviço, categoria, descrição nas palavras do cliente, prioridade, responsável e estado. No fecho: código de resolução, notas de resolução, causa raiz quando conhecida, tempos de resposta e de resolução, se foi reaberto e se foi criado um artigo da base de conhecimento.

Como devem ser categorizados os tickets de suporte?

Duas camadas, oito a quinze categorias de topo, nomeadas pelo que o cliente experienciou em vez da estrutura interna da sua equipa. Categorize no primeiro contacto e permita correção no fecho. Evite um grupo Outros, ou reveja-o mensalmente e promova os itens recorrentes para categorias reais.

O que são códigos de resolução e porque é que importam?

Um conjunto fixo de valores que descreve como um ticket foi resolvido: resolvido pelo suporte, resolvido pela engenharia, documentação fornecida, solução alternativa fornecida, erro do utilizador, duplicado, não foi detetada falha. Importam porque as notas de resolução em texto livre não podem ser contadas, e dois desses códigos em particular indicam onde estão os seus problemas reais.

Como definir a prioridade do ticket?

Derive-a do impacto e da urgência usando uma matriz publicada em vez de deixar os agentes escolherem livremente. Impacto é quantas pessoas são afetadas e o quão mal. Urgência é a rapidez com que tem de ser resolvido. Publique a matriz com objetivos de resposta para que a prioridade seja um cálculo e não uma negociação.

O que deve dizer uma mensagem de resolução de ticket?

O que foi a causa, o que fez, o que o cliente deve ver agora e como voltar a contactar se voltar a acontecer. Nomear a causa é a parte mais frequentemente esquecida e é o que dá ao cliente confiança de que a correção vai manter-se.

Quanto tempo deve esperar antes de fechar um ticket?

Cinco a dez dias úteis na espera pelo cliente, com um lembrete antes de fechar e uma declaração clara de que responder vai reabri-lo. Sem uma janela de fecho automático, as contagens de tickets abertos inflacionam indefinidamente e as métricas de tempo de resolução deixam de fazer sentido.

Posso personalizar este ticket e modelo de resolução?

Sim, todas as versões são totalmente editáveis. As categorias e os códigos de resolução são as partes que têm de ser suas e são entregues como um conjunto inicial para editar em vez de adotar na íntegra. Na Trupeer AI, também pode aplicar o seu kit de marca para que as mensagens e artigos dirigidos ao cliente correspondam.

Modelos relacionados

• Customer service SOP

• Product support SOP template

• IT SOP template

• Customer satisfaction template

• Customer service training manual template

• Corrective action plan template

• Knowledge base template

• Job aid template