--- title: 24. Portal, caso e ciclo de vida slug: 24-portal-caso-e-ciclo-de-vida docTags: createdAt: 2026-10-13T14:41:54.093Z --- *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.* *** ### O portal é outro endereço **\`/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 que o colaborador faz no portal O portal é a casa de quem trabalha na organização, e não só de quem pede ajuda. As abas: | **aba** | **o que é** | **pede** | | ------------------------- | ---------------------------------------------------------------------------------- | -------------------------------------- | | **Preciso de ajuda** | procurar no catálogo e na base; se não resolver, abrir o chamado | `caso:abrir` | | **Leitura obrigatória** | os documentos que a organização pede que você leia; a ciência fica ligada à versão | `documento:ler` | | **Pesquisar e perguntar** | procurar documentos do acervo, ou perguntar à base em linguagem natural | `documento:ler`, `documento:perguntar` | | **Análise de aderência** | trazer um documento e ver se ele atende às normas marcadas; nada é guardado | `documento:analisar` | | **Meus chamados** | acompanhar os próprios chamados | `caso:abrir` | 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. *** ### São três páginas, e elas se citam | **Endereço** | **Quem entra** | **O que faz** | | ------------ | ---------------------------- | ----------------------------------------------- | | / | auditor, gestor | conduz auditorias, trata achados, monta painéis | | /responder | a área ou equipe avaliada | responde as perguntas que lhe foram despachadas | | /portal | quem precisa de alguma coisa | procura na base de conhecimento e abre chamado | 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. *** ### O artigo vem antes do formulário 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. *** ### Quando a palavra não acha, a descrição acha 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. *** ### Casos — abrir, atender e encerrar 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. *** ### O ciclo de vida do caso é seu **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* | **Regra** | **Por quê** | | -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | de **Novo** só se vai para triagem, atendimento ou cancelado | encerrar um caso que ninguém olhou é a forma mais comum de fila limpa mentindo sobre trabalho feito | | os três **"aguardando"** voltam para atendimento, e não para triagem | o caso já foi triado; refazê‑lo joga fora a decisão de quem triou | | **Resolvido** reabre para atendimento | resolver é uma afirmação sobre o problema, e quem abriu pode discordar | | **Encerrado** e **Cancelado** não saem | um estado terminal do qual se sai não é terminal: é um estado intermediário com nome de fim, e todo indicador que conta "encerrados" passa a contar o que voltou | *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. *** ### Regras de atendimento: condição e ação em listas 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. *** ### O ensaio diz onde conferir e o que esperar 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á. | **Ação** | **Onde conferir** | **O que esperar** | | -------------- | ----------------- | ---------------------------------------------------------------------------------------------------------------- | | Notificar | Avisos | um aviso novo para o destinatário, com aquele assunto; sai também por e-mail se a conta estiver configurada | | Atribuir | o caso | o campo Atendente deixa de estar vazio e o relógio de atribuição para | | Alterar campo | o caso | o campo passa a valer aquilo, e a troca entra no histórico com o nome da regra | | Alterar status | o caso | o caso vai para aquele status — se a transição não existir no ciclo de vida, a regra falha e a falha fica no log | | Criar tarefa | o caso | uma tarefa nova, pendente e sem dono | | Escalar | o caso | um escalonamento registrado e um aviso a quem a matriz da política aponta | | Vincular | o caso | um vínculo novo, visível nos dois lados | *** ### "Ao disparar, nada mudaria" 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. *** ### Uma regra de tempo não se repete com o caso parado 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.