SLA, calendário e escalonamentos

Os prazos configuram-se em «Settings → SLA». A própria página te diz no topo quando não há nenhuma política ativa. Uma política tem três partes: um nome, as condições e as metas. As políticas novas são criadas inativas de propósito — para que possas acabar de as configurar antes de elas fazerem alguma coisa.

As condições são «Team», «Priority», «Main category» e «Subcategory». Vazio significa «Any», ou seja, «aplica-se a tudo» — não «não se aplica a nada». Se várias políticas corresponderem, ganha a que tiver o número mais baixo em «Order»; é por isso que a política mais restrita fica em cima e a geral por baixo.

Os dois campos de categoria estão agrupados por equipa, porque as categorias pertencem a uma equipa — mas são-te oferecidas todas, incluindo as de outras equipas. Isso é intencional: numa passagem, o ticket muda de equipa, a categoria não. Um ticket que o helpdesk passou à equipa de rede continua a levar a classificação do helpdesk, e uma política pode apontar exatamente para isso. Depois de escolheres uma categoria principal, o campo por baixo só oferece as subcategorias ligadas a ela — um par que não pode existir num ticket é recusado ao guardar.

Cada política tem duas metas. «Time to first response» termina com a primeira resposta pública de um agente — uma confirmação automática e uma nota interna não contam, explicitamente. «Time to resolution» termina assim que o ticket chega a um estado que conta como resolvido (qual é, defines em «Settings → General → Status»). As duas metas têm os seus minutos, o seu calendário e a sua reação ao incumprimento.

No ticket, os prazos estão à direita no cartão «Details» e, por baixo, «Show deadline history»: um registo que anota cada passo — iniciado, em pausa, retomado, cumprido, falhado — cada um com um motivo e o tempo de trabalho usado. Só os agentes e os administradores o veem; para os clientes não pode ser consultado.

Se alguém mudar depois a prioridade ou a equipa, o relógio passa para a política que então corresponde: o tempo de trabalho usado até aí é liquidado com o calendário antigo e, a partir daí, valem os valores novos. Se já não houver política que corresponda, o relógio termina sem veredito — não conta como cumprido nem como incumprido.

Se nenhuma política correspondia quando o ticket foi criado, o relógio arranca da primeira vez que uma política corresponde depois de uma alteração, por exemplo uma prioridade mais alta. Conta a partir desse momento. O relógio da primeira resposta só arranca se ainda ninguém tiver respondido.

Só nascem relógios novos quando um ticket é reaberto. As outras mudanças de estado não criam relógios novos.

Um calendário diz quando o relógio corre. Tem um nome, um fuso horário próprio e um número qualquer de janelas por dia da semana — uma pausa de almoço é simplesmente um dia com duas janelas. Uma janela pode passar da meia-noite; nesse caso aparece «ends next day» ao lado.

Que calendário se aplica a uma equipa define-se na equipa («Settings → Teams»). Na meta individual de uma política podes sobrepor-te: «From the team» usa o da equipa, ou escolhes outro. É exatamente isso que produz o caso habitual — as avarias contam a toda a hora, tudo o resto só no horário de expediente.

O que é contado é o tempo que passa realmente dentro da janela, não a diferença entre as horas do relógio. Na mudança para a hora de verão isso faz diferença: um dia 24/7 em outubro tem 25 horas, e um turno noturno das 22:00 às 06:00 tem sete em vez de oito na primavera. Uma janela de expediente das 09:00 às 17:00 nunca é afetada, porque na UE a mudança acontece de noite.

Se não for possível encontrar um calendário com horas de funcionamento, não é criado nenhum prazo — mais vale nenhum do que um adivinhado. No ticket aparece uma nota em vez de uma data.

Por baixo de cada calendário está a lista «Closed days». Um clique em «Import holidays (.ics)» aceita um ficheiro de calendário e comunica depois quatro números: quantos dias foram assumidos, quantos substituídos, quantos ilegíveis e quantos já lá estavam. Também podes introduzir dias soltos à mão.

O símbolo ↻ a seguir a um dia significa «repete-se todos os anos». Só é correto para datas fixas: 3 de outubro cai na mesma data todos os anos, a Sexta-Feira Santa e a segunda-feira de Pentecostes dependem da data da Páscoa e mudam. Os feriados móveis aparecem, por isso, na lista com a data concreta de cada ano — na imagem, «Good Friday» sem o símbolo.

Um dia fechado engole a janela inteira desse dia, incluindo a parte que se estende pelo dia seguinte. E quando um calendário não conhece um único dia fechado para os próximos doze meses, a página di-lo explicitamente — caso contrário o sistema conta em silêncio por cima dos feriados e produz prazos errados.

A discussão mais frequente sobre prazos é esta: o ticket está há três dias à espera da resposta do cliente e o relógio continua a correr. Por isso, cada meta tem o interruptor «Pause while waiting for the requester» — individualmente, não para a política inteira.

Se estás à espera é decidido pelo estado: em «Settings → General → Status», cada estado traz uma marca a dizer se conta como «à espera de quem pediu». Com o interruptor ligado, o prazo descansa enquanto o ticket estiver num estado desses. O relógio de parede continua a correr — é por isso que a lista mostra «Paused» em vez de um tempo restante, e o histórico de prazos contém «Paused» e «Resumed» com as respetivas horas. O tempo de espera também não conta se o ticket for resolvido diretamente a partir de um estado desses.

Para a primeira resposta costuma deixar-se o interruptor desligado: deves a primeira resposta seja o que for que se esteja à espera. Para a resolução costuma estar ligado. A imagem mostra exatamente essa configuração.

Assim que uma política está ativa, a lista de tickets ganha a coluna «Deadline». Mostra o tempo restante do próximo prazo em aberto («14h 53m»). Quando já não corre nenhum prazo no ticket, fica lá o veredito: o selo «In time» para um cumprido, o «Breached» vermelho para um falhado. Um ticket sem relógio nenhum recebe um traço neutro, e isso é intencional: um ticket anterior à política não é uma falha.

Se não houver política ativa, a coluna não existe de todo — não fica lá vazia. O mesmo vale para o filtro: em «Filter», a caixa «Breached only» só aparece quando existirem prazos.

Um ticket tem dois relógios, mas a coluna só tem um lugar — mostra o prazo EM ABERTO mais urgente. Se a primeira resposta foi falhada e a resolução ainda corre, a coluna mostra o tempo restante da resolução com um «!» vermelho ao lado. Essa marca diz: um prazo deste ticket já foi incumprido — e é exatamente assim que o filtro «Breached only» o encontra, porque pergunta por qualquer prazo incumprido, incluindo um que já terminou há muito. Qual dos dois foi está escrito no próprio ticket.

Também podes ordenar por ele: sob o mesmo título «Deadline» está um campo com «Due soonest first» e «Due latest first». Os tickets sem relógio a correr vão sempre para o fim — não são os menos urgentes, simplesmente não são abrangidos. A ordenação por prazo tem precedência sobre a ordenação por «Updated at»: nenhuma lista consegue satisfazer duas ordens ao mesmo tempo.

Por meta defines em «When breached» o que acontece num incumprimento: «Record only» apenas regista, «Notify assignee and observers» envia uma mensagem a quem tem o ticket e a quem o observa (não à equipa inteira), «Hand over to another team» passa o ticket. Para a passagem tens de escolher uma equipa de destino — uma política sem ela é recusada ao guardar, porque pareceria configurada e não faria nada.

A ação corre exatamente uma vez por relógio. Sem esse travão, um reinício do servidor voltaria a enviar a mesma mensagem. A marca de «já feito» é colocada mesmo quando o envio falhou — uma mensagem que não chegou é melhor do que um ciclo que envia uma nova a cada minuto.

O próprio incumprimento é datado do momento em que se venceu, não da passagem de verificação — caso contrário os relatórios dependeriam do ritmo do serviço de verificação. E é medido contra o tempo de trabalho usado: um relógio em pausa não pode incumprir, mesmo que a data de vencimento já tenha passado há muito.

A passagem repõe o estado em «Open». As linhas do histórico sobre isso são internas; o cliente só vê no ticket o novo estado e a nova equipa.

Em «Reports» escolhes o período e carregas em «Generate report» — sem esse clique a página fica vazia. O relatório contém então o bloco «Service level agreements» com uma linha por meta: cumpridos, incumpridos, ainda a correr, taxa alcançada e tempo médio usado.

A contagem é por meta, não por ticket — está escrito também por baixo da tabela. Um ticket com as duas metas aparece, por isso, duas vezes, uma em cada linha.

A taxa alcançada conta apenas relógios já decididos. Os que continuam a correr não pertencem ao denominador, caso contrário todos os SLA acabados de ligar pareceriam catastróficos ao início e melhorariam sozinhos. Se ainda não houver um único relógio decidido, aparece um traço — não «0 %».

Se trabalhares com incidentes coletivos, há uma linha adicional «Achieved without group incidents»: um único incidente coletivo com cem tickets associados distorceria a taxa nos dois sentidos. Deixa de fora todos os tickets ligados a um incidente coletivo.

Neste bloco, os agentes só veem as suas próprias equipas. Sem o Professional, o bloco só aparece se houver dados de prazos de antes; nesse caso continua legível.