IA en restauración: lo que cambia en la cocina y lo que no

La IA en restauración llega casi siempre por el lado equivocado: un comercial enseña una pantalla que predice las ventas del sábado, el gerente la mira con interés y nadie pregunta de dónde sale el dato. Dos meses después la predicción sigue ahí, nadie la usa para decidir el pedido al proveedor y la suscripción se renueva por inercia. En hostelería el margen es tan estrecho que una herramienta que no cambia una decisión concreta es directamente una pérdida.

Esta guía va de las cuatro o cinco cosas que sí mueven la cuenta de resultados en un restaurante o en un grupo de restauración de entre 2 y 30 locales: prever comensales, mantener el escandallo vivo, ordenar las compras y leer lo que dicen los clientes sin dedicarle una mañana a la semana. También de qué sistemas hay que tocar —TPV, comandero, gestor de compras, agregadores— y en qué orden hacerlo para que cada fase pague la siguiente.

Un aviso de partida, porque ahorra dinero: en restauración el cuello de botella nunca es el modelo. Es que las ventas están en el TPV, el escandallo en una hoja de cálculo que mantiene el jefe de cocina, los albaranes en una carpeta de papel y las reseñas repartidas en cuatro portales y dos agregadores de delivery. Si eso no se junta, cualquier proyecto se queda en demo bonita.

¿Dónde aporta de verdad la IA en restauración?

Hay cuatro frentes con retorno defendible. El resto, hoy, es accesorio o es automatización de toda la vida con la palabra «IA» pegada encima.

Previsión de comensales y de ventas por plato. Es el caso con más recorrido porque toca a la vez tres costes: compras, merma y personal. Un restaurante que sabe con tres días de antelación que el jueves vendrá un 30% menos de gente compra distinto y monta otro cuadrante.

Escandallo y coste de materia prima. No es predicción, es cálculo constante: el precio del proveedor cambia cada semana y el escandallo que se hizo en enero ya no describe el margen de octubre. Aquí la IA aporta sobre todo en leer los albaranes y mantener los precios actualizados sin teclear.

Compras y gestión de stock. Pedido sugerido por proveedor a partir de la previsión, el stock real y el plazo de entrega. Lo que más se nota en un restaurante no es ahorrar un 2% en la compra: es dejar de tirar producto fresco y dejar de quedarse sin el plato estrella un viernes.

Reseñas y atención. Clasificar miles de comentarios por tema (servicio, espera, temperatura del plato, ruido, precio) y responder lo repetitivo. El volumen es alto, el texto es corto y el error es barato porque siempre revisa alguien antes de publicar.

Si todavía no tienes el histórico de tickets limpio y unido al de compras, el proyecto que necesitas no es de IA: es de datos. Cuesta menos y es la condición para todo lo demás.

¿Qué sistemas hay que tocar: TPV, comandero y gestor de compras?

Ningún caso de uso funciona en el vacío. Todos leen o escriben en sistemas que ya tienes, y ahí se decide si el proyecto sale en seis semanas o en seis meses.

| Sistema | Qué dato aporta | Qué comprobar antes | |---|---|---| | TPV | Ticket a nivel de línea: plato, cantidad, hora, mesa, camarero, descuento | Si exporta por API o solo PDF diario; si guarda más de 12 meses de histórico | | Comandero / KDS | Tiempos de cocina por plato, anulaciones, hora de salida | Si registra la hora de comanda y la de servicio, no solo el total | | Gestor de compras | Albaranes, precio por proveedor y fecha, unidades de compra | Si el precio histórico se sobrescribe al actualizar (muy habitual, y destruye el dato) | | Escandallo / recetario | Composición del plato, mermas teóricas, alérgenos | Si está en el sistema o vive en una hoja de cálculo personal | | Reservas | Comensales confirmados, no-shows, antelación, tamaño de grupo | Si se registran las cancelaciones y los walk-ins, no solo las reservas cumplidas | | Agregadores de delivery | Pedidos, comisiones, incidencias, valoraciones | Si hay acceso al detalle o solo liquidación mensual agregada | | Horarios y fichajes | Horas planificadas frente a horas reales por servicio | Si el fichaje se asocia al turno y al local |

La pregunta que decide el proyecto es siempre la misma: ¿tu TPV deja sacar el ticket línea a línea con hora? Si solo da el total del día, se puede trabajar igual, pero la previsión será de ventas globales y no sabrás qué plato comprar de más. Conviene saberlo antes de firmar, no después. Si vienes de integraciones que se complicaron, el patrón que describimos en integrar ERP y CRM sin romper nada aplica igual aquí.

¿Cómo se prevén los comensales y qué se hace con esa previsión?

Una previsión que nadie convierte en decisión es un gráfico caro. La secuencia útil tiene tres pasos y conviene exigirlos por separado.

Previsión. Estimar comensales y ventas por familia de plato para cada servicio futuro. Un modelo decente usa el histórico de los dos últimos años, el día de la semana, el festivo local, el clima previsto, las reservas acumuladas a fecha de hoy y los eventos cercanos (un partido, un congreso, una feria). Un modelo malo usa la media de los últimos cuatro jueves y falla justo en las fechas atípicas, que son donde está el dinero.

Traducción a compras. La previsión en comensales no sirve en el almacén. Hay que pasarla por el escandallo para convertirla en kilos de cada materia prima, restar el stock y proponer un pedido por proveedor respetando plazos y pedido mínimo. Aquí es donde la mayoría de las herramientas se quedan cortas: predicen bonito y no llegan al albarán.

Traducción a cuadrante. Comensales por franja horaria se convierten en personas por turno. No es automático —hay convenio, contratos y personas con vida— pero tener la carga esperada por hora cambia la conversación de «pon a dos más por si acaso» a «el pico es de 21:00 a 22:30».

Qué esperar de forma realista: el primer efecto no suele ser vender más, sino tirar menos producto fresco y dejar de pagar horas que no hacían falta. Es una ganancia de margen, no de facturación, y se ve antes en el porcentaje de merma que en la caja. La mecánica de fondo es la misma que explicamos en previsión de demanda aplicada a un inventario que caduca en días en vez de meses.

Un error típico: medir el acierto del modelo solo en el total del mes. En restauración el total puede cuadrar mientras el día a día falla en ambos sentidos y se compensa. Pide siempre el error medido por servicio, no agregado.

¿Puede la IA mantener el escandallo al día?

Esta es, de lejos, la parte menos vistosa y la que más margen recupera. En la mayoría de los restaurantes el escandallo se hizo bien una vez y se actualiza «cuando hay un rato», que nunca hay.

Lo que se automatiza hoy con garantías:

• Lectura de albaranes y facturas de proveedor. Extraer producto, cantidad, unidad y precio de un PDF o una foto, y volcarlo al gestor de compras. Es extracción de documentos de manual, con validación humana sobre lo dudoso. El detalle de cómo se monta y qué tasa de error esperar está en extracción de datos de documentos.
• Conciliación de precios. Avisar cuando el precio facturado no coincide con el acordado, o cuando sube más de un umbral. Suena menor; en un grupo con 200 referencias y seis proveedores es dinero que hoy se escapa sin que nadie lo vea.
• Recálculo del coste del plato. Si el aceite sube un 18%, qué platos se comen el margen y cuáles aguantan. Esa lista, cada mes, encima de la mesa.
• Detección de desvío entre teórico y real. El escandallo dice que de ese lomo salen 14 raciones y los tickets dicen que salieron 11. La diferencia es merma, ración generosa o fuga. El sistema no te dice cuál; te dice dónde mirar.

Con el coste real del plato actualizado ya se puede hablar de precio de carta con criterio en vez de por costumbre. El marco para hacerlo sin quemar al cliente lo desarrollamos en optimización de precios con datos. Y si el problema es más de proveedor que de carta, la lógica de homologación y detección de desvíos está en IA en compras.

¿Qué hace la IA con las reseñas y los pedidos a domicilio?

Un grupo de cinco locales puede acumular entre 2.000 y 6.000 reseñas al año repartidas en portales de opinión, mapas y dos agregadores de delivery. Nadie las lee todas. Lo habitual es mirar la nota media, que se mueve despacio y no dice qué arreglar.

Lo que aporta la IA aquí es concreto:

• Clasificar cada comentario por tema, local y sentimiento. El resultado es un cuadro de mando mensual donde ves que las menciones negativas a «espera» se concentran en un local, en los viernes noche, y empezaron cuando cambió el jefe de sala. Eso es accionable; un 4,2 de media no lo es.
• Separar el problema de cocina del problema de reparto. En delivery, media de las quejas de «frío» o «tardó» no son tuyas, son del repartidor. Distinguirlo cambia la decisión: una es formación de cocina, la otra es renegociar o cambiar de canal.
• Redactar borradores de respuesta con el tono de la casa y mencionando lo concreto que dijo el cliente, siempre con revisión humana antes de publicar.
• Cruzar reseñas con operación. Si las quejas de espera coinciden con los servicios de menos personal por comensal, ya tienes una hipótesis que probar la semana que viene.

La mecánica de clasificación, y dónde se equivoca, está en análisis de sentimiento. Lo que no hace y conviene decir claro: ni inventar reseñas, ni pedirlas de forma encubierta, ni filtrar las malas. Además de ir contra las políticas de los portales, se detecta y penaliza.

En reservas y atención, un asistente que responde por WhatsApp el horario, si hay opciones sin gluten, si se puede ir con perro o si queda mesa para cuatro a las nueve quita de encima la mitad de las llamadas de un viernes. Las condiciones reales del canal, con sus costes, están en chatbot de WhatsApp para empresas. La regla que damos siempre: el camino a una persona tiene que estar visible desde el primer mensaje.

¿Por dónde empezar y en qué orden?

Un orden que funciona en restaurantes independientes y grupos pequeños, pensado para que cada fase pague la siguiente:

| Fase | Qué se hace | Plazo típico | Qué tienes al final | |---|---|---|---| | 0. Datos | Unir tickets del TPV, compras y reservas en un sitio; limpiar referencias duplicadas | 3-5 semanas | Una fuente única de la que fiarte | | 1. Visibilidad | Cuadro de mando de ventas, ticket medio, coste de materia prima y merma por local | 2-4 semanas | Se acaba la discusión sobre qué número es el bueno | | 2. Albaranes | Extracción automática de facturas de proveedor y escandallo vivo | 4-6 semanas | Coste real del plato, actualizado solo | | 3. Previsión | Modelo de comensales y ventas por familia, por servicio | 4-8 semanas | Sabes qué servicios van flojos con antelación | | 4. Decisión asistida | Pedido sugerido y propuesta de cuadrante, con aprobación humana | 4-6 semanas | Menos merma y menos roturas | | 5. Atención | Clasificación de reseñas y respuestas automáticas a lo repetido | 3-5 semanas | Sala con menos cola de mensajes |

Dos reglas sobre este calendario. La primera: no se salta la fase 0 por mucho que el proveedor diga que su herramienta «se conecta sola». Se conecta, sí, y aprende del dato sucio que tengas. La segunda: la fase 1 parece poco ambiciosa y es la que más cambia las reuniones de dirección, porque es la primera vez que todos los locales miran la misma métrica definida igual.

Sobre presupuesto: la horquilla depende sobre todo de cuántos sistemas hay que leer y de si el TPV tiene API. Los rangos por tipo de proyecto y lo que los infla los detallamos en cuánto cuesta un proyecto de IA. Si el negocio incluye alojamiento, buena parte de la lógica de revenue la tratamos en IA en hoteles.

¿Qué no conviene automatizar en un restaurante?

Lista corta y honesta, porque equivocarse aquí se paga en sala:

• La gestión de una queja en mesa. Un cliente molesto necesita una persona con autoridad para invitar a algo. Un mensaje automático enciende más la situación.
• El pedido final a proveedor sin revisión, al menos el primer trimestre. El sistema propone; el jefe de cocina aprueba. Un error de unidad de compra (cajas frente a kilos) se nota mucho en un producto fresco.
• La carta. Qué platos entran y salen es criterio gastronómico, no optimización. El modelo puede decirte qué margen deja cada uno; no qué restaurante quieres ser.
• La respuesta pública a una reseña de una estrella. Borrador automático sí; publicación automática no.
• El cuadrante entero. La carga prevista es una entrada; conciliar convenio, contratos y personas sigue siendo trabajo de responsable de sala.

Preguntas frecuentes

¿Cuánto histórico de ventas hace falta para prever comensales?

Dos años completos es el mínimo razonable para que el modelo distinga estacionalidad de ruido y aprenda los festivos locales. Con un año se puede empezar, pero fallará en las fechas atípicas, que son justo donde más dinero hay en juego.

¿Esto tiene sentido en un solo restaurante o hace falta ser un grupo?

Tiene sentido en uno solo, empezando por abajo. El escandallo vivo y un cuadro de mando con ventas, merma y coste de materia prima es un proyecto de pocas semanas y ya cambia decisiones. La previsión fina por plato compensa antes cuanto mayor es el volumen y la rotación.

¿Necesito cambiar de TPV para usar IA en restauración?

Normalmente no, pero sí comprobar si expone el ticket a nivel de línea y con hora. Si solo da totales diarios, puedes trabajar con ciclos semanales; lo que no tendrás es detalle por plato. Cambiar de TPV por este motivo solo compensa si ya lo estabas valorando por otras razones.

¿La previsión sirve también para el delivery?

Sí, y conviene tratarlo como un canal aparte. El patrón horario, el ticket medio y la mezcla de platos del delivery no se parecen a los de la sala, y mezclarlos en un único modelo empeora los dos. Dos modelos simples rinden más que uno complicado.

---

Si estás valorando por dónde empezar y no quieres comprar herramienta antes de tener claro el caso, una auditoría te deja un mapa de qué datos tienes, cuáles faltan y qué proyecto paga primero. Y si prefieres contrastarlo en media hora, mirando tu TPV y tu última hoja de escandallo, hablemos.