Gestion de restaurantes: cocina, delivery y POS unificados
Un restaurante pierde clientes cuando la informacion se pierde entre la libreta del mozo, la cocina y la app de delivery. Conoce la solucion.
La noche que todo salio mal#
Sabado 21hs en un restaurante de Palermo con 28 mesas. Noche completa, lista de espera, dos delivery apps sonando sin parar.
El mozo de la zona 2 tomo el pedido de la mesa 7 en su libreta: un bife de chorizo jugoso, una ensalada caesar sin croutons y un Malbec Catena. Arranco la comanda, cruzo el salon, y cuando llego a la cocina se encontro con 6 comandas apiladas de las mesas que atendio en los ultimos 15 minutos. Dejo las 7 comandas en el pasaplatos. El chef tomo la primera.
A las 21:40, la mesa 7 empezo a mirar para los costados. A las 21:50, el comensal levanto la mano. El mozo fue a la cocina: "¿La 7?". El chef reviso las comandas. La comanda de la mesa 7 estaba en el piso, debajo de la mesada. Se habia caido.
Mientras tanto, la tablet de Rappi sono tres veces y nadie la escucho porque estaba en la oficina del fondo. Tres pedidos de delivery cancelados automaticamente por timeout. Perdida: $38.000 en una hora.
El dueno del restaurante, Gabriel, cerro esa noche con la sensacion de que todo el equipo habia trabajado al maximo — y aun asi habian perdido clientes, plata y reputacion.
El agujero negro de los restaurantes#
Lo que le paso a Gabriel no es un accidente. Es un problema estructural. La informacion en un restaurante viaja por canales que no se hablan:
La libreta del mozo es un canal. La cocina es otro. La tablet de Rappi es otro. La de PedidosYa, otro. La planilla de reservas en la puerta, otro. El Excel de costos que el contador mira una vez por mes, otro.
Cada canal funciona bien aislado. Pero la operacion de un restaurante no es aislada — es una cadena donde el mozo toma, la cocina produce, el salon sirve y la caja cobra. Si un eslabon se rompe, toda la cadena se para. Y el eslabon mas fragil siempre es el mismo: la transferencia de informacion entre personas.
Gabriel nos conto que habia intentado resolver el problema con mas tecnologia: un POS para la caja, una tablet por estacion de cocina, una app de reservas, un Excel para recetas. Termino con 6 herramientas que no se hablaban entre si y un costo de $800 USD mensuales solo en software.
"Cambie una libreta por seis pantallas", nos dijo. "Pero el problema era el mismo: yo seguia siendo el que conectaba todo con la cabeza."
La noche que todo fluyo#
Tres meses despues, visitamos el mismo restaurante un sabado a la noche. Misma cantidad de mesas, mismo nivel de ocupacion, misma presion.
Pero algo era diferente. El mozo de la zona 2 tomo el pedido en una pantalla tactil: bife de chorizo, punto jugoso, sin guarnicion, con ensalada caesar sin croutons. En el momento en que confirmo, tres cosas pasaron simultaneamente:
El bife aparecio en la pantalla de la estacion de parrilla. La ensalada aparecio en la pantalla de la estacion de frios. La botella de Malbec aparecio en la pantalla de la barra. Cada cocinero veia solo lo suyo, con un timer corriendo.
A los 12 minutos, el bife empezo a ponerse amarillo en la pantalla del expedidor — estaba cerca del umbral de tiempo. A los 14 minutos, la parrilla lo marco como listo. La ensalada ya estaba esperando. La barra habia mandado el vino hace 10 minutos. El expedidor confirmo que los tres items estaban completos. El mozo recibio una notificacion: "Mesa 7 lista para servir."
Tiempo total desde el pedido hasta el plato en la mesa: 16 minutos.
Mientras tanto, los pedidos de Rappi y PedidosYa entraban en la misma cola de cocina, se ruteaban a las mismas estaciones, y se marcaban con un tag de "delivery" para que el cocinero supiera que iban en bolsa, no en plato. Sin tablets separadas, sin que nadie tuviera que escuchar un sonido en la oficina del fondo.
Lo que Gabriel no esperaba#
Los beneficios obvios fueron inmediatos: menos pedidos perdidos, menos tiempos de espera, menos estrés en la cocina. Pero hubo cosas que Gabriel descubrio despues.
La primera fue el food cost real. Gabriel siempre habia calculado el costo de su hamburguesa "mas o menos": sumaba los ingredientes principales y redondeaba. Cuando cargo las recetas con cantidades exactas, yields y sub-recetas, descubrio que su hamburguesa clasica tenia un food cost de 36.7% en lugar del 28% que creia. Estaba perdiendo margen en su plato mas vendido sin saberlo.
El sistema le mostro algo mas: la hamburguesa era un "Plowhorse" — un plato muy popular pero con margen bajo. Ajusto el precio $800 pesos y cambio un proveedor de pan. Paso a "Star" sin perder una sola venta.
La segunda revelacion fueron los comensales repetidos. Gabriel no tenia idea de que el señor de la mesa 12 habia venido 8 veces en dos meses y siempre pedia bife con Malbec en la terraza. Ahora, cuando ese comensal reserva, el mozo ya sabe sus preferencias, su alergia a lacteos y que le gusta la terraza. Sin preguntarle nada.
La tercera fue la barra. Gabriel tenia un happy hour que sus bartenders aplicaban "de memoria" — a veces lo activaban a las 17:50, a veces se olvidaban hasta las 18:30. Ahora el happy hour se activa solo a las 18:00 y se desactiva solo a las 20:00. A las 20:01, los precios vuelven a la normalidad sin que nadie toque nada.
El sabado que nadie lo llamo#
Gabriel nos conto que el primer sabado que no lo llamaron por un problema fue el momento en que supo que habia funcionado.
Antes, todos los sabados a la noche recibia entre 5 y 8 llamadas: "Se cayo una comanda", "No se si esta mesa ya cobro", "El delivery de Rappi no se cargo", "¿Cuantas reservas hay para las 21?". Cada llamada lo sacaba de lo que estuviera haciendo — generalmente, tratar de disfrutar su unico dia libre.
Ese sabado, su telefono no sono. El lunes reviso los numeros: 94 cubiertos, 12 pedidos de delivery, 0 pedidos perdidos, tiempo promedio de mesa 48 minutos (vs. 62 antes), food cost promedio 31.2%.
No sono porque la informacion ya no necesitaba un humano para viajar. El pedido del mozo llegaba a la cocina solo. El delivery entraba a la cola solo. El timer alertaba si algo se demoraba. El stock se descontaba solo. El food cost se calculaba solo.
Gabriel no habia contratado mas gente. No habia reducido mesas. Solo habia eliminado los agujeros por donde se perdia la informacion.
La mesa 7, tres meses despues#
La mesa 7 sigue siendo una de las mas pedidas del restaurante. Esta en la esquina, con vista a la calle. Los sabados se reserva con dias de anticipacion.
El ultimo sabado, el comensal de la mesa 7 llego, se sento, y el mozo le dijo: "Bienvenido de vuelta. ¿El Malbec Catena de siempre?"
El comensal sonrio. No porque el vino fuera especial, sino porque alguien se acordo.
En realidad, no se acordo nadie. Se acordo el sistema. Pero el resultado fue el mismo: un cliente que se sintio reconocido, que pidio postre por primera vez en tres visitas, y que dejo una propina del 20%.
A veces la diferencia entre un restaurante que sobrevive y uno que crece no esta en la comida. Esta en si la informacion llega a donde tiene que llegar, cuando tiene que llegar.
¿Cuanta informacion se pierde en tu restaurante entre la mesa, la cocina y la caja?
Proba rql.Ecosystem gratis
ERP + CRM + WhatsApp + IA. Sin tarjeta, sin compromiso. Operativo en minutos.
Equipo rqlEcosystem
rql.Sistemas
El equipo detrás de rql.Ecosystem — plataforma de gestión integral para organizaciones argentinas.
Te gusto este articulo?
Suscribite al newsletter para recibir novedades y tips cada semana.