Pedidos com tarefas e aprovação

«Entra um colega novo» não é um único ticket. É um portátil, duas contas, uma extensão telefónica e talvez acesso a partir do exterior. Cada peça pertence a uma equipa diferente, e mesmo assim queres um caso que te diga como estão as coisas.

É para isso que serve um pedido. É um ticket que cria as suas tarefas no momento em que é submetido, e cada tarefa torna-se um ticket próprio na equipa que a trata.

Um pedido não é uma segunda coisa para manter. Vive num modelo de ticket: em «Settings → Request workflows» encontras todos os modelos de ticket e ligas as tarefas a um deles.

Para cada tarefa preenches alguns campos. «Task» é o nome que quem pede lê, «Handled by» é a equipa que a recebe, e «Ticket title» e «What the team has to do» preenchem o ticket que daí resulta.

Várias tarefas podem apontar para a mesma equipa. Essa equipa recebe então vários tickets, não um ticket com uma lista lá dentro.

Uma tarefa sem equipa não é sequer oferecida. O próprio campo o diz: «Not assigned yet — this task is not offered». Assim podes guardar um plano que ainda não está pronto.

Por cima das tarefas está uma frase que resume o plano inteiro: o que é criado de origem, quanto quem pede pode alterar e quem dá a libertação. Muda uma definição e a frase reescreve-se sozinha.

Antes de «Ticket title» está o texto fixo «Parent ticket title -». O novo ticket começa com o título do pedido, seguido do teu título, por exemplo «New colleague in accounting - Set up notebook and docking station». Assim, a equipa especializada vê a que pedido pertence uma tarefa. Se deixares o campo vazio, segue-se em vez disso o nome da tarefa.

«Main category» e «Subcategory» preenchem previamente a categoria do novo ticket. Só recebes as categorias da equipa em «Handled by», porque é aí que o ticket é criado. Se mudares a equipa, os dois campos são limpos. Defines os dois ou nenhum, e se ficarem vazios o ticket é criado sem categoria.

O nome do pedido está por cima das tarefas. Com o lápis ao lado dele, mudas-lhe o nome. O nome pertence ao modelo de ticket, por isso também muda em «Settings → Templates» e no formulário de novo ticket.

Quando alguém escolhe o modelo no formulário de novo ticket, aparece a caixa «What is needed?» com uma linha para assinalar por cada tarefa.

Há três tipos, definidos por tarefa. «Selectable, off by default» começa vazia, «Selectable, on by default» começa assinalada e pode ser desmarcada, e «Always — cannot be deselected» corre sempre.

Uma tarefa que corre sempre continua a ser mostrada, marcada com «(always included)». Quem pede deve ver o que acontece de qualquer forma.

Por baixo da caixa lês o que daí resulta: «Each selected item becomes its own ticket for the team that handles it.»

Um cliente também pode submeter um pedido, desde que o modelo esteja libertado para clientes. O interruptor para isso está no modelo.

O cliente vê então apenas o seu pedido. Os tickets nas equipas especializadas ficam escondidos dele, embora tenham nascido do pedido dele — esses tickets contêm credenciais e notas internas. As notas internas deles também não aparecem no histórico do pedido. Quando uma equipa especializada fecha o seu ticket, os anexos dele são copiados para o pedido com o selo «Internal», e o cliente não os vê nem os transfere.

Se um pedido chega por e-mail, torna-se um ticket comum. Nesse caso, inicias o fluxo de trabalho depois. É o botão «Start workflow» no cabeçalho do ticket que faz isso.

Na janela escolhes o modelo certo em «Template». Por baixo aparece a mesma caixa «What is needed?» do formulário de novo ticket. Assinala o que o pedido solicita.

Em «Title» ajustas o título do ticket. Os títulos das tarefas começam por ele. Mais abaixo encontras os campos adicionais do modelo. Introduz aí os dados do pedido. Os campos obrigatórios têm uma estrela.

Com «Start» as tarefas são criadas tal como num pedido feito pelo formulário. Se o modelo precisar de uma aprovação, o ticket e as suas tarefas ficam bloqueados até ela ser dada.

Em cada ticket só se pode iniciar um fluxo de trabalho. Depois disso, o botão desaparece. Também falta nos tickets fechados e nos tickets que são eles próprios uma tarefa. Qualquer pessoa que possa trabalhar no ticket pode iniciá-lo.

No próprio pedido, as tarefas estão listadas em «Workflow tasks», com a contagem ao lado, por exemplo «1 of 4 done».

Cada linha mostra o nome da tarefa, o número do seu ticket, a equipa e quem é o responsável, e o nome é uma ligação para esse ticket.

«Done» vem do estado do ticket, não de um visto à parte. O que conta como fechado na lista de tickets conta como concluído aqui — duas maneiras de contar a mesma coisa acabariam mais cedo ou mais tarde por divergir.

O bloco só aparece num pedido. Um ticket normal não o mostra.

Quando uma equipa especializada fecha o seu ticket, o seu «Closing comment» chega ao pedido. Fica lá como nota interna, e a primeira linha indica o número e o nome da tarefa. O cliente não vê esta nota.

As credenciais e tudo o que o agente do pedido deve transmitir pertencem ao comentário de fecho. Todos os outros comentários da equipa especializada ficam no ticket dela. Se a equipa fechar sem comentário, não é criada nenhuma nota.

Uma aprovação abrange todo o pedido, não cada tarefa. Oito aplicações são uma mensagem para a chefia, não oito.

Isto configura-se em «Approvals», no mesmo plano, e a frase por cima enuncia a regra: «One approval covers the whole request. Add a second stage only when single tasks need their own release.» Cada fase tem cinco campos: «Name» é o nome da fase, «Covers» diz a que se aplica, «Decided by» diz de onde vem quem aprova, «Approver» contém a pessoa, e «Remind after (hours)» define o lembrete.

Quem aprova não precisa de conta no sistema de tickets: introduzes um endereço de e-mail e a decisão é tomada através de uma ligação. Uma chefia que aprova duas vezes por trimestre não custa, por isso, nenhum lugar de agente.

A mensagem contém exatamente uma ligação para uma página. De propósito, não há botões de aprovar ou recusar na própria mensagem: um antivírus que abrisse todas as ligações estaria a aprovar.

A página tem como título o nome da fase. Mostra o número e o título do pedido, quem pediu, e em «This decision covers» as tarefas a que a decisão diz respeito, com um campo de comentário e os dois botões por baixo.

A ligação não dura para sempre, e a página indica o prazo: «Please decide by …». É válida durante 14 dias. Depois disso, a página só diz que a ligação é inválida ou expirou, e um administrador volta a enviar o pedido com «Reassign».

Uma decisão não pode ser retirada e, depois, a página di-lo: «A decision cannot be changed.»

Algumas tarefas precisam de uma libertação própria. O acesso a partir do exterior não é a mesma coisa que um portátil.

Para isso acrescentas uma segunda fase e escolhe-la na tarefa, em «Extra approval». Enquanto disser «None — the request approval is enough», basta a libertação do pedido. As duas fases são perguntadas ao mesmo tempo, não uma depois da outra. Uma fase só é perguntada se uma das tarefas escolhidas lhe disser respeito. A fase do pedido inteiro é sempre perguntada.

Uma tarefa é libertada quando todas as fases que lhe dizem respeito tiverem concordado. Uma tarefa sem fase própria arranca logo, a menos que a fase do pedido inteiro ainda esteja à espera. Nesse caso arranca assim que o pedido for aprovado.

Até lá a tarefa está bloqueada. O ticket dela fica em «Waiting for approval» e não tem responsável. Em vez de botões de estado, o cartão diz «This ticket is waiting for approval and cannot be worked on yet.» Antes disso, nenhum caminho lhe dá um responsável.

O bloqueio vale também para as ações em massa na lista de tickets. Seleciona lá um ticket destes e lês o motivo: «This ticket is waiting for approval and cannot be worked on yet.»

O ticket é criado à mesma de imediato, para que a equipa especializada veja o que aí vem e ninguém tenha de ficar de olho no pedido.

Podes definir um lembrete por fase, indicado em horas.

Se não vier resposta, a mesma mensagem sai outra vez ao fim desse tempo, com a mesma ligação da primeira. Quem tiver guardado a primeira mensagem pode continuar a usá-la.

Sem lembrete, o pedido limita-se a esperar, sem voltar a perguntar.

O que não existe é uma libertação por decurso do prazo. Por baixo do campo está escrito por palavras: «A request is never approved automatically. If nobody reacts, it keeps waiting.» Um prazo que concordasse sozinho não seria uma aprovação, seria uma formalidade.

Recusar exige um motivo. Sem texto, a página não aceita a recusa.

O campo diz para onde vai o texto: «Comment (required when you reject — the requester will see it)». Uma nota interna não pertence aqui.

Quem pediu recebe um e-mail com o motivo e não tem de perguntar porque é que nada avança.

Aprovar não precisa de motivo. É o resultado esperado.

Se apenas uma segunda fase recusar, a recusa diz respeito apenas às tarefas dessa fase. O resto do pedido continua.

Uma tarefa recusada fica com o estado «Rejected» e conta como terminada, para que o pedido não fique pendurado para sempre em algo que nunca vai chegar.

Assim que o pedido é recusado, as outras pessoas que aprovam deixam de receber mensagens. A ligação delas diz então «This request has already been rejected. Your decision is no longer needed.» Na lista do ticket, a fase delas mostra «No longer needed: the request was rejected.»

No pedido, «Approvals» mostra uma linha por fase com quem aprova, o estado e, num pedido em aberto, há quanto tempo está à espera.

Depois da decisão, a linha mostra quando foi tomada e com que comentário. É esse o rasto de auditoria, e fica com o caso.

Se quem aprova estiver de férias, um administrador passa o pedido para outro endereço. O botão chama-se «Reassign» e só aparece enquanto o pedido estiver em aberto.

Só um administrador o pode fazer. Um agente que pudesse reatribuir poderia reatribuir a si próprio e depois decidir.

A reatribuição cria uma ligação nova, e a antiga morre de imediato — mesmo que alguém a tenha reencaminhado.

A própria passagem aparece na mesma lista: quem a fez, quando, de quem para quem.

Ninguém pode decidir em nome de outra pessoa. A ligação é o único caminho, e quem a recebeu fica registado no caso.