# Parte 5 — Oportunidades (FASE 5)

> Encargo: pensar como Rector, Director TIC, Director de Infraestructura, Coordinador de Laboratorios, Decano y Director Académico. Qué información les gustaría ver, y qué funcionalidades aumentarían muchísimo el valor del producto.
>
> Se presenta primero **lo que cada rol pide de verdad** (con la pregunta literal que hace en una reunión), y después **las 22 oportunidades de producto** ordenadas por valor.

---

## 5.1 Lo que pide cada rol

### El Rector / Vicerrector Administrativo

**Lo que no le interesa:** cuántas reservas hubo.
**Lo que pregunta literalmente:** *«¿Estoy usando lo que pagué?»*, *«¿Cuánto me cuesta un puesto vacío?»*, *«¿Qué facultad consume más de lo que aporta?»*, *«¿Qué le digo al Consejo Superior en tres cifras?»*

| Lo que le gustaría ver | Estado hoy |
|---|---|
| **% de ocupación de la capacidad instalada**, por sede y por tipo de espacio | 🔴 no existe el denominador |
| **Coste de la capacidad ociosa**, en pesos | 🔴 no hay coste/hora por espacio en ninguna tabla |
| **Personas-hora atendidas** y su crecimiento contra el semestre equivalente | 🟡 el dato existe (`CupoConsumido`), nadie lo usa |
| **Cobertura**: qué porcentaje de la población estudiantil usó el servicio | 🔴 falta el total de matriculados y la deduplicación de clientes |
| **% de servicio prestado en remoto** — la narrativa de innovación | 🔴 |
| **Tres cifras para el Consejo**, con una sola fuente de verdad | 🟡 el dashboard ejecutivo no existe; el hub actual no comunica ningún número |

**La oportunidad que le vendería el sistema:** *«Puedo demostrarle, con evidencia auditable, que atendió a N personas-hora usando el X % de su capacidad, y que hay Y millones inmovilizados en equipos que nadie tocó en 90 días.»* Ninguna de esas dos frases se puede decir hoy con los datos disponibles. Ambas están a un habilitador de distancia.

---

### El Director TIC

**Lo que pregunta:** *«¿Qué equipos están fallando?»*, *«¿Cuántas licencias necesito comprar?»*, *«¿El acceso remoto se está usando o lo montamos para nada?»*, *«¿Cuándo se cae el servicio y cuánto tardo en enterarme?»*

| Lo que le gustaría ver | Estado hoy |
|---|---|
| **Disponibilidad (uptime) por equipo y laboratorio**, con MTBF y MTTR | 🔴 el motor (`GuacdProbe`) está construido y no persiste nada |
| **Equipos apagados o inalcanzables ahora mismo**, en semáforo | 🔴 consultable uno a uno, sin UI ni cron |
| **Tasa de fallo de conexión remota y sus causas** | 🔴 Guacamole no persiste fallos por diseño; falta la tabla de intentos |
| **Horas remotas por estudiante y por programa** | 🔴 todos navegan con `guacadmin` |
| **Demanda de software por laboratorio**, para negociar licencias | 🔴 se declara el software disponible, no el usado; y sin versión ni número de licencias |
| **Salud del sistema en una pantalla**: crons, colas, integración Guacamole, errores | 🟡 existen `doctor`, `smoke`, `guac-smoke` y `email-queue --dry-run --json`, **ninguno cableado a una pantalla** |
| **Adopción por módulo** (qué módulos del sistema se usan de verdad) | 🔴 `log_urls` tiene 0 filas |

**El hallazgo que más le va a doler y más le va a servir:** hoy nadie se enteraría de que el servicio de correo está caído. **19 notificaciones llevan meses sin salir y no hay ninguna alerta.** El comando que lo detecta ya existe y devuelve JSON con exit code; sólo hay que programarlo y pintarlo.

**La oportunidad:** convertir los cuatro comandos de diagnóstico existentes en **un panel de salud operativa**. Es trabajo de días y transforma la percepción del sistema de «herramienta administrativa» a «plataforma gestionada».

---

### El Director de Infraestructura / Planta Física

**Lo que pregunta:** *«¿Qué módulo del campus está saturado y cuál está vacío a las 3 de la tarde?»*, *«¿Estoy usando el aforo que pago?»*, *«¿Puedo liberar un edificio?»*, *«¿Cuántos m² por estudiante estoy consumiendo?»*

| Lo que le gustaría ver | Estado hoy |
|---|---|
| **Mapa de calor del campus por edificio y piso** | 🔴 la columna `agendas.Edificio` **fue eliminada deliberadamente** por una migración. En producción anterior había 21 edificios y 46 salones |
| **% de aforo aprovechado** (asistentes reales / capacidad del espacio) | 🔴 `citas` no guarda asistentes |
| **Ocupación en m² y densidad personas/m²** | 🔴 **no existe ningún campo de superficie en ninguna tabla** |
| **Índice de sobredimensión**: grupos pequeños en espacios grandes | 🔴 mismo bloqueo |
| **Horas perdidas por bloqueo, por causa** | 🟡 el dato existe pero el reporte oficial **excluye los bloqueos globales** por un `INNER JOIN`, y el motivo es texto libre |
| **Disponibilidad futura a 30 días** para planear obras y mantenimiento | 🔴 |

**Este es el rol peor servido por el producto actual**, y no por falta de ambición sino por una decisión de modelado: **el «salón» y la «agenda» se fusionaron en una sola fila**. La generación anterior tenía la jerarquía completa Sede → Edificio → Piso → Salón → Equipo, poblada con datos reales (858 puestos en 46 salones). **Recuperarla no es inventar: es restaurar algo que el cliente ya mantenía.**

**La oportunidad de mayor impacto para él:** el **índice de sobredimensión**. Un auditorio de 200 puestos reservado sistemáticamente para 12 personas es el desperdicio más caro y más invisible de una universidad, y hoy el sistema no lo puede ver. Requiere dos cosas: la jerarquía física y **la captura de asistentes** — que en la generación anterior existía como campo y estuvo **100 % vacío**, señal de que hay que resolverlo con proceso (un check-in con conteo), no sólo con esquema.

---

### El Coordinador de Laboratorios

Es el usuario diario. Es quien decide si el sistema se usa o se abandona.

**Lo que pregunta:** *«¿Qué tengo que hacer hoy?»*, *«¿Quién tiene el portátil con serial X ahora mismo?»*, *«¿Qué PC está a punto de morir?»*, *«¿A quién sanciono y a quién le doy una segunda oportunidad?»*, *«¿Abro el sábado?»*

| Lo que le gustaría ver | Estado hoy |
|---|---|
| **Panel del día**: entregas pendientes, aprobaciones por vencer, **préstamos vencidos sin devolver** | 🟡 existe el panel operativo; **le falta lo urgente**: los préstamos vencidos sólo generan un warning en un log |
| **¿Quién tiene qué ahora mismo?**, por serial | 🔴 el serial entregado no se captura (la generación anterior sí lo hacía, con 2.531 sesiones) |
| **Equipos sobreexplotados y ociosos**, con recomendación de rotación | 🟡 el dato de horas agendadas existe; el de horas usadas no |
| **Reincidentes de no-show con su historial**, para decidir la sanción | 🟢 existe y es uno de los mejores reportes |
| **Aviso preventivo al estudiante antes de sancionarlo** | 🔴 hoy **el sistema sanciona sin haber avisado nunca** |
| **Ocupación por franja para decidir horarios y turnos de monitor** | 🟡 el conteo existe; el porcentaje no |
| **Historial de una unidad concreta** | 🔴 **está implementado en backend y no tiene UI** |

**Tres oportunidades de altísimo valor y bajo esfuerzo para este rol:**
1. **Cablear lo que ya existe**: `resourceDetail`, `resourceHistory` y `resourceToggleBlock` están implementados, sus URLs se publican al front, y `board.js` no las consume. Son tres botones.
2. **Añadir «préstamos vencidos» al panel del día.** El servicio ya los detecta; sólo escribe un warning. Convertirlo en tarjeta y alerta es una línea de código y resuelve el riesgo patrimonial más inmediato (en producción, **50,1 % de devoluciones tardías**).
3. **Capturar el serial al entregar.** El campo de configuración existe (`PrestamoInmediatoRequiereSerial`), el flujo lo soporta, y hoy no se persiste como dato consultable.

---

### El Decano

**Lo que pregunta:** *«¿Mi facultad recibe lo que le corresponde?»*, *«¿Mis estudiantes están usando los laboratorios que pedí?»*, *«¿Qué le respondo al par académico en la visita de acreditación?»*, *«¿Qué docente mío está desperdiciando aulas?»*

| Lo que le gustaría ver | Estado hoy |
|---|---|
| **Horas consumidas por su facultad y su % del total institucional** | 🔴 dimensión inexistente |
| **Cobertura**: qué % de sus estudiantes usó el servicio | 🔴 |
| **Uso por programa**, para justificar inversión ante Consejo de Facultad | 🔴 texto libre |
| **Evidencia para acreditación**: horas de laboratorio por estudiante y por programa, con serie histórica | 🔴 |
| **Sus docentes con más no-shows** (conversación incómoda pero necesaria) | 🔴 |
| **Su equidad de acceso frente a otras facultades** | 🔴 |

**El decano es el rol con más presupuesto y el peor servido de todos.** Y aquí está la oportunidad comercial más grande del producto:

> **La evidencia para acreditación.** Un par académico pregunta «¿cuántas horas de laboratorio recibió un estudiante de este programa?». Hoy ninguna universidad puede responder eso con un clic. Un sistema que entregue ese dato con serie histórica por programa **deja de ser un software de reservas y se convierte en un instrumento de acreditación**. Eso cambia quién firma el contrato y cuánto está dispuesto a pagar.

Todo depende del habilitador 3 (dimensión académica), que es trabajo de **días**, no de meses: dos tablas catálogo, una columna `IdPrograma` en `clientes` y un script de mapeo asistido sobre 19 valores distintos (a escala real, unas pocas centenas).

---

### El Director Académico / Registro

**Lo que pregunta:** *«¿La malla de horarios está saturando los espacios?»*, *«¿Cuánta capacidad tengo libre para programar el próximo semestre?»*, *«¿Qué grupos puedo mover para descongestionar?»*

| Lo que le gustaría ver | Estado hoy |
|---|---|
| **Disponibilidad futura por franja para programar el semestre** | 🔴 |
| **Reservas recurrentes vs. espontáneas** (demanda institucional vs. individual) | 🔴 la tabla de recurrencias **no existe en la base** |
| **Choques entre programación académica y demanda libre** | 🔴 |
| **Perfil horario real vs. malla planificada** | 🟡 el perfil existe, la malla no está en el sistema |
| **Efecto de mover un grupo de aula** (simulación) | 🔴 |

**Hallazgo que le concierne directamente:** el perfil horario de producción (**62,2 % de reservas a las 07:00 o 09:00, y sólo 3,9 % entre las 14:00 y las 17:00**) no describe preferencias de usuario: **describe su malla de horarios**. Es una radiografía de la programación académica hecha desde el otro lado, y es información que hoy nadie le está entregando.

**La oportunidad:** un módulo de **simulación de escenarios** («si muevo estos 3 grupos a la tarde, la ocupación pico baja del 94 % al 71 %»). Requiere la capacidad ofertada y las series recurrentes, pero es la funcionalidad que convierte el sistema en herramienta de planeación en lugar de registro.

---

### El Director Financiero (rol no listado, pero es quien aprueba)

**Lo que pregunta:** *«¿Cuánto vale lo que tengo?»*, *«¿Cuánto me cuesta una hora de laboratorio?»*, *«¿Cuánto recuperé del sistema el año pasado?»*

| Lo que le gustaría ver | Estado hoy |
|---|---|
| **Valor del parque y valor inmovilizado** | 🟡 `activos.Valor` es la única medida monetaria del sistema, y la tabla está vacía |
| **Coste por hora de servicio** (presencial vs. remoto) | 🔴 no hay coste/hora en ninguna parte |
| **Depreciación y antigüedad del parque** | 🔴 sin `FechaCompra` ni `VidaUtilMeses`, `Valor` es un monto sin edad |
| **Costo de mantenimiento por activo y % sobre valor de reposición** | 🔴 mantenimiento no existe |
| **Pérdida y daño patrimonial atribuido** | 🔴 en producción esto sí se medía: **226 devoluciones con daño y 101 elementos no devueltos**, atrapados en texto libre |
| **ROI del módulo de acceso remoto** | 🔴 |

**Oportunidad concreta y barata:** cuatro columnas en `activos` (`FechaCompra`, `ValorCompra`, `VidaUtilMeses`, `FinGarantia`) convierten un catálogo estático en un **activo financiero medible**: depreciación, antigüedad, cobertura de garantía y coste por hora de uso. Es la diferencia entre «tengo una lista de equipos» y «tengo un parque gestionado».

---

## 5.2 Las 22 oportunidades de producto, por valor

Ordenadas por **valor de negocio ÷ esfuerzo**. Las cinco primeras cambian la percepción del producto en semanas.

### Nivel 1 — Valor altísimo, esfuerzo bajo (semanas)

**O1. Encender el sistema: programar los tres crons.**
`expire-citas`, `email-queue` y `waitlist expire`. Sin ellos el no-show nunca se materializa, nadie recibe notificaciones y la lista de espera se congela. **Es la intervención de mayor retorno por esfuerzo de toda la plataforma**, y hoy el sistema está funcionalmente congelado sin que nadie lo note. Añadir además `guac-smoke` como healthcheck y documentar los cinco workers en el runbook (hoy no están).

**O2. Panel de salud operativa.**
Cablear a una pantalla lo que ya existe: `bin/doctor`, `bin/smoke --json`, `bin/guac-smoke --json`, `bin/email-queue --dry-run --json` y `bin/expire-citas --dry-run --json` (que ya devuelve `pending_expired`, `confirmed_no_show`, `overdue_return_warned`, `clients_auto_blocked`, `waitlist_notified`, `errors`, `elapsed_ms` — **es prácticamente un endpoint de métricas listo para consumir**). Resultado: nadie vuelve a enterarse por un estudiante de que el correo está caído.

**O3. Cablear las cinco funcionalidades terminadas y sin interfaz.**
`resourceDetail`, `resourceHistory`, `resourceToggleBlock` (tablero de préstamos), `guacConexiones&a=testJson` (sonda de equipo) y `byHour`/`byWeekday` (código muerto en el servicio de estadísticas remotas). Cinco funcionalidades completas esperando un botón. **Es el trabajo de producto más barato disponible.**

**O4. Añadir las urgencias reales al panel del día.**
Préstamos vencidos sin devolver, antigüedad del backlog de aprobación, solicitudes a menos de 24 h de su franja sin decidir, y estado de la cola de correo. Convierte una pantalla informativa en una **lista de trabajo**.

**O5. Corregir los cuatro defectos de reporting.**
(a) Universo unificado `citas` ∪ `citas_canceladas` en todos los KPIs de cancelación. (b) Separar rechazo de expiración con `NegadoPorUserId`. (c) `LEFT JOIN` en cancelaciones y bloqueos (hoy se pierden las cancelaciones de equipos y todos los bloqueos globales). (d) Retirar de la vista el gráfico «por área» y el KPI «tasa de utilización» de activos. **Cuesta horas y evita que un comité decida con cifras falsas.**

### Nivel 2 — Valor alto, esfuerzo medio (1–2 meses)

**O6. Dimensión académica: facultad, programa y periodo.**
Dos tablas catálogo (`facultades`, `programas` con `IdFacultad`, `Nivel`, `Metodologia`), una columna `clientes.IdPrograma` conservando el texto original como origen, y `periodos_academicos (Codigo 'AAAA-1', FechaInicio, FechaFin)` resuelto por join de rango — **sin tocar `citas`**. **Desbloquea 5 de los 30 dashboards solicitados y abre la conversación con decanos.** Es el habilitador de mayor retorno comercial.

**O7. Tabla de capacidad ofertada.**
Materializar los ocho JSON de horario en `agenda_slots_ofertados (IdAgenda, IdAgendaRecurso, Fecha, HoraInicio, HoraFin)` menos bloqueos y festivos, refrescada por job. **Convierte «horas reservadas» en «% de ocupación»** y con ello 8 dashboards pasan de descriptivos a diagnósticos. Es el único KPI que toda universidad pide primero.

**O8. Check-in y captura de asistentes.**
Una acción de llegada (por QR, que ya se genera, o por el mostrador) con hora real y número de asistentes. Habilita: puntualidad real, tasa de asistencia auditable, **% de aforo aprovechado** y la evaluación de la política `BloqueoLlegadaTarde` que hoy es decorativa. **Nota de realismo importante:** la generación anterior tenía los campos (`Llegada`, `Asistencia`, `Asistentes`) y estuvieron **91–100 % vacíos**. El problema no es de esquema, es de proceso: el check-in tiene que ser de un solo gesto o no se hará.

**O9. Unificar los dos inventarios de equipos.**
Decidir un modelo canónico entre `activos` y `agendas_recursos`, con una tabla puente si hace falta convivencia temporal. Sin esto, ningún dashboard de utilización de equipos cubre la operación real, porque el módulo que factura el día a día nunca toca `activos`.

**O10. Registro de intentos de conexión remota.**
Una tabla y una llamada en seis puntos ya identificados en el código. Desbloquea: tasa de éxito de conexión, causas de fallo, embudo reserva→sesión, **cola de mantenimiento priorizada por equipos que fallan**, y —crucialmente— **atribución de la sesión a una persona real** mientras se comparta la cuenta de servicio.

**O11. Sondeo de disponibilidad de equipos.**
Tabla `equipos_sondeos` + cron cada 5 min usando `GuacdProbe`, que ya traduce 12 códigos de error a lenguaje de negocio. Desbloquea uptime, MTBF, MTTR, semáforo en vivo y la alerta de mayor valor del módulo remoto: **«el equipo de tu reserva de las 10:00 está apagado»**.

**O12. Promover el canal de origen a columna.**
`citas.CanalOrigen` (portal / mostrador / quick-create / préstamo inmediato / práctica libre / recurrencia / API). Hoy vive dentro de un JSON. Desbloquea **el KPI de adopción del autoservicio**, que es la métrica de eficiencia más importante para el equipo de operación: cada reserva de autoservicio es una hora-hombre ahorrada.

**O13. Aplicar las tres migraciones pendientes.**
Corregir la migración rota de `clientes_bloqueos` y habilitar lista de espera y series recurrentes. Y en la lista de espera, **añadir la acción de reclamar el cupo**: hoy el estado «Convertida» es inalcanzable y el correo invita a hacer clic en un botón que no existe. **Sin las series recurrentes no se puede distinguir demanda institucional de espontánea**, que es la distinción más importante para planear capacidad.

**O14. Catálogos de motivos.**
Tres catálogos pequeños con enorme efecto analítico: motivo de cancelación, motivo de rechazo y tipo de bloqueo. Hoy los tres son texto libre y en producción el 55,8 % de las cancelaciones no tenía ni comentario.

### Nivel 3 — Valor alto, esfuerzo mayor (trimestre)

**O15. Jerarquía física del campus.**
`edificios` y `salones` (o `espacios_fisicos`) con `Piso`, `Capacidad`, `AreaM2`, `EsAula`, y el anclaje `activos.IdEspacioFisico`. **Recupera datos que el cliente ya mantenía** (21 edificios, 46 salones, 858 puestos) y desbloquea el mapa de calor del campus, la densidad por m² y el índice de sobredimensión.

**O16. Módulo de mantenimiento, mínimo viable.**
Las tres piezas de la Parte 4 (DB-25): historial de estados, órdenes de trabajo reducidas y botón «Reportar falla». Con eso se obtienen MTTR, MTBF, downtime, disponibilidad y costo. **Y elimina el *sniffing* de texto** que hoy deja equipos permanentemente no prestables por un falso positivo en la descripción.

**O17. Documento de préstamo con custodia.**
Recuperar el concepto de orden de salida: fecha+hora de salida, compromiso de retorno y regreso real (**como `datetime`, no `time`**), funcionario que entrega y funcionario que recibe, acompañantes, y estado «Vencida» como dato y no como warning en un log. En producción: **2.559 órdenes, 50,1 % devueltas tarde con 33 horas de retraso medio, 48,6 % derivando en sanción**. Es el proceso de mayor riesgo patrimonial y hoy no existe.

**O18. Identidad nominal en Guacamole.**
Un usuario Guacamole por cliente, con permiso concedido al aprobar y revocado al cerrar la reserva — **el flujo que está especificado en `DISEÑO_SISTEMA.md` §4.13 y quedó sin implementar**. Desbloquea el KPI más vendible del módulo (horas remotas por estudiante y programa) y permite que **Guacamole mismo** haga cumplir la ventana horaria con `access_window_start` / `valid_until`. Cierra además el hallazgo de seguridad IDOR.

**O19. Capa de agregados y dimensión tiempo.**
Tablas `kpis_diarios`, `agg_uso_equipo_dia`, `agg_concurrencia_15min` y `dim_tiempo` con calendario académico, refrescadas por job nocturno con lock y marca de frescura. Es lo que hace que 51 dashboards sean viables sin tumbar la base. Y elimina el patrón actual del dashboard remoto —descargar todo el historial y filtrarlo en memoria— que es **el riesgo que arruina una demo con volumen real**.

### Nivel 4 — Diferenciadores estratégicos

**O20. Motor de reglas y alertas inteligentes.**
Tabla de reglas + evaluación en el job nocturno + los dos canales existentes + **deduplicación anti-fatiga** + registro de si la alerta produjo una acción. Convierte el producto de reactivo a proactivo. La regla estrella: «el equipo de la reserva de las 10:00 está apagado».

**O21. Bandeja de recomendaciones automáticas.**
El DB-30. Reglas sobre agregados, no IA, con el LLM redactando la justificación. **Y se mide su propia tasa de aceptación**, replicando el diseño ya probado de `asistente_ia_acciones`. Es lo que un director abre cuando no tiene tiempo para los otros 29 dashboards.

**O22. Simulación de escenarios para programación académica.**
«Si muevo estos grupos a la tarde, ¿qué pasa con la ocupación pico?». Requiere capacidad ofertada y series recurrentes. Convierte el sistema de registro en herramienta de planeación, y es la funcionalidad que lo pone en la mesa del Director Académico en lugar del auxiliar de mostrador.

---

## 5.3 Cinco oportunidades de posicionamiento comercial

Más allá de la funcionalidad, cinco reencuadres que cambian a quién se le vende y por cuánto:

1. **De «software de reservas» a «instrumento de acreditación».** El dato de horas de laboratorio por estudiante y por programa, con serie histórica, es lo que un par académico pide y ninguna universidad puede entregar. Depende de un habilitador de días.

2. **De «acceso remoto» a «más servicio con menos metros cuadrados».** El dashboard RM-06 (ocupación física vs. remota) sustenta la frase que a un vicerrector administrativo le importa: *«puedo darte el mismo servicio con menos espacio»*. Requiere la atribución de sesiones.

3. **De «inventario» a «gestión de activos».** Cuatro columnas (`FechaCompra`, `ValorCompra`, `VidaUtilMeses`, `FinGarantia`) convierten una lista en un parque con depreciación, garantías y coste por hora. Es la diferencia entre hablar con el coordinador y hablar con el director financiero.

4. **De «reportes» a «decisiones».** La bandeja de recomendaciones con tasa de aceptación medida es un diferenciador que casi ningún competidor tiene, y es demostrable en una demo de dos minutos.

5. **Honestidad del dato como característica de venta.** Ningún competidor muestra la cobertura y la frescura de sus propios números. Un dashboard que dice «basado en 340 de 512 registros, datos al 3/08 06:00» **gana credibilidad en un comité técnico** en lugar de perderla. Y evita el escenario que esta auditoría documenta: cifras precisas que responden preguntas mal planteadas.

---

## 5.4 Lo que hay que dejar de prometer

Ser explícito aquí protege la relación comercial. Hasta que se cierren los habilitadores, **no debe demostrarse ni prometerse**:

| No prometer | Por qué |
|---|---|
| «% de ocupación» | No existe el denominador. Se puede ofrecer «horas reservadas» y «ranking de uso» |
| «Dashboards por facultad y programa» | La dimensión no existe; el join actual devuelve 100 % «Sin área» |
| «Trazabilidad del acceso remoto por estudiante» | Todos navegan con la cuenta de servicio compartida |
| «Tasa de fallo de conexión» | Guacamole no persiste fallos por diseño |
| «Gestión de mantenimiento» | No existe ninguna tabla ni columna |
| «Métricas de asistencia y puntualidad» | No existe check-in; la puntualidad actual es artificialmente perfecta por construcción |
| «Lista de espera» y «reservas recurrentes» | Código completo, tablas inexistentes; y la lista de espera carece de la acción de reclamar el cupo |
| «Sincronización con el sistema académico» | El módulo es un stub que reporta «ok» con un mensaje hardcodeado |
| «Auditoría de accesos y cambios» | 0 filas en las tres tablas de log tras dos generaciones del producto |
| «Atención de tickets» | El cliente puede abrirlos; no existe interfaz para responderlos |
| «Recordatorios de reserva» | Los campos existen y no tienen consumidor |
| «Predicción con IA» | No hay tubería de ML ni dos semestres de datos limpios |

**Y una demo específica que hoy no se puede hacer:** el dashboard de escritorio remoto renderiza vacío (0 filas de historial y servidor inalcanzable). Antes de cualquier demostración del diferenciador comercial hay que resolver la estrategia de datos de ese módulo — con fixtures detrás del repositorio, con una base espejo de demostración, o con un Guacamole real generando sesiones. **Nunca sembrando datos falsos en una tabla de auditoría de una instancia productiva.**

---

*Continúa en la [Parte 6 — Catálogo de KPIs](06_CATALOGO_KPIS.md).*