McDonald's terminó el drive-thru con IBM. Faltó un número, no la tecnología.

En 2021, McDonald’s e IBM empezaron a probar pedidos por voz en el drive-thru. En junio de 2024, McDonald’s terminó la prueba.

El caso se volvió meme antes de volverse referencia. Circularon videos de un pedido que sumaba más de 200 McNuggets solo, de tocino agregado a un helado, de una cuenta que pasaba de doscientos dólares.

La lectura fácil es directa: la IA no estaba lista. Está equivocada. No por el motivo que te imaginas.

Vamos por orden.

Lo que se anunció

En 2019, McDonald’s compró Apprente, una empresa de reconocimiento de voz, y armó un laboratorio interno de tecnología. En 2021, vendió ese laboratorio a IBM y firmó una alianza para desarrollar el pedido automatizado por voz en el drive-thru.

El sistema llegó a más de 100 locales en Estados Unidos. La promesa era operativa, no técnica: sacar al cajero del paso de tomar el pedido y devolver ese tiempo a la cocina y a la ventanilla de entrega.

Sacar esa posición en la hora pico es lo que cambia la cuenta. En el pico, quien toma el pedido es el cuello de botella, y cada segundo de más en la ventanilla se vuelve fila en la calle.

Según reportes de la prensa de negocios, el sistema llegó a tomar cerca del 85% de los pedidos sin intervención. Número alto para un problema difícil. Un drive-thru es ruido de motor, acentos, un niño en el asiento de atrás, y un menú con miles de combinaciones.

Los videos virales eran síntoma, no causa. Todo cajero se equivoca en pedidos. La pregunta nunca fue si la máquina erraba. Fue si erraba lo bastante poco como para cambiar la cantidad de gente en turno.

Lo que cambió en el registro público

En junio de 2024, McDonald’s comunicó a los franquiciados que retiraría la tecnología de IBM de los locales de prueba antes de fin de julio. La empresa dijo que volvería a mirar el pedido por voz con otros socios y que decidiría los próximos pasos antes de fin de año.

Fíjate en lo que ese comunicado no dice. No dice que la IA falló. Dice que la prueba terminó.

Tres años de piloto. Más de 100 locales. Y el cierre llegó sin un número público que dijera “pasó” o “no pasó”.

La omisión que explica el caso

Acá está la parte que importa, y es una sola.

El caso de negocio del pedido por voz en el drive-thru es sacar o reubicar al cajero. Esa es la ganancia. No es que la IA sea lista. Es que la posición de tomar el pedido deje de existir.

Durante los tres años de prueba, un empleado siguió confirmando cada pedido en la pantalla. El humano nunca salió del circuito.

Haz la cuenta gruesa. Si la voz resuelve el 85% y la persona confirma el 100%, la nómina no se movió. En algunos turnos, la confirmación en pantalla hasta suma un paso más.

Cuando el humano se queda para corregir el 15% que la máquina falla, no cambiaste un costo por otro. Apilaste un sistema nuevo encima de un sueldo que sigue ahí.

McDonald’s no falló en construir la IA. Falló en definir, antes del piloto, el número que dejaría salir al humano.

Sin ese número, la prueba no tenía línea de llegada. Midió “está mejorando” durante tres años, en lugar de “cruzó el punto que prescinde de la persona”. Mejora sin un fin definido no es progreso. Es costo parado en el medio.

Klarna se saltó una frontera parecida en atención: cuándo la IA debía parar y pasar al humano. El drive-thru tenía la frontera opuesta. Cuándo el humano podía parar. Ninguna de las dos estaba escrita al inicio.

El criterio que lo habría detectado

Si tu operación está pensando en automatización que reemplaza una posición (self-checkout, visión en góndola, pedido por WhatsApp, voz en el mostrador), tres números tienen que existir antes del primer local:

• El umbral de autonomía. La precisión, en la hora pico real y no en el promedio, en la que el humano sale de la posición. Sin el pico, el número te engaña.
• El techo de intervención. La tasa de corrección humana por encima de la cual el piloto es costo, no ahorro. Si la persona corrige más que ese techo, el proyecto ya respondió “no”.
• La fecha de matar o subir. El piloto no corre para siempre. Tiene plazo para volverse producción o ser apagado, decidido antes de empezar.

Los tres se definen en la semana cero, en conversación, con la operación en la sala. No son técnicos. Son una negociación entre quien opera el local, quien cuida el costo y quien responde por la experiencia.

Sáltate esa conversación y el piloto hace lo que hizo el de McDonald’s. Corre años en el medio caro, mejorando un número que nadie acordó dónde tenía que llegar.

Sé honesto contigo un segundo.

Mira el piloto de automatización que está corriendo en tu operación ahora. ¿Hay un humano confirmando lo que hace la máquina? Pregunta una sola cosa: ¿cuál es el número que hace salir a ese humano?

Si nadie en la sala sabe responder, tu piloto no tiene fin. Solo tiene costo.

Lo que este post no está afirmando

No tenemos acceso a los datos internos de McDonald’s ni de IBM. La lectura está construida sobre el registro público: comunicados, reportes, declaraciones oficiales.

No estamos diciendo que el intento fue tonto. La voz en drive-thru es de los problemas más difíciles del retail, y probarlo a escala fue una decisión defendible.

Estamos diciendo, nada más, que el post-mortem honesto apunta a un criterio ausente, no a una falla de tecnología. La diferencia cambia tu próxima conversación de presupuesto.

Si arranca con “vamos a automatizar la atención del mostrador”, la pregunta antes de aprobar no es “qué proveedor”. Es esta: ¿qué precisión, en el pico, deja salir al cajero, y en cuánto tiempo decidimos si llegó ahí?

Definir ese número es una pelea entre áreas. Cada una defiende el indicador que ya mide. Es más fácil con alguien de afuera en la sala que conoce la forma de la conversación y la fuerza a cerrarse.

Mándame los tres indicadores que tu operación ya sigue en ese mostrador o ese checkout. En una hora te devuelvo cuáles habrían predicho el resultado de McDonald’s y cuáles son ruido.

Si vemos una forma de proyecto, el Diagnóstico de dos semanas termina con un documento de una página: tres indicadores, tres rangos meta, tres disparadores de revisión. Ese documento va a la pared de la operación, antes de la primera línea de código.