Gestão de tickets

Crias um ticket novo com «New Ticket» na barra da esquerda. O formulário chama-se «Create new ticket». Como agente, registas também com ele os pedidos de outras pessoas — é para isso que serve o campo «User»: diz para quem é o caso, não quem o está a escrever.

Tudo o que tem um asterisco é obrigatório: «Title», «User», «Main category» e «Description». Há mais um que passa facilmente despercebido: o formulário não guarda sem uma subcategoria, mesmo que «Subcategory» não tenha asterisco — uma categoria principal e uma subcategoria andam juntas e são sempre definidas em par.

Que campos são obrigatórios define-se em «Settings → Ticket Settings». O cartão «Admin / Agent Field Settings» só tem para isso o interruptor «Field is mandatory». O cartão «Customer Field Settings» tem ainda «Is hidden for Customer» e «Is not editable». É por isso que um cliente pode ver um formulário mais curto do que o teu, sem que ninguém tenha de manter dois formulários. «Title» e «Description» são sempre obrigatórios. Isso não pode ser desligado.

Depois podes alterar quase tudo: à direita do ticket está o cartão «Details» com quem pediu, telefone, e-mail, local, categoria e número de referência; alteras o campo e confirmas com o «Save» por baixo. O estado, a atribuição, a prioridade, o canal e os observadores estão um cartão acima, em «Actions». O estado e a atribuição têm efeito imediato. A prioridade, o canal e os observadores só são guardados com o «Save» do cartão «Details».

Só os agentes e os administradores podem alterar isto. Quem pediu pode ler o caso, comentá-lo e anexar ficheiros, mas não alterar a classificação sobre a qual os teus relatórios são construídos.

Há um efeito secundário que vale a pena saber uma vez: se editares um ticket que ainda não pertence a ninguém, passa a ser teu. O sistema inscreve-te como agente e move o estado de «Open» para «Assigned» — os dois ficam no histórico. Se não era essa a intenção, atribui-o depois a outra pessoa.

Cada uma destas alterações fica no histórico do ticket, com nome, hora, valor antigo e valor novo. Não tens de ligar nada para isso.

Fica a pergunta de como voltar a livrar-te dos tickets. Em «Settings → Archive» escolhes um período, vês com «Preview» quantos tickets fechados ele contém e crias um ficheiro ZIP com «Create archive»: tickets, comentários, histórico, campos personalizados e anexos, tudo num ficheiro. Criá-lo não remove nada. Os tickets só saem da base de dados em funcionamento com o passo à parte «Delete from live DB» na lista «Existing archives» — e podem ser repostos a partir desse mesmo ficheiro.

A descrição e os comentários não são caixas de texto simples. Cada uma tem uma barra de ferramentas por cima, e os botões dizem o que fazem quando apontas para eles: «Bold», «Italic», «Underline», «Strikethrough», «Text color», «Highlight color», «Bullet list», «Numbered list», «Quote», «Link» e «Clear formatting».

Uma ligação faz-se assim: seleciona o texto, carrega em «Link» e escreve o endereço na pequena caixa. Uma entrada vazia volta a remover a ligação. São permitidos endereços web e de correio (http, https, mailto) — tudo o resto é deitado fora ao guardar, para que um comentário não possa passar nada a ninguém.

As imagens entram pela área de transferência: tira uma imagem do ecrã e cola-a diretamente no editor com Ctrl+V. No início, o texto mostra apenas uma marca como «[inline-image:1]». Ao guardares, o sistema carrega a imagem e mostra-a exatamente nesse ponto — e ela vai também para o separador «Attachments», onde estão todos os ficheiros do caso. Colar imagens funciona na descrição de um ticket existente e num comentário novo. Não funciona no formulário «Create new ticket» nem enquanto editas um comentário.

O que vês é o que os outros veem: a formatação, as listas e as ligações mantêm-se no ticket e também na mensagem para quem pediu. A marcação vinda de fora — de uma página web copiada ou de um e-mail recebido, por exemplo — é reduzida a este conjunto permitido. Nada do teu texto se perde no processo, apenas o invólucro.

Um comentário pode ser marcado como interno com «Internal note (not visible to the customer)». Passa então a ter o selo «Internal» e fica invisível para quem pediu — nem a pesquisa o traz à superfície.

Cada um pode alterar e apagar os seus próprios comentários. O que um cliente escreveu só pode ser alterado ou apagado por esse cliente ou por um administrador. Isso inclui os e-mails dele. Os comentários de colegas podem ser alterados e apagados por qualquer agente que possa trabalhar no ticket. Isso inclui uma equipa que teve o ticket antes.

Os ficheiros pertencem ao caso, não a um comentário. No ticket, o separador «Attachments» leva à lista: «Upload file» acrescenta um, e cada linha indica o ficheiro, o tamanho e a data. Qualquer pessoa envolvida no ticket pode anexar alguma coisa, incluindo quem pediu; assim ninguém tem de te enviar a imagem do ecrã por e-mail. Um cliente só pode apagar os anexos que ele próprio carregou. Quando um subticket é fechado, os seus anexos são copiados para o ticket principal, onde levam o selo «Internal». Os agentes veem-nos; os clientes não os veem nem os transferem.

Um clique no nome abre a pré-visualização, sem teres de transferir o ficheiro. Nas imagens podes aproximar, afastar e rodar — útil para um ecrã fotografado de lado. Um PDF é mostrado na mesma janela, com vista geral das páginas, ampliação e impressão. Os ficheiros de texto são mostrados como texto. Com «Open in new tab» abres o ficheiro numa janela própria.

Um anexo pertence ao caso e viaja com ele: aparece no histórico («File uploaded: …»), sobrevive à passagem para outra equipa e acaba dentro do ficheiro de arquivo quando o ticket é arquivado.

O separador «History» do ticket responde à pergunta que está por trás de cada seguimento: quem alterou o quê, e quando? Cada linha indica a pessoa, o campo, o valor antigo riscado, o novo a seguir e a hora ao segundo. A entrada mais recente está em cima.

As entradas são escritas sem intervenção tua — nas mudanças de estado, de prioridade, de atribuição, de categoria, de local, de observadores, de título e de descrição, bem como na criação («Ticket opened»), em cada comentário e em cada ficheiro carregado. O número no separador diz-te à partida quanto movimento houve no caso.

O histórico não pode ser editado nem desligado. É exatamente isso que o torna útil: é a razão pela qual um ticket não pode ser apagado individualmente, e viaja para o ficheiro de arquivo quando o ticket é arquivado.

Num comentário, o histórico regista apenas que foi adicionado, editado ou apagado. O texto está no separador «Comments». Um comentário interno também aparece no histórico, mas só para os agentes e os administradores.

O estado diz onde um ticket está neste momento. O sistema traz doze estados — Open, Assigned, In Progress, Waiting for User Response, Resolved, Closed e mais alguns. Encontra-los em «Settings → General Settings», na secção «Drop-down lists», atrás do separador «Status»; «+ Add status» cria um teu, «Edit status» abre um existente.

O que importa é a diferença entre o nome e o significado. No editor de um estado, em «Meaning of this status», há três interruptores: «Counts as resolved», «Counts as closed» e «Waiting for the requester». Só estes interruptores dizem ao sistema como tratar um estado.

Podes mudar o nome de todos os estados, incluindo os que vêm com o sistema: no fundo do editor, em «Translations», há um campo «Name» por idioma — escreve aí o que as tuas pessoas devem ler. O nome técnico por trás fica intocado, e é exatamente por isso que nada se parte: a automatização, os relatórios e os interruptores acima dependem desse nome e não da tua etiqueta. Assim, «Resolved» pode passar a «Done».

Apagar, no entanto, não funciona com todos. Oito estados têm o selo «Mandatory» na lista — Open, Assigned, In Progress, Resolved, Closed, Reopened, Waiting for approval e Rejected. Podem ser renomeados e reordenados, mas não removidos; tentar acaba com uma mensagem clara. Isso não está lá para te chatear: dependem deles processos que, de outro modo, parariam sem dizer nada — por exemplo o fecho automático, que precisa de um estado «resolvido» como ponto de partida.

Dois estados pertencem ao próprio sistema: «Waiting for approval» e «Rejected» têm o selo «System only». Nascem de um processo de aprovação, e ninguém deve poder afirmar à mão que foi recusado algo que nunca esteve em decisão.

O que os três fazem: um estado que conta como resolvido fecha o ticket sozinho ao fim de 24 horas. Um estado que conta como fechado é o estado final para onde o ticket é movido. E «Waiting for the requester» significa exatamente isso: estamos à espera de quem pediu, não de outra equipa nem de um prestador de serviços. É essa a marca em que o relógio do SLA para, se o configurares assim.

Por baixo está «Allowed transitions to new status». Aqui assinalas que estados podem ser alcançados a partir deste. Deixa tudo vazio e nada fica restringido; assinala alguma coisa e todos os outros caminhos ficam fechados. É assim que se constrói um fluxo que não pode ser saltado — por exemplo: de «Open» só se pode ir para «In Progress» ou «Assigned», mas não diretamente para «Closed».

Os restantes interruptores do editor são pormenores com grande efeito: a cor para a lista, «Sort order» para a ordem, «Show status in new ticket form» (este estado deve sequer poder ser escolhido ao criar um ticket?), «Requires comment in dialog» (obrigar a um motivo) e «System only» para estados que só o próprio sistema pode definir.

Até quatro estados aparecem no ticket como botões em «Change Status to:». Escolhes-os no editor com o interruptor «Set as primary status (max. 4)». Na definição de origem são In Progress, Waiting for User Response, Waiting for Service Provider Response e Resolved. Todos os outros estados estão em «More statuses».

Tudo o que aparece como lista pendente num ticket pertence-te. Em «Settings → General Settings» está o cartão «Drop-down lists» com seis separadores: «Department», «Position», «Location», «Role», «Status» e «Priority». O manuseamento muda de lista para lista.

Um a um: escreve o nome em inglês no campo vazio e carrega no botão ao lado — tem o nome da lista, por isso «+ Add location», «+ Add department» e assim por diante. As linhas por baixo são as entradas existentes. Em «Department», «Position» e «Location», é aí que mudas um nome e confirmas com o «Save» ao lado.

Para muitas entradas de uma vez, «Department», «Position» e «Location» oferecem também «Export JSON» e «Import JSON». Num sistema acabado de instalar, transferes a estrutura vazia com «Export JSON», preenche-la e voltas a importá-la. Não é uma forma de mudar nomes — o próprio cartão o diz.

Algumas entradas têm o selo «Mandatory». Entre elas estão as três funções «Admin», «Agent» e «Customer», oito dos estados que vêm com o sistema, e um marcador em cada uma das listas Location, Position e Department («None selected or available»). Nenhuma delas pode ser apagada: dependem delas permissões e processos que, de outro modo, parariam sem dizer nada. Os estados podem, ainda assim, ser renomeados no seu editor. As funções e os marcadores não podem ser renomeados. O que é permitido depende da lista. «Role» está bloqueada: não é possível acrescentar nem renomear uma função. Em «Priority» acrescentas e apagas entradas, mas não há ficheiro nem mudança de nome. «Status» tem o seu próprio editor e também não tem ficheiro.

A tradução para os outros idiomas não se faz aqui, mas de uma só vez na página de traduções. Aqui basta o nome em inglês — é a âncora a que as traduções se prendem depois.

O estado é a única entrada com um editor próprio, porque dele depende mais do que um nome; tem o seu cartão mais abaixo.

As categorias são o que quem pede ou o agente escolhe ao criar um ticket — e aquilo por que agrupas os teus relatórios mais tarde. Cada equipa tem as suas: um helpdesk ordena por coisas diferentes de um departamento de rede, e nenhum vê as listas do outro.

Encontra-las em «Settings», na entrada «<team name> Categories». No exemplo, a equipa chama-se «Helpdesk», por isso a entrada diz «Helpdesk Categories».

A página tem três cartões: «Main categories», «Subcategories» e «Links». O arranque mais rápido: escreve o nome em inglês no campo «EN (required)» e carrega em «+ New main category» ou «+ New subcategory». A tradução faz-se depois, de uma só vez, na página de traduções — aqui não há nada a preparar para isso.

Se tiveres muitas categorias pela frente, segue o caminho do ficheiro: «Export JSON» transfere a estrutura — num sistema acabado de instalar o ficheiro está vazio e apenas te mostra a disposição. Preenche-lo (à mão ou com a ajuda de uma inteligência artificial), guardas e voltas a carregá-lo com «Import JSON». Não é uma forma de mudar nomes: um nome altera-se no campo dessa categoria e confirma-se com o «Save» ao lado — a página também o diz.

O terceiro cartão, «Links», é onde está o trabalho a sério. Escolhe uma categoria principal em cima, assinala em baixo as subcategorias que lhe pertencem e guarda com «Save links». O truque: uma subcategoria pode estar ligada a várias categorias principais. Assim só precisas de «Malfunction» uma vez e reutiliza-la em Printer, Network, Meeting-Room e Notebook.

A partir daí, as categorias ficam disponíveis no ticket. Apagar pode falhar enquanto houver tickets a usar uma categoria — isso é intencional, caso contrário os tickets antigos perderiam a sua classificação. Se removeres uma ligação, os tickets que usam esse par continuam a poder ser guardados. Só uma categoria escolhida de novo é verificada contra as ligações.

Se passares um ticket para outra equipa, a classificação dele mantém-se, mesmo que a nova equipa nem sequer tenha essas categorias. Fica então no campo juntamente com a sua origem, por exemplo «Meeting-Room · from Helpdesk», e aparece esbatida: a nova equipa vê como o caso correu até aí, mas não pode atribuir essa entrada. Para o reclassificar, escolhe da sua própria lista — e o sistema quer então uma categoria principal e uma subcategoria em conjunto.

Cada ticket tem um canal. Está no formulário e depois no cartão «Actions», em «How the request came in», e responde a uma pergunta que rapidamente se torna importante nos relatórios: o trabalho chega pelo portal ou por telefone?

Só podes escolher o que uma pessoa sabe e o sistema não: «Phone» e «Entered by an agent». Os outros dois valores são definidos pelo próprio sistema — «Self-service» quando foi quem pediu que criou o ticket no portal, e «E-mail» quando nasceu de uma mensagem recebida. Quando um agente cria um ticket, o formulário começa com «Entered by an agent».

Um canal definido pelo sistema não pode ser alterado depois por ninguém. O campo diz então «Recorded by the system. It cannot be changed.» Caso contrário, o campo perderia exatamente a afirmação para a qual existe. Ao contrário, num ticket registado por telefone continuas a poder alterar tudo o resto.

Só um agente ou um administrador pode definir o canal. Para quem pede, seria uma afirmação sobre o seu próprio caso — e os relatórios dependeriam da honestidade de toda a gente.

«E-mail» exige uma caixa de correio ligada, o que faz parte da edição Professional. Os outros três canais existem nas duas edições.

Por cima de cada lista de tickets está o campo «Search tickets…». Não pesquisa apenas os títulos, mas o caso inteiro: o título, a descrição, o nome de quem pediu, o endereço de e-mail e o telefone, o local, o número de ticket de referência, todos os comentários e os valores de texto dos teus campos personalizados.

O exemplo mostra-o: «coffee» não aparece em nenhum título, apenas na descrição de um ticket — e mesmo assim é encontrado. Não tens, portanto, de te lembrar do título de um ticket; basta uma palavra do caso.

As maiúsculas e minúsculas não contam. A pesquisa aplica-se sempre à lista em que estás e pode ser combinada com o «Filter» ao lado; «Reset» limpa a pesquisa e os filtros. A lista memoriza os teus filtros, separadamente para cada lista de equipa. Continuam definidos quando voltas de um ticket, recarregas a página ou inicias sessão noutro computador. O texto da pesquisa não fica memorizado. Para os clientes há um limite que não se vê e que convém saber: não pesquisam comentários internos — caso contrário, poderiam deduzir da lista de resultados o que foi discutido internamente. Também não pesquisam campos personalizados ocultos para os clientes.

Cada pessoa monta a sua própria lista de tickets. Para isso, o botão «Columns» está ao lado de «Filter». Abre a janela «Choose columns».

Na janela assinalas cada coluna que queres ver. As setas ao lado definem a ordem. «#» e «Title» estão sempre incluídas. A largura de uma coluna mudas na própria lista, arrastando a margem do seu cabeçalho.

«Save» guarda a tua escolha na tua conta de utilizador. Por isso vale em qualquer computador e mantém-se depois de terminares a sessão. «Default columns» repõe a lista na definição de origem.

Quando não há espaço para todas as colunas, as que estão mais à direita saem primeiro. «#», «Title» e «Status» ficam sempre. Por isso pões à frente o que mais te importa.

Com o Professional, os teus campos personalizados também são oferecidos. Aparecem na janela com o seu próprio nome, aqui por exemplo «Asset tag».

Os clientes podem montar a sua lista da mesma maneira, mas são-lhes oferecidas menos colunas. «Team», «Created by», «Last activity», «Status changed at», «Deadline», «Follow-up» e «Time» não estão disponíveis para eles. Os campos que escondeste dos clientes também não aparecem como coluna.

Num telemóvel o botão não é mostrado. Aí a lista mostra as colunas que cabem.

O ticket oferece para isso dois botões lado a lado, e a diferença está escrita por baixo em letra pequena. «Involve another team»: continuas responsável e a outra equipa trabalha ao teu lado num ticket ligado. «Escalate to another team»: a outra equipa assume o caso.

Quando passas o caso, a responsabilidade muda sem que nasça um segundo ticket. A tua equipa mantém o acesso de leitura e pode continuar a comentar, mas já não pode alterar nada — que é exatamente o que a janela te diz antes de confirmares. Aí escolhes a equipa de destino e podes acrescentar um motivo.

Quando envolves uma equipa, o teu ticket fica nas tuas mãos e recebe um subticket na outra equipa. O teu passa ao estado «Waiting for other team»; assim que a outra equipa fechar o dela, o teu regressa como «Back from other team». Assim não tens de perguntar se aconteceu alguma coisa do outro lado. Os anexos do subticket são copiados para o teu ticket com o selo «Internal», e o cliente não os vê.

Quanto à classificação: as categorias da equipa que passou o caso mantêm-se no ticket, mesmo quando a nova equipa não as tem — aparecem lá com a sua origem, esbatidas. Assim a nova equipa vê como o caso correu até aí e pode reclassificá-lo na sua própria lista, se for preciso.

Só quem é responsável neste momento pode passar um ticket adiante. Uma estação anterior continua a ver o caso, mas não o pode passar uma segunda vez. Pode comentar, mas não pode puxar o ticket de volta para si.

Na lista da tua equipa, o ticket mostra então «Waiting for other team» enquanto a outra equipa trabalha nele. A caixa «Also show tickets this team handed over» vem assinalada de origem, e a escolha de cada utilizador fica guardada. Para a outra equipa, o ticket começa como «Open».

Quem passa o ticket torna-se observador dele. A janela di-lo antes de confirmares. Como observador, recebes um e-mail quando o estado muda, o ticket é fechado ou alguém comenta. Como qualquer observador, retiras-te com «Stop observing».

Quando falta uma informação nos teus tickets — o número de inventário, o fim da garantia, o centro de custo — acrescenta-la tu. Em «Settings → Ticket Settings», no fundo, está o cartão «Custom fields»; o botão chama-se «Add custom field».

Na janela dás um nome e um tipo de campo: «Text», «Multiline text», «Integer», «Decimal», «Date» ou «Yes / No». O tipo decide o que pode ser introduzido — um campo de data não aceita «para a semana», e é exatamente por isso que depois podes fazer relatórios sobre ele.

Em «Scope» decides onde o campo se aplica: «All teams (including new ones)» ou «Selected teams only». A primeira escolha abrange também as equipas que ainda não existem — o tipo de diferença de que só se dá conta meio ano depois.

Os três interruptores em «Defaults» são «Mandatory by default», «Hidden for customer by default» e «Not editable by customer by default». Só se aplicam a um campo enquanto não tiver sido guardado nada para esse campo nas definições do campo, na mesma página. Assim que o definires aí, são as definições do campo que decidem.

No ticket, os campos personalizados estão num cartão próprio, «Additional information», entre a descrição e os comentários. Sem um modelo, o formulário mostra todos os campos personalizados da equipa. Se escolheres um modelo ao criar um ticket, ele mostra exatamente os campos que esse modelo lista, pela ordem dele — «apenas os campos de que este caso precisa».

Um modelo pode ainda tornar um campo obrigatório. O que o administrador escondeu dos clientes continua escondido, mesmo que um modelo o inclua. Um campo obrigatório que um modelo não inclui não é pedido, por isso essa exigência não se aplica aos tickets criados com esse modelo.

Quantos campos personalizados uma equipa pode ter define-se em «Settings → General Settings», no cartão «Custom fields limit». Livras-te de um campo com «Deactivate»: desaparece do formulário, mas os seus valores ficam nos tickets antigos — o interruptor «Show deactivated» volta a trazê-lo à lista.

Às vezes alguém deve acompanhar um caso sem trabalhar nele: o responsável da equipa num assunto delicado, o colega que assume na semana seguinte. É para isso que servem os observadores. No ticket, o campo «Observers» está no cartão «Actions» e o botão chama-se «Add observer»; o formulário «Create new ticket» tem o mesmo campo. No ticket, uma alteração aí é guardada com o «Save» do cartão «Details».

Só podem ser escolhidos agentes e administradores da equipa a que o ticket pertence. Um cliente não pode ser observador — receberia mensagens sobre trabalho interno.

Um observador recebe um e-mail quando alguma coisa acontece no ticket: um comentário novo, uma mudança de estado, uma nova atribuição, campos alterados. Não é enviado de imediato, mas agrupado: depois da última alteração, o sistema espera um minuto e envia UMA mensagem com tudo o que aconteceu nesse tempo. Assim, tratar de um ticket de uma assentada não gera sete mensagens. Se chegarem vários comentários nesse tempo, vão todos na mensagem.

Quem observa faz parte do histórico: uma alteração é registada como qualquer outra, com o estado antigo e o novo.

Introduzir observadores faz parte do Basic. A mensagem aos observadores faz parte do Professional, porque precisa do envio de correio. Sem isso podes introduzir observadores, mas não sai nada. Um observador pode retirar-se a si próprio com o botão «Stop observing». Isso não exige o direito de alterar o ticket.

Um observador também é adicionado automaticamente: quem passa um ticket com «Escalate to another team» torna-se observador. Assim fica a saber o que a outra equipa faz com ele.

Quando duas pessoas trabalham no mesmo ticket ao mesmo tempo, a gravação mais tardia pode substituir a anterior, e ninguém daria por isso. Por isso o ticket mostra quem mais o tem aberto. Além disso, recusa uma gravação que se baseie numa versão desatualizada.

O aviso está no cabeçalho do ticket. «Marco Rossi is viewing this ticket» significa que o Marco tem o ticket aberto. «Marco Rossi is actively editing this ticket» significa que o Marco tem dados por guardar no ticket. Pode ser uma resposta começada, um comentário a ser alterado, o título ou a descrição em modo de edição, um seguimento, um campo personalizado ou um registo de tempo. Também contam os campos alterados nos cartões «Actions» e «Details», enquanto não forem guardados com «Save». Uma janela aberta no ticket também conta. São as janelas «Involve another team?», «Escalate to another team?», «Close ticket», «Resolve incident» e «Start a workflow», e ainda a janela do comentário a uma mudança de estado. Após dois minutos sem escrever nada, o aviso volta a mostrar «viewing», mesmo que o rascunho ainda lá esteja.

Se vários colegas tiverem o ticket aberto, o aviso resume-os, por exemplo «Marco Rossi and 2 more are viewing this ticket». Aponta para o aviso para ver todos os nomes. Assim que alguém estiver a editar ativamente, a linha só conta as pessoas que estão a editar. Nunca te vês a ti próprio. Se tiveres o ticket aberto em dois separadores, contas uma vez. Se o ticket só estiver aberto num separador oculto, sais do aviso dos outros ao fim de cerca de um minuto.

Quando um colega guarda uma alteração, o aviso diz «Marco Rossi changed this ticket», com o botão «Refresh» ao lado. Um comentário novo de outra pessoa mostra «Marco Rossi added a comment». Se a alteração não veio de uma pessoa, por exemplo de uma regra de automatização ou de um e-mail recebido, o aviso diz «This ticket was changed». O aviso fica até recarregares.

«Refresh» carrega a versão atual do ticket, como o estado, a atribuição, os campos e o histórico. Não recarrega a página inteira. Os teus dados por guardar ficam. Uma resposta começada fica na caixa de resposta, e um título ou uma descrição abertos mantêm o teu texto. Se o texto guardado tiver mudado entretanto, aparece «The saved text has changed in the meantime.» por baixo do campo. Se guardares nessa altura, o teu texto substitui o guardado. O botão «Refresh» no cabeçalho do ticket faz o mesmo.

Se mesmo assim guardares sobre uma versão desatualizada, a gravação é recusada. Abre-se a janela «Ticket changed in the meantime». Se uma pessoa fez a alteração, a janela indica-a. A tua alteração não foi guardada. Clica em «Refresh», compara a tua alteração com a versão atual e guarda de novo. Isto vale para qualquer alteração ao próprio ticket, por exemplo o estado, a atribuição, a prioridade, o cartão «Details» e os campos personalizados.

Os comentários nunca são recusados. Duas respostas não se substituem uma à outra. Ambas ficam no ticket. O mesmo vale para os anexos e os registos de tempo. As ações em massa na lista de tickets e as regras de automatização também não são comparadas com a versão. Alteram o ticket diretamente. Quem o tiver aberto vê o aviso a seguir.

Os clientes não veem nada disto. Não aparecem no aviso. Também não veem quem está a trabalhar no ticket deles.

Quem tem um ticket aberto fica apenas na memória do servidor. Cerca de um minuto depois de a pessoa ter saído do ticket, a entrada desaparece. Nada disto é escrito num registo. O ticket guarda quem o alterou por último. Essa entrada faz parte da exportação de dados dessa pessoa. Quando a pessoa é anonimizada, a entrada é removida.

O canal de correio é uma estrada com dois sentidos, e eles andam juntos: uma mensagem recebida transforma-se num ticket, a tua resposta sai como mensagem, e a resposta de quem pediu cai como comentário no mesmo ticket, não num segundo.

A associação não é feita por intuição: uma resposta só cai no ticket existente quando a mensagem traz a referência do caso no assunto ou os cabeçalhos de resposta do programa de correio. Uma mensagem sem nenhuma das duas coisas começa um caso novo — mais vale um ticket a mais do que dois casos sem relação juntos só porque o assunto calhou a coincidir.

Tudo para isso está em «Settings → E-Mail Settings». O cartão de cima, «SMTP settings», é o caminho de saída: servidor, porta, «Use SSL», utilizador e palavra-passe, além do endereço e do nome do remetente. Com «Send test e-mail» envias uma mensagem de teste a ti próprio — guarda primeiro, testa depois, como o próprio cartão diz.

O cartão «IMAP settings» é o caminho de entrada: servidor, porta, o intervalo de recolha e as duas pastas. Não tens de adivinhar o nome da pasta: «Read from server» vai buscar as pastas que existem mesmo na tua caixa de correio, «Create on server» cria uma nova. O campo aceita então o caminho que o teu servidor de correio usa — um servidor escreve «INBOX/Processed», outro «INBOX.Processed», e os dois significam o mesmo.

A «Processed folder» recebe as mensagens que o sistema põe de lado: mensagens de remetentes bloqueados, mensagens geradas automaticamente e mensagens que um fluxo de trabalho move com «Move to folder» sem pasta própria. Deixa-a vazia e ficam na caixa de entrada. Por baixo defines quando corre a limpeza («Hour», «Minute») e que idade uma mensagem pode atingir («Retention (days)») — caso contrário a caixa de correio cresce em silêncio.

As caixas de correio pertencem à equipa, não ao sistema: em «Team mailboxes», cada equipa introduz o seu endereço com uma palavra-passe. Esse endereço é ao mesmo tempo o remetente das mensagens dessa equipa — assim quem pediu responde para o mesmo sítio de onde o correio é recolhido.

E agora a parte sem a qual nada disto acontece: o fluxo de trabalho. Uma caixa de correio configurada, por si só, não faz nada. Se uma equipa não tiver um fluxo de trabalho ativo, a caixa de correio nem sequer é consultada — nenhum ticket, nenhuma confirmação, as mensagens ficam simplesmente lá. A resposta automática aos teus clientes existe apenas aqui, e é configurada por ti. Isso é intencional: um sistema que escrevesse a todos os endereços de remetente sem que ninguém o pedisse seria pior do que um que fica calado.

Em «E-Mail workflows» escolhes a equipa em cima e crias um fluxo de trabalho com «+ Add workflow». Recebe um nome (só para ti), um interruptor «Enabled» e duas afirmações sobre quando se aplica: «Match» decide se todas as condições têm de ser verdadeiras («All conditions») ou se basta uma, e «Stop after match» termina a execução assim que este fluxo tiver correspondido — um fluxo mais abaixo nunca chega então à sua vez. A ordem muda-se com as setas ao lado.

Em «When?» está a condição propriamente dita. «Every e-mail in this mailbox» aceita todas as mensagens; «Only when subject or text contains» exige uma palavra no assunto ou no corpo. «Advanced» torna tudo preciso: aí escolhes o que é observado — «Subject or body», «Subject», «Body», «Sender (From)» ou «Recipient (To/Cc)» — e como é comparado: «Contains», «Equals» ou «Regex». É assim que separas, por exemplo, os relatos enviados para um endereço comum de tudo o resto.

Por baixo estão cinco ações como interruptores. São o verdadeiro conteúdo do fluxo de trabalho — o que não estiver ligado não acontece:

«Create or append ticket» transforma a mensagem num ticket — ou acrescenta-a como comentário a um já existente quando a referência está no assunto. Sem esta ação, uma mensagem nunca se torna um caso.

«Set fields» define a prioridade, o estado, a categoria principal e a subcategoria, a equipa responsável e quem fica com o ticket logo no momento da criação. Tudo o que ficar em «— Keep default —» fica como ficaria sem um fluxo de trabalho.

«Auto-reply» é a confirmação a quem enviou. Com este interruptor desligado, o teu cliente não recebe nenhuma confirmação, por melhor que esteja configurado tudo o resto. «Send mail» também pode escrever a quem enviou, como mostra a ação seguinte.

«Send mail» envia uma mensagem adicional: ou para quem enviou a mensagem recebida, ou para membros escolhidos da equipa e endereços fixos. Tem as suas próprias «Send conditions» — deixa-as vazias e sai em cada execução deste fluxo de trabalho.

«Move to folder» arquiva a mensagem tratada numa pasta. Deixa o campo vazio e vale a «Processed folder» geral das definições de IMAP acima.

A ação «Auto-reply» em detalhe: constróis o assunto a partir de blocos. «Original subject {originalSubject}» assume o assunto da mensagem recebida, «Ticket reference {ticketTag}» insere a referência do caso — juntos dão algo como «Printer problem [TICKET-99-a1b2c3]».

A referência não é acrescentada sozinha. Só aparece onde puseres {ticketTag}. {ticketId} só insere o número simples, e o sistema não reconhece uma resposta por ele. Sem a referência no assunto, uma resposta continua a ser associada se trouxer os cabeçalhos de resposta da confirmação. Só uma mensagem sem nenhum dos dois se torna um ticket novo.

O texto por baixo é a tua mensagem de confirmação. Escreve-a em inglês: passa pela mesma exportação e importação que todos os outros textos, e só assim pode ser traduzida para os outros idiomas. Deixa-a vazia e o sistema envia a sua própria mensagem predefinida. Aqui são permitidas as mesmas variáveis.

«Reply language» decide em que idioma saem o assunto e o texto: «Standard English» usa inglês, «Fixed language» um idioma que escolhes, «Assigned agent's language» o idioma do agente responsável, e «Team default language» o idioma predefinido da equipa. As traduções em si mantêm-se na página de idiomas.

Um conselho que o sistema também imprime por cima do cartão: tudo o que pertence a um caso pertence a UM fluxo de trabalho. Só as ações dentro do mesmo fluxo conhecem o ticket que acabou de ser criado — é por isso que a confirmação pode indicar o número dele e uma ação de um segundo fluxo não pode.

Todo o canal de correio, de entrada e de saída, faz parte da edição Professional. No Basic o sistema não envia nem recebe e-mail; aí os tickets são criados pelo portal, pelo telefone e pelo agente.