Hub de TI / ITSM

Propósito y mapa del hub

El Hub de TI es el centro operativo de TI según el framework ITIL. Desde aquí llegas a la consola operativa del service desk y del NOC, a la gestión de incidents, solicitudes, problems y changes, a la Knowledge Base, a los dashboards y a los reportes. Es la herramienta diaria de los operadores (L1/L2/L3), de los líderes de equipo y de los gerentes de TI, y el punto de acceso a las vistas de dirección del servicio.

Esta página está organizada en fichas: primero las páginas del hub (la landing, la consola operativa, Change, Problem, Major Incident, Knowledge Base, Voicemail), luego los modales transversales que se usan en los tickets (Editor, Composer, Inspector, Taxonomías, Notas internas, Adjuntos, Vínculos, Acciones masivas, Playbook, KB, Dashboard, Control de Calidad, Datos Históricos). Las páginas ITOM, Events&AIOps, Operations Cockpit, IT Report Center y Customer Service se mencionan aquí, pero se describen en sus propias páginas.

Landing del Hub de TI

Para qué sirve. Es la página de entrada del hub: presenta las acciones rápidas del hub y los recuadros (tiles) hacia las páginas operativas, de dirección y de reportes.

Cuándo usarla. Al inicio de la sesión de TI, para elegir el área en la que vas a trabajar o para lanzar las acciones transversales (KB, CMDB, Control de Calidad, Taxonomías).

Cómo abrirla. Desde la Home de Core (recuadro IT Hub) o desde la barra de herramientas «IT Hub» que aparece en las páginas del hub.

Qué muestra. En el encabezado, una hero strip con el título «IT Hub — Centro operativo IT · Network Operations · Service Desk · Operations & ITSM» y las acciones rápidas del hub:

Knowledge Base — abre la KB del dominio de TI.
CMDB / Assets — abre la CMDB centralizada.
Datos Históricos — abre el modal de los datos archivados (cold store); requiere un cliente seleccionado (ve Datos Históricos).
Control de Calidad — visible para los roles habilitados; abre la revisión de calidad de los tickets cerrados (ve Control de Calidad).
Taxonomías — visible para los administradores; abre el modal de Taxonomías de tickets (Taxonomías de tickets).

Abajo, los recuadros están agrupados en tres secciones:

Operación (CORE) — tres recuadros principales:

NOC · Network Operations — cola operativa con filtro de tier L1/L2/L3: monitoreo, triage, investigación, escalación.
Service Desk · Asistencia y solicitudes — cola del service desk con filtro de tier L1/L2/L3: triage, restablecimientos, incident/problem, catálogo. (El dominio interno sigue siendo OPS.)
Customer Service · grupos por cliente — tickets CS-* sobre los grupos dedicados del cliente (Customer Service, Enterprise Service e ICC).

Dirección de servicios — tres cockpits (visibles para los roles de gerente/director, *:MGR):

NOC Service Director — P1/War Room en vivo, SLA por cliente, cobertura de turno, escalación, broadcast al equipo.
Service Desk Director — FCR, AHT, volúmenes por canal, CSAT, tiempos de cola, desempeño de los analistas.
Customer Service Director — dirección de la línea de clientes sobre los grupos por cliente.

Herramientas operativas y reportes — recuadros compactos: ITOM, Events & AIOps, Problem Management, Change Management, IT Operations Dashboard, IT Report Center, Voicemail.

Cada recuadro muestra un ícono, un badge de estado (LIVE/NEW/…) y una línea de features (las etiquetas de las funciones principales). Al final de la página está el bottom dock unificado con softphone, chat y presencia.

Cómo se usa. Haces clic en el recuadro del área que quieres; las acciones rápidas del encabezado abren sus modales o páginas. Los recuadros y las acciones visibles dependen del rol (RBAC): la landing filtra los tiles según los perfiles de acceso del usuario y el tier requerido.

Qué pasa después. La navegación te lleva a la página o consola elegida; el estado de la sesión (cliente/tenant actual) se propaga a las páginas de destino.

Notas. Los KPI del hub se quitaron a propósito de la landing: con la vista entre tenants no serían significativos; las métricas viven en las páginas dedicadas (consola NOC, dashboard de SLA, cockpits).

Consola operativa L1/L2/L3 (NOC y Service Desk)

Para qué sirve. Es la consola donde se trabajan los tickets en cola, compartida por el NOC y el Service Desk mediante el mismo motor de layout. Te permite monitorear la cola, seleccionar un ticket, ver su detalle y actuar con acciones rápidas y herramientas de contexto. Una sola pantalla cubre los tres niveles (L1/L2/L3) mediante el filtro de tier.

Cuándo usarla. Es el puesto de trabajo del operador durante toda la jornada: atención, diagnóstico, escalación, resolución.

Cómo abrirla. Desde la landing del IT Hub, recuadros NOC o Service Desk. La consola Problem (Problem Management Console) usa el mismo layout.

Qué muestra. Un layout de tres paneles:

Cola (izquierda) — la lista de tickets, con:
- filtros rápidos: Todos, P1/P2, Míos, Unassigned, + L2/L3;
- búsqueda por clave, asunto o CI;
- actualización automática cada 60 segundos (con la hora de la última actualización y un contador).
Detalle (centro) — el ticket seleccionado con todos sus datos; desde aquí se abren el Editor (Editor de tickets) y las acciones.
Herramientas (derecha) — pestañas de contexto que cambian según el tier.

Arriba, una franja de KPI. Para el NOC L1: Tickets abiertos, P1/P2 activos, SLA breach, MTTR (min), Resueltos hoy.

Las acciones rápidas (L1): Atender (asignarme), Escalate L2/L3 (equipo GRP-NOC_L2), Resolver, Abrir Major Incident (escalación MIM). Las herramientas del L1: CI relacionados (CMDB explorer), Runbook (KB del NOC L1, Playbook de incidents), Monitoreo (Grafana, Alertmanager), SLA timer (tiempo restante), Dashboard (abre el dashboard de KPI en un modal).

Al pasar al tier L2 cambian los KPI, las acciones y las herramientas: KPI Incidents abiertos, P1/P2 abiertos, Change window, MTTR, Root-cause pending; acciones Take ownership, Escalate L3, Iniciar RCA (5-why + timeline), Abrir Change (RFC → CAB), Escalate MIM; herramientas RCA workspace (timeline builder, plantilla 5-why), Change mgmt (calendario del CAB, nueva RFC), Runbook L2/L3.

Abajo, los vínculos a Service Topology e ITOM Health, y el bottom dock con softphone (SIP), chat y presencia.

Cómo se usa. Filtras y buscas en la cola, seleccionas un ticket (detalle al centro), actúas con las acciones rápidas o abres el Editor para el trabajo completo; las herramientas de la derecha dan acceso a la CMDB, los runbooks, el monitoreo y los SLA. Las selecciones múltiples habilitan las acciones masivas (Acciones masivas).

Qué pasa después. «Atender» te asigna el ticket; «Escalate» lo mueve al equipo superior; «Resolver» lo cierra; «Abrir Major Incident» inicia el workbench MIM (Major Incident Workbench). Cada acción actualiza la cola, los KPI, la línea de tiempo y las notificaciones.

Notas. El filtro de tier y las matrices de escalación, los nombres de los equipos (GRP-NOC_*, GRP-OPS-*) y las colas se gobiernan de forma central; la actualización automática mantiene la cola al día sin recargar la página.

Editor de tickets

Es la ventana más usada de todo exoCortex Core: la describimos en dos secciones.

Para qué sirve, cuándo y cómo se abre

Para qué sirve. El Editor de tickets es el panel (drawer) donde trabajas un solo ticket: te permite leer todos sus datos, cambiar su estado (transiciones del workflow), modificar sus campos, comentar, gestionar adjuntos y notas internas, y consultar los SLA, la línea de tiempo, los tickets vinculados y el rastro de auditoría.

Cuándo usarla. Cada vez que atiendes o actualizas un ticket: atención, actualización del avance, solicitud de información, resolución, cierre.

Cómo abrirla. Haciendo clic en un ticket de cualquier lista (consola operativa, colas, resultados de búsqueda, widgets), o con el atajo ⌘O (Ctrl+O), que abre un picker para escribir la clave del ticket.

Característica distintiva — varios tickets. El Editor maneja hasta 6 tickets abiertos al mismo tiempo, cada uno en su propia pestaña (tab) arriba. Pasas de un ticket a otro con un clic o con ⌘Tab. Una pestaña con cambios sin guardar muestra el indicador de «sucio» (dirty). Cada ticket se cierra con la «x» de su pestaña.

Modos de visualización. El drawer tiene tres modos: anclado al lado (side-by-side), a pantalla amplia (focus) y minimizado (PIP) abajo. Esc contrae el drawer (collapse) sin perder su contenido.

Qué muestra: barra de estado y pestañas internas

Debajo de las pestañas de los tickets hay una barra de estado con los atributos clave y los controles rápidos: estado actual y botones de transición (confirmación con ⌘↵); prioridad (Highest/High/Medium/Low/Lowest); asignado (control «Asignar», que abre el selector de usuarios); indicadores de cola/equipo, tipo y clave.

El cuerpo está organizado en pestañas internas:

Detalle — los campos del ticket: asunto, descripción (texto plano), prioridad y los campos personalizados (custom fields) del issue type, cargados desde el catálogo y editables junto con los demás. Se guarda con ⌘S.
Timeline — la cronología de los eventos (creación, transiciones, comentarios, modificaciones).
Comentarios — el historial de comentarios (autor, fecha), mostrado en Markdown, con el área de escritura y el botón Enviar comentario (activo solo cuando hay un borrador).
SLA — los SLA asociados con cuenta regresiva «en vivo».
Linked — los objetos vinculados (tickets, llamadas, chats, vínculos) con fecha y origen; se agregan con el Link Picker (Vincular tickets).
Adjuntos — la lista de archivos con Ver, Descargar, Eliminar y carga; los adjuntos son inmutables (para «modificarlos» los eliminas y los vuelves a subir).
Notas internas — anotaciones reservadas al equipo (Notas internas).
Auditoría — la línea de tiempo del ciclo de vida.
Postmortem — la ficha de post-incident review, para los tipos que la incluyen (Major Incident, SOC Incident).

Cuando el ticket se refiere a un CI/host está disponible Console PAM (acceso privilegiado zero-knowledge al sistema).

Cómo se usa y qué pasa después

Cambiar el estado: eliges la transición; el workflow avanza, la línea de tiempo registra el evento y se disparan las notificaciones y automatizaciones (asignaciones, SLA, escalaciones).
Modificar los campos: editas en la pestaña Detalle y guardas con ⌘S; los cambios se envían en bloque. La descripción y los comentarios están en texto plano (single source): lo que escribes es lo que se guarda y se vuelve a leer.
Comentar: escribes en la pestaña Comentarios y envías; el comentario entra al historial y notifica según la matriz de notificación.
Gestionar adjuntos / asignar: desde sus pestañas o controles.

Atajos: ⌘O abrir picker · ⌘S guardar · ⌘↵ transición · Esc contraer · ⌘Tab siguiente ticket.

Notas. Las acciones disponibles (transiciones, edición de campos, eliminación de adjuntos, visibilidad de notas internas) dependen de los permisos del rol. La pestaña Postmortem solo aparece en los tipos que la incluyen.

Composer, creación de tickets

Para qué sirve. Es la ventana donde el operador crea un ticket nuevo (por cuenta de un usuario/cliente o a partir de una llamada/chat).

Cuándo usarla. Al abrir un caso nuevo: llamada al service desk, solicitud por chat, reporte que hay que monitorear, creación manual de incident/request/change.

Cómo abrirla. Desde el botón de creación en las listas o cockpits, o con Ctrl+N. El contexto se puede heredar de un chat o una llamada activa: reportante, asunto, descripción, CI, adjuntos, incident relacionado, tipo.

Qué muestra. Un modal centrado (con modo focus a pantalla amplia y PIP abajo a la izquierda), en tres pasos que se revelan de forma progresiva:

Identify — proyecto/tenant de destino, canal, solicitante (reporter).
Classify — tipo de ticket (issue type) y dominio (menú filtrado según la sección del dominio), prioridad y categoría.
Detail — asunto, descripción, campos específicos, adjuntos y, si aplica, una nota interna inicial.

Cada paso tiene un indicador de estado (pendiente/en curso/completado). Al lado, el panel AI Copilot: sugerencia del título, propuesta de prioridad, categorización, detección de duplicados, artículos de la KB y runbooks pertinentes.

Cómo se usa. Completas los tres pasos (el tipo determina los campos obligatorios — Solicitudes de servicio). Varios borradores: hasta 5 borradores abiertos, guardados en el servidor y localmente, con guardado automático cada 3 segundos. Envío con Ctrl+Enter o con el botón: el ticket se crea; la nota interna inicial, si existe, se agrega justo después. Atajos: Ctrl+N nuevo borrador · Ctrl+S guardar · Ctrl+Enter enviar · Esc contraer.

Qué pasa después. El ticket entra al workflow de su tipo, se enruta a la cola/equipo competente según las reglas de enrutamiento del dominio y se generan las notificaciones. Puedes abrir el ticket de inmediato en el Editor (Editor de tickets).

Notas. El tenant de destino debe ser concreto: los valores comodín (*, __ALL__) se rechazan. Si no indicas el dominio, no se fuerza ningún tipo predeterminado.

Vista previa del ticket

Para qué sirve. Muestra un ticket en solo lectura con vista previa, impresión y exportación, sin abrirlo para edición.

Cuándo usarla. Para una consulta rápida, para imprimir o para copiar el vínculo a un ticket y compartirlo.

Cómo abrirla. Desde listas y widgets con la acción de vista previa.

Qué muestra. Los datos del ticket y los comentarios: asunto, solicitante, estado, prioridad, descripción e historial de comentarios.

Cómo se usa. Botones de imprimir/exportar y Copiar vínculo.

Qué pasa después. No se modifica ningún dato (solo lectura). Para hacer cambios, pasas al Editor.

Notas. Los comentarios son opcionales (si no hay, la vista sigue siendo válida).

Taxonomías de tickets

Para qué sirve. Define las categorías y subcategorías de servicio que usa el Composer para clasificar los tickets. Es la herramienta de configuración de la taxonomía global.

Cuándo usarla. Cuando el administrador necesita crear o modificar las categorías de clasificación de los tickets.

Cómo abrirla. Desde la acción Taxonomías en la hero de la landing de TI (visible para los administradores).

Qué muestra. El árbol global de Category/Subcategory con las entradas existentes y los controles para crear, modificar y eliminar.

Cómo se usa. Agregas o modificas categorías y subcategorías; estas llenan el selector «Tipo/Categoría» del Composer (Composer, creación de tickets) y se usan para el enrutamiento y los reportes.

Qué pasa después. Los cambios quedan disponibles en el Composer y en las herramientas de clasificación; las taxonomías son una fuente única.

Notas. Es una función administrativa.

Notas internas

Para qué sirve. Gestiona las anotaciones reservadas al equipo en un ticket, que el solicitante no ve.

Cuándo usarla. Para anotar información de trabajo, hipótesis, contactos o detalles sensibles que no deben aparecer en la comunicación con el usuario.

Cómo abrirla. Desde la pestaña Notas internas del Editor (Editor de tickets).

Qué muestra. La lista de notas internas del ticket con autor y fecha, y el área para agregar una nota nueva.

Cómo se usa. Agregas una nota; solo la ven los operadores/equipos con permiso.

Qué pasa después. La nota se registra en el ticket (canal separado de los comentarios públicos) y contribuye a la trazabilidad interna.

Notas. La visibilidad de las notas internas depende de los permisos del rol.

Visor de adjuntos

Para qué sirve. Te permite ver, imprimir y descargar los adjuntos de un ticket sin tener que descargarlos a tu computadora para abrirlos.

Cuándo usarla. Para revisar un archivo adjunto (imagen, PDF, log) mientras trabajas el ticket.

Cómo abrirla. Desde la acción Ver en la pestaña Adjuntos del Editor, o desde los lugares donde aparece un adjunto.

Qué muestra. La vista previa del archivo con los comandos de impresión y descarga.

Cómo se usa. Abres el adjunto, lo consultas y, si quieres, lo imprimes o descargas.

Qué pasa después. El archivo no se modifica (los adjuntos son inmutables).

Notas. Para «modificar» un adjunto, lo eliminas y subes una nueva versión.

Vincular tickets

Para qué sirve. Crea un vínculo entre tickets (relación tipificada: por ejemplo, «duplica», «bloquea», «relacionado»).

Cuándo usarla. Para relacionar un ticket con otros (incidents del mismo problem, solicitudes duplicadas, dependencias).

Cómo abrirla. Desde la pestaña Linked del Editor.

Qué muestra. El tipo de vínculo, un campo de búsqueda del ticket de destino (que excluye el ticket de origen para evitar autovínculos) y un comentario opcional.

Cómo se usa. Eliges el tipo, buscas y seleccionas el ticket de destino, y confirmas.

Qué pasa después. Se crea el vínculo y la pestaña Linked del ticket se recarga con la nueva relación.

Notas. El catálogo de tipos de vínculo es una fuente única; el autovínculo está bloqueado.

Acciones masivas

Para qué sirve. Ejecuta acciones sobre varios tickets seleccionados a la vez: cierre masivo y escalación masiva.

Cuándo usarla. Para despachar en bloque varios tickets similares (por ejemplo, cerrar una serie de alertas que ya se normalizaron o escalar un grupo de tickets al mismo equipo).

Cómo abrirla. Seleccionando varios tickets en la cola o lista y eligiendo la acción masiva.

Qué muestra. La lista de tickets seleccionados, la elección de la acción (cerrar/escalar) y los parámetros requeridos (resolución para el cierre, equipo de destino para la escalación — los da el contexto, no están fijos en el código).

Cómo se usa. Confirmas la acción: cerrar cierra los tickets seleccionados, escalar los lleva al siguiente nivel. Se requiere una selección válida.

Qué pasa después. Los tickets se actualizan en bloque; la cola y los KPI se recargan; cada cambio queda registrado en la auditoría.

Notas. Las resoluciones y los equipos disponibles dependen de la configuración del tenant.

Playbook launcher

Para qué sirve. Lista y ejecuta los playbooks/runbooks aplicables al contexto de la página o del ticket.

Cuándo usarla. Para aplicar un procedimiento estandarizado (diagnóstico, remediación, comunicación) a un incident o a un CI.

Cómo abrirla. Desde la quick-action Playbook de las páginas de gestión o desde el ícono registrado en el bottom dock.

Qué muestra. Los playbooks aplicables, filtrados por dominio y etiqueta y habilitados para el tenant, con la opción de dar entradas de contexto (por ejemplo, el CI afectado).

Cómo se usa. Eliges un playbook y lo ejecutas en Dry-run (simulación) o Ejecutar (ejecución real), reutilizando la API de playbooks.

Qué pasa después. La ejecución produce sus efectos (acciones automáticas, actualizaciones del ticket/CI) y registra el resultado.

Notas. El tenant es el de la sesión y no se indica a mano; las acciones sensibles están protegidas por barreras.

Knowledge Base

Para qué sirve. Busca y consulta los artículos de la Knowledge Base directamente mientras trabajas, para resolver rápido y para el KB-deflection.

Cuándo usarla. Durante el triage o el diagnóstico, para encontrar un procedimiento o un artículo útil sin salir de la página.

Cómo abrirla. Desde la quick-action KB en las herramientas de la consola operativa, o desde los lugares que integran la búsqueda en la KB.

Qué muestra. Un campo de búsqueda y la lista de resultados; al seleccionar un artículo, la vista del artículo con título, metadatos y cuerpo.

Cómo se usa. Escribes una consulta y buscas; abres el artículo y lo consultas; regresas a la lista con «atrás».

Qué pasa después. El artículo puede resolver el caso (deflection) o darte los pasos a seguir; la KB también alimenta las sugerencias del AI Copilot del Composer.

Notas. El endpoint de búsqueda es canónico; la KB completa se gestiona en la página dedicada (Knowledge Base).

Dashboard de KPI

Para qué sirve. Abre en overlay un dashboard editorial de KPI, sin abrir una página aparte.

Cuándo usarla. Para consultar al vuelo los KPI de un área (por ejemplo, NOC L1 Monitoring) mientras trabajas en la consola.

Cómo abrirla. Desde la quick-action Abrir Dashboard de KPI en las herramientas de la consola.

Qué muestra. El reporte editorial generado con datos reales: KPI, tendencias, desgloses.

Cómo se usa. Lo abres y consultas las gráficas y los valores; reemplaza a los antiguos dashboards separados.

Qué pasa después. No se modifica ningún dato (solo lectura); al cerrarlo regresas a la consola.

Notas. Si el runtime del reporte no está disponible, el modal falla de forma explícita (fail-loud), sin datos ficticios.

Change Management

Para qué sirve. Gobierna el ciclo de vida de los changes de infraestructura según ITIL: Standard (preaprobado, sin CAB), Normal (aprobación del CAB) y Emergency (aprobación del eCAB), con las ventanas de Change Freeze.

Cuándo usarla. Para registrar, evaluar, aprobar y programar los cambios; para gestionar las reuniones del CAB y las ventanas de congelamiento.

Cómo abrirla. Desde la landing del IT Hub, recuadro Change Management, o desde la consola operativa (acción «Abrir Change» en el tier L2).

Qué muestra. Una fila de KPI y cuatro pestañas:

Lista — los changes con estado, tipo, riesgo, ventana y resultado.
CAB — la agenda del Change Advisory Board: RFC en discusión, participantes, votos (tipo IT-CAB-MEETING).
Calendar Window — el calendario de las ventanas de cambio (cuadrícula mensual), con la «Window propuesta».
Audit Trail — el rastro de las acciones sobre los changes.

Cómo se usa. Creas o evalúas un change (RFC), lo llevas al CAB para su aprobación y programas la ventana de ejecución; desde cada change abres el Editor para registrar el avance y las aprobaciones (Aprobación de changes (CAB)).

Qué pasa después. Un Normal Change requiere la aprobación del CAB antes de ejecutarse; un Emergency sigue el trámite del eCAB (aprobación retroactiva). Durante un freeze, los changes no se pueden aprobar sin autorización explícita del Change Manager.

Notas. Las reuniones del CAB se pueden generar de forma periódica; el acta y el resultado de la votación quedan registrados en el IT-CAB-MEETING correspondiente.

Aprobación de changes (CAB)

Para qué sirve. Registra la decisión de aprobación sobre un change (normalmente un Normal Change en el CAB).

Cuándo usarla. En sesión del CAB/eCAB, cuando el change está pendiente de aprobación y tú eres uno de los aprobadores.

Cómo abrirla. Desde la pestaña CAB o desde el Editor del change (pestaña Aprobaciones). Es el mismo modal descrito en Aprobación, aquí aplicado a los changes.

Qué muestra y cómo se usa. La cadena de aprobación con los pasos y su estado, y las decisiones Aprobar / Rechazar / Pedir información / Delegar, con comentario. Si se requiere, la firma.

Qué pasa después. La aprobación del último paso habilita la ejecución del change en la ventana programada; un rechazo lo regresa; todas las decisiones se notifican y quedan registradas.

Notas. Las reglas del CAB/eCAB y los freezes condicionan el resultado (ve Cockpits y vistas de dirección/Procesos de TI).

Problem Management Console

Para qué sirve. Gestiona los problems y el análisis de causa raíz (RCA), hasta los Known Errors con workaround documentado.

Cuándo usarla. Cuando varios incidents comparten una causa común, o para hacer un análisis estructurado de causa raíz.

Cómo abrirla. Desde la landing del IT Hub, recuadro Problem Management.

Qué muestra. El layout de cola de la consola operativa (KPI, lista con actualización automática cada 60 s), especializado para problems, con el vínculo al calendario del CAB y a los incidents relacionados. Expone el RCA (5-why + engine) y la Known Error DB (KEDB).

Cómo se usa. Abres un problem, haces el análisis RCA (plantilla 5-why, timeline) y documentas la causa raíz y el workaround; a partir de un problem promueves un Known Error y creas el artículo de la KB correspondiente.

Qué pasa después. Un Known Error publicado pone el workaround a disposición del primer nivel (KB-deflection) y reduce el tiempo de resolución de los incidents recurrentes. La plantilla KEDB recopila: Síntoma, Root cause, Workaround temporal, Fix permanente / change asociado, CI impactados, Incidents relacionados.

Notas. El RCA también se puede iniciar desde el tier L2 de la consola operativa (acción «Iniciar RCA»).

Major Incident Workbench

Para qué sirve. Es el tablero para gestionar las crisis (Major Incidents): coordina la war room, las actualizaciones, las acciones y el cierre.

Cuándo usarla. Cuando se declara un Major Incident (de forma manual o por regla automática cuando un Incident P1 pasa de 30 minutos).

Cómo abrirla. Desde la acción Abrir/Escalate Major Incident de la consola operativa, o desde los vínculos directos.

Qué muestra. El título Major Incident Workbench, el botón Resolve Major Incident, el panel Impact y cuatro pestañas:

Timeline — la cronología de los eventos del incidente.
Actions — los Action items, las acciones asignadas durante la crisis.
Comms — las comunicaciones (actualizaciones a stakeholders/cliente).
Postmortem — la post-incident review.

Incluye el Incident Bridge (botón Config MI / editar bridge): vínculo a la llamada de crisis, Incident Commander, participantes, línea de tiempo de las actualizaciones en tiempo real. La sección Linked tickets muestra los tickets vinculados al incidente.

Cómo se usa. Abres o actualizas el bridge, registras los action items y las comunicaciones, y actualizas la línea de tiempo; al cerrar, presionas Resolve Major Incident.

Qué pasa después. Al resolverse, se requiere un PIR (Post-Incident Review) obligatorio, que se llena en la pestaña Postmortem. Las actualizaciones se comunican a los stakeholders según las comunicaciones configuradas.

Notas. Los umbrales y la clasificación de los Major Incidents (P0–P3) se configuran en el modal Config MI (Configuración de Major Incidents (Config MI)) y en la página Admin MI Config (Admin MI Config).

Configuración de Major Incidents (Config MI)

Para qué sirve. Configura los parámetros de los Major Incidents: umbrales de activación y clasificación de severidad.

Cuándo usarla. Durante la configuración inicial o la revisión de las políticas de MIM.

Cómo abrirla. Desde el botón Config MI del Major Incident Workbench o desde la página Admin MI Config (Admin MI Config).

Qué muestra y cómo se usa. Los parámetros de umbral (por ejemplo, el tiempo después del cual un Incident P1 se vuelve Major) y la clasificación P0–P3 (Clasificación de Major Incidents). Los defines y los guardas.

Qué pasa después. Las reglas automáticas de creación de Major Incidents usan estos parámetros.

Notas. Es una función administrativa.

Knowledge Base

Para qué sirve. Es la gestión completa de la Knowledge Base: búsqueda, artículos, redacción, análisis de uso y administración. Alimenta el autoservicio y el KB-deflection.

Cuándo usarla. Para buscar, crear, actualizar y analizar los artículos de la KB (tipo IT-KB).

Cómo abrirla. Desde la acción Knowledge Base de la landing de TI o desde el recuadro KB.

Qué muestra. Cinco pestañas:

Search — búsqueda de artículos con campo de consulta, resultados y prueba de una consulta (para verificar qué encontraría el usuario) y sugerencias.
Articles — la lista de artículos con filtro por categoría y la lista de categorías; botón Nuevo artículo.
Editor — la redacción del artículo: 1 frase de resumen, categoría, etiquetas, cuerpo, adjuntos y estado de publicación.
Analytics — las métricas de uso (número de artículos, artículos por categoría).
Admin — la administración de la KB (categorías, aplicabilidad por país — por ejemplo, «IT, FR, DE»).

Cómo se usa. Buscas y consultas; con permiso de redacción creas o actualizas un artículo (resumen, categoría, etiquetas, cuerpo, adjuntos) y lo publicas; la pestaña Search te permite probar la eficacia de la búsqueda; Analytics mide la adopción.

Qué pasa después. Los artículos publicados están disponibles en el modal de la KB (Knowledge Base), en el triage (deflection) y en el autoservicio; la aplicabilidad por país rige su visibilidad.

Notas. Existe una vista pública (KB de dominio, artículo y pública) para la consulta externa.

KB de dominio, artículo y pública

KB de dominio — la vista de los artículos filtrada por dominio (IT/NOC/OPS/ITSM), a la que llegas con la acción KB del hub.
Artículo de la KB — la página de detalle/redacción de un artículo con categoría, etiquetas, autor y cuerpo.
KB pública — la vista de consulta pública de los artículos destinados al exterior.

Voicemail

Para qué sirve. Reúne los mensajes de voz enrutados al service desk (usuarios / reportes de TI) y te permite escucharlos, leer su transcripción y convertirlos en tickets.

Cuándo usarla. Para gestionar los mensajes de voz recibidos fuera de horario o cuando el softphone no contestó.

Cómo abrirla. Desde la landing del IT Hub, recuadro Voicemail (con contador de mensajes no leídos).

Qué muestra. El inbox de mensajes de voz con reproductor de audio, transcripción con IA (Whisper), risk scoring (Claude) y el callback integrado en el softphone.

Cómo se usa. Escuchas o lees el mensaje, evalúas el riesgo, le regresas la llamada al remitente con un clic (callback del softphone) o abres un ticket a partir del contenido.

Qué pasa después. El callback inicia una llamada; abrir un ticket te lleva al Composer con el contexto del mensaje de voz.

Notas. La página se comparte con las áreas relacionadas (mismo endpoint canónico).

Control de Calidad

Para qué sirve. Hace la revisión de calidad de los tickets cerrados: documentación, ownership, cumplimiento de SLA, proceso, resultado y seguridad.

Cuándo usarla. Para las verificaciones de calidad por muestreo o sistemáticas de los tickets de TI cerrados.

Cómo abrirla. Desde la acción Control de Calidad de la landing de TI (visible para los roles habilitados para el control de calidad).

Qué muestra y cómo se usa. La lista de tickets cerrados por revisar y la cuadrícula de criterios de calidad; evalúas cada criterio y registras el resultado de la revisión.

Qué pasa después. Los resultados alimentan los indicadores de calidad del servicio y pueden reabrir o marcar los tickets no conformes (QC-Gate).

Notas. Es una función reservada a los roles de calidad/gestión.

Datos Históricos

Para qué sirve. Consulta los datos históricos archivados que ya no están en la base de datos operativa.

Cuándo usarla. Para recuperar tickets/datos archivados fuera de la ventana operativa.

Cómo abrirla. Desde la acción Datos Históricos de la landing de TI.

Qué muestra y cómo se usa. La interfaz de búsqueda en el archivo histórico; requiere un cliente seleccionado (si el contexto es «Todos los tenants» / *, el modal te pide seleccionarlo).

Qué pasa después. Los resultados se muestran en solo lectura desde el archivo frío.

Notas. Se refiere a los datos movidos al archivo histórico según la política de archivado.

Páginas relacionadas con el hub (descritas en otra parte)

Desde la landing de TI también llegas a páginas que se tratan en sus propias páginas, a las que te remitimos: ITOM y Events & AIOps (NOC, Observability e ITOM), IT Operations Dashboard / Operations Cockpit y las vistas Service Director (Cockpits y vistas de dirección), IT Report Center (Cockpits y vistas de dirección/Reportes), Customer Service (Customer Service, Enterprise Service e ICC), CMDB / Assets (Asset Management y CMDB).