Hub IT / ITSM

Objetivo e mapa do hub

O Hub IT é o centro operacional de IT segundo o framework ITIL. A partir daqui chegas à consola operacional do service desk e do NOC, à gestão de incidents, pedidos, problems e changes, à Knowledge Base, aos dashboards e aos relatórios. É a ferramenta diária dos operadores (L1/L2/L3), dos team leaders e dos gestores de IT, e o ponto de acesso às vistas de direção de serviço.

Esta página está organizada em fichas: primeiro as páginas do hub (a landing, a consola operacional, Change, Problem, Major Incident, Knowledge Base, Voicemail), depois os modais transversais usados nos tickets (Editor, Composer, Inspector, Taxonomias, Notas internas, Anexos, Ligações, Ações em massa, Playbook, KB, Dashboard, Controlo de Qualidade, Dados Históricos). As páginas ITOM, Events&AIOps, Operations Cockpit, IT Report Center e Customer Service são referidas aqui, mas descritas nas respetivas páginas.

Landing do Hub IT

Para que serve. É a página de entrada do hub: apresenta as ações rápidas do hub e os painéis (tiles) para as páginas operacionais, de direção e de relatórios.

Quando a usar. No início da sessão de IT, para escolheres a área em que vais trabalhar, ou para lançares as ações transversais (KB, CMDB, Controlo de Qualidade, Taxonomias).

Como a abrir. A partir da Home do Core (painel IT Hub) ou da barra de ferramentas «IT Hub» presente nas páginas do hub.

O que mostra. No cabeçalho, uma hero strip com o título «IT Hub — Centro operativo IT · Network Operations · Service Desk · Operations & ITSM» e as ações rápidas do hub:

• Knowledge Base — abre a KB do domínio IT.
• CMDB / Assets — abre a CMDB centralizada.
• Dados Históricos — abre o modal dos dados arquivados (cold store); exige um cliente selecionado (ver Dados Históricos).
• Controlo de Qualidade — visível para os papéis autorizados; abre a revisão de qualidade dos tickets fechados (ver Controlo de Qualidade).
• Taxonomias — visível para os administradores; abre o modal Taxonomias de ticket (Taxonomias de ticket).

Por baixo, os painéis estão agrupados em três secções:

Operação (CORE) — três painéis principais:

• NOC · Network Operations — fila operacional com filtro de tier L1/L2/L3: monitorização, triagem, investigação, escalada.
• Service Desk · Assistência e pedidos — fila do service desk com filtro de tier L1/L2/L3: triagem, reset, incident/problem, catálogo. (O domínio interno continua a ser OPS.)
• Customer Service · grupos por cliente — tickets CS-* nos grupos dedicados do cliente (Customer Service, Enterprise Service e ICC).

Direção de serviços — três cockpits (visíveis para os papéis de gestor/diretor, *:MGR):

• NOC Service Director — P1/War Room live, SLA por cliente, cobertura do turno, escaladas, broadcast à equipa.
• Service Desk Director — FCR, AHT, volumes por canal, CSAT, tempos de fila, desempenho dos analistas.
• Customer Service Director — direção da linha de clientes sobre os grupos por cliente.

Ferramentas operacionais e Reporting — painéis compactos: ITOM, Events & AIOps, Problem Management, Change Management, IT Operations Dashboard, IT Report Center, Voicemail.

Cada painel mostra ícone, badge de estado (LIVE/NEW/…) e uma linha de features (as tags das funções principais). No fundo da página está o bottom dock unificado com softphone, chat e presença.

Como se usa. Clicas no painel da área pretendida; as ações rápidas do cabeçalho abrem os respetivos modais/páginas. Os painéis e as ações visíveis dependem do papel (RBAC): a landing filtra os tiles com base nos perfis de acesso do utilizador e no tier pedido.

O que acontece depois. A navegação leva à página/consola escolhida; o estado da sessão (cliente/tenant atual) é propagado às páginas de destino.

Notas. Os KPI do hub foram retirados da landing de propósito: com a vista transversal aos tenants não seriam significativos; as métricas estão nas páginas dedicadas (consola NOC, dashboard de SLA, cockpits).

Consola operacional L1/L2/L3 (NOC e Service Desk)

Para que serve. É a consola de tratamento dos tickets em fila, partilhada pelo NOC e pelo Service Desk através do mesmo motor de layout. Permite monitorizar a fila, selecionar um ticket, ver o seu detalhe e agir com ações rápidas e ferramentas de contexto. Um único ecrã cobre os três níveis (L1/L2/L3) através do filtro de tier.

Quando a usar. É o posto de trabalho do operador durante todo o dia: atribuição, diagnóstico, escalada, resolução.

Como a abrir. A partir da landing IT Hub, painéis NOC ou Service Desk. A consola Problem (Problem Management Console) usa o mesmo layout.

O que mostra. Um layout de três painéis:

1. Fila (esquerda) — a lista dos tickets, com:
   • filtros rápidos: Todos, P1/P2, Meus, Unassigned, + L2/L3;
   • pesquisa por chave, assunto ou CI;
   • atualização automática a cada 60 segundos (com a hora da última atualização e contador).
2. Detalhe (centro) — o ticket selecionado com todos os seus dados; daqui abres o Editor (Editor de ticket) e as ações.
3. Ferramentas (direita) — separadores de contexto que mudam com o tier.

No topo, uma faixa de KPI. Para o NOC L1: Tickets abertos, P1/P2 ativos, SLA breach, MTTR (min), Resolvidos hoje.

As ações rápidas (L1): Assumir (atribuir a mim), Escalate L2/L3 (equipa GRP-NOC_L2), Resolver, Abrir Major Incident (escalada MIM). As ferramentas L1: CI ligados (CMDB explorer), Runbook (KB NOC L1, Playbook de incident), Monitorização (Grafana, Alertmanager), Temporizador de SLA (tempo restante), Dashboard (abre o dashboard de KPI num modal).

Na passagem ao tier L2 mudam os KPI, as ações e as ferramentas: KPI Incidents abertos, P1/P2 abertos, Change window, MTTR, Root-cause pending; ações Take ownership, Escalate L3, Iniciar RCA (5-why + timeline), Abrir Change (RFC → CAB), Escalate MIM; ferramentas RCA workspace (timeline builder, template 5-why), Change mgmt (CAB calendar, nova RFC), Runbook L2/L3.

Em baixo, as ligações a Service Topology e ITOM Health, e o bottom dock com softphone (SIP), chat e presença.

Como se usa. Filtras e pesquisas na fila, selecionas um ticket (detalhe ao centro), ages com as ações rápidas ou abres o Editor para o tratamento completo; as ferramentas da direita dão acesso a CMDB, runbooks, monitorização e SLA. As seleções múltiplas ativam as ações em massa (Ações em massa).

O que acontece depois. «Assumir» atribui o ticket ao operador; «Escalate» passa-o para a equipa superior; «Resolver» fecha-o; «Abrir Major Incident» inicia o workbench MIM (Major Incident Workbench). Cada ação atualiza a fila, os KPI, a timeline e as notificações.

Notas. O filtro de tier e as matrizes de escalada, os nomes das equipas (GRP-NOC_*, GRP-OPS-*) e as filas são geridos centralmente; a atualização automática mantém a fila alinhada sem recarregar a página.

Editor de ticket

É a janela mais usada de todo o exoCortex Core: descrevemo-la em duas secções.

Para que serve, quando e como se abre

Para que serve. O Editor de ticket é o painel (drawer) de tratamento de um único ticket: permite ler todos os seus dados, mudar o estado (transições de workflow), alterar os campos, comentar, gerir anexos e notas internas, consultar SLA, timeline, tickets ligados e o registo de auditoria.

Quando a usar. Sempre que assumes ou atualizas um ticket: atribuição, atualização do progresso, pedido de informações, resolução, fecho.

Como a abrir. Clicando num ticket em qualquer lista (consola operacional, filas, resultados de pesquisa, widgets), ou com o atalho ⌘O (Ctrl+O), que abre um picker onde escreves a chave do ticket.

Característica distintiva — multi-ticket. O Editor gere até 6 tickets abertos ao mesmo tempo, cada um no seu separador (tab) no topo. Passas de um ticket para outro com um clique ou com ⌘Tab. Um separador com alterações por guardar mostra o indicador «sujo» (dirty). Cada ticket fecha-se no «x» do separador.

Modos de visualização. O drawer suporta três modos: ancorado ao lado (side-by-side), em ecrã largo (focus) e minimizado (PIP) em baixo. Esc reduz o drawer (collapse) sem perder o conteúdo.

O que mostra: barra de estado e separadores internos

Por baixo dos separadores dos tickets, uma barra de estado com os atributos-chave e os controlos rápidos: estado atual e botões de transição (confirmação ⌘↵); prioridade (Highest/High/Medium/Low/Lowest); responsável (controlo «Atribuir», que abre o seletor de utilizadores); indicadores de fila/equipa, tipo e chave.

O corpo está organizado em separadores internos:

1. Detalhe — os campos do ticket: assunto, descrição (texto simples), prioridade e os campos personalizados (custom fields) do issue type, carregados do catálogo e editáveis com os restantes. Guardas com ⌘S.
2. Timeline — a cronologia dos eventos (criação, transições, comentários, alterações).
3. Comentários — o histórico dos comentários (autor, data), apresentado em Markdown, com a área de escrita e o botão Enviar comentário (ativo só quando há um rascunho).
4. SLA — os SLA associados com contagem decrescente em tempo real.
5. Linked — os objetos ligados (tickets, chamadas, chats, links) com data e origem; adicionas novos com o Link Picker (Ligar tickets).
6. Anexos — a lista dos ficheiros com Visualizar, Descarregar, Eliminar e carregamento; os anexos são imutáveis (para «alterar», eliminas e voltas a carregar).
7. Notas internas — anotações reservadas à equipa (Notas internas).
8. Audit — a timeline do lifecycle.
9. Postmortem — a ficha de post-incident review, para os tipos que a preveem (Major Incident, SOC Incident).

Quando o ticket diz respeito a um CI/host, está disponível a Consola PAM (acesso privilegiado zero-knowledge ao sistema).

Como se usa e o que acontece depois

• Mudar o estado: escolhes a transição; o workflow avança, a timeline regista o evento e disparam notificações e automatizações (atribuições, SLA, escaladas).
• Alterar os campos: editas no separador Detalhe e guardas com ⌘S; as alterações são enviadas em bloco. A descrição e os comentários estão em texto simples (single source): o que escreves é o que fica guardado e é lido de volta.
• Comentar: escreves no separador Comentários e envias; o comentário entra no histórico e gera notificações segundo a matriz de notificação.
• Gerir anexos / atribuir: nos respetivos separadores/controlos.

Atalhos: ⌘O abrir picker · ⌘S guardar · ⌘↵ transição · Esc reduzir · ⌘Tab ticket seguinte.

Notas. As ações disponíveis (transições, alteração de campos, eliminação de anexos, visibilidade das notas internas) dependem das permissões do papel. O separador Postmortem só aparece para os tipos que o preveem.

Composer, criação de tickets

Para que serve. É a janela de criação de um novo ticket pelo operador (em nome de um utilizador/cliente ou na sequência de uma chamada/chat).

Quando a usar. Na abertura de um novo caso: telefonema para o service desk, pedido por chat, alerta a monitorizar, criação manual de incident/request/change.

Como a abrir. No botão de criação das listas/cockpits ou com Ctrl+N. O contexto pode ser herdado de um chat ou telefonema ativo: reporter, assunto, descrição, CI, anexos, incident relacionado, tipo.

O que mostra. Um modal centrado (com modo focus em ecrã largo e PIP em baixo à esquerda), em três passos de revelação progressiva:

1. Identify — projeto/tenant de destino, canal, requerente (reporter).
2. Classify — tipo de ticket (issue type) e domínio (menu filtrado pela secção do domínio), prioridade e categoria.
3. Detail — assunto, descrição, campos específicos, anexos, eventual nota interna inicial.

Cada passo tem um indicador de estado (por fazer/em curso/concluído). Ao lado, o painel AI Copilot: sugestão do título, proposta de prioridade, categorização, deteção de duplicados, artigos de KB e runbooks relevantes.

Como se usa. Preenches os três passos (o tipo determina os campos obrigatórios — Pedidos de serviço). Vários rascunhos: até 5 rascunhos abertos, guardados no servidor e localmente, com gravação automática a cada 3 segundos. Envio com Ctrl+Enter ou no botão: o ticket é criado; a eventual nota interna inicial é adicionada logo a seguir. Atalhos: Ctrl+N novo rascunho · Ctrl+S guardar · Ctrl+Enter enviar · Esc reduzir.

O que acontece depois. O ticket entra no workflow do seu tipo, é encaminhado para a fila/equipa competente segundo as regras de encaminhamento do domínio, e são geradas as notificações. Podes abrir o ticket logo no Editor (Editor de ticket).

Notas. O tenant de destino tem de ser concreto: os valores universais (*, __ALL__) são rejeitados. Sem domínio indicado, não é forçado nenhum tipo predefinido.

Pré-visualização de ticket

Para que serve. Mostra um ticket só de leitura com pré-visualização, impressão e exportação, sem o abrir em edição.

Quando a usar. Para uma consulta rápida, para imprimir ou para copiar a ligação de um ticket a partilhar.

Como a abrir. A partir de listas e widgets, com a ação de pré-visualização.

O que mostra. Os dados do ticket e os comentários: assunto, requerente, estado, prioridade, descrição e histórico de comentários.

Como se usa. Botões de impressão/exportação e Copiar ligação.

O que acontece depois. Nenhuma alteração aos dados (só leitura). Para intervir, passas ao Editor.

Notas. Os comentários são opcionais (se não existirem, a vista continua válida).

Taxonomias de ticket

Para que serve. Define as categorias e subcategorias de serviço usadas pelo Composer para classificar os tickets. É a ferramenta de configuração da taxonomia global.

Quando a usar. Quando o administrador tem de criar/alterar as categorias de classificação dos tickets.

Como a abrir. Na ação Taxonomias da hero da landing IT (visível para os administradores).

O que mostra. A árvore global de Category/Subcategory com as entradas existentes e os controlos de criação/alteração/remoção.

Como se usa. Adicionas ou alteras categorias e subcategorias; estas preenchem o seletor «Tipo/Categoria» do Composer (Composer, criação de tickets) e são usadas para encaminhamento e relatórios.

O que acontece depois. As alterações ficam disponíveis no Composer e nas ferramentas de classificação; as taxonomias são uma fonte única.

Notas. É uma função administrativa.

Notas internas

Para que serve. Gere as anotações reservadas à equipa num ticket, não visíveis para o requerente.

Quando a usar. Para registar informações de tratamento, hipóteses, contactos ou detalhes sensíveis que não devem aparecer na comunicação com o utilizador.

Como a abrir. No separador Notas internas do Editor (Editor de ticket).

O que mostra. A lista das notas internas do ticket com autor e data, e a área para inserir uma nova nota.

Como se usa. Adicionas uma nota; fica visível apenas para os operadores/equipas com permissão.

O que acontece depois. A nota fica registada no ticket (canal separado dos comentários públicos) e contribui para a rastreabilidade interna.

Notas. A visibilidade das notas internas está sujeita às permissões do papel.

Visualizador de anexos

Para que serve. Permite visualizar, imprimir e descarregar os anexos de um ticket sem ter de os descarregar localmente para os abrir.

Quando a usar. Para examinar um ficheiro anexado (imagem, PDF, log) durante o tratamento.

Como a abrir. Na ação Visualizar do separador Anexos do Editor, ou nos pontos onde é mostrado um anexo.

O que mostra. A pré-visualização do ficheiro com os comandos de impressão e download.

Como se usa. Abres o anexo, consulta-lo e, se necessário, imprime-lo ou descarrega-lo.

O que acontece depois. Nenhuma alteração ao ficheiro (os anexos são imutáveis).

Notas. Para «alterar» um anexo, eliminas e carregas uma nova versão.

Ligar tickets

Para que serve. Cria uma ligação entre tickets (relação tipificada: ex. «duplica», «bloqueia», «relacionado»).

Quando a usar. Para relacionar um ticket com outros (incidents com o mesmo problem, pedidos duplicados, dependências).

Como a abrir. No separador Linked do Editor.

O que mostra. O tipo de ligação e um campo de pesquisa do ticket de destino (que exclui o ticket de origem para evitar autoligações) e um comentário opcional.

Como se usa. Escolhes o tipo, pesquisas e selecionas o ticket de destino, confirmas.

O que acontece depois. A ligação é criada e o separador Linked do ticket recarrega e mostra a nova relação.

Notas. O catálogo dos tipos de ligação é uma fonte única; a autoligação é impedida.

Ações em massa

Para que serve. Executa ações sobre vários tickets selecionados de uma só vez: fecho em massa e escalada em massa.

Quando a usar. Para despachar em bloco vários tickets homogéneos (ex. fechar uma série de alertas resolvidos, ou escalar um grupo de tickets para a mesma equipa).

Como a abrir. Selecionando vários tickets na fila/lista e escolhendo a ação em massa.

O que mostra. A lista dos tickets selecionados, a escolha da ação (fechar/escalar) e os parâmetros pedidos (resolução para o fecho, equipa de destino para a escalada — fornecidos pelo contexto, não hardcoded).

Como se usa. Confirmas a ação: fechar fecha os tickets selecionados, escalar passa-os para o nível seguinte. É necessária uma seleção válida.

O que acontece depois. Os tickets são atualizados em bloco; a fila e os KPI recarregam; cada alteração fica registada em auditoria.

Notas. As resoluções e as equipas disponíveis derivam da configuração do tenant.

Playbook launcher

Para que serve. Lista e executa os playbooks/runbooks aplicáveis ao contexto da página ou do ticket.

Quando a usar. Para aplicar um procedimento padronizado (diagnóstico, remediação, comunicação) a um incident ou a um CI.

Como a abrir. Na quick-action Playbook das páginas de gestão ou no ícone registado no bottom dock.

O que mostra. Os playbooks aplicáveis filtrados por domínio e tag e ativos para o tenant, com a possibilidade de fornecer inputs de contexto (ex. CI afetado).

Como se usa. Escolhes um playbook e executa-lo em Dry-run (simulação) ou Executar (execução real), reutilizando a API dos playbooks.

O que acontece depois. A execução produz os seus efeitos (ações automáticas, atualizações ao ticket/CI) e regista o resultado.

Notas. O tenant é o da sessão e não se indica manualmente; as ações sensíveis estão protegidas por barreiras.

Knowledge Base

Para que serve. Pesquisa e consulta os artigos da Knowledge Base diretamente durante o tratamento, para a resolução rápida e o KB-deflection.

Quando a usar. Durante a triagem/diagnóstico, para encontrares um procedimento ou um artigo útil sem saíres da página.

Como a abrir. Na quick-action KB das ferramentas da consola operacional, ou nos pontos que integram a pesquisa na KB.

O que mostra. Um campo de pesquisa e a lista de resultados; ao selecionares um artigo, a vista do artigo com título, metadados e corpo.

Como se usa. Escreves uma query e pesquisas; abres o artigo e consulta-lo; regressas à lista com «voltar».

O que acontece depois. O artigo pode resolver o caso (deflection) ou dar os passos a seguir; a KB alimenta também as sugestões do AI Copilot do Composer.

Notas. O endpoint de pesquisa é canónico; a KB completa gere-se na página dedicada (Knowledge Base).

Dashboard de KPI

Para que serve. Abre em overlay um dashboard editorial de KPI, sem abrir uma página separada.

Quando a usar. Para consultar rapidamente os KPI de uma área (ex. NOC L1 Monitoring) enquanto trabalhas na consola.

Como a abrir. Na quick-action Abrir Dashboard de KPI das ferramentas da consola.

O que mostra. O relatório editorial gerado a partir dos dados reais: KPI, tendências, breakdown.

Como se usa. Abres e consultas os gráficos e os valores; substitui os antigos dashboards separados.

O que acontece depois. Nenhuma alteração aos dados (só leitura); ao fechar, regressas à consola.

Notas. Se o runtime do relatório não estiver disponível, o modal falha de forma explícita (fail-loud), sem dados fictícios.

Change Management

Para que serve. Governa o ciclo de vida dos changes de infraestrutura segundo o ITIL: Standard (pré-aprovado, sem CAB), Normal (aprovação do CAB) e Emergency (aprovação do eCAB), com as janelas de Change Freeze.

Quando a usar. Para registar, avaliar, aprovar e planear as alterações; para gerir as reuniões do CAB e as janelas de bloqueio.

Como a abrir. A partir da landing IT Hub, painel Change Management, ou da consola operacional (ação «Abrir Change» no tier L2).

O que mostra. Uma linha de KPI e quatro separadores:

1. Lista — os changes com estado, tipo, risco, janela e resultado.
2. CAB — a agenda do Change Advisory Board: RFC em discussão, participantes, votos (tipo IT-CAB-MEETING).
3. Calendar Window — o calendário das janelas de alteração (grelha mensal), com a «Window proposta».
4. Audit Trail — o registo das ações sobre os changes.

Como se usa. Crias/avalias um change (RFC), levas o change ao CAB para aprovação, planeias a janela de execução; a partir de cada change abres o Editor para o avanço e o registo das aprovações (Aprovação de change (CAB)).

O que acontece depois. Um Normal Change exige a aprovação do CAB antes da execução; um Emergency segue o percurso do eCAB (aprovação retroativa). Durante um freeze, os changes não podem ser aprovados sem autorização explícita do Change Manager.

Notas. As reuniões do CAB podem ser geradas periodicamente; a ata e o resultado da votação ficam registados no respetivo IT-CAB-MEETING.

Aprovação de change (CAB)

Para que serve. Regista a decisão de aprovação sobre um change (tipicamente um Normal Change em CAB).

Quando a usar. Em sede de CAB/eCAB, quando o change aguarda aprovação e és um dos aprovadores.

Como a abrir. No separador CAB ou no Editor do change (separador Aprovações). É o mesmo modal descrito em Aprovação, aqui aplicado aos changes.

O que mostra e como se usa. A cadeia de aprovação com os passos e o seu estado, e as decisões Aprovar / Rejeitar / Pedir informações / Delegar, com comentário. Se for exigida, a assinatura.

O que acontece depois. A aprovação do último passo permite a execução do change na janela planeada; uma rejeição devolve-o; todas as decisões são notificadas e registadas.

Notas. As regras do CAB/eCAB e os freezes condicionam o resultado (ver Cockpits e vistas de direção/Processos de IT).

Problem Management Console

Para que serve. Gere os problems e a análise das causas raiz (RCA), até aos Known Errors com workaround documentado.

Quando a usar. Quando vários incidents partilham uma causa comum, ou para conduzir uma análise estruturada da causa raiz.

Como a abrir. A partir da landing IT Hub, painel Problem Management.

O que mostra. O layout de fila da consola operacional (KPI, lista com atualização automática a cada 60 s), especializado para os problems, com a ligação ao CAB calendar e aos incidents relacionados. Expõe a RCA (5-why + engine) e a Known Error DB (KEDB).

Como se usa. Abres um problem, conduzes a análise RCA (template 5-why, timeline) e documentas a causa raiz e o workaround; a partir de um problem promoves um Known Error e crias o artigo de KB correspondente.

O que acontece depois. Um Known Error publicado disponibiliza o workaround ao primeiro nível (KB-deflection) e reduz o tempo de resolução dos incidents recorrentes. O template KEDB reúne: Sintoma, Root cause, Workaround temporário, Correção permanente / change associado, CI afetados, Incidents relacionados.

Notas. A RCA também pode ser iniciada no tier L2 da consola operacional (ação «Iniciar RCA»).

Major Incident Workbench

Para que serve. É o painel de gestão das crises (Major Incident): coordena a war room, as atualizações, as ações e o fecho.

Quando a usar. Quando é declarado um Major Incident (manualmente ou por regra automática quando um Incident P1 ultrapassa os 30 minutos).

Como a abrir. Na ação Abrir/Escalate Major Incident da consola operacional, ou nas ligações diretas.

O que mostra. O título Major Incident Workbench, o botão Resolve Major Incident, o painel Impact e quatro separadores:

1. Timeline — a cronologia dos eventos do incidente.
2. Actions — os Action items, as ações atribuídas durante a crise.
3. Comms — as comunicações (atualizações a stakeholders/cliente).
4. Postmortem — a post-incident review.

Está disponível a Incident Bridge (botão Config MI / editar bridge): ligação à chamada de crise, Incident Commander, participantes, timeline das atualizações em tempo real. A secção Linked tickets mostra os tickets ligados ao incidente.

Como se usa. Abres/atualizas a bridge, registas os action items e as comunicações, atualizas a timeline; no fecho, carregas em Resolve Major Incident.

O que acontece depois. Na resolução está previsto um PIR (Post-Incident Review) obrigatório, preenchido no separador Postmortem. As atualizações são comunicadas aos stakeholders segundo as comunicações definidas.

Notas. Os limiares e a classificação dos Major Incidents (P0–P3) configuram-se no modal Config MI (Configuração de Major Incident (Config MI)) e na página Admin MI Config (Admin MI Config).

Configuração de Major Incident (Config MI)

Para que serve. Configura os parâmetros dos Major Incidents: limiares de ativação e classificação de severidade.

Quando a usar. Na configuração inicial ou na revisão das políticas MIM.

Como a abrir. No botão Config MI do Major Incident Workbench ou na página Admin MI Config (Admin MI Config).

O que mostra e como se usa. Os parâmetros de limiar (ex. tempo a partir do qual um Incident P1 passa a Major) e a classificação P0–P3 (Classificação de Major Incident). Defines e guardas.

O que acontece depois. As regras automáticas de criação do Major Incident usam estes parâmetros.

Notas. É uma função administrativa.

Knowledge Base

Para que serve. É a gestão completa da Knowledge Base: pesquisa, artigos, redação, análise de utilização e administração. Alimenta o self-service e o KB-deflection.

Quando a usar. Para pesquisar, criar, atualizar e analisar os artigos de KB (tipo IT-KB).

Como a abrir. Na ação Knowledge Base da landing IT ou no painel KB.

O que mostra. Cinco separadores:

1. Search — pesquisa de artigos com campo de query, resultados e teste de uma query (para verificar o que o utilizador encontraria) e sugestões.
2. Articles — a lista dos artigos com filtro por categoria e a lista das categorias; botão Novo artigo.
3. Editor — a redação do artigo: 1 frase de resumo, categoria, tags, corpo, anexos e estado de publicação.
4. Analytics — as métricas de utilização (número de artigos, artigos por categoria).
5. Admin — a administração da KB (categorias, aplicabilidade por país — ex. «IT, FR, DE»).

Como se usa. Pesquisas e consultas; com permissão de redação, crias/atualizas um artigo (resumo, categoria, tags, corpo, anexos) e publica-lo; o separador Search permite testar a eficácia da pesquisa; o Analytics mede a adoção.

O que acontece depois. Os artigos publicados ficam disponíveis no modal da KB (Knowledge Base), na triagem (deflection) e no self-service; a aplicabilidade por país rege a sua visibilidade.

Notas. Existe uma vista pública (KB de domínio, artigo e pública) para consulta externa.

KB de domínio, artigo e pública

• KB de domínio — a vista dos artigos filtrada por domínio (IT/NOC/OPS/ITSM), acessível pela ação KB do hub.
• Artigo de KB — a página de detalhe/redação de um artigo, com categoria, tags, autor e corpo.
• KB pública — a vista de consulta pública dos artigos destinados ao exterior.

Voicemail

Para que serve. Reúne as mensagens de voz encaminhadas para o service desk (utilizadores / comunicações de IT) e permite ouvi-las, ler a transcrição e transformá-las em tickets.

Quando a usar. Para gerir as mensagens de voz recebidas fora de horas ou quando o softphone não atendeu.

Como a abrir. A partir da landing IT Hub, painel Voicemail (com contador de mensagens não lidas).

O que mostra. A inbox das mensagens de voz com leitor de áudio, transcrição por IA (Whisper), risk scoring (Claude) e o callback integrado no softphone.

Como se usa. Ouves/lês a mensagem, avalias o risco, ligas de volta ao remetente com um clique (callback do softphone) ou abres um ticket a partir do conteúdo.

O que acontece depois. O callback inicia uma chamada; a abertura de um ticket leva ao Composer com o contexto da mensagem.

Notas. A página é partilhada com as áreas ligadas (mesmo endpoint canónico).

Controlo de Qualidade

Para que serve. Executa a revisão de qualidade dos tickets fechados: documentação, ownership, cumprimento de SLA, processo, resultado e segurança.

Quando a usar. Para as verificações de qualidade por amostragem ou sistemáticas sobre os tickets de IT fechados.

Como a abrir. Na ação Controlo de Qualidade da landing IT (visível para os papéis autorizados ao controlo de qualidade).

O que mostra e como se usa. A lista dos tickets fechados a rever e a grelha dos critérios de qualidade; avalias cada critério e registas o resultado da revisão.

O que acontece depois. Os resultados alimentam os indicadores de qualidade do serviço e podem reabrir/assinalar os tickets não conformes (QC-Gate).

Notas. É uma função reservada aos papéis de qualidade/gestão.

Dados Históricos

Para que serve. Consulta os dados históricos arquivados que já não estão na base de dados operacional.

Quando a usar. Para recuperar tickets/dados arquivados para além da janela operacional.

Como a abrir. Na ação Dados Históricos da landing IT.

O que mostra e como se usa. A interface de pesquisa no arquivo histórico; exige um cliente selecionado (se o contexto for «Todos os tenants» / *, o modal pede que o selecione).

O que acontece depois. Os resultados são mostrados só de leitura a partir do arquivo frio.

Notas. Diz respeito aos dados movidos para o arquivo histórico segundo a política de arquivo.

Páginas ligadas ao hub (descritas noutro local)

A partir da landing IT chegas também a páginas tratadas nas respetivas páginas próprias, para as quais remetemos: ITOM e Events & AIOps (NOC, Observability e ITOM), IT Operations Dashboard / Operations Cockpit e as vistas Service Director (Cockpits e vistas de direção), IT Report Center (Cockpits e vistas de direção/Reporting), Customer Service (Customer Service, Enterprise Service e ICC), CMDB / Assets (Asset Management e CMDB).