Para qué existe

Este dashboard mide personas, y eso cambia cómo está construido. La evaluación existía antes, pero se armaba a mano y llegaba como un número sin respaldo: discutirlo era imposible para las dos partes.

Cada embarque se califica de 0 a 100 en tres dimensiones, y el score del operador es el promedio de sus embarques evaluables — los que ya tienen entrega registrada o ya están cerrados. Los que siguen en tránsito aparecen como N/A: calificar lo que aún no termina no mide a nadie.

• Tiempo de cierre (50%). Días entre la entrega real y el cierre del embarque. El objetivo son 6 días: cerrar a tiempo da 100 y pasar de diez días da 0, con una escala escalonada en medio.
• Cumplimiento (30%). Las correcciones que su trabajo obligó a hacer después — reversas de factura y reaperturas —, clasificadas por motivo y con peso distinto según el daño. Tocar una factura de un embarque ya cerrado cuesta vez y media, y la penalización tiene tope: un mal mes no manda el score a cero para siempre.
• Calidad de captura (20%). Qué tan completa quedó la información en el ERP. Se revisan entre 11 y 15 campos clave según el modo de transporte, porque a un aéreo se le exige guía y consolidado y a un terrestre no.

La regla de diseño que ordena todo lo demás: el número nunca aterriza sin explicación. Cada punto restado se puede abrir hasta el embarque que lo causó. Un score que no se puede auditar no se puede defender en una conversación de desempeño.

De dónde salen los datos

Dos fuentes: el feed de embarques, del que salen volumen, estatus y completitud de fechas, y las solicitudes de corrección que el área de cumplimiento captura en Airtable. El cruce se arma por identificador de embarque.

Ese segundo endpoint tiene una trampa que dejé documentada porque es fácil reusarlo mal: no devuelve todas las solicitudes, devuelve las penalizables — descarta los errores de timbrado y lo que no llegó a procesado en los dos sistemas. Está bien para este dashboard, que es para lo que nació, y está mal para cualquier otra cosa: esconde una de cada tres. Quien necesite las completas tiene otro endpoint.

Decisiones de construcción

• Los pesos de las penalizaciones viven en el dashboard, no en el endpoint. El endpoint dice qué pasó; cuánto cuesta cada cosa es una regla de negocio que se ajusta sin tocar la integración.
• Hay operadores fuera de la medición. Quien ya no opera no alimenta ningún indicador, así que exigirle fechas solo inflaba el pendiente de todos. No se ocultan del dashboard: dejan de contar, y la celda lo dice.
• Los embarques archivados no piden fechas. Están cerrados para siempre; penalizarlos no cambia nada operativo, a diferencia de los que todavía se pueden corregir.
• Una fecha capturada en el campo equivocado se señala distinto a una fecha faltante. No falta capturarla: falta moverla. Decirlo igual provocaba que la capturaran dos veces.

Qué es distinto en esta demo

Es el mismo archivo que corre en producción, con la capa de datos sustituida. El cálculo del score, los pesos y el desglose son los reales.

• Los operadores son ficticios, con iniciales inventadas. Publicar la evaluación de personas reales con nombre y apellido no es una opción, aunque los números fueran falsos.
• Los motivos de corrección sí son los del catálogo real, porque son parte de cómo funciona el modelo.
• Exportar a Excel está desactivado: el visor no da permiso de descarga.