Un dashboard puede ser un activo o un pasivo según qué muestra. Los buenos dashboards te dejan tomar decisiones; los malos te entretienen mostrando muchos gráficos sin ayudarte a actuar. Cuando diseñamos el portal de Rutik tuvimos que tomar decisiones sobre qué KPIs traer al frente, cuáles dejar en segundo plano y cuáles directamente no incluir. Este post explica esas decisiones.
Vale la pena leerlo aunque no termines siendo cliente, porque las mismas reglas aplican a cualquier panel operativo: el contenido importa más que el diseño.
Los KPIs principales del portal
Cuando un usuario entra a /app después de loguearse, lo primero que ve son cuatro tarjetas grandes con cuatro métricas. Son las que mejor responden la pregunta operativa central: "¿cómo va mi flota este período?". Cada una está pensada para encender una alarma cuando se mueve en la dirección equivocada.
1. Buses monitoreados
Cuántos vehículos tienen telemetría activa en este momento, sobre el total instalado. Si el número es 39 de 42, hay 3 buses sin reportar que requieren atención técnica.
Esta métrica parece administrativa pero es la primera línea de salud del sistema. Si dejara de aparecer, el resto de los KPIs serían sospechosos. Por eso va arriba: te dice si la información que estás viendo es completa o si tienes un agujero.
2. Alertas de pasajeros fantasma (últimos 30 días)
El conteo total de eventos que el motor de reconciliación marcó como diferencias significativas entre la ocupación medida y los boletos emitidos. No son personas individuales: son eventos a nivel de tramo donde la métrica cruzó el umbral de riesgo.
La tendencia es más importante que el valor absoluto. Si el número está cayendo respecto al mes anterior, el sistema está funcionando como disuasivo —que es lo que esperamos. Si está creciendo, hay un problema operativo emergente que necesita atención.
3. Pérdida estimada evitada (CLP)
Aquí está la métrica que la gerencia quiere ver primero pero que requiere más cuidado al interpretar. Lo que el sistema reporta es el monto referencial de fuga que se hubiera producido si las alertas detectadas no se hubieran disuadido o atajado.
El cálculo: número de pasajeros sin boleta detectados × tarifa promedio informal asumida. Lo importante: es un estimado direccional, no una recuperación contable. La diferencia es relevante. La caja de la empresa no aumenta automáticamente con esta cifra; aumenta cuando la fiscalización efectiva traduce las detecciones en menos fuga futura.
Por eso preferimos llamarla "pérdida evitada" en lugar de "dinero recuperado". Es honesto y previene malentendidos.
4. Viajes reconciliados
Cuántos trayectos del último período fueron cruzados exitosamente contra el sistema de boletaje. Otra métrica de salud: si bajara mucho, significa que la integración con boletaje está fallando en alguna parte y los otros KPIs pierden confiabilidad.
Las cuatro juntas dan una mirada completa: salud del sensor, evolución del problema, magnitud económica y salud de la integración. Más de cuatro métricas en primer plano sería ruido.
Qué hay en segundo plano
Debajo de las tarjetas principales hay dos paneles más:
Mini-chart de alertas diarias
Una visualización compacta de los últimos 7 días en barras. Permite ver si hay días específicos con concentración de fuga (típicamente domingos por la tarde, fines de mes, periodos de mayor demanda). Es un gráfico simple a propósito: no necesita ser una obra de arte, necesita responder "¿cuándo está pasando?".
Tabla de alertas recientes
Los últimos 5 a 10 eventos relevantes, ordenados por reciente y por monto. Cada fila tiene: bus, ruta, chofer, diferencia detectada, pérdida estimada del tramo, fecha y hora. Esto es lo que un gerente revisa cuando se sienta a fiscalizar.
Hacer clic en una fila lleva al detalle del viaje, donde el dato se vuelve granular: tramo a tramo, conteo medido vs. boletos emitidos, secuencia de eventos. Ahí ya no estás resumiendo, estás investigando.
Las páginas operativas: flota, equipo, configuración
El portal tiene tres páginas adicionales que cubren las necesidades operativas no relacionadas con análisis de datos.
Flota lista los vehículos instalados, su estado de telemetría (operativo, alerta, offline), patente, ruta asignada y último evento recibido. Permite responder rápido la pregunta "¿qué bus está sin reportar?" sin tener que ir a logs técnicos.
Equipo es la administración de usuarios de la organización. El portal es multi-tenant, así que cada empresa cliente ve solo sus datos. Los roles definen qué puede hacer cada usuario:
- Owner: puede todo, incluido editar la organización.
- Admin: puede invitar miembros, ver todo, no puede borrar la organización.
- Viewer: solo lectura. Útil para asignar a gerentes que necesitan el dato pero no la administración.
Configuración maneja el perfil personal y los datos básicos de la empresa.
Lo que deliberadamente no está
Tan importante como qué hay es qué decidimos dejar fuera. Algunos ejemplos:
No mostramos rankings de pasajeros por tramo
El dato está disponible internamente pero no lo exponemos como reporte agregado. La razón: empuja a la gerencia a tomar decisiones sobre demanda comercial basadas en métricas que el sistema no fue diseñado para responder. Para análisis de demanda existen herramientas mejores; Abordo es un sistema de fiscalización, no de business intelligence.
No mostramos "score de honestidad" del chofer
Tentador, pero potencialmente injusto. Las diferencias detectadas pueden tener causas no atribuibles al chofer (terminales sin control, pasajeros que evaden, problemas técnicos puntuales). Lo que sí mostramos es eventos detectados por chofer, dejando que la gerencia interprete dentro de su contexto. No reemplazamos el juicio profesional con un puntaje moral automático.
No mostramos video
Aunque el dispositivo procesa video internamente, el portal no expone ningún video. La privacidad no es solo no transmitir, es también no exhibir. Ni siquiera para "ver una alerta en contexto". Los eventos son numéricos; el contexto se explora con tramo y horario, no con imagen.
No mostramos métricas vanity
Cosas como "total de personas contadas en la historia de la flota". Suena impresionante en un dashboard pero no ayuda a nadie a tomar decisiones. Lo que cuenta son las cifras del período actual y su tendencia.
Cómo leer los KPIs sin engañarse
Tres trampas comunes al interpretar un dashboard como este:
Trampa 1: extrapolar de poco tiempo. Una semana puede mostrar cifras atípicas. Lo que importa es la tendencia a 30, 60 o 90 días. Si el sistema acaba de ser instalado, esperar al menos un mes antes de sacar conclusiones operativas.
Trampa 2: confundir detecciones con culpa. Una alerta no es una sentencia. Es una pieza de evidencia para una conversación. Tratar los datos como veredictos automáticos termina mal —laboralmente y en términos de calidad de información.
Trampa 3: olvidar la disuasión. Cuando las alertas bajan, no significa que el sistema dejó de detectar. Significa que está cumpliendo su función. El éxito se mide por la caída, no por el volumen.
Cierre
Un buen dashboard es una conversación destilada en una pantalla. Cada métrica que aparece es una decisión sobre qué importa para tu día a día como gerente. En Rutik hicimos esas decisiones explícitamente y las revisitamos cada cierto tiempo cuando aprendemos algo nuevo de los clientes en operación. Si terminamos trabajando juntos, vas a notar que el portal es deliberadamente simple. Eso es a propósito.
En el portal demo puedes navegar el dashboard con datos de ejemplo. Solicita acceso en /contacto y te creamos una cuenta de prueba sobre tu flota cuando arrancamos el prototipo.