Casos de uso de automação

Configuração · Automação · 9.2.2

Os blocos de construção estão na página Automações e as opções de fluxo em Automações avançadas. Esta página junta tudo: seis processos completos que pode reconstruir no seu próprio tenant, de um único acionador até ao último e-mail. Cada um está escrito como a lista de passos que introduziria no Editor, com o desenho por baixo exatamente como a vista Diagrama o desenha; reconstrua a regra e deverá reconhecer a imagem.

Uma dica prática antes de começar: construa a regra toda enquanto ela ainda está inativa, faça uma execução de teste contra um registo real e só depois a ligue. Todos os processos abaixo sobrevivem a esse teste.

1. Acolhimento de um novo colaborador entre o IT, o RH, as Instalações e a Segurança

O clássico processo entre departamentos. Vem um novo colega; o IT tem de preparar contas e um portátil, o RH tem de fechar a papelada, as Instalações têm de arranjar um cartão de acesso e um posto de trabalho, a Segurança tem de resolver os direitos de acesso e as autorizações. Ninguém deve esperar por outra pessoa onde não é preciso, e o gestor deve ouvir falar disto exatamente uma vez: no momento em que tudo está pronto.

Configuração: um modelo de ticket “Novo colaborador” com campos personalizados para a data de início, o departamento e o gestor. A regra corre em tickets, acionador Criado, condição: modelo igual a Novo colaborador, para que um ticket aberto a partir de outro modelo nunca arranque o processo.

Todos veem o plano completo desde o primeiro minuto: as tarefas abaixo das esperas existem de imediato como tarefas pendentes no ticket, subtarefas incluídas, só não podem ser concluídas antes da sua vez. Os quatro departamentos trabalham em paralelo, cada faixa empurra a sua própria equipa depois de cinco dias, e o gestor recebe exatamente um e-mail, no momento em que a última tarefa fica feita.

Três variações que vale a pena considerar. Acrescente uma espera por um momento concreto ancorada três dias antes do campo da data de início, à frente de uma mensagem de boas-vindas ao novo colaborador: um ponto de contacto que deve cair na agenda fica atrás de um momento, enquanto a confirmação acima sai, e bem, no momento em que o trabalho fica feito. Troque a espera única de uma faixa por um ramo por registo quando quiser insistir individualmente com a pessoa atribuída a cada tarefa em vez da faixa como um todo. E para a saída de um colaborador, construa a imagem espelhada: as mesmas quatro faixas, mas em que as tarefas revogam em vez de preparar, e em que o último passo é uma ação Anonimizar registo, segundo um agendamento, depois do período de retenção.

2. Aprovação de uma compra

Um pedido de serviço acima de um limite precisa do sim de um gestor antes de alguém encomendar o que for. A resposta ainda não existe quando a regra dispara, por isso isto é uma espera por uma alteração num registo, não uma condição.

Configuração: a regra corre em tickets, acionador Criado, condições: tipo igual a Pedido de compra E valor (campo personalizado) maior que 500.

O padrão generaliza-se a qualquer aprovação: assinatura de um contrato, revisão de conteúdos, pedidos de acesso. A espera transporta a pergunta, os critérios de libertação definem o “sim”, o caminho de parada define o “não”, e o limite de tempo define o “demasiado lento”.

3. Uma escada de taxas de cancelamento

Preços por níveis é aquilo para que serve a definição Executar apenas a primeira ação correspondente: os passos passam a ser uma escada e ganha o primeiro que corresponda. Esta cobra os cancelamentos tardios de uma reserva de sala.

Configuração: a regra corre em reservas de sala, acionador Atualizado a observar o campo de cancelamento, condição: cancelada alterado para sim. Definição da regra: executar apenas a primeira ação correspondente.

Ordene os degraus do mais estreito para o mais amplo: a escada para na primeira correspondência, por isso “menos de 48 horas” tem de ficar acima de “menos de uma semana”. O preço é sempre calculado a partir do preço base da linha, nunca a partir do seu preço atual, por isso uma regra que dispare duas vezes não pode acumular a taxa, e um preço que alguém alterou à mão nunca é tocado. Esta escada vem como o modelo “Taxa de cancelamento tardio”, para que possa partir de uma cópia que funciona.

4. Opinião sem spam

Duas regras pequenas que, juntas, mantêm um fluxo de opiniões constante e sem ruído.

Depois de cada reserva: regra em reservas, acionador Antes ou depois de uma data, uma hora depois da data de fim. Um passo: enviar e-mail ao organizador com o formulário de opinião. Limite de execução: uma vez por registo, para que uma reserva reagendada não pergunte duas vezes.

A cada décimo ticket fechado: regra em tickets, acionador Atualizado a observar o estado, condição: estado alterado para um estado fechado. Limite de execução: a cada N vezes com N igual a 10. Um passo: enviar e-mail a pedir uma avaliação. O contador vive na regra, por isso é de toda a empresa: pergunta a cada décimo fecho, seja quem for a fechar.

O limite de execução é o que faz o verdadeiro trabalho nas duas regras. As execuções ignoradas aparecem no histórico como tal, para que possa verificar a cadência em vez de a adivinhar.

5. Retenção segundo o RGPD

Os dados pessoais têm de desaparecer quando a sua finalidade termina, e por política em vez de por memória. As ações de conformidade mais um acionador segundo um agendamento fazem da retenção uma regra que pode mostrar a um auditor.

Configuração: a regra corre em visitantes, acionador Segundo um agendamento, semanalmente na noite de domingo. Condições: data de fim da visita há mais de 180 dias.

Aqui contam duas propriedades. As ações de conformidade voltam a verificar as permissões do autor da regra no momento da execução, por isso uma regra que sobreviva aos direitos do seu autor ignora em vez de eliminar. E cada passagem escreve histórico de execução, que é precisamente a prova de que uma política de retenção precisa. Use Eliminar registo em vez de Anonimizar onde não pode ficar absolutamente nada, e prefira a eliminação reversível a não ser que a política exija a definitiva.

6. Uma primeira resposta da IA em cada ticket

Um ticket que chega às 02:00 já teve o seu primeiro tratamento às 02:01. A ação Acionar a IA coloca um agente à porta de entrada do service desk: cada ticket novo é lido, resumido, classificado e recebe um rascunho de resposta antes de um colega o abrir.

Configuração: a regra corre em tickets, acionador Criado, sem condições: cada participação conta. O modelo “Resumo de IA nos tickets novos” é o ponto de partida que já funciona.

O parceiro de escalagem é uma segunda regra pequena ao lado desta: em tickets, acionador Atualizado a observar a prioridade, condição: prioridade alterada para Crítica. Um passo: enviar mensagem de chat ao grupo de trabalho de piquete no Teams ou no Google Chat. A regra observa o registo, não o autor da alteração, por isso dispara seja quem for a subir a prioridade: um colega, ou a IA quando corre um caso de uso de classificação que a define.

A fronteira é deliberada: o agente trabalha dentro do Gfacility. Lê, resume, classifica, escreve rascunhos e encaminha; as mãos no teclado continuam a ser humanas. E é exatamente isso que quer às 02:00: quem pega no ticket às 08:30 começa com um resumo, um passo seguinte sugerido e uma resposta pronta a sair, e só o que se revelou mesmo crítico foi logo comunicado à equipa de piquete. O que um agente consegue fazer e como configurar casos de uso está em Casos de uso de IA.