Programación de turnos con inteligencia artificial en un restaurante

El horario que arma el encargado a mano cada domingo por la noche

Conozco el patrón porque lo he visto en más de una cocina: el dueño revisa el estado de resultados a fin de mes y ve que el costo de personal subió, y la primera reacción casi siempre es la misma, recortar personal. Baja un mesero del turno de la tarde y listo. El problema es que ese recorte se hace sobre el promedio del mes, no sobre la hora del día, y un restaurante no vende parejo: vende en punta de almuerzo, vende en punta de cena, y entre esas dos puntas hay huecos de dos o tres horas donde media plantilla está de pie sin nada que atender. Cortar parejo sobre un promedio castiga las horas donde sí hay gente para atender y deja intactas las horas donde sobra personal.

El segundo síntoma es al revés y duele más porque lo ve el cliente: un viernes de lluvia, o un feriado que nadie marcó en el calendario del turno, la demanda se dispara y la cocina se ahoga con la mitad del personal que necesitaba. El mesero corre, el plato tarda, la reseña baja una estrella, y el problema que originó todo (un turno mal calzado a la demanda de esa hora específica) queda invisible en la contabilidad. Nadie apunta “perdimos una mesa por demora” en ningún reporte. La conclusión errada que se saca de esas dos escenas es “necesito más personal” o “necesito menos personal”, cuando la pregunta real es otra: ¿tengo el personal correcto en la hora correcta?

Qué es programar turnos con inteligencia artificial, sin la promesa del piloto automático

Programar turnos con inteligencia artificial no es que un software le diga al encargado qué hacer y él obedezca sin mirar. Es un modelo que toma el historial de ventas por hora, cruza el día de la semana, la temporada, los feriados y los eventos cercanos al local, y devuelve una curva de demanda esperada, hora por hora, para los próximos días. Dentro del terreno más amplio de IA para restaurantes, esta es una de las aplicaciones más concretas, porque ataca directo la segunda línea de costo más grande después de la materia prima: la nómina. Esa curva no reemplaza al encargado, le da el insumo que hoy arma a ojo y con memoria selectiva.

La diferencia entre “el jueves siempre está tranquilo” y una curva medida hora por hora, construida sobre semanas reales de venta, es la diferencia entre una intuición y un patrón que se puede probar.

Nada de esto sirve si el punto de venta no registra bien la hora de cada venta, o si el negocio cambia de carta o de zona de forma tan seguida que el historial de la semana pasada ya no predice nada de la semana que viene. La programación de turnos con IA parte de un supuesto que hay que verificar antes de prometerlo: que existe suficiente historial de ventas por hora, limpio y consistente, como para que un patrón sea confiable y no ruido.

Predecir la demanda por hora y por día: la data que ya tienes en la caja

La materia prima de todo esto ya está en la caja, aunque casi ningún restaurante la mira con esa intención. Cada venta que pasa por el punto de venta queda registrada con hora, monto y casi siempre el detalle de qué se pidió. Es el mismo historial que, mirado desde otro ángulo, alimenta el control de inventario con IA en restaurantes: la diferencia es qué pregunta le haces a esa data. Acumulado durante meses, ese registro dibuja una curva de demanda por franja horaria y por día de la semana mucho más confiable que la memoria de cualquier encargado, por buena que sea. Un modelo de predicción de demanda toma esa curva y la ajusta con las variables que sí cambian el patrón normal:

• Estacionalidad y día de la semana: un viernes no se parece a un martes, y diciembre no se parece a marzo; el modelo aprende esas diferencias en vez de asumir un promedio plano.
• Feriados y fechas propias del negocio: San Valentín, el aniversario del local, el fin de mes de quincena, cualquier fecha que históricamente movió la venta hacia arriba o hacia abajo.
• Eventos cercanos al local: un concierto, un partido, una feria a dos cuadras, que explican un pico que de otro modo parecería ruido.
• Clima: la lluvia y el calor extremo cambian el patrón de consumo en muchos formatos de restaurante, y ese efecto también queda registrado si se cruza con data histórica de clima.

El resultado no es un número mágico de cuánto vas a vender el jueves, es una curva de probabilidad por hora que se vuelve más precisa cada semana que el modelo se sigue alimentando de ventas reales. Y como toda predicción basada en historial, tiene un límite honesto: si el negocio abre una sucursal nueva, cambia de barrio o de concepto de carta, no hay historial que valga y el modelo necesita empezar de cero a acumular información antes de ser útil.

El turno calzado a la curva real, no a la costumbre del negocio

Tener la curva de demanda es la mitad del trabajo. La otra mitad es traducirla en bloques de turno reales, con nombre y apellido, que alguien pueda ejecutar el lunes. Ahí es donde el algoritmo deja de ser una curva abstracta y se convierte en una propuesta concreta de horario, que cruza tres cosas a la vez: la curva de demanda por hora, la cobertura mínima que exige cada rol (no es lo mismo cocina que salón, ni salón que caja), y la disponibilidad real de cada persona del equipo.

El calce no es cortar personal a cero en las horas valle. Un restaurante necesita una base mínima de gente en sala y cocina incluso en la hora más floja, porque abrir con menos de esa base degrada el servicio de cualquier cliente que sí entra. Lo que cambia con el calce a la curva real es la forma del turno alrededor de esa base: en las horas pico se suma refuerzo, en las horas valle se sostiene lo mínimo, y en las horas de transición (el cierre del almuerzo, la previa de la cena) se escalona la entrada y salida de personal en vez de mover a todo el equipo al mismo tiempo, como suele pasar cuando el turno se arma a mano.

También hay una parte que el modelo no debería tocar solo: los feriados atípicos, el primer fin de semana de una promoción nueva, o un evento que el negocio organiza por su cuenta. Ahí el histórico no alcanza y el encargado tiene información que el sistema no tiene. Si tu restaurante recién está por empezar a usar IA en un restaurante en 30 días, vale decirlo de una vez: calzar el turno a la curva real casi nunca es el primer proyecto que conviene automatizar, porque necesita meses de historial limpio antes de dar una recomendación confiable. El turno bien calzado combina la curva predicha con el ajuste manual de quien conoce el barrio, no reemplaza uno por el otro.

Qué exige la normativa laboral y qué no se le puede delegar a un algoritmo

Antes de automatizar cualquier parte de esto hay un límite que no es de tecnología, es legal, y conviene decirlo sin rodeos: la normativa laboral fija descansos obligatorios, máximos de horas por turno y por semana, y plazos mínimos de aviso antes de publicar o cambiar un horario. Eso existe en la gran mayoría de países donde opera un restaurante, pero el detalle exacto (cuántas horas, cuánto aviso, qué se considera turno partido, qué recargo aplica) varía de país a país, y en algunos casos de ciudad a ciudad o de convenio colectivo a convenio colectivo.

Por eso esta página no cita artículos ni números de ninguna ley: hacerlo sería prometer una certeza que no se puede sostener desde un texto general. Lo que sí se puede afirmar es el orden correcto de las cosas: la normativa laboral aplicable al local, revisada con el abogado laboral o el área legal que corresponda, es la que define las reglas dentro de las cuales el modelo de turnos tiene permitido optimizar. El algoritmo no decide el mínimo de descanso entre turnos ni el aviso previo que corresponde, eso lo decide la ley del país y, encima de la ley, la política interna del negocio. El software se configura para respetar esos límites como restricciones duras, no como una sugerencia que se puede saltar en una semana difícil.

Esto no es un trámite legal para cumplir de cara a una auditoría. Es la base sobre la que se apoya todo lo demás: un modelo que sugiere un horario que viola el descanso mínimo entre turnos no está optimizando nada, está trasladando un riesgo legal del escritorio del encargado al software, sin que nadie lo haya decidido de forma consciente.

El efecto real en la rotación de personal, para bien y para mal

La rotación de personal en restaurantes es alta en casi cualquier país donde se mida, y una parte de esa rotación, la que sí se puede intervenir, nace directamente en cómo se arma el turno. Un horario que cambia cada semana sin patrón, que se publica con dos días de anticipación, o que parte la jornada en bloques cortos con huecos muertos en el medio, hace que la persona no pueda planear nada de su vida fuera del trabajo: ni un segundo empleo, ni estudiar, ni cuidar a alguien. Esa impredictibilidad pesa tanto como el sueldo a la hora de decidir si alguien se queda, un fenómeno que aparece también en cualquier análisis serio de IA para recursos humanos aplicado a retención de personal.

Un turno calzado a la curva real de demanda, publicado con anticipación y con algo de estabilidad semana a semana, sí puede reducir esa fricción, porque le da a la persona algo que valorar además del sueldo: previsibilidad. Ese es el argumento a favor de meter algoritmo en esto. Pero el mismo algoritmo que calza bien puede calzar mal si a alguien se le ocurre usarlo solo para bajar horas: la rotación que se evita del lado de la previsibilidad se puede generar del otro lado, el de sentir que el negocio te trata como una variable que se ajusta a cero apenas puede.

Cómo se mide el ahorro sin que el servicio se resienta

El error más común al medir esto es mirar solo el costo de personal en aislado, como si bajarlo fuera la meta. La métrica que de verdad importa es el costo de personal como proporción de la venta de esa franja, no de la venta del mes completo. Bajar el costo de personal a costa de perder ventas porque no había quién atendiera en el pico no es ahorro, es una transferencia de plata perdida de una línea contable a otra que no se ve tan fácil: la mesa que se fue por la demora no aparece como “pérdida por mala programación de turnos”, aparece simplemente como una venta que nunca se hizo.

Un sistema de medición honesto cruza al menos tres cosas antes de declarar éxito: el costo de personal como proporción de la venta por franja horaria, las horas extra que se generaron porque la predicción falló, y algún indicador de calidad de servicio en el pico (tiempo de espera, quejas, mesas perdidas) que confirme que bajar el costo no vino acompañado de un servicio peor. Cualquier proveedor que ofrezca un porcentaje de ahorro cerrado antes de ver la data de tu restaurante está prometiendo un número que no puede sostener, algo que ya toca revisar de entrada al analizar cuánto cuesta implementar IA en un restaurante: el ahorro real depende de qué tan mal calzado estaba el turno antes, y eso varía tanto entre restaurantes que un promedio de mercado no dice nada útil sobre el caso propio.

El límite ético: optimizar turnos contra las personas es la forma más rápida de perder al equipo

Hay una frontera en todo esto que no es técnica ni legal, es ética, y es la que más rápido se cruza cuando alguien mide el proyecto solo por cuánto bajó el costo de personal. Optimizar el turno contra la demanda es legítimo. Optimizar el turno contra la persona que lo trabaja es otra cosa, y tiene formas concretas y reconocibles:

• Fragmentar la jornada al mínimo: partir el turno en bloques cortos, con huecos muertos en el medio, para no pagar una hora completa, aunque la persona igual pierda el día entero yendo y viniendo.
• Avisar el horario con muy poca antelación: publicar turnos días u horas antes, de forma que nadie pueda organizar nada fuera del trabajo.
• Rotar los días libres sin ningún patrón: cambiar el descanso cada semana para maximizar la cobertura, sin que la persona pueda comprometerse con nada estable en su vida.

Nada de eso sale como una línea de código que diga “sé cruel con el equipo”. Sale de una función objetivo mal definida: si al modelo solo se le pide minimizar el costo de personal, la solución matemáticamente óptima tiende exactamente hacia esos tres comportamientos, porque desde el punto de vista del algoritmo la persona es una variable de costo, no alguien con una vida fuera del turno. El límite hay que ponerlo antes de encender el sistema, no corregirlo después de que el equipo empezó a renunciar.

Dónde trazar la línea antes de automatizar el próximo horario

La pregunta que separa un proyecto bien hecho de uno mal hecho no es qué tan preciso es el modelo. Los modelos de predicción de demanda por hora, con suficiente historial, llegan a ser bastante buenos, eso ya está resuelto en la práctica. La pregunta que sí decide el resultado es qué piso se le puso al algoritmo antes de dejarlo optimizar: si respeta el descanso y el aviso que exige la normativa del país, si protege un mínimo de estabilidad para las personas, y si el negocio está midiendo el costo de personal junto con la calidad de servicio y no en aislado. Es exactamente el tipo de criterio que suelo poner sobre la mesa cuando trabajo como el consultor de IA de un negocio de restauración, antes de tocar una sola línea del horario.

Un restaurante que arma turnos así deja de adivinar los domingos en la noche y empieza a decidir con la curva real de su propio negocio. Eso es una mejora real y medible. Pero el mismo proyecto, corrido sin esos límites, produce un horario más barato en el papel y un equipo que rota más rápido de lo que cualquier ahorro puede compensar. La tecnología no elige entre esas dos versiones: la elige quien define el objetivo antes de encender el sistema, y esa decisión no se delega a un algoritmo.