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 aparecem e quais deles são obrigatórios define-se em «Settings → Ticket Settings», em separado para os agentes e para os clientes. É por isso que um cliente vê um formulário mais curto do que o teu, sem que ninguém tenha de manter dois formulários.

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 prioridade, a atribuição, o canal e os observadores estão um cartão acima, em «Actions», e têm efeito imediato, sem gravação à parte.

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. Só então esses tickets desaparecem da base de dados em funcionamento — 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.

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 «Only for Admin/Agents». Passa então a ter o selo «Internal» e fica invisível para quem pediu — nem a pesquisa o traz à superfície.

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 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.

Um comentário aparece aí de forma abreviada — o texto completo 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. Seis estados têm o selo «Mandatory» na lista — Open, Assigned, In Progress, Resolved, Closed e Reopened. 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 «Rejected», 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.

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», «Site», «Role», «Status» e «Priority». Atrás de cada um está o mesmo manuseamento, por isso só o tens de aprender uma vez.

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 site», «+ Add department» e assim por diante. As linhas por baixo são as entradas existentes: é aí que mudas um nome e confirmas com o «Save» ao lado.

Para muitas entradas de uma vez existem «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», seis dos estados que vêm com o sistema, e um marcador em cada uma das listas Site, Position e Department («None selected or available»). Podem ser renomeados, mas não apagados: dependem deles permissões e processos que, de outro modo, parariam sem dizer nada.

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 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 «Email» quando nasceu de uma mensagem recebida.

É também por isso que não podes passar depois um canal definido pelo sistema para «Phone»: 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.

«Email» 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. 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.

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.

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.

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» aplicam-se aos tickets novos: «Mandatory by default», «Hidden for customer by default» e «Not editable by customer by default». São predefinições — as definições do campo na mesma página continuam a ser o sítio onde defines tudo ao pormenor por função.

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, mas não pode levantar uma regra: o que o administrador escondeu dos clientes ou declarou obrigatório continua assim, mesmo que um modelo diga o contrário. Caso contrário, um modelo seria uma forma de fugir a uma regra da casa.

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.

Só podem ser escolhidos agentes e administradores de uma equipa envolvida. 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.

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

A notificação é um e-mail, por isso o envio de correio tem de estar configurado (Professional). Sem isso podes introduzir observadores, mas não sai nada.

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.

As mensagens tratadas passam para a «Processed folder»; 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 — o único sítio onde o sistema responde por iniciativa própria. Com este interruptor desligado, o teu cliente nunca recebe uma resposta automática, por melhor que esteja configurado tudo o resto.

«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]».

A referência não é acrescentada sozinha. Só aparece onde puseres {ticketTag} ou {ticketId} — e é exatamente por ela que o sistema reconhece depois a resposta do teu cliente. Sem ela no assunto, cada seguimento começa um ticket novo em vez de se tornar um comentário do antigo.

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, nem mosaico no relatório.

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.

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. Preencher o dia anterior é o caso normal, e 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 em «Log».

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.

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 visto «Billable». O tempo é registado uma vez, e o visto decide se vai para a fatura.

É por isso que o ticket mostra dois totais: à esquerda tudo o que foi registado, à direita a soma faturável.

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, retira o visto 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. 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 um ticket da lista tiver tempo.

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».

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 cima dos números merece ser levada a sério: eles 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.

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 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.

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.