Manual

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.

O registo de tempos está desligado de origem. Enquanto estiver desligado não há campo nem coluna. O cartão «Time spent» no relatório só aparece então se tiver sido registado tempo no período escolhido.

Um campo morto seria pior do que nenhum, por isso a funcionalidade desaparece por completo em vez de ficar ali esbatida.

O interruptor está em «Settings → General», no cartão «Time tracking per ticket», e chama-se «Enable time tracking».

A partir daí, todas as equipas participam. Para deixar uma de fora, desligas na própria equipa, em «Settings → Teams», na caixa «Team details».

Uma empresa com uma equipa de TI interna e uma equipa virada para o cliente muitas vezes só precisa dele na segunda.

Se voltares a desligar o registo de tempos mais tarde, as entradas existentes continuam legíveis e exportáveis — são uma base de faturação, não uma comodidade. Deixa de ser possível registar coisas novas. As entradas existentes também deixam de poder ser alteradas ou apagadas.

O ticket tem um cartão chamado «Time spent». «Log time» abre a introdução.

Ao lado do campo estão botões rápidos: um clique em «30m» regista trinta minutos. Que botões aparecem define-se nas definições.

O campo «Duration» também aceita introdução livre: «90» são noventa minutos, «1.5h» é uma hora e meia, e «1h 30m» também. Um número sem unidade são sempre minutos.

Uma introdução que o sistema não perceba por completo é recusada. «1h in the evening» não se torna uma entrada de uma hora — torna-se uma mensagem de erro.

Em «What for (optional)» escreves para que foi o tempo. O texto viaja para a exportação e não aparece no histórico do ticket.

Vários agentes registam tempo no mesmo ticket. Cada entrada traz o seu dia, a sua nota e o nome de quem fez o trabalho.

O tempo é registado num dia, não numa hora do relógio. Para isso, a introdução tem um campo de data que começa no dia de hoje; para preencher o dia anterior, escolhes aí o dia antes. Um dia no futuro não é aceite. Uma hora exata alegaria uma precisão que a introdução não tem.

Para sessões longas há um cronómetro no ticket: «Start timer» põe-no a andar, «Pause» pára-o.

O cronómetro nunca cria uma entrada por si. Propõe o tempo decorrido, e nada é guardado enquanto não carregares no botão «Log …», que indica o tempo. O que fica registado é o tempo que realmente correu.

Substitui contas de cabeça, não conhecimento. Sem ele a funcionalidade está completa, porque escrever o valor é o caminho principal.

Abrir outro ticket põe o cronómetro em pausa, e o ticket novo diz-te a que ticket ele está preso. Se ainda houver tempo por registar à espera noutro ticket e arrancares aqui o cronómetro, a aplicação pergunta primeiro. A pergunta «Start timer» oferece «Log …» para o tempo do outro ticket, «Discard» e «Cancel». Aparece a partir de um minuto de tempo decorrido.

Uma janela escondida não é uma pausa. O cronómetro continua a andar se te limitares a clicar noutro sítio.

Contra um cronómetro deixado a andar durante a noite existe um tempo máximo. O valor é limitado, nunca deitado fora, e o agente é avisado.

O cronómetro está desligado de origem. Encontra-lo nas definições, em «Stopwatch on the ticket».

Cada entrada tem um interruptor «Billable». O tempo é registado uma vez, e o interruptor decide se vai para a fatura.

É por isso que o ticket pode mostrar dois totais: à esquerda tudo o que foi registado, à direita a soma faturável. O segundo total só aparece quando é diferente do primeiro.

Não há um tipo próprio para cortesia comercial. A cortesia, o trabalho em garantia e o retrabalho interno chamam-se coisas diferentes em cada empresa, e o sistema conhece apenas a única distinção de que o dinheiro depende.

É assim que se regista uma cortesia: introduz o tempo como sempre, desliga «Billable» e escreve o motivo na nota.

A entrada passa então a mostrar «not billable». Os minutos ficam no total registado, porque o trabalho aconteceu mesmo.

Quem não regista o tempo de todo perde precisamente o número que mais tarde explica porque é que se cobrou tão pouco a um cliente.

Se a maior parte do teu trabalho não for faturável, inverte a predefinição com o interruptor «New entries are billable by default».

De origem, tudo é faturado ao minuto. Quem fatura em quartos de hora define dois valores.

«Rounding increment (minutes)» é o passo. Cada entrada é arredondada para cima até ao múltiplo seguinte.

«Minimum per entry (minutes)» é o mínimo. Cada entrada é faturada com pelo menos este valor.

Os dois funcionam um a seguir ao outro: primeiro o mínimo, depois o passo. Com um mínimo de 20 e um passo de 15, cinco minutos tornam-se trinta, porque o resultado tem de satisfazer os dois.

Por baixo dos dois campos está uma frase de exemplo com os teus próprios valores. É calculada, não afirmada.

Só o valor faturado é arredondado, e só por entrada — nunca o total. Duas entradas pequenas são, por isso, arredondadas para cima duas vezes.

O tempo registado fica intocado. Alterar o arredondamento mais tarde não falsifica dados antigos, porque o valor é calculado no momento em que é mostrado.

Vês os dois na entrada: onde o arredondamento altera o valor, o resultado aparece ao lado entre parênteses.

Um prestador de serviços muitas vezes não quer nenhum ticket fechado sem tempo registado. Há um interruptor para isso.

Chama-se «Require a time entry before resolving or closing» e está desligado de origem.

Aplica-se apenas quando é uma pessoa a mudar o estado, e só a quem pode registar tempo. Aplica-se também quando um modelo de resposta define o estado num ticket individual. Um agente sem entrada recebe uma mensagem e o ticket fica aberto.

O fecho automático, a fusão e as ações em massa nunca são bloqueados. Caso contrário haveria tickets que ninguém mais conseguiria fechar.

Este é o interruptor mais perigoso de toda a funcionalidade. Só o ligues quando a tua equipa registar mesmo o tempo de todas as vezes.

A lista de tickets ganha uma coluna «Time» que mostra quanto já foi registado num caso.

Não a ligas. Aparece assim que o registo de tempos está ligado. Só os agentes e os administradores a veem. Podes retirá-la da tua lista com «Columns».

Em janelas estreitas é uma das primeiras a sair. A lista mantém então as colunas sem as quais um ticket não se encontra.

Tempo que fica apenas num ticket não é base para uma fatura. Por isso a página de relatórios tem um cartão «Time spent». Só quem tem a permissão «Time tracking: see the report» vê o cartão.

No topo estão quatro números: registado, faturado, o número de entradas e o número de tickets que têm algum tempo.

Este último número é o mais importante depois do total. Quarenta horas em três de quinhentos tickets não é uma avaliação — são três agentes que são os únicos a registar.

Por baixo vêm as repartições: por quem pediu, por equipa, por categoria e por dia.

A isso junta-se uma tabela por campo personalizado. É esse o caminho para faturar por empresa ou por centro de custo: crias um campo personalizado, preenche-lo no ticket, e o relatório agrupa por ele.

O período no topo da página aplica-se ao dia em que o trabalho foi feito. Trabalho de julho num ticket de junho aparece, por isso, no relatório de julho.

Uma nota por baixo dos botões de exportação merece ser levada a sério: os números vêm de entradas feitas por pessoas e das tuas regras de arredondamento. São uma base de trabalho, não uma fatura auditada.

Por baixo do cartão estão três botões. Entregam as entradas individuais, não os totais da página. Contêm exatamente as entradas que correspondem aos teus filtros.

São dois destinatários, não três formatos de ficheiro. «Export entries (CSV)» e «Export entries (Excel)» vão para a contabilidade: os dois são completos e nunca são cortados.

«Export entries (PDF)» é o documento para uma pessoa. Vai para o cliente como anexo da fatura. O PDF não tem coluna para a nota.

O PDF está limitado a 20 000 entradas, e o próprio documento o diz. De qualquer forma, ninguém lê uma fatura com mais linhas do que isso.

Os três ficheiros são construídos a partir da mesma fonte: os filtros, o arredondamento, as colunas e os números existem uma vez, por isso os três não podem divergir.

Uma entrada que não é faturável tem uma célula vazia na coluna do faturável, não um zero. Um zero seria somado numa tabela dinâmica.

Se a «Per-agent evaluation» do registo de tempos estiver desligada, a coluna «Agent» falta nos três ficheiros. Se a tua licença voltar ao Basic, as entradas existentes continuam legíveis e exportáveis.

Um cliente nunca vê as entradas de tempo, nem sequer no seu próprio ticket.

Isto não é uma definição, é um bloqueio no servidor. Não há interruptor que o abra.

A razão está nas próprias entradas: as notas são escritas para a equipa. Dizem o que correu mal e quanto tempo demorou a procura da causa.

Outros sistemas deste tipo fazem o mesmo. Onde o tempo chega ao cliente, chega-lhe como documento.

É para isso que serve a exportação em PDF: vai com a fatura e não para o ticket no portal do cliente.

O relatório pode ainda mostrar quem registou quanto. De origem, não mostra.

O tempo por pessoa é um dado de desempenho e, em muitas empresas, a comissão de trabalhadores tem uma palavra a dizer sobre ele.

O interruptor chama-se «Per-agent evaluation» e está nas definições.

Enquanto estiver desligado, o servidor nem sequer entrega os números. A tabela não está escondida — não existe.

Essa diferença importa. Um bloqueio que só o ecrã conhece não é um bloqueio.