Quilmes tiene 240.000 heladeras repartidas por todo el país. Entre el 3 y el 5% desaparece cada año — y los presuntos ladrones eran, muchas veces, los propios dueños de los comercios. Recuperarlas llevaba semanas, cuando pasaba. Todos lo llamaban un problema de robo. A un ex analista de bases de datos le llevó un mes ver que no lo era.
Seis años de bases de datos, primer mes de diseño
Fue mi primer rol de diseño de producto. Llegué después de seis años como analista de bases de datos, y el research repetía algo conocido: nadie podía decir dónde debería estar cada heladera. El inventario vivía en los depósitos y moría en el envío. Los recambios de mantenimiento devolvían una máquina distinta de la que salió. Los papeles que ataban una heladera a un comerciante estaban desconectados de ambos. Eso no es un problema de robo — es una cadena de custodia rota. Un problema de integridad de datos disfrazado de delito.
El 80/20 fue un código QR
Antes de diseñar nada sofisticado, resolvimos el problema más básico, el que explicaba el 80% del asunto: cada heladera recibió un QR que el representante escanea en la entrega — activándola en el lugar y atando máquina, documentación legal, punto de venta y posición geográfica en un solo gesto. Por primera vez existió un inventario completo. No se puede recuperar lo que no se puede ubicar.
Tres canales, porque la gente mira lo que ya mira
Cuando una heladera se apaga, las primeras horas definen la recuperación. El protocolo notificaba a tres audiencias por los canales que ya monitoreaban: los representantes de campo recibían la alerta como tarea dentro de Bees, el sistema propio de ABInBev — con puntos para sus objetivos mensuales, así la primera respuesta estaba incentivada, no pedida; la gerencia de CAPEX recibía email; y cada cambio de estado quedaba en la plataforma como rastro auditable. Si la recuperación fallaba, ese rastro habilitaba la vía legal — funcionalidad central, no ocurrencia tardía.
Mirando usuarios ignorar el feedback
El testing con el equipo de CAPEX y una gerente regional de trade confirmó las decisiones de layout — los highlights entre mapa y tabla se leían intuitivos, la configuración se encontraba sin guía — y dejó un hallazgo que baja el copete: nadie leía el feedback del sistema. Los mensajes de confirmación eran invisibles. Cambió cómo diseño feedback desde entonces: si importa, no puede pedir permiso.
Resultados, y qué es proyección
El tiempo entre el hecho y la acción pasó de dos semanas a un promedio de tres horas. La trazabilidad pasó de inexistente a completa. Los 250.000 dólares anuales de ahorro son una proyección, no un número auditado — sale de reposiciones recuperadas y ventas destrabadas, y prefiero etiquetarlo antes que lavarlo.
Dos semanas → tres horas
Del hecho a la acción, promedio
US$250K / año
Ahorro proyectado · reposiciones recuperadas + ventas destrabadas
La parte honesta
No todo lo que exploré en Sensify llegó a producción. Un rediseño del sistema de alertas quedó en exploración — el problema de fatiga que lo motivó terminó siendo una nota de campo: Alertas a escala: cuando la cura es la enfermedad. El protocolo de robo sí se implementó, porque obedecía la lección que me llevó seis años de bases de datos aprender y un proyecto aplicar: primero el registro, después la alarma.