24. Portal, caso e ciclo de vida

O site de quem pede, a fila de quem atende, a matriz que diz o que a plataforma aceita e as regras que agem sobre o caso.

`/portal`, e não uma aba do produto.

A separação não é estética. Quem abre um chamado trabalha na empresa, não é auditor: entrar no produto para pedir ajuda significa atravessar um menu de auditorias, riscos e não conformidades que não lhe diz respeito e no qual ele não tem o que fazer. Uma barra lateral de portas trancadas faz a pessoa concluir que errou de lugar — e o que ela faz então é telefonar. O chamado que nasce de um telefonema nasce sem registro.

O portal tem endereço próprio, pacote próprio e tela própria: cabeçalho, seletor de tema, seletor de tamanho de texto, e nada mais. A autenticação continua sendo a mesma — o mesmo servidor, o mesmo cadastro de pessoas. Identidade separada seria um segundo cadastro de usuários para manter, e um segundo lugar onde alguém esquece de remover quem saiu da organização.

A aba Pedir ajuda continua existindo dentro do produto, como atalho para quem já está lá. É o mesmo componente, e não uma segunda implementação.

O portal é a casa de quem trabalha na organização, e não só de quem pede ajuda. As abas:

Cada aba aparece só para quem tem a permissão. O Solicitante (quem entra pelo login da empresa) tem a ajuda, os chamados, a leitura e a pergunta à base; a análise de aderência é do Colaborador (quem entra por convite), que também responde auditoria no /responder. Ler, perguntar e analisar a aderência não consomem licença por si (D11); o que consome é o perfil — o Colaborador ocupa vaga de Analista, porque responde auditoria. O custo da IA fica contido pela cota diária por pessoa. As mesmas telas continuam no menu do produto (Acervo), para o auditor e o gestor.

As três compartilham o mesmo login — o mesmo servidor, o mesmo cadastro de pessoas. Identidade separada seria um segundo cadastro de usuários para manter, e um segundo lugar onde alguém esquece de remover quem saiu da organização.

Quando o tenant configurou o próprio provedor de identidade (Integração com o diretório), a entrada do portal e do /responder mostra Entrar pelo provedor da organização, acima do login e senha. É o provedor do tenant daquele endereço, o mesmo da plataforma, e a volta dele cai de novo no site de onde a pessoa saiu, e não na plataforma. Com o tenant em "só o login da empresa", o formulário de senha some e fica só o botão.

E se citam: o rodapé de cada uma leva às outras duas, e o rodapé do menu lateral do produto leva às duas de fora. Separadas sem se citarem viram ilhas, e a pessoa que precisa da outra volta a perguntar a alguém por onde se entra — que é exatamente o que a separação veio evitar.

Metade do que chega como chamado já está respondida na base de conhecimento. Um portal que abre o formulário primeiro transforma toda dúvida em chamado — e o artigo que resolveria em trinta segundos vira uma fila de dois dias.

A busca do portal é por termo. Quem escreve "não consigo entrar" não encontra um item chamado "Redefinição de senha", porque as palavras não coincidem — e era esse o ponto em que a pessoa desistia do portal.

Quando a busca não acha nada e há o que descrever, aparece Classificar o que eu escrevi: a plataforma lê a descrição e diz onde aquilo se encaixa.

•     Com catálogo cadastrado, o modelo escolhe dentro do que existe. Não inventa galho novo: um catálogo que cresce sozinho a cada chamado deixa de ser catálogo em um mês, e a fila de atendimento passa a ter trezentas categorias com um caso cada.

•     Sem catálogo — que é o estado de fábrica —, ele propõe um trio novo: serviço, categoria e subcategoria. É o único modo em que ele escreve no catálogo, e mesmo assim só depois de alguém com permissão de administrar aceitar.

•     "Nenhuma serve" é uma resposta legítima, e a tela a mostra como tal. Um chamado mal classificado vai para a fila errada e espera lá; um palpite classificado parece uma decisão.

A sugestão não abre o chamado e não se aplica sozinha. Ela vem com o nome do modelo e o grau de confiança, e quem confirma é quem pediu — sugestão aplicada sem confirmação é decisão sem autor, e quando erra não há a quem perguntar por quê.

A classificação exige um modelo de linguagem ativo em Administração ▸ Modelo de linguagem. Sem ele, a tela diz isso em vez de falhar em silêncio.

A tela Casos é a fila de quem atende. Filtre por Estado, Prioridade, Buscar (número ou título) e só os meus; a barra de cada linha diz qual relógio corre e quanto dele já passou.

1.     Para registrar, clique em Abrir caso. Preencha O que aconteceu (obrigatório), Detalhe, Item do catálogo (ou sem item — o atendente classifica), Impacto e Urgência. Marque Envolve dado pessoal quando for o caso: eleva a prioridade e aciona o prazo legal. Clique em abrir.

2.     Clique no caso. No topo ficam os Relógios do acordo; abaixo, as abas Trabalho, Vínculos e Linha do tempo.

3.     Em Responder, escreva e clique em Responder ao solicitante — é o que cumpre o relógio de primeira resposta — ou em Nota interna, que o solicitante não vê.

4.     Em Tarefas, clique em concluir em cada uma. As obrigatórias aparecem marcadas.

5.     Em Mover o caso, os botões são as situações para onde o ciclo de vida deixa ir; algumas pedem motivo.

6.     Para fechar, clique em Encerrar com causa: escolha a Categoria de causa, escreva a Solução aplicada (obrigatória) e, se houve, a Solução de contorno. Clique em encerrar.

A prioridade sai da matriz da política (impacto × urgência); quando algo a eleva, o caso diz de quanto e por quê.

Para ligar o caso a um objeto de governança, na aba Vínculos:

1.     Clique em Vincular a um registro.

2.     Escolha o Tipo de registro — risco, não conformidade, controle, ativo (alvo), processo, auditoria, política, oportunidade, plano de ação ou outro caso — e a Relação. Para risco, a relação padrão é materializa: o caso conta como ocorrência do risco e entra no histórico de frequência da reavaliação. Materializa só existe para risco, e duplica só para outro caso.

3.     Busque pelo número ou pelo título e clique no registro. O vínculo aparece na lista, com o nome do registro, e a prioridade é recalculada — vínculo com risco de criticidade alta ou com contrato sobe um degrau.

4.     Para desfazer, clique no x do vínculo e confirme em Desfazer vínculo. A linha do tempo registra a remoção, e a prioridade é recalculada sem ele.

Vincular e desfazer pedem a permissão de atender caso. Os vínculos criados por regra ("Vincular a um registro", em Regras de atendimento) aparecem na mesma lista.

Tratamento ▸ Ciclo de vida do caso (pede a permissão de administrar casos).

1.     Escolha o tipo: Incidente, Requisição, Problema, Incidente maior ou Ocorrência.

2.     Na matriz, cada linha é a situação de origem e cada coluna a de destino. Clique na célula para ligar ou desligar a transição.

3.     Clique em Gravar o ciclo. O botão fica desligado enquanto nada mudou ou enquanto algum status ficaria sem saída.

A plataforma nasce com nove situações por tipo de caso — incidente, requisição, problema, incidente maior e ocorrência — e com o desenho de fábrica de o que liga cada uma às outras.

A tela é uma matriz, e não uma lista de transições. A diferença não é estética: numa lista, "de Resolvido não se volta para Novo" é uma linha que não existe, e o que não existe não se vê. Na matriz é uma célula vazia — que se vê, e que se clica para mudar de ideia.

O que não estiver marcado a plataforma recusa. É isso que impede um chamado de encerrar sem que ninguém o tenha olhado.

As regras do desenho de fábrica

O que a gravação recusa

Três incoerências, e a recusa é deliberada. Uma máquina de estados incoerente não quebra nada no momento em que é gravada: ela quebra semanas depois, quando um caso entra num status de onde não sai, e o que se vê então é um chamado parado que ninguém entende.

•     transição de um status para ele mesmo;

•     saída a partir de um estado terminal;

•     status sem nenhuma saída — a tela avisa enquanto você edita, e não só ao gravar, porque descobrir isso no fim faria você refazer a matriz inteira para achar a linha vazia.

Voltar ao de fábrica apaga o seu desenho. A linha de fábrica fica intacta o tempo todo, e é por isso que voltar sempre funciona.

Em Tratamento ▸ Regras de atendimento (pede a permissão de administrar casos), a regra se monta escolhendo, e não escrevendo JSON:

1.     Clique em Nova regra. Preencha Nome, Descrição, Gatilho e Ordem.

2.     Em Condição, clique em Adicionar condição para cada linha e escolha em Vale quando se valem todas as linhas ou qualquer uma.

3.     Em Ação, escolha O que fazer e preencha os parâmetros que aparecem.

4.     Deixe Ativa e Só simular (não age sobre o caso) marcadas enquanto testa. Clique em Gravar.

5.     Na lista, clique em Ensaiar, escolha o Caso e clique em Rodar sem executar. O botão Conferir em … leva ao lugar onde o efeito apareceria.

6.     Satisfeito, abra a regra (Editar), desmarque Só simular e grave.

Varrer agora roda na hora a varredura do tempo que a plataforma faz sozinha a cada cinco minutos. Remover, dentro do editor, pergunta antes de apagar a regra: o log de disparos dela sai junto, e o que ela já fez nos casos fica no histórico de cada um. Para só pausar, desmarque Ativa. O que cada regra fez aparece na coluna Disparos, ao lado da lista.

O que cada parte faz:

•     Gatilho — quando a regra é avaliada: o caso nasce, muda, encosta no prazo ou para de andar.

•     Condição — linhas de campo, operador e valor. Os campos com valores conhecidos (prioridade, impacto, urgência, nível, tipo, estado) oferecem a lista; os demais aceitam texto. Escolha se valem todas as linhas ou qualquer uma. Sem linha, a regra vale para todo caso do gatilho.

•     Ação — o que fazer: notificar, atribuir, alterar um campo, mudar o status, criar tarefa, escalonar ou vincular. Cada ação mostra só os parâmetros dela (para quem notificar, por qual modo atribuir, qual campo e valor, e assim por diante).

A regra continua gravada no mesmo formato de antes, e o JSON segue disponível em Editar como JSON (avançado). Uma regra antiga com grupos aninhados (um "e" dentro de um "ou") abre direto no modo avançado, com um aviso: o formulário não a mostraria inteira, e abrir num formulário que a achatasse mudaria o que ela faz.

Antes ele terminava em "notificaria ATENDENTE sobre INC-2026-000015" e parava ali, deixando duas perguntas sem resposta — onde eu confiro? e o que eu devo ver? — cuja única saída era disparar de verdade e procurar. Ensaio que obriga a executar para ser entendido não é ensaio.

Agora cada ensaio devolve três coisas: a página onde o registro muda, o link para ela já apontado ao caso, e uma frase no futuro dizendo o que aparece lá.

O ensaio avisa antes quando a ação dispararia sem fazer nada. O caso de sempre: a regra avisa o atendente, e o caso ainda não tem atendente — ela dispara, registra o disparo e não avisa ninguém. Era exatamente isto que se via como "ficou disparando e nada aconteceu".

Quando acontece de verdade, o disparo não fica gravado como sucesso. A linha antiga dizia que a regra agiu, e quem investigava acreditava no log.

Três gatilhos não dependem de ninguém agir — percentual de SLA, prazo e inatividade — e a condição deles continua verdadeira enquanto o caso fica parado. Sem memória, a varredura de cinco em cinco minutos redisparava a mesma regra sobre o mesmo caso indefinidamente: dois casos chegaram a 388 disparos cada em dois dias. Em simulação isso enche o log; ligada, seriam 388 e-mails para a mesma pessoa sobre o mesmo chamado — e o que a organização faz com isso é desligar a automação inteira.

A memória é o movimento do caso, e não um intervalo fixo: assim que alguém interage, o aviso volta a poder sair. Um intervalo fixo silenciaria o aviso de um caso que acabou de mudar de mão, que é justamente quando ele importa.

O ensaio mostra quantas vezes aquela regra já disparou sobre aquele caso. Número alto é quase sempre condição que nunca deixa de ser verdadeira.