Starbucks: cuando contar más rápido no mejora el inventario

Cinco envases de leche de avena aparecían como diez. Ese es uno de los episodios que Fast Company recogió de un trabajador de Starbucks: el sistema habría contado también el reflejo en el refrigerador. Es un testimonio, no una auditoría del producto. Pero describe con precisión la clase de dificultad que separa una demostración tecnológica de una jornada de trabajo.

NomadGo anunció en septiembre de 2025 que su tecnología llegaría a más de 11.000 establecimientos propios de Starbucks en Norteamérica. Combinaba visión por computadora y reconstrucción espacial para contar productos con un dispositivo móvil. El proveedor prometía hasta ocho veces más velocidad. La finalidad declarada era liberar tiempo del personal y mejorar la disponibilidad de los productos.

La idea tiene sentido económico. Contar existencias consume atención que podría dedicarse a atender clientes. El problema de diseño empieza cuando el tiempo ahorrado depende de que alguien prepare la escena, repita la captura, detecte errores y corrija el resultado. Esas tareas también pertenecen al proceso. Si quedan fuera de la evaluación, la automatización parece más barata de lo que resulta durante un turno normal.

Reuters informó el 21 de mayo de 2026 que Starbucks había retirado Automated Counting en Norteamérica. La cobertura describió dificultades para distinguir productos y registrar existencias. La empresa situó el cambio dentro de un esfuerzo por simplificar tareas, uniformar conteos y mejorar reposición y suministro. La retirada de esta herramienta concreta no permite concluir que Starbucks abandonara la IA en general.

Tampoco permite reconstruir desde fuera toda la cadena causal. No contamos con resultados comparables por tienda, tasas de corrección ni diferencias entre condiciones de captura. Podrían coexistir problemas de reconocimiento, diseño del trabajo y abastecimiento. Elegir uno como culpable universal sería prematuro. Nuestra primera tarea sería localizar dónde se perdía la utilidad del dato y cuánto costaba compensar esa pérdida.

Retirar una solución puede ser una buena respuesta si devuelve control a la operación. También puede destruir aprendizaje si la organización se limita a cerrar el proyecto. Conservaríamos los incidentes clasificados por condición, producto y consecuencia, junto con los cambios que intentaron resolverlos. Ese registro permitiría distinguir una tecnología que todavía necesita madurar de una tarea cuyo diseño hacía improbable obtener el beneficio esperado.

Un inventario combina cantidades con tiempo. Saber cuántos envases había al cerrar una tienda sirve de poco si las ventas, las entregas o las mermas modifican esa cantidad antes del siguiente pedido. Propondríamos reconstruir una jornada completa: quién cuenta, qué movimientos ocurren después, cuándo se calcula la necesidad y qué restricciones enfrenta quien abastece. La cámara sería una estación dentro de ese recorrido.

Consideremos una situación hipotética: el conteo sobreestima una referencia y el pedido queda por debajo de la necesidad. La tienda compensa con una compra urgente, una sustitución o una transferencia. El cliente quizá nunca ve el error, pero alguien pagó por corregirlo. Si solo se mide la disponibilidad final, el sistema puede parecer eficaz gracias al esfuerzo invisible del equipo. Si solo se mide precisión, se pierde la consecuencia comercial.

Por eso vincularíamos una muestra de lecturas con pedidos y resultados posteriores. Nos interesaría cuánto cambia una decisión cuando el conteo se equivoca, qué referencias son sensibles y qué margen existe para corregir a tiempo. Una discrepancia pequeña en un producto crítico podría merecer más atención que un error mayor en un artículo abundante. La tolerancia debería responder al uso del dato, con criterios acordados entre tienda y abastecimiento.

Seleccionaríamos establecimientos con configuraciones distintas: refrigeradores, iluminación, volumen, espacio de almacenamiento y rotación del personal. Incluiríamos turnos de mucha actividad y empleados que no participaron en el diseño. Una prueba acompañada constantemente por especialistas puede demostrar viabilidad, pero todavía no demuestra que la operación pueda sostenerla. La selección tendría que representar las condiciones donde después se espera trabajar sin ese acompañamiento.

Durante la primera fase, la lectura automática produciría una recomendación en paralelo al conteo de referencia, sin modificar pedidos. Registraríamos diferencias y tiempo total invertido, incluida la corrección. La revisión manual tampoco sería una verdad infalible: auditaríamos discrepancias para evitar juzgar el sistema contra un dato humano equivocado. Solo después probaríamos su influencia sobre un conjunto acotado de decisiones, con posibilidad de suspenderlo.

No exigiríamos que todas las categorías funcionaran igual para continuar. Si ciertos envases generan errores repetidos, podrían permanecer bajo conteo manual mientras otros pasan a asistencia automática. Esa convivencia aumenta la complejidad del procedimiento y debe justificarse con beneficios observables. Preferiríamos una cobertura menor que el personal pueda explicar a una cobertura universal que dependa de excepciones improvisadas y de recordar qué cifras conviene ignorar.

Dar a un empleado un botón para corregir no basta. Debe quedar claro cuándo puede usarlo, qué evidencia necesita y si la modificación altera el pedido. Diseñaríamos una corrección breve, visible y recuperable, evitando que la persona repita todo el trabajo. Las discrepancias frecuentes irían a quien pueda cambiar el producto o el procedimiento; no deberían acumularse como una obligación permanente de cada tienda.

También revisaríamos los incentivos. Si la evaluación premia completar capturas, habrá presión para registrar una captura aunque el dato no ayude. Propondríamos observar correcciones y omisiones como señales de aprendizaje, con muestreo para detectar uso indebido. El objetivo sería que reportar un problema temprano resulte más útil para el equipo que ocultarlo hasta que aparezca como una falta de producto frente al cliente.

Hay un costo en conservar supervisión humana. Debe incluirse al comparar alternativas, igual que el mantenimiento, los dispositivos y la formación. Si contar directamente sigue siendo más barato para una categoría, aceptaríamos esa conclusión. Una automatización puede merecer continuidad porque reduce variabilidad o permite decisiones más frecuentes, pero ese beneficio tendría que demostrarse por separado. Ahorrar minutos no autoriza a sumar ventajas que todavía nadie ha observado.

Antes del ensayo acordaríamos una línea de base y límites de avance: tiempo completo por conteo, discrepancias relevantes para reposición, faltantes, compras urgentes y desperdicio. Compararíamos tiendas y periodos semejantes, reconociendo que promociones, cambios de demanda y entregas pueden explicar diferencias. No prometeríamos un porcentaje de ahorro sin esa medición. El tamaño del ensayo dependería de la variabilidad observada y de la decisión que deba respaldar.

La ampliación tendría un responsable capaz de detenerla. Un aumento de discrepancias críticas, trabajo manual encubierto o deterioro de disponibilidad activaría revisión, aunque la adopción aparente siguiera creciendo. A la inversa, resultados consistentes en determinados formatos permitirían avanzar allí. El aprendizaje útil sería suficientemente específico para indicar dónde funciona la intervención, cuánto cuesta sostenerla y en qué condiciones deja de ser una buena elección.

El caso deja una exigencia concreta para cualquier operación que quiera incorporar IA al trabajo físico: seguir el dato hasta el momento en que alguien actúa con él. Allí aparecen los costos que una demostración no muestra. Si una persona tiene que desconfiar de cada lectura antes de preparar el pedido, todavía hay un problema de diseño pendiente, por muy rápido que termine el conteo en la pantalla.