Etapas del Ciclo de Vida de un Ticket (N1)

✅ Matriz de Etapas – CNOC

📋 Tabla de Navegación Rápida – Etapas del Ticket CNOC

✅ MATRIZ DE ETAPAS

📋 Tabla de Navegación Rápida – Etapas del Ticket CNOC

🧩 Etapa ⏱ ¿Cuenta para KPI CNOC? 🎯 Acción principal del N1 🛠 Condición para excluir de KPI 📌 Uso común
OPEN ✅ Sí Asignar el ticket en <10/15 min Ninguna. Siempre cuenta Inicio del ticket
WO Open ✅ Sí (si no se escala en tiempo) Asignar área y colocar tabla de escalación Si se escala en tiempo y se documenta Preparación para enviar
WO Assigned ❌ No (si escalado correctamente) Verificar aceptación por el área Tabla de escalación cumplida Área acepta WO
WO Worker Assigned ❌ No Validar que técnico fue designado Escalación en tiempo y documentada Técnico asignado
WO Work in Progress ❌ No Supervisar progreso si es necesario Escalación cumplida y técnico activo Técnico en acción
WO Resolved ✅ Sí Validar solución técnica y con cliente Ninguna. Siempre cuenta al CNOC Área técnica terminó
Pendiente Cliente ❌ No (si se justifica) Contactar cliente, documentar intentos Registro claro de contacto/espera Validar servicio
Monitoreo ❌ No Observar estabilidad, preparar cierre Justificación técnica o solicitud cliente Observación técnica
Dictamen ❌ No Generar informe para cliente Aplicable solo a tickets cerrados técnicamente Documentación post-solución
WO Pendiente Proveedor ❌ No Registrar proveedor y contacto Proveedor asignado/documentado Esperando tercero
Pendiente Otros ❌ No Indicar afectación masiva y registrar evento Validación de masividad con evidencia Incidente generalizado
Resuelto ❌ No Confirmar que todo está en orden Validación completa hecha Ticket listo para cierre
Closed ❌ No Nada. Fin del proceso - Ticket cerrado formalmente

🧩 Etapa: OPEN

🧾 Definición

Es la etapa inicial del ciclo de vida del ticket. Se activa automáticamente cuando el ticket es creado en el sistema. En esta etapa aún no ha sido asignado a ningún operador o área específica.

🎯 Objetivo de la etapa

Asegurar que el ticket sea recibido y asignado rápidamente al área o persona correspondiente para comenzar el diagnóstico o resolución.

⏱️ Tiempo máximo permitido

  • OPEN < 10 min → Meta mínima: ≥ 90%
  • OPEN < 15 min → Meta extendida: ≥ 98%

Estos tiempos son parte del KPI:
“% de Tickets con Tiempo en Etapa OPEN < 10 min y < 15 min”

📈 ¿Afecta al KPI CNOC?

✅ Sí, siempre.

Todo el tiempo que un ticket permanezca en la etapa OPEN cuenta directamente para los KPIs de:

  • Tiempo de asignación
  • Resolución rápida (forma parte del tiempo total del ticket)

🔧 Acciones esperadas del N1

  • Revisar bandejas o alertas de nuevos tickets en tiempo real.
  • Priorizar tickets según tipo: reactivos, accesos, proactivos o VIP.
  • Asignar el ticket al equipo/operador correspondiente.
  • Documentar correctamente la asignación si se requiere.

📌 Buenas prácticas

Acción Resultado
Monitoreo constante de bandejas Asignación dentro del tiempo objetivo
Uso de filtros por prioridad Mejora tiempos de respuesta
Automatización de alertas Reducción de tiempo en OPEN
Supervisión del backlog Evita acumulación y tickets olvidados

⚠️ Errores comunes

  • Dejar el ticket en OPEN sin asignar más de 15 min.
  • No priorizar correctamente tickets reactivos o críticos.
  • Pensar que OPEN no cuenta para KPIs (sí cuenta).

⚙️ Lógica Operativa

  1. Inicio automático:
    - La etapa OPEN inicia en cuanto se genera el ticket.
    - Marca el inicio del reloj para los KPIs de respuesta y resolución.
  2. Responsabilidad directa del CNOC (N1):
    - El N1 tiene máximo 10 minutos para tomar el ticket.
    - No existen pausas válidas: no se puede justificar el tiempo en esta etapa.
  3. Regla de cumplimiento de KPI:
    - <10 min → ✅ Cumple KPI
    - >15 min → ❌ Penaliza KPI
  4. Validación operativa:
    - Toda asignación debe estar documentada si no se hace en tiempo.
    - Se recomienda establecer alertas automáticas al minuto 7 como advertencia.
  5. No hay excusas válidas:
    - No aplica “Pending Customer”, “Vendor” ni ninguna justificación operativa.
    - El sistema considera todo el tiempo como carga al CNOC.

🧩 Etapa: Work in Progress

🧾 Definición

Es la etapa en la cual el ticket ya fue asignado a un operador del CNOC y se está realizando el diagnóstico inicial y la gestión directa del incidente. Aquí el personal N1 evalúa el estado del enlace, verifica alarmas, ejecuta comandos y toma decisiones para resolver o escalar.

🎯 Objetivo de la etapa

Diagnosticar el problema en el menor tiempo posible y aplicar una solución directa o, si es necesario, escalar el caso a otra área técnica (Back Office, Planta Externa, etc.).

⏱️ Tiempo máximo permitido

  • ≤ 30 min → Resolución directa: ≥ 60%
  • ≤ 60 min → Resolución directa: ≥ 90%
  • ≤ 120 min → Resolución directa: ≥ 98%

Estos tiempos forman parte del KPI:
“% de Tickets resueltos por CNOC en ≤ 30, ≤ 60 y ≤ 120 minutos”

📈 ¿Afecta al KPI CNOC?

✅ Sí, siempre.

Es el tiempo más importante en la evaluación de la eficiencia del CNOC, ya que representa la gestión activa del incidente.

  • KPIs de resolución directa
  • KPIs de solución sin escalar a Back Office
  • KPIs de solución con afectación o sin afectación en menos de 8/12h

🔧 Acciones esperadas del N1

  • Ejecutar comandos de verificación de conectividad, interfaces, servicios.
  • Revisar alarmas, SNMP, logs de eventos, tráfico, etc.
  • Validar si se trata de una falla real o falsa alarma.
  • Aplicar soluciones temporales o definitivas (ej. reinicio de interfaces, corrección de configuración).
  • Escalar correctamente si no es posible resolver desde N1.
  • Documentar detalladamente los hallazgos.

📌 Buenas prácticas

Acción Resultado
Validar equipos y topología antes de escalar Reduce escalaciones innecesarias
Uso de plantillas de comandos y scripts Acelera diagnóstico
Registro detallado de acciones y tiempos Facilita auditorías y mejora KPI
Escalación documentada y oportuna Disminuye penalización en tiempos

⚠️ Errores comunes

  • Permanecer demasiado tiempo en Work in Progress sin escalar.
  • No ejecutar comandos adecuados para validar estado.
  • Escalar sin documentar correctamente los pasos seguidos.
  • Escalar sin usar la tabla de escalación cuando aplica.
  • Dejar el ticket estancado sin actividad.

⚙️ Lógica Operativa

  1. Inicio de la etapa:
    - Comienza cuando el operador toma el ticket desde OPEN.
    - El reloj de diagnóstico inicia oficialmente para los KPIs de resolución.
  2. Responsabilidad del CNOC (N1):
    - Toda acción, validación o intento de solución debe ejecutarse en esta etapa.
    - El tiempo aquí es crítico para cumplir el KPI de solución rápida (≤ 30, 60, 120 min).
  3. Regla de medición:
    - Si el ticket se resuelve dentro de esta etapa en ≤ 30 min → ✅ Excelente KPI.
    - Si no hay resolución ni escalación justificada → ❌ Afecta el KPI de eficiencia.
  4. Escenarios especiales:
    - Si el problema requiere escalar → el N1 debe seguir la tabla de escalación.
    - Si no se escala correctamente o se justifica mal → el tiempo total se carga al CNOC.
  5. Validación operativa:
    - Todo ticket debe tener evidencias técnicas: screenshots, comandos, alarmas.
    - El ticket debe pasar a WO Open si es necesario escalar, dentro del tiempo permitido.

🧩 Etapa: WO Open (Orden de Trabajo Abierta)

🧾 Definición

Etapa en la que el ticket ya fue escalado por el CNOC a otra área técnica, pero aún no ha sido formalmente asignado o tomado por dicha área. Esta etapa tiene dos fases operativas, ambas bajo responsabilidad del CNOC hasta que alguien más se haga cargo.

🔀 Fases dentro de WO Open

🔹 Fase 1 – WO Open sin asignación:

  • El CNOC genera la orden, pero todavía no se ha indicado el área específica ni la tabla de escalación.
  • Ejemplo: el gestor aún está confirmando a quién se enviará o espera una aprobación interna.

🔹 Fase 2 – WO Open asignada a un área:

  • El ticket ya fue asignado al área específica (ej. BOIP, Planta Interna, etc.).
  • Se activa la tabla de escalación jerárquica, que define los responsables y tiempos por nivel.
  • El tiempo sigue contando como responsabilidad del CNOC hasta que el área lo acepte (WO Assigned).

🎯 Objetivo de la etapa

Transferir la responsabilidad técnica de resolver el incidente a otra área, asegurando que el traspaso se realice en tiempo y forma, siguiendo una tabla de escalación definida.

⏱️ Tiempo máximo permitido

No hay tiempo estándar global, pero se utiliza la tabla de escalación del área receptora. Ejemplo BOIP:

Nivel Nombre Tiempo desde inicio WO Hora límite de escalación
Inmediato Línea directa BOIP Inmediato 10:46 AM
Nivel 2 Luisa Fernanda 30 min 11:16 AM
Nivel 3 Lenin Díaz 45 min 11:31 AM
Nivel 4 Edwin Martinez 1.5 horas 12:16 PM
Nivel 5 Eugener Velasquez 2 horas 12:46 PM

✅ El gestor tiene ±15 minutos de margen para cada escalación.
❌ Si se incumple algún tiempo sin justificación → afecta KPI CNOC.

📈 ¿Afecta al KPI CNOC?

✅ Sí, condicionalmente:

  • Si no se asigna y no se escalan los niveles a tiempo → penaliza KPIs de resolución.
  • Afecta especialmente los KPIs que consideran tiempos totales de gestión del CNOC antes del traspaso formal:
    • Resolución CNOC ≤ 30/60/120 min
    • Resolución con o sin afectación ≤ 8h / 12h
    • % de solución sin escalar a BO

🔧 Acciones esperadas del N1

  • Generar la WO con la información técnica clara.
  • Asignar al área correcta siguiendo el protocolo.
  • Activar la tabla de escalación completa desde el primer contacto.
  • Escalar jerárquicamente cada nivel cuando el anterior no responde.
  • Registrar cada escalación con:
    • Nombre del contacto
    • Hora exacta
    • Canal usado (llamada o WhatsApp)

📌 Buenas prácticas

Acción Resultado
Registrar toda la tabla desde el inicio Asegura control y trazabilidad
Escalar dentro del rango de ±15 min Evita impacto negativo en KPI
Usar canales rápidos y comprobables Facilita auditoría operativa y cumplimiento del proceso
Notificar a supervisión si hay bloqueo Permite activar refuerzo o reasignación

⚠️ Errores comunes

  • Asignar al área y no iniciar tabla de escalación.
  • No documentar los contactos por WhatsApp o llamada.
  • Dejar la WO abierta más de 2 horas sin seguimiento.
  • Suponer que “asignar” exime de responsabilidad inmediata.

⚙️ Lógica Operativa

  1. Inicio de la etapa:
    - Desde que se crea la WO (fase 1).
    - Pasa a fase 2 cuando se asigna un área con tabla de escalación.
  2. Responsabilidad del CNOC:
    - Hasta que la orden sea aceptada (WO Assigned), el tiempo sigue bajo CNOC.
    - CNOC debe gestionar las escalaciones jerárquicas, sin excusas.
  3. Regla de medición:
    - Si alguna escalación se realiza fuera de los márgenes de ±15 min → sigue sumando al KPI CNOC.
    - Si todas se cumplen y están documentadas → el tiempo se justifica y no penaliza.
  4. Validación operativa:
    - Tiempos de cada nivel de escalación.
    - Registro de contacto por canal.
    - Capturas de pantalla de chats si aplica.
    - Registro en el ticket del seguimiento y estado.

🧩 Etapa: WO Assigned

🧾 Definición

La etapa WO Assigned se activa cuando la orden de trabajo (WO) ya ha sido formalmente asignada a un grupo técnico (Back Office, Planta, Proveedor, etc.). Es el punto en que se espera que ese grupo acepte la responsabilidad del ticket.

🎯 Objetivo de la etapa

Garantizar que el grupo técnico reciba y gestione el ticket dentro de los tiempos de la tabla de escalación, para que el CNOC deje de acumular tiempo en el KPI.

📈 ¿Afecta al KPI CNOC?

⚠️ Sí, condicionalmente.

  • ✅ No afecta si se cumplen todos los tiempos de escalación previos, incluyendo:
    • Creación oportuna de WO
    • Asignación correcta del grupo
    • Escalaciones realizadas en tiempo
    • Justificación y registro documentado
  • ❌ Afecta si:
    • No se cumple el margen de ±15 minutos
    • No se documentan correctamente las gestiones
    • No se justifica adecuadamente la falta de respuesta

⏱️ Tiempo bajo responsabilidad del CNOC

🔁 El reloj del KPI CNOC sigue activo durante esta etapa hasta que se cumplan dos condiciones:

  1. El grupo técnico acepta formalmente la orden.
  2. El CNOC demuestra cumplimiento de la tabla de escalación.

🔧 Acciones esperadas del N1

  • Monitorear si la WO fue aceptada por el grupo.
  • Realizar escalaciones jerárquicas si el grupo no responde.
  • Documentar claramente:
    • Nombre del contacto
    • Hora exacta de la escalación
    • Canal usado (llamada o WhatsApp)
  • Escalar a supervisión si hay demoras sin respuesta.

📌 Buenas prácticas

Acción Resultado
Cumplir con cada escalación en la tabla Exime al CNOC del tiempo posterior
Registrar cada escalación en tiempo y forma Protege los KPIs en auditoría
Validar aceptación efectiva del grupo técnico Confirma el traspaso de responsabilidad
Copiar al supervisor en escalaciones tardías Respalda operativamente al operador N1

⚠️ Errores comunes

  • Asignar el grupo técnico pero no escalar cuando no responden.
  • No registrar el canal ni hora exacta de contacto.
  • No involucrar al supervisor cuando ya pasó el tiempo límite de la tabla.
  • Suponer que WO Assigned por sí sola libera responsabilidad del CNOC.

⚙️ Lógica Operativa

  1. Inicio de la etapa:
    - Cuando la orden se asigna formalmente a un grupo técnico.
  2. Condición para que no cuente al CNOC:
    - Se deben haber ejecutado correctamente todas las escalaciones previas.
  3. Regla de medición:
    - Si el CNOC no justifica las escalaciones, el tiempo sigue contando.
  4. Validación operativa:
    - Tabla de escalación visible y actualizada
    - Capturas de contacto por cada nivel
    - Registros con marcas horarias

🧩 Etapa: WO Worker Assigned

🧾 Definición

Esta etapa indica que un técnico específico ya ha sido asignado por el grupo técnico receptor (ej. Back Office, Planta Interna/Externa, Proveedor) para ejecutar el diagnóstico o reparación. Marca la transición entre planificación y ejecución técnica.

🎯 Objetivo de la etapa

Iniciar formalmente el trabajo por parte del personal técnico designado para atender la orden de trabajo en sitio o de forma remota.

📈 ¿Afecta al KPI CNOC?

⚠️ Sí, condicionalmente.

  • ✅ No afecta si:
    • El CNOC escaló oportunamente en etapas anteriores.
    • Se cumplió la tabla de escalación y se documentó.
    • La orden fue tomada por el técnico en tiempo esperado.
  • ❌ Afecta si:
    • No se siguió la tabla de escalación correctamente.
    • Hay retraso sin justificación ni reporte por parte del CNOC.
    • No hay gestión ni contacto con supervisores técnicos.

🔧 Acciones esperadas del N1

  • Verificar que un técnico haya sido asignado en la WO.
  • Confirmar con el grupo técnico si no se refleja en el sistema.
  • Notificar a supervisión CNOC si hay más de 15 minutos de inactividad.
  • Registrar la hora de verificación y canal de contacto (llamada, WhatsApp).

📌 Buenas prácticas

Acción Resultado
Verificar transición de “WO Assigned” Permite cerrar tiempo de CNOC con trazabilidad
Monitorear SLA interno del grupo técnico Previene acumulación de tiempo CNOC
Documentar contacto con supervisores técnicos Protege KPI en caso de demora
Usar bitácoras para registrar espera del técnico Justifica bloqueos fuera de control del CNOC

⚠️ Errores comunes

  • No verificar que el técnico fue asignado formalmente.
  • Asumir que la asignación de grupo técnico implica asignación de técnico.
  • No realizar seguimiento si la orden está estancada.
  • No documentar comunicaciones de retraso.

⚙️ Lógica Operativa

  1. Inicio de la etapa: - Ocurre cuando el sistema muestra un técnico vinculado a la orden.
  2. Condición para no penalizar al CNOC: - Debe haber evidencia de cumplimiento previo en escalaciones y justificación del retraso si existe.
  3. Regla de medición: - Tiempo sin técnico asignado y sin justificación = penaliza KPI.
  4. Validación operativa: - Nombre y hora del técnico asignado. - Documentación del tiempo de espera. - Contacto registrado con supervisión técnica.

🧩 Etapa: WO Work in Progress

🧾 Definición

Esta etapa indica que el técnico asignado ya está realizando acciones activas para resolver el incidente. Puede incluir intervenciones en sitio, pruebas remotas, reemplazo de equipos, ajustes de configuración u otras acciones técnicas formales.

🎯 Objetivo de la etapa

Ejecutar la solución técnica del incidente conforme al diagnóstico del CNOC o instrucciones del grupo técnico asignado. Esta etapa implica trabajo real y medible sobre el enlace o servicio afectado.

📈 ¿Afecta al KPI CNOC?

  • ❌ No afecta, siempre y cuando:
    • El CNOC cumplió la tabla de escalación en WO Open y WO Assigned.
    • Se documentó correctamente que la orden fue aceptada y el técnico inició la intervención.
    • El CNOC ya trasladó la responsabilidad técnica al grupo correspondiente.
  • ⚠️ Podría afectar si:
    • La orden se mantiene sin movimiento y el CNOC no reporta o gestiona.
    • La escalación previa no fue documentada o no se ejecutó en tiempo.
    • El CNOC debe retomar el caso por mal cierre o error técnico.

🔧 Acciones esperadas del N1

  • Monitorear el avance general del caso.
  • Verificar si el técnico cerró la orden o dejó observaciones pendientes.
  • Prepararse para recibir el ticket nuevamente si requiere validación posterior.

📌 Buenas prácticas

Acción Resultado
Validar hora de inicio de la intervención técnica Permite justificar cierre del tiempo CNOC
Confirmar tipo de acción técnica realizada Mejora documentación post resolución
Contactar al área si hay inactividad >30 min Acelera la atención del caso
Documentar cualquier seguimiento CNOC en ticket Mejora la trazabilidad del caso

⚠️ Errores comunes

  • No confirmar si realmente se está trabajando la orden.
  • No reclamar si la orden se estanca sin actividad del técnico.
  • Asumir que esta etapa “libera” responsabilidad del CNOC automáticamente.
  • Olvidar que el CNOC debe validar la solución al cierre técnico.

⚙️ Lógica Operativa

  1. Inicio: cuando el técnico abre su actividad y documenta acciones.
  2. Fin: al registrar WO Resolved (resolución técnica).
  3. Medición: el tiempo no afecta al CNOC si las escalaciones previas fueron correctas.
  4. Validación operativa:
    • Evidencia del inicio técnico.
    • Registro detallado de acciones.
    • Comunicación activa con el grupo si hay retrasos.

🧩 Etapa: WO Resolved

🧾 Definición

La etapa WO Resolved se activa cuando el grupo técnico o proveedor cierra la orden de trabajo, indicando que la intervención ha sido completada y que, desde su perspectiva, el servicio ha sido restablecido. A partir de aquí, el CNOC retoma el control operativo del ticket para validar la solución.

🎯 Objetivo de la etapa

Validar que la solución técnica aplicada haya resuelto el incidente mediante pruebas de conectividad, tráfico, latencia y validación directa con el cliente si aplica. Esta etapa es el puente entre la ejecución técnica y el cierre administrativo.

📈 ¿Afecta al KPI CNOC?

✅ Sí. Todo el tiempo que el ticket permanezca en esta etapa cuenta como responsabilidad del CNOC:

  • Equivale a una extensión del Work in Progress.
  • Afecta KPIs de:
    • Resolución CNOC ≤ 30/60/120 min
    • Resolución con o sin afectación ≤ 8h / 12h
    • Reincidencias

⏱️ Tiempo bajo responsabilidad del CNOC

Desde que el grupo técnico marca el ticket como WO Resolved, el CNOC retoma la carga de tiempo y debe actuar de inmediato para evitar impacto negativo en los KPIs.

🔧 Acciones esperadas del N1

  • Verificar estado en herramientas de monitoreo: interfaces, tráfico, latencia.
  • Ejecutar comandos de validación técnica (ping, traceroute, sh int).
  • Contactar al cliente si aplica y validar operatividad del servicio.
  • Cambiar etapa del ticket a:
    • Cliente Pendiente si requiere validación del cliente.
    • Monitoreo si debe observarse estabilidad.
    • Resuelto si todo está validado.
  • Documentar capturas, comandos y contactos.

📌 Buenas prácticas

Acción Resultado
Iniciar validación apenas se recibe WO Resolved Mejora los tiempos de cierre
Contactar al cliente cuando es necesario Evita reincidencias por validación incompleta
Incluir pruebas objetivas Respalda auditorías y reduce rechazos
Documentar paso a paso Mejora la trazabilidad del cierre

⚠️ Errores comunes

  • Dejar el ticket en WO Resolved sin acción inmediata.
  • No realizar validación técnica.
  • Cerrar sin contactar al cliente cuando era obligatorio.
  • Ir a "Resuelto" sin pruebas → riesgo de reincidencias.

⚙️ Lógica Operativa

  1. Inicio: el grupo técnico marca “Resuelto”.
  2. Responsabilidad CNOC: validación técnica completa y decisión de cierre.
  3. Medición KPI: tiempo desde WO Resolved hasta cambio de etapa.
  4. Validación: pruebas técnicas, contacto cliente, evidencias documentadas.

🧩 Etapa: Pendiente Cliente

🧾 Definición

Esta etapa se utiliza cuando el CNOC ha retomado el ticket tras la resolución técnica (WO Resolved), pero necesita realizar pruebas con el cliente final o espera confirmación directa para validar completamente el restablecimiento del servicio.

🎯 Objetivo de la etapa

Permitir que el CNOC realice:

  • Pruebas con personal del cliente (on-site o remoto).
  • Validaciones de servicios desde equipos finales (routers, switches, servidores, etc.).
  • Confirmación verbal o escrita del cliente sobre la recuperación del servicio.

📈 ¿Afecta al KPI CNOC?

❌ No afecta, siempre que esté bien justificada:

  • No penaliza KPIs si se justifica con:
    • Registro de intentos de contacto
    • Evidencia de llamada/WhatsApp
    • Notas en ticket indicando espera de respuesta
  • Penaliza si:
    • No hay justificación en el ticket
    • Ticket permanece inactivo en esta etapa
    • No se documentan medios/contactos

🔧 Acciones esperadas del N1

  • Llamar al cliente e indicar motivo de validación
  • Documentar la hora del intento de contacto
  • Registrar nombre de persona o anotar “cliente no responde”
  • Reintentar cada 30–60 min
  • Escalar internamente si cliente no responde por varias horas

📌 Buenas prácticas

Acción Resultado
Registrar cada intento de contacto Justifica uso de la etapa
Anotar nombre, hora y canal Protección ante auditorías
Utilizar campos del ticket Mejor trazabilidad
Escalar si cliente no responde Evita bloqueos por SLA

⚠️ Errores comunes

  • No documentar al cambiar a esta etapa
  • Asumir que esta etapa excluye automáticamente del KPI
  • No hacer seguimiento periódico
  • Cerrar sin validar con el cliente

⚙️ Lógica Operativa

  1. Inicio: cuando el CNOC recibe el ticket como WO Resolved y no puede validar con cliente.
  2. No afecta KPI si: se documenta intento de contacto con prueba (registro, captura, nota).
  3. Fin: el cliente responde y se valida servicio. El ticket puede pasar a:
    • Resuelto
    • Monitoreo
    • Reabierto
  4. Validación: prueba técnica y contacto registrado con hora, nombre, canal.

🧩 Etapa: Monitoreo

🧾 Definición

La etapa de Monitoreo se utiliza cuando el servicio ha sido técnicamente restablecido y validado, pero el CNOC o el cliente solicitan observar la estabilidad del enlace o servicio durante un período determinado antes de cerrar el ticket definitivamente.

🎯 Objetivo de la etapa

Permitir una observación proactiva y preventiva del enlace para garantizar que el servicio no presente intermitencias o fallas recurrentes, evitando el cierre prematuro del ticket.

📈 ¿Afecta al KPI CNOC?

❌ No afecta, siempre que esté justificada:

  • ✅ No penaliza KPIs si:
    • El servicio ya fue restablecido
    • Existe justificación técnica o por parte del cliente
    • Hay evidencia de monitoreo activo
  • ❌ Afecta si:
    • Se usa sin razón válida
    • No hay seguimiento o justificación

🔧 Acciones esperadas del N1

  • Configurar herramientas de monitoreo
  • Observar alarmas, pérdidas de paquetes o caídas
  • Documentar en el ticket razón y duración estimada del monitoreo
  • Finalizar el ticket o volver a abrirlo según resultado del monitoreo

📌 Buenas prácticas

Acción Resultado
Especificar duración del monitoreo Evita permanencia excesiva
Documentar herramientas y parámetros Mejora trazabilidad
Contactar al cliente al finalizar Valida satisfacción y cierre adecuado
Monitoreo de 24h para enlaces críticos Reduce reincidencias

⚠️ Errores comunes

  • Dejar tickets en Monitoreo sin plazo definido
  • No realizar pruebas reales
  • No cerrar después del tiempo observado
  • No avisar al cliente antes del cierre

⚙️ Lógica Operativa

  1. Inicio: tras validación técnica o solicitud del cliente
  2. Requiere: acuerdo previo y justificación
  3. Fin: al finalizar período observado (24/48h), o antes si hay nuevas fallas
  4. Validación: logs, capturas de tráfico, estabilidad reportada

🧩 Etapa: Dictamen

🧾 Definición

La etapa Dictamen se asigna a un ticket cuando el cliente solicita un informe formal o documento técnico que detalle el diagnóstico, acciones tomadas y resolución del incidente. Es una etapa administrativa y documental.

🎯 Objetivo de la etapa

Generar y entregar al cliente un documento que:

  • Explique técnicamente lo sucedido con el servicio
  • Incluya las acciones correctivas realizadas
  • Sirva como respaldo para auditorías internas o mejora continua

📈 ¿Afecta al KPI CNOC?

❌ No afecta, bajo ninguna condición:

  • La solución técnica ya fue aplicada y validada
  • No hay acciones pendientes sobre el servicio
  • Proceso documental independiente a los KPIs operativos

🔧 Acciones esperadas del N1

  • Recolectar detalles técnicos (logs, pruebas, capturas)
  • Consultar a otras áreas si se requiere contenido adicional
  • Redactar el dictamen en formato requerido (generalmente PDF)
  • Enviar por el canal solicitado (correo, portal, etc.)
  • Registrar en el ticket la entrega y contenido

📌 Buenas prácticas

Acción Resultado
Redactar con lenguaje técnico claro Aumenta credibilidad ante el cliente
Incluir capturas de pruebas y alarmas Facilita comprensión del diagnóstico
Documentar tiempos y acciones paso a paso Respalda auditoría y trazabilidad
Registrar fecha y canal de entrega Facilita auditoría y control

⚠️ Errores comunes

  • No entregar el dictamen en el tiempo comprometido
  • Lenguaje poco claro o sin sustento técnico
  • No registrar el envío del documento en el sistema
  • Suponer que reinicia el ciclo de solución (no es así)

⚙️ Lógica Operativa

  1. Inicio: a solicitud del cliente, una vez validada la solución
  2. Responsabilidad: del CNOC generar o coordinar la elaboración
  3. Medición: no cuenta en KPIs pero puede ser auditado
  4. Validación:
    • Documento entregado
    • Registro en el ticket con fecha, canal y contenido
    • Confirmación de recepción por parte del cliente

🧩 Etapa: WO Pendiente Proveedor (sin proveedor asignado)

🧾 Definición

Esta etapa se utiliza cuando se ha determinado que la falla requiere la intervención de un proveedor externo, pero aún no ha sido asignado un técnico o grupo específico de dicho proveedor. Es común en casos que involucran enlaces arrendados, infraestructura externa o mantenimientos fuera del alcance interno.

🎯 Objetivo de la etapa

Esperar a que el proveedor:

  • Asigne personal técnico
  • Confirme disponibilidad o ETA
  • Inicie formalmente la intervención

📈 ¿Afecta al KPI CNOC?

❌ No afecta, siempre que esté correctamente justificado y documentado:

  • No penaliza si:
    • El proveedor está registrado en la WO
    • Se adjunta evidencia de contacto (correo, WhatsApp, sistema)
    • Hay seguimiento y escalación si el proveedor no responde
  • Penaliza si:
    • No hay proveedor registrado
    • No se documenta la solicitud formal
    • No se hace seguimiento ante retraso

🔧 Acciones esperadas del N1

  • Registrar al proveedor en la WO
  • Contactar formalmente al proveedor
  • Documentar nombre, fecha y hora del contacto
  • Realizar seguimiento y escalar si no hay respuesta
  • Verificar si el proveedor asigna técnico para actualizar etapa

📌 Buenas prácticas

Acción Resultado
Documentar la solicitud formal al proveedor Justifica el uso de esta etapa y protege el KPI
Actualizar la orden con el nombre del proveedor Activa monitoreo y trazabilidad
Escalar si no hay respuesta o asignación Justifica el tiempo de espera
Registrar toda la gestión en el ticket Aumenta trazabilidad y defensa operativa

⚠️ Errores comunes

  • Marcar esta etapa sin haber solicitado atención
  • No registrar al proveedor en la orden
  • Dejar esta etapa activa sin seguimiento
  • Asumir que no cuenta tiempo sin justificarlo

⚙️ Lógica Operativa

  1. Inicio: Cuando se cambia a esta etapa en el sistema y no hay proveedor asignado aún.
  2. Condición para no afectar KPI: El CNOC debe demostrar traslado de responsabilidad y documentación del contacto.
  3. Fin: Cuando el proveedor asigna técnico → etapa cambia a WO Assigned o WO Worker Assigned.
  4. Validación: Nombre registrado, evidencia de contacto, y registro de seguimiento.

🧩 Etapa: Pendiente Otros

🧾 Definición

La etapa Pendiente Otros se utiliza para tickets asociados a eventos masivos o situaciones especiales, donde el incidente no puede ser gestionado individualmente debido a que:

  • Hay múltiples servicios afectados
  • Se requiere coordinación entre múltiples áreas o equipos
  • La solución depende de una condición externa (ej. tormentas, vandalismo, cortes eléctricos)

🎯 Objetivo de la etapa

Congelar temporalmente el tiempo del ticket mientras se atiende un incidente mayor, bajo un plan de contingencia centralizado. Permite al CNOC administrar recursos sin ser penalizado individualmente por cada ticket vinculado al mismo evento raíz.

📈 ¿Afecta al KPI CNOC?

  • ❌ No afecta si:
    • El incidente está vinculado a un evento masivo real y documentado
    • Se deja evidencia clara en el ticket sobre la causa raíz
    • El ticket se asigna a un grupo de seguimiento masivo
  • ❌ Afecta si:
    • Se usa para un caso individual sin justificación
    • No se registra adecuadamente el contexto
    • No hay seguimiento continuo del caso

🔧 Acciones esperadas del N1

  • Verificar con supervisión si el ticket corresponde a una afectación mayor
  • Cambiar a esta etapa solo con confirmación de masividad
  • Documentar:
    • Nombre del evento
    • Área afectada
    • Estado de avance del evento
  • Actualizar periódicamente el estado del ticket

📌 Buenas prácticas

Acción Resultado
Documentar nombre del evento (ej. “Falla Masiva TGU”) Justifica el uso de esta etapa
Vincular a un reporte de falla central Refuerza trazabilidad técnica
Registrar condiciones externas (tormenta, corte eléctrico) Protege el KPI CNOC
Actualizar cada 4–6 horas el estado Mejora la gestión del backlog

⚠️ Errores comunes

  • Usar esta etapa como excusa sin justificación técnica
  • No vincular el ticket al evento mayor en la documentación
  • No escalar si la afectación persiste
  • Dejar el ticket indefinidamente en esta etapa sin resolución

⚙️ Lógica Operativa

  1. Inicio: Solo tras validación de que es parte de una afectación masiva
  2. Condición para no afectar KPI: Registro claro del evento, monitoreo y actualización constante
  3. Fin: Cuando el evento se resuelve y se puede trabajar individualmente
  4. Validación: Nombre del evento, capturas, trazas, avance documentado

🧩 Etapa: Resuelto

🧾 Definición

La etapa Resuelto indica que el CNOC ha validado la recuperación completa del servicio y considera que el incidente ha sido solucionado técnica y operativamente. El ticket se encuentra listo para ser cerrado, pero aún permanece activo por procesos internos o validación de terceros (cliente, supervisión, etc.).

🎯 Objetivo de la etapa

  • Confirmar que el servicio está operativo
  • Validar con el cliente (si aplica)
  • Registrar pruebas técnicas
  • Asegurar que no hay acciones pendientes del CNOC

📈 ¿Afecta al KPI CNOC?

❌ No afecta, siempre y cuando:

  • El tiempo total hasta esta etapa esté dentro de los rangos establecidos
  • No haya retrasos previos sin justificación

🔧 Acciones esperadas del N1

  • Realizar validación final del enlace
  • Confirmar con el cliente que el servicio está estable
  • Registrar evidencia (comandos, monitoreo, conversación)
  • Documentar la causa raíz y solución

📌 Buenas prácticas

Acción Resultado
Contactar al cliente antes de marcar como resuelto Evita reincidencias
Anexar evidencia técnica del restablecimiento Mejora trazabilidad y reduce auditorías
Indicar causa raíz y solución aplicada Documentación clara para futuro
Informar internamente que se pasará a cierre Sincronización con otros equipos

⚠️ Errores comunes

  • Marcar como resuelto sin pruebas o validación
  • No contactar al cliente si aplica
  • Cerrar directamente sin pasar por esta etapa
  • No registrar el resumen técnico del caso

⚙️ Lógica Operativa

  1. Inicio: Luego de validaciones internas y/o con cliente
  2. Condición: Confirmación de que no hay fallas y documentación completa
  3. Fin: Cuando el ticket se cierra formalmente (pasa a “Closed”)
  4. Validación: Capturas, comandos técnicos, contacto cliente, resumen técnico

🧩 Etapa: Closed

🧾 Definición

La etapa Closed marca el fin oficial del ticket. No se permiten más modificaciones ni se generan tiempos. Es el cierre administrativo y final del proceso.

🎯 Objetivo de la etapa

  • Finalizar formalmente el caso en el sistema
  • Habilitar evaluación de KPIs
  • Generar reportes históricos
  • Permitir auditorías de solución y documentación

📈 ¿Afecta al KPI CNOC?

❌ No afecta.

  • Al ser una etapa final, no tiene impacto en ningún KPI de tiempo o reincidencia

🔧 Acciones esperadas del N1

  • Verificar que todo esté correctamente documentado
  • Asegurarse que el cierre no sea prematuro
  • Incluir resumen técnico si no se hizo antes

📌 Buenas prácticas

Acción Resultado
Revisión final del ticket Asegura calidad y consistencia
Verificar que el ticket no tiene tareas abiertas Evita reclamos o reactivaciones
Dejar evidencia técnica clara Mejora procesos de retroalimentación

⚠️ Errores comunes

  • Cerrar sin pasar por “Resuelto”
  • No incluir resumen o pruebas de solución
  • Cerrar sin validación del cliente (si aplica)

⚙️ Lógica Operativa

  1. Inicio: Una vez validado todo el proceso y sin pendientes
  2. Condición: Confirmación de resolución completa y sin tareas abiertas
  3. Post-cierre: Solo puede reabrirse por reincidencia o revisión especial