Diccionario de Indicadores

📅 Cobertura histórica de datos

El dashboard carga registros históricos procesados desde los archivos de scrapping. Los cortes de fecha difieren por fuente porque el uso de cada sistema arrancó en momentos distintos.

Módulo	Sistema / Fuente	Desde	Hasta	Registros	Formatos OS incluidos
🔧 Con visita	iClass + Suricata Cx	Junio 2025	Junio 2026	24.020 OS	suricata-NNN · TIK.XXXXXX · numérico 12 dígitos
📞 Sin visita	Suricata Tickets Cerrados	Enero 2026	Junio 2026	25.546 tickets	tickets numéricos Suricata (6 dígitos)
🏗️ Instalaciones	iClass + MicroWisp	Junio 2025	Junio 2026	6.285 OS	INST.XXXXXX · INS.XXXXXX

🏗️

OS de infraestructura vs OS de cliente (módulo Con visita)

Las OS de formato numérico (101039XXXXXXXX) incluyen dos categorías con ciclos de vida distintos

OS de infraestructura de red infra: true · ~1.774 OS
Trabajos internos de la empresa sin relación con abonados: montaje de nodos/CTO, tendido de fibra, fusión óptica, mantenimiento preventivo/correctivo de red, tareas generales, relevamientos. Pueden quedar abiertas semanas antes de cerrarse administrativamente, lo que genera T5 de 100–700h que distorsionan las métricas de atención al cliente.

OS de cliente sin ticket Suricata infra: false · ~2.133 OS
Visitas a domicilios de abonados que se crearon directamente en iClass sin pasar por Suricata: devolución de equipos, retiros, migraciones tecnológicas, visitas técnicas. Se incluyen en las métricas normales.

⚙️ En el dashboard: cada registro NT_VIS lleva el campo infra: true/false. El Comparativo de Tiempos excluye las OS de infraestructura por defecto. El botón 🏗️ Incluir infraestructura en los filtros permite activarlas para análisis de la operación de red.

📅

¿Por qué difieren los cortes?

Cada sistema empezó a usarse en distinto momento

iClass desde junio 2025: los archivos mensuales exportados cubren desde 25.6.xls. Los meses anteriores (oct 2024–may 2025) tienen muy bajo volumen (1–18 OS/mes), que corresponden a pruebas o casos de borde, no a operación real.

Suricata tickets desde enero 2026: el sistema de ticketing remoto no se usaba masivamente hasta marzo 2026. Entre sep 2024 y dic 2025 solo existen 53 tickets en total. El volumen real arranca en enero 2026 (~90 tickets/mes) y explota en marzo 2026 (~3.039/mes).

Churn y cobranza: datos disponibles según disponibilidad del scrapping de MicroWisp y Soft System, sin corte histórico especial.

Formato de OS iClass por período

Período	Formato OS	Join con Suricata	Módulo destino
Jun–Nov 2025	TIK.XXXXXX	Suricata Cx → columna Ticket	Con visita
Jun–Nov 2025	INS.XXXXXX	MicroWisp → ID	Instalaciones
Oct 2025 →	suricata-NNN	Suricata Cx → #orden	Con visita
Nov 2025 →	INST.XXXXXX	MicroWisp → ID	Instalaciones
Todo el período	101039XXXXXXXX (12 dígitos)	Sin vínculo Suricata	Con visita (iClass-only)

📁 Archivos fuente

Todos los indicadores se derivan de estos archivos exportados manualmente (scraping 2×/día). Ningún sistema está integrado entre sí; los cruces se hacen en la plataforma con joins por código de cliente u orden.

iClass

relatorio_excel.xls

Sistema: iClass (ICAS) · Órdenes de servicio

engine='xlrd', header=2

Suricata Cx

Suricata Cx (2).xlsx

Sistema: Suricata · Tickets cerrados (con visita)

header=1

Suricata Tk

Suricata Tickets Cerrados.xlsx

Sistema: Suricata · Tickets sin visita

header=1

MicroWisp

Lista de Instalaciones (11).xlsx

Sistema: MicroWisp / Soluciones · Instalaciones

Excel 2

Usuarios

Lista de Usuarios - 2026-03-19.xlsx

Sistema: MicroWisp / Soluciones · Base de clientes

Excel 1 · col A=Codigo, C=Nombre

Billing

Archivo de Clientes con Saldo.xlsx

Sistema: Soft System (ERP) · Facturación y saldos

Excel 3 · col G=Grupo_Cliente

Clave de join entre sistemas

iClass["OS"] → extrae orden_id con regex suricata\d?-(\d+) → join con Suricata_Cx["#orden"]
Ejemplo: "suricata2-18450" → orden_id = 18450
Cobertura del join: ~98% de las OS tienen match. El 2% restante son OS sin ticket Suricata vinculado (se excluyen de NT_VIS).

🔧 Indicadores de tiempo — Con visita técnica

Aplican solo a OS de iClass que tienen un ticket Suricata vinculado. Son los casos donde el reclamo no pudo resolverse de forma remota y requirió enviar un técnico al domicilio. El dataset base (NT_VIS) tiene 1.072 OS válidas de mayo 2026 y es resultado del join iClass × Suricata Cx por número de orden.

Línea de tiempo completa — flujo del cliente

Creado
Suricata Cx

Cliente contacta

T1

Solicitación
iClass

OS creada

T2 ⬛ 75%

Programación
iClass

Técnico agendado

T3 min

Final Desplaz.
iClass

Llega al domicilio

T4 min

Fin visita
iClass

Técnico termina

T5

Cierre
iClass

Coord. aprueba

T6 ≈0

Cerrado
Suricata Cx

Cliente cerrado

◄──────────────────────────── T_TOTAL (cubre todo el arco: Suricata Creado → Suricata Cerrado) ────────────────────────────►

T1

Respuesta interna horas

¿Cuánto tardó el equipo en crear la OS desde que el cliente abrió el ticket?

Trazabilidad de campos

Inicio

Creado → Suricata Cx (2).xlsx · Suricata

Fin

Solicitación → relatorio_excel.xls · iClass · header=2

Fórmula

T1 = iClass["Solicitación"] − Suricata_Cx["Creado"]

Resultado en horas (segundos / 3600).
Join previo: iClass["OS"] → orden_id → Suricata_Cx["#orden"].

Qué mide conceptualmente: El tiempo de decisión y derivación interna. Cubre desde que el cliente reporta el problema hasta que el agente de Suricata evalúa que no puede resolverlo de forma remota y crea la Orden de Servicio en iClass. Incluye el tiempo de espera del cliente en la cola de atención más el tiempo de evaluación del agente.

T2

Espera de agenda horas ⬛ ~75% del total

¿Cuánto tiempo esperó la OS en cola hasta tener técnico y fecha asignados?

Trazabilidad de campos

Inicio

Solicitación → relatorio_excel.xls · iClass

Fin

Programación → relatorio_excel.xls · iClass

Fórmula

T2 = iClass["Programación"] − iClass["Solicitación"]

Ambos campos del mismo archivo.
La OS queda "en cola" entre ambas fechas.

Qué mide conceptualmente: El tiempo que la OS pasa esperando en la cola de Logística hasta que alguien le asigna un técnico disponible con fecha y hora de visita. Es el cuello de botella dominante del proceso: representa aproximadamente el 75% del tiempo total de resolución. Reducir T2 tiene mayor impacto en la experiencia del cliente que cualquier otro indicador.

T3

Viaje del técnico minutos

¿Cuánto tardó el técnico en llegar al domicilio del cliente?

Trazabilidad de campos

Inicio

Temprano Desplazamiento → relatorio_excel.xls · iClass (app móvil)

Fin

Final Desplazamiento → relatorio_excel.xls · iClass (app móvil)

Fórmula

T3 = iClass["Final Desplazamiento"] − iClass["Temprano Desplazamiento"]

Resultado en minutos (segundos / 60).
El técnico registra ambos eventos desde la app iClass en su celular.

Qué mide conceptualmente: El tiempo de tránsito del técnico desde que sale del punto anterior (u oficina) hasta que llega al domicilio del cliente. Depende de la zona geográfica y la carga de la ruta del día. Los técnicos registran estos eventos manualmente desde la app.

⚠ Nota de calidad: Algunos técnicos no registran el desplazamiento en la app → T3 = 0 o negativo. Se excluyen del cálculo: filtro: T3 > 0. El porcentaje de registros válidos varía por técnico.

T4

Trabajo en domicilio minutos

¿Cuánto tiempo trabajó el técnico en el domicilio del cliente?

Trazabilidad de campos

Campo

Tiempo en Visita (Minutos) → relatorio_excel.xls · iClass · col 29 · precalculado por el sistema

Fórmula

T4 = iClass["Tiempo en Visita (Minutos)"]

Campo precalculado por iClass (columna 29 del export). El sistema lo calcula internamente como Entrada→Salida y lo almacena directamente.
Desde v24 del dashboard se usa este campo en lugar de calcular Salida−Entrada manualmente, eliminando los falsos outliers por Salida no registrada en la app.

Qué mide conceptualmente: El tiempo de trabajo activo del técnico en el sitio. Es el único indicador que representa trabajo real sobre el problema; todos los demás son tiempos de espera, tránsito o burocracia. En los casos de "cliente ausente" (impacto), T4 ≈ 0 porque el técnico no pudo ingresar a trabajar.

⚠ Calidad de datos: T4 = 0 cuando el técnico no registró actividad en la app (cliente ausente, cancelación, etc.) — estos casos se incluyen en el análisis. Los valores extremos T4 > 1.440 min (24 h) se marcan como sospechosos en la vista 🚩 errores. Hasta v23 se calculaba como Salida−Entrada, lo que generaba falsos valores imposibles cuando el técnico no registraba la Salida.

T5

Aprobación del coordinador horas

¿Cuánto tardó el coordinador en revisar y cerrar la OS después de que el técnico la marcó como terminada?

Trazabilidad de campos

Inicio

Fecha Cierre Por Técnico → relatorio_excel.xls · iClass (app móvil)

Fin

Cierre → relatorio_excel.xls · iClass (escritorio)

Quién

Cerrado Por → relatorio_excel.xls · iClass · username del coordinador

Fórmula

T5 = iClass["Cierre"] − iClass["Fecha Cierre Por Técnico"]

Resultado en horas.
"Cerrado Por" se usa para el análisis por coordinador (excluye prefijo INRE*).

Qué mide conceptualmente: La demora burocrática de aprobación posterior al trabajo de campo. El técnico terminó, el cliente esperaría que su problema ya esté resuelto, pero el ticket sigue abierto hasta que el coordinador revisa y aprueba en el sistema. Hay una brecha marcada entre coordinadores: algunos aprueban en ~1h, otros tardan 17–20h. Identifica ineficiencias en el proceso de supervisión.

⚠ El campo Cerrado Por puede contener usernames del sistema con prefijo INRE (ej: INREASALDIVAR). Se excluyen del análisis por coordinador porque son cierres automáticos del sistema, no aprobaciones humanas.

⚠ Cierre en lote (batch-close): iClass registra el mismo Cierre para múltiples OS en ciertos días administrativos, aunque la FCT de cada OS sea de días o semanas atrás. Esto produce T5 de 100–500 h en esas OS. Los casos con T5 > 168 h (7 días) se marcan como sospechosos y se excluyen de la vista normal del detalle en el dashboard — aparecen en la vista 🚩 errores para trazabilidad. La mediana del Comparativo no se ve afectada (< 0.05 h de variación). Ejemplo mayo 2026: 10 OS afectadas sobre 1.717, con Cierre en lote los días 13/05, 14/05 y 26/05.

T6

Cierre en Suricata horas mediana ≈ 0

¿Cuánto tiempo transcurrió entre el cierre en iClass y el cierre del ticket en Suricata?

Trazabilidad de campos

Inicio

Cierre → relatorio_excel.xls · iClass

Fin

Cerrado → Suricata Cx (2).xlsx · Suricata

Fórmula

T6 = Suricata_Cx["Cerrado"] − iClass["Cierre"]

Cruza dos sistemas distintos: iClass y Suricata.

Qué mide conceptualmente: El desfase entre el cierre administrativo interno (iClass) y el cierre que ve el sistema de tickets del cliente (Suricata). En la práctica este valor es casi siempre 0 o muy cercano a 0, lo que indica que ambos sistemas se sincronizan prácticamente en simultáneo. Se mantiene en el flujo como indicador de monitoreo: si algún día T6 empieza a crecer, significa que hay un proceso manual desincronizado.

TT

Tiempo punta a punta (con visita) horas

¿Cuánto tiempo total pasó el cliente esperando resolución, desde que contactó hasta que su caso se cerró?

Trazabilidad de campos

Inicio

Creado → Suricata Cx (2).xlsx · Suricata · momento de contacto del cliente

Fin

Cerrado → Suricata Cx (2).xlsx · Suricata · cierre del ticket

Fórmula

T_total = Suricata_Cx["Cerrado"] − Suricata_Cx["Creado"]

Ambos campos del mismo archivo. Filtro de calidad: 0h < T_total < 500h.

Qué mide conceptualmente: El tiempo de experiencia del cliente. A diferencia del resto de los indicadores que vienen de iClass, el T_total usa únicamente Suricata, que representa el tiempo real que el cliente espera: desde que abrió el contacto hasta que le llegó la confirmación de cierre. T_total ≈ T1 + T2 + T3 + T4 + T5 + T6 + micro-gaps entre etapas.

⚠ Filtro de outliers: T_total < 0 → timestamp de cierre anterior al de apertura (error de carga). T_total > 500h → tickets reabiertos de meses anteriores. Ambos se excluyen.

📞 Indicadores de tiempo — Sin visita (resolución remota)

Tickets de Suricata que se cerraron sin generar una OS en iClass. El agente resolvió el reclamo de forma remota (guía al cliente, reinicio remoto de equipo, configuración, etc.). El dataset (NT_SIN) proviene únicamente de Suricata.

RES

Tiempo de resolución remota horas

¿Cuánto tardó el agente en resolver el ticket sin necesidad de enviar un técnico?

Trazabilidad de campos

Inicio

Creado → Suricata Tickets Cerrados.xlsx · Suricata

Fin

Cerrado → Suricata Tickets Cerrados.xlsx · Suricata

Quién

Asignado a → Suricata Tickets Cerrados.xlsx · nombre del agente

Área

Area → Suricata Tickets Cerrados.xlsx · cola de atención (Soporte, Visita técnica, Ventas, etc.)

Motivo

topic → Suricata Tickets Cerrados.xlsx · motivo de contacto (Sin Servicio, Consulta Adm., etc.)

Fórmula

RES = Suricata_Tk["Cerrado"] − Suricata_Tk["Creado"]

Resultado en horas. Un ticket en NT_SIN es aquel presente en Suricata Tickets Cerrados pero sin correspondencia en el join con iClass.

Qué mide conceptualmente: El tiempo total de atención remota. A diferencia del flujo con visita (que pasa por iClass), aquí todo ocurre dentro de Suricata. El agente recibe el ticket, lo trabaja directamente con el cliente, y lo cierra sin derivación a campo. El campo Area indica en qué cola cayó el ticket, no si se realizó una visita: un ticket en el área "Visita técnica" puede haberse resuelto de forma remota (el agente lo evaluó y lo resolvió sin visita).

🏗️ Indicadores de tiempo — Instalaciones

OS de iClass del tipo "Instalación" cruzadas con datos de MicroWisp. El flujo es distinto al de soporte: no hay T1 (no hay ticket Suricata previo) ni T3 (el técnico ya va directo a instalar). Los indicadores T2, T4 y T5 se calculan con la misma lógica que en el flujo de soporte pero sobre las OS de instalación.

T2

Espera de agenda (instalación) horas

¿Cuánto esperó la solicitud de instalación hasta tener técnico y fecha asignados?

Trazabilidad de campos

Inicio

Solicitación → relatorio_excel.xls · iClass

Fin

Programación → relatorio_excel.xls · iClass

Fórmula

T2 = iClass["Programación"] − iClass["Solicitación"]

Misma fórmula que en soporte, aplicada a OS de tipo Instalación.

Qué mide conceptualmente: El tiempo entre que se crea la OS de instalación (generalmente al firmar el contrato o pagar) y que Logística asigna un técnico con fecha concreta. Equivale al "plazo de entrega del servicio" desde el punto de vista del cliente nuevo.

T4

Trabajo en sitio (instalación) minutos

¿Cuánto tiempo tardó el técnico en completar la instalación?

Trazabilidad de campos

Campo

Tiempo en Visita (Minutos) → relatorio_excel.xls · iClass · col 29 · precalculado por el sistema

Fórmula

T4 = iClass["Tiempo en Visita (Minutos)"]

Campo precalculado por iClass (columna 29). Desde v24 del dashboard se usa este campo en lugar de Salida−Entrada, eliminando falsos outliers por Salida no registrada.

Qué mide conceptualmente: El tiempo de trabajo de campo para completar la instalación física del servicio (cableado, configuración de router, prueba de señal, etc.). Es útil para planificación de rutas y productividad del técnico.

T5

Cierre administrativo (instalación) horas

¿Cuánto tardó el coordinador en cerrar la OS de instalación después de que el técnico terminó?

Trazabilidad de campos

Inicio

Fecha Cierre Por Técnico → relatorio_excel.xls · iClass

Fin

Cierre → relatorio_excel.xls · iClass

Fórmula

T5 = iClass["Cierre"] − iClass["Fecha Cierre Por Técnico"]

Qué mide conceptualmente: La demora entre que el técnico termina la instalación y el coordinador la oficializa en el sistema. Hasta que esto ocurre, el cliente técnicamente "no está dado de alta" en el sistema. T5 alto en instalaciones impacta directamente en cuando el cliente puede empezar a usar el servicio y cuando empieza a facturarse.

TT

Total instalación (punta a punta) horas

¿Cuánto tardó el proceso completo de instalación desde que se agendó hasta que se cerró?

Trazabilidad de campos

Inicio

Solicitación → relatorio_excel.xls · iClass (OS de instalación)

Fin

Cierre → relatorio_excel.xls · iClass

Qué mide conceptualmente: A diferencia del T_total de soporte (que usa Suricata), el T_total de instalaciones usa solo iClass porque no hay ticket Suricata previo. Cubre desde que se crea la OS de instalación hasta su cierre definitivo. Es el "lead time" de instalación: el plazo que experimenta el cliente desde que se le confirma la cita hasta que tiene el servicio activo.

📉 Indicadores de Churn / Caída de clientes

Seguimiento de bajas, suspensiones y retiros. Toda la información proviene del campo Tipo_Cliente del archivo de Billing, que codifica el estado del cliente y el período de la baja dentro del mismo string.

RetD

Retiro por deuda

¿Cuántos clientes fueron dados de baja y retirados el equipo por falta de pago?

Trazabilidad de campos

Campo

Tipo_Cliente → Archivo de Clientes con Saldo.xlsx · Soft System (Billing) · columna G

Fórmula / filtro

RetD_mes = COUNT(clientes donde Tipo_Cliente CONTIENE 'RetD' + MesAño) Ejemplo: "L212RetDFeb26" → retiro por deuda en febrero 2026

El mes y año de la baja van embebidos en el código: RetDFeb26, RetDMar26, etc.

Qué mide conceptualmente: Clientes que cumplieron el ciclo completo de morosidad: 1 mes de caída → suspensión → 2 meses de caída → baja definitiva + retiro de equipo. El dato se lee del código del tipo de cliente en Billing, donde el mes de la baja está incorporado al string.

RetV

Retiro voluntario

¿Cuántos clientes pidieron darse de baja por decisión propia?

Trazabilidad de campos

Campo

Tipo_Cliente → Archivo de Clientes con Saldo.xlsx · Soft System (Billing) · columna G

Qué mide conceptualmente: Bajas solicitadas por el propio cliente (no por deuda). El código del Tipo_Cliente contiene 'RetV' + mes/año. La suma RetD + RetV = caídas totales del período. Distinguir ambos tipos permite saber si el churn es por problemas económicos del cliente (RetD) o por disconformidad con el servicio (RetV).

SUS

Suspendidos

¿Cuántos clientes están suspendidos actualmente por falta de pago?

Trazabilidad — Fuente principal

Campo

Status → Lista de Usuarios.xlsx · MicroWisp · valor "OFFLINE"

Alt.

Fecha suspendido → Lista de Usuarios.xlsx · MicroWisp · tiene fecha si fue suspendido

Alt.

Tipo_Cliente → Clientes con Saldo.xlsx · Billing · valor "Inactivo/Sus Admin"

Fórmula

SUS = COUNT(clientes con Status = 'OFFLINE' [MicroWisp] OR Fecha_suspendido IS NOT NULL [MicroWisp] OR Tipo_Cliente LIKE 'Inactivo%' [Billing])

Los suspendidos son clientes en el paso intermedio del ciclo de morosidad: ya cayeron 1 mes, aún no llegaron a los 2 meses para el retiro definitivo.

Qué mide conceptualmente: El stock de clientes en riesgo inminente de baja definitiva. Un cliente suspendido tiene el servicio cortado (OFFLINE en MicroWisp) pero sigue en la base como recuperable. Si en el próximo mes no regulariza, pasa a RetD. Es el indicador de alerta temprana del churn.

💰 Indicadores de Cobranza y Morosidad

Indicadores financieros del período. Fuente confiable para saldos e importes: siempre usar Billing (Soft System). MicroWisp (Usuarios) tiene columnas financieras (Deuda actual, Saldo) pero no son contables; se usan solo para días de atraso y estado de suspensión.

COB

Cobranza total del período

¿Cuánto se cobró en el período seleccionado y por qué medio de pago?

Trazabilidad de campos

Importe

Fact_Mes_1 … Fact_Mes_12 → Archivo de Clientes con Saldo.xlsx · Billing · columnas AE … AP

Medio

Grupo_Cliente → Archivo de Clientes con Saldo.xlsx · Billing · columna G · define medio de pago

Fórmula

Cobranza_total = SUMA(Fact_Mes_N) para N = meses en la ventana seleccionada Por medio = SUMA(Fact_Mes_N) GROUP BY Grupo_Cliente

Grupo_Cliente define el medio: Cupón, Visa, Empresa, etc. Fact_Mes_N son los 12 últimos meses disponibles.

Qué mide conceptualmente: El dinero efectivamente facturado/cobrado en el período. Cada columna Fact_Mes_N corresponde a un mes (N=1 es el más reciente, N=12 el más antiguo). El campo Grupo_Cliente actúa como segmentador por medio de pago, no como tipo de cliente.

MOR

Deuda actual / Morosidad

¿Cuánto se debe y hace cuánto tiempo está en mora cada cliente?

Trazabilidad de campos

Deuda

Deuda actual → Lista de Usuarios.xlsx · MicroWisp · columna AP · formato "2 $ 14.600"

Días

Fecha suspendido → Lista de Usuarios.xlsx · MicroWisp · para calcular días de atraso

Fórmula

Meses_deuda = ENTERO inicial del campo "Deuda actual" (ej. "2 $ 14.600" → 2 meses) Importe_deuda = monto del campo (ej. "2 $ 14.600" → $14.600) Días_atraso = HOY − Fecha_suspendido (si no hay fecha: meses_deuda × 30)

⚠ Las columnas financieras de MicroWisp (AP Deuda actual, AQ Saldo, AS Total cobrar) no son contables. Para saldo confiable usar Billing (col Saldo). Meses/días de atraso solo existen en MicroWisp.

Qué mide conceptualmente: La exposición crediticia de la empresa. El campo Deuda actual de MicroWisp codifica en un solo string tanto el tiempo de mora (entero inicial) como el monto adeudado. Un valor de "2 $ 14.600" indica 2 meses de deuda acumulada por $14.600. El umbral crítico es 2 meses: ahí se activa el retiro del equipo.

📋 Tabla resumen — todos los indicadores

ID	Nombre	Campo inicio	Archivo inicio	Campo fin	Archivo fin	Unidad	Sección
T1	Respuesta interna	Creado	Suricata Cx	Solicitación	iClass	horas	Con visita
T2	Espera de agenda	Solicitación	iClass	Programación	iClass	horas	Con visita
T3	Viaje del técnico	Temprano Desplazamiento	iClass	Final Desplazamiento	iClass	minutos	Con visita
T4	Trabajo en domicilio	Tiempo en Visita (Minutos)	iClass	(precalculado · col 29)	iClass	minutos	Con visita
T5	Aprobación coordinador	Fecha Cierre Por Técnico	iClass	Cierre	iClass	horas	Con visita
T6	Cierre en Suricata	Cierre	iClass	Cerrado	Suricata Cx	horas	Con visita
TT	Punta a punta (con visita)	Creado	Suricata Cx	Cerrado	Suricata Cx	horas	Con visita
RES	Resolución remota	Creado	Suricata Tickets	Cerrado	Suricata Tickets	horas	Sin visita
T2i	Espera de agenda (instalación)	Solicitación	iClass	Programación	iClass	horas	Instalaciones
T4i	Trabajo en sitio (instalación)	Tiempo en Visita (Minutos)	iClass	(precalculado · col 29)	iClass	minutos	Instalaciones
T5i	Cierre admin. instalación	Fecha Cierre Por Técnico	iClass	Cierre	iClass	horas	Instalaciones
TTi	Punta a punta (instalación)	Solicitación	iClass	Cierre	iClass	horas	Instalaciones
RetD	Retiro por deuda	Tipo_Cliente CONTAINS 'RetD'+MesAño				Billing	clientes	Churn
RetV	Retiro voluntario	Tipo_Cliente CONTAINS 'RetV'+MesAño				Billing	clientes	Churn
SUS	Suspendidos	Status='OFFLINE' ó Fecha_suspendido IS NOT NULL				MicroWisp	clientes	Churn
COB	Cobranza total	SUMA(Fact_Mes_N) por Grupo_Cliente				Billing	$	Cobranza
MOR	Deuda actual	Deuda actual (columna AP) → parse "N $ Monto"				MicroWisp	$ / meses	Morosidad

📖 Diccionario de Indicadores