Modelos de resposta e de ticket

Os modelos estão em «Settings → Templates». A linha por baixo do título diz o que fazem e o que não fazem: «Reply templates fill the comment editor and suggest field actions. Nothing is sent automatically.» Um modelo é um gesto preparado, não uma máquina — és sempre tu a enviar.

Há dois tipos e escolhes um ao criar: «Add reply template» para a resposta num ticket aberto, «Add ticket template» para o formulário de novo ticket. O tipo não pode ser alterado depois, porque decide que campos o formulário mostra. O selo por cima de cada modelo diz-te qual estás a ver: «Reply template» a azul, «Ticket template» a verde.

Um modelo de resposta é feito do texto da resposta («Reply text»), da caixa «Internal note» e de um número qualquer de ações. Há seis ações: «Set the status», «Set the priority», «Assign to a user», «Remove the assignee», «Hand over to another team» e «Set a follow-up».

A lista «Assign to a user» começa com a entrada «The agent who applies it». Escolhe essa quando várias pessoas partilham o modelo: o ticket passa então a pertencer a quem o aplicou, e não a uma pessoa fixa da lista. «Set a follow-up» pede uma quantidade e uma unidade (minutos, horas, dias, minutos úteis, horas úteis, dias úteis) e ainda a nota que mais tarde te dirá porque é que o ticket está de volta.

A caixa azul no fim de cada modelo escreve numa frase o que ele vai fazer — por exemplo «Inserts the text as a public comment, sets status to Waiting for Service Provider Response, assigns to the applying agent, sets a follow-up in 3 days.» A frase reconstrói-se enquanto editas. É a tua contraprova: se disser algo diferente do que pretendias, há uma definição errada.

O texto não é obrigatório. «Passar isto para a equipa de rede sem escrever uma palavra» é um modelo válido — a frase diz então «Suggests actions without a reply text». A ação «Set the status» segue as mesmas regras que uma mudança de estado feita à mão. Aplicado a vários tickets de uma vez, o modelo ignora os tickets bloqueados e indica o motivo.

A janela «Close ticket» também oferece modelos de resposta, no campo «Template». Só lista modelos cuja ação ativa «Set the status» define um estado que conta como resolvido ou fechado. Os modelos internos não são oferecidos aí. Se escolheres um, a janela assume o texto dele como comentário. Se o modelo enviar uma mensagem e a janela oferecer o envio de mensagem, só assume o destinatário se este for «Requester» ou um endereço fixo. As outras ações do modelo não são executadas aí, e os anexos dele não são acrescentados. O ticket é fechado como habitualmente.

Num ticket aberto, o botão «Template» está por cima do editor de comentários. Um clique abre a pesquisa com sugestões («Search templates…») e escolher um preenche o editor de comentários. Mais nada acontece, e a linha por baixo di-lo: «Nothing happens until you add the comment.»

Cada ação do modelo transforma-se num selo ao lado do botão — em linguagem corrente, não em jargão: «sets status to Waiting for Service Provider Response», «assigns to the applying agent», «sets a follow-up in 3 days». Clicar num selo risca-o: fica desmarcado e não vai correr. Outro clique volta a trazê-lo.

As ações desmarcadas ficam riscadas, não removidas. Assim continua visível o que o modelo teria sugerido — e a decisão continua reversível enquanto não tiveres enviado.

Que selos começam ativos é decidido pelo modelo: nas definições, cada ação tem um interruptor «Suggested». Esse interruptor é a proposta para todos os casos; o selo no ticket é a decisão para este.

O «×» a seguir aos selos volta a remover o modelo. O texto fica no editor — é bem possível que já o tenhas reescrito; só o efeito desaparece, ou seja, as ações, a mensagem e os anexos.

Envias com o botão habitual de comentar. Só então o comentário é criado, e só depois disso correm as ações que continuam ativas.

O texto da resposta pode usar cinco variáveis; a lista está por baixo do campo: «{requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}». Escreve-as com chavetas, exatamente como aí aparecem.

«{ticketRef}» é a referência do ticket na forma «[TICKET-8-…]». É por ela que o sistema reconhece a resposta de um cliente quando ela volta por e-mail. Já «{ticketId}» é apenas o número simples.

São resolvidas quando o modelo é APLICADO, não quando é guardado: a página de definições continua a mostrar «{requesterName}», o editor de comentários no ticket mostra o nome real. A razão é prática — resolver ao guardar gravaria para sempre no modelo os valores de UM ticket.

Assim lês o texto final antes de alguma coisa sair da empresa. Se a saudação não servir, alteras no editor como em qualquer outro texto.

Quem conta como «quem pediu» é decidido pelo ticket, não pela conta: quem está registado no ticket vem antes da conta que o submeteu. Se um agente submeter um ticket por um colega depois de um telefonema, a resposta cumprimenta na mesma o colega e não o agente.

Uma variável mal escrita é recusada ao guardar, e é nomeada: «Reply text: unknown placeholders {requesterNam}. Available here: {requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}.» Assim dás por ela enquanto escreves o modelo, não num cliente.

O assunto do e-mail tem a SUA lista, mais curta («{originalSubject}, {ticketTag}, {ticketId}») — e é por isso que ela está lá impressa uma segunda vez. «{ticketRef}» também funciona aí e significa o mesmo que «{ticketTag}». «{requesterName}», «{ticketTitle}» e «{agentName}» não funcionam no assunto e são recusadas da mesma maneira.

O interruptor «Send the comment as e-mail» transforma o comentário também na mensagem. De propósito, não há um segundo campo de texto para isso: o que está no ticket é o que o cliente lê — dois textos acabariam por divergir.

Em «Recipient» escolhes entre «Requester», «Assignee», «Observers» e «Fixed address». Quem é quem pediu é resolvido pelo servidor quando o modelo é aplicado — um modelo ainda não conhece o ticket. A própria conta da caixa de entrada nunca recebe mensagens; seria escrever para nós próprios. Se o campo «User» tiver um nome sem endereço, não sai nenhuma mensagem para quem pediu. Também não é enviada, em vez disso, a quem registou o ticket.

O assunto pode levar «{originalSubject}», «{ticketTag}» e «{ticketId}». Mantém lá «{ticketTag}»: é por essa referência que o sistema reconhece a resposta do cliente e a acrescenta ao mesmo ticket. Sem ela, cada resposta dá origem a um ticket novo.

A mensagem sai como texto simples. O negrito, as listas e as ligações são retirados antes do envio, caso contrário o cliente leria a marcação em bruto. Dentro do ticket, o comentário mantém a sua formatação.

No ticket, a mensagem é mais um selo ao lado das ações («E-mail to Requester») e tão desmarcável como elas. Assim um modelo nunca envia nada sem que o tenhas visto. O selo só aparece quando a caixa de correio da equipa envia mensagens nas ações do ticket.

Os anexos de um modelo («Attachments») são cópias próprias dos ficheiros. Aplicar o modelo acrescenta-os ao TICKET, com uma linha própria no histórico — não fazem parte da mensagem. Ter anexos num modelo não exige licença Professional; só o envio exige. Um modelo com o visto «Internal note» não acrescenta ficheiros.

A maioria dos modelos não nasce numa prancheta, mas no momento em que escreves a mesma resposta pela segunda vez. Por isso, cada comentário num ticket tem à direita um pequeno ícone de folha, com a etiqueta «Make template». Toma exatamente esse comentário como texto de partida — também o comentário de um colega. Só quem pode gerir modelos vê o ícone.

Se o ticket tiver anexos, uma janela pergunta primeiro quais devem ir juntos: «Tick only the attachments the template should carry — one of them may be a customer's screenshot. Nothing is ticked by default.» Nada vem assinalado, e isso é de propósito.

Depois disso aterras na página de modelos com um rascunho que ainda NÃO está guardado. Em cima está a faixa âmbar «Draft from ticket #… — name it and review the text (it may contain customer details), then save.» O nome está vazio: tens de dar um, caso contrário não guarda.

O que é assumido: o texto, a caixa «Internal note», a equipa do ticket e o estado do ticket como sugestão — o estado e a prioridade dele já lá estão como duas ações. O que não é assumido: quem pediu, o endereço e o título. Esses pertencem a este caso.

Lê o texto antes de guardares. Vem de um caso real e pode conter o nome de uma pessoa, um número de encomenda ou uma sala. Nada é anonimizado por ti — a faixa di-lo, mas fazê-lo é tarefa tua.

Só «Save» cria o modelo; os anexos assinalados são então copiados e confirmados com uma mensagem.

«Applies to» decide a quem o modelo é oferecido: a uma equipa concreta ou a «All teams». Um modelo novo começa com uma equipa concreta — «All teams» é uma escolha que alguém tem de fazer, não uma predefinição silenciosa.

Num ticket são-te oferecidos os modelos da equipa responsável e os globais. Se o ticket passar para outra equipa, a lista acompanha-o — passas a poder escolher entre os modelos da nova equipa.

O interruptor «Draft» transforma o modelo na tua oficina: «Only you can see this template until you publish it.» O rascunho de outra pessoa não aparece em lista nenhuma e também não pode ser alcançado pelo endereço — nem sequer por administradores. Um modelo novo começa como rascunho; só quando desligas isso e guardas é que os outros o veem.

Dois modelos não podem partilhar um nome se se puderem encontrar: um modelo global colide com qualquer modelo do mesmo nome, em qualquer equipa. Já um modelo de resposta e um modelo de ticket podem partilhar um nome — nunca aparecem lado a lado na mesma lista.

«Duplicate» faz uma cópia, e a cópia é sempre um rascunho: «Duplicated. The copy is a draft only you can see.» É o caminho cómodo para uma variante sem que ninguém receba a versão a meio.

Um modelo de ticket preenche o formulário «Create new ticket». Não tem texto de resposta, não tem ações e não tem mensagem — neste momento não existe nenhum ticket sobre o qual agir. O formulário mostra, por isso, campos diferentes dos de um modelo de resposta, e a moldura verde diz-te que estás a ver um modelo de ticket.

Podes pré-preencher «Ticket title», «Owning team of the new ticket», «Main category», «Subcategory», «Priority» e a «Ticket description». Todos os campos podem ficar em «Not prefilled» — o que ficar vazio é preenchido depois por quem usar o formulário.

Repara na diferença entre os dois campos de equipa: «Applies to», em cima, diz QUEM vê o modelo. «Owning team of the new ticket» diz PARA ONDE vai o novo ticket. São duas perguntas diferentes e podem ter respostas diferentes.

As categorias estão agrupadas por equipa, porque uma categoria pertence a uma equipa. Se escolheres uma de outra equipa, o formulário avisa-te e a gravação é recusada: no formulário de novo ticket da equipa de destino, essa categoria nem sequer seria oferecida, por isso o pré-preenchimento daria em nada.

Aqui não há variáveis, e a indicação por baixo do texto di-lo: «No placeholders here: the template only prefills the form, nothing is resolved or sent.» Um «{requesterName}» acabaria literalmente no ticket novo — e é por isso que é recusado ao guardar.

A caixa azul resume também aqui o que o modelo faz: «Prefills the new ticket with title 'New notebook for a colleague' · category Notebook / New request · priority Medium · team Helpdesk · the description.»

No próprio formulário escolhes o modelo com o botão «Template»; ao lado está «Prefills the form - nothing is created until you submit.» Tudo o que vem pré-preenchido continua a poder ser alterado, e nada é criado enquanto não submeteres.

O sistema traz um modelo de exemplo: «Example: create accounts for a new colleague». Mostra a forma da coisa e não faz nada por si — reconstrói-o ou apaga-o.

O interruptor «Offer this template to customers» está desligado de origem. A indicação ao lado diz as duas coisas que precisas de saber: «Customers can pick this template when they create a ticket. A draft stays hidden either way.»

Porque está desligado de origem: muitas vezes um modelo tem um nome em vocabulário interno e foi escrito para colegas. Torná-lo visível aos clientes é uma afirmação para fora — alguém deve fazê-lo de propósito, não por acidente.

O cliente vê o mesmo botão «Template» por cima do formulário de novo ticket, mas apenas os modelos libertados. Um rascunho continua escondido mesmo com o interruptor ligado — as duas regras estão uma atrás da outra, não lado a lado.

O objetivo não é a comodidade, é o primeiro contacto: um pedido que chega completo poupa a ronda de perguntas que, de outro modo, custaria dois dias. Põe essas perguntas na descrição do modelo — o cliente responde-lhes enquanto cria o ticket.

Podes ir mais longe com «Fields to ask for». O modelo decide então que campos personalizados o formulário pede, por que ordem, e quais deles são obrigatórios. Essa seleção SUBSTITUI os campos habituais da equipa, não os acrescenta. É exatamente essa a sua finalidade. Os campos personalizados em si fazem parte do Professional; o cartão deles chama-se «Campos personalizados». Libertar um modelo para os clientes funciona em todas as edições.

Um campo escondido dos clientes continua escondido, mesmo que um modelo o liste. A seleção de campos é uma ferramenta de ordem e de recorte, não uma forma de contornar as definições dos campos.

Cada utilização que faz mais do que inserir texto escreve UMA entrada no histórico, sob o nome de campo «Template». Nomeia o modelo. As ações que correram escrevem linhas próprias. Sem ela não haveria forma de explicar mais tarde porque é que um ticket saltou de repente para «In Progress»: as ações individuais escrevem as suas próprias linhas, mas nenhuma delas nomeia o modelo.

A imagem diz: «Template 'First reply: we have your ticket' applied». O que o modelo fez está nas linhas das suas próprias ações, como a mudança de estado.

As ações desmarcadas não estão lá: não aconteceram. Uma falha está lá e é nomeada como tal, a seguir à palavra «failed». Um modelo só de texto, sem ações, mensagem nem anexos, não deixa nenhuma entrada «Template» num ticket individual. Apenas inseriu texto. Aplicado a vários tickets de uma vez, a entrada é sempre escrita, juntamente com a linha interna «Bulk».

A entrada é INTERNA — quem pediu não a vê. O nome de um modelo é vocabulário interno («recusa padrão»), e o histórico está aberto também a quem criou o ticket. As alterações de campos continuam visíveis para essa pessoa; apenas a sua origem num modelo não fica.

O autor é o agente, não «system» e não o modelo. Isso é intencional: aplicá-lo foi decisão dele. Ao contrário de uma regra de automatização, o que fica no ticket aqui é uma pessoa.