Caso ilustrativo: describe un patrón real y repetido que vemos en restaurantes y bares de barrio, compuesto a partir de varios proyectos similares — no corresponde a un cliente concreto identificado.
El punto de partida
Restaurante de barrio, 15-20 mesas. El TPV servía únicamente para cobrar. El inventario y las compras a proveedor se llevaban en un Excel aparte, actualizado cuando había tiempo. Nadie sabía con precisión qué ingredientes se consumían realmente en cada plato — se pedía "a ojo" según la experiencia de cocina — y las mermas o pérdidas solo se detectaban, mal y tarde, en el cierre trimestral de inventario.
El resultado era una sensación constante de trabajar a ciegas sobre el margen: sabían cuánto facturaban cada noche, pero no cuánto de esa facturación era beneficio real plato a plato.
Los pedidos a proveedor se hacían por costumbre más que por dato — "esta semana pedimos lo de siempre" — y cuando un ingrediente subía de precio, nadie lo notaba hasta que el margen ya llevaba semanas erosionado sin que se supiera por qué.
El primer cambio: inventario conectado al TPV por recetas
Se definió la receta de cada plato del menú — ingredientes y cantidades exactas. A partir de ahí, cada venta registrada en el TPV descuenta automáticamente esos ingredientes del inventario. Lo que antes era una estimación mensual pasó a ser un dato que se actualiza solo, venta a venta, sin que cocina tenga que parar a anotar nada.
Montar el recetario inicial llevó cierto trabajo — sentarse con cocina a definir cada plato con precisión — pero fue una inversión que se hizo una sola vez. A partir de ahí, el sistema mantiene el dato solo.
El segundo cambio: alertas de stock crítico
Con el consumo real descontándose en tiempo real, el sistema puede avisar antes de que un ingrediente clave se agote — evitando el escenario típico de quedarse sin un producto un viernes o sábado por la noche, justo cuando más se necesita.
Antes, esa alerta llegaba tarde: alguien se daba cuenta a media comanda, con el cliente ya sentado en la mesa. Ahora el aviso llega con margen suficiente para hacer un pedido urgente o ajustar el menú del día.
El tercer cambio: margen real por plato y por zona
Cruzando el coste real de cada receta con su precio de venta, el restaurante pudo ver por primera vez el margen de cada plato individual, y no solo el total de caja al cierre. Esto reveló platos que llevaban meses vendiéndose con un margen mucho más ajustado de lo que se pensaba — y otros con margen sobrado que podían promocionarse más.
También permitió ver el consumo por zona del local, no solo el total: comparar cómo rinden mesas de terraza frente a sala, o comida frente a cena, con datos reales en lugar de impresión de sala.
El resultado
Las mermas, antes invisibles hasta el cierre trimestral, empezaron a detectarse mientras aún se podía actuar sobre ellas, y se redujeron de forma notable. Varios platos que no rentaban se ajustaron de precio o de receta en cuanto se identificaron. Y por encima de cualquier cifra concreta, el equipo dejó de operar con la incertidumbre permanente sobre si el margen real acompañaba a la facturación de cada noche.
La decisión de subir el precio de un plato, o de cambiarle un ingrediente por otro más barato sin perder calidad, dejó de tomarse por intuición de cocina y pasó a apoyarse en un número concreto, disponible el mismo día en que se necesita.
Es nuestro servicio de software a medida para hostelería — descúbrelo en Soluciones
Preguntas frecuentes
¿Cómo se conecta el inventario de un restaurante con el TPV?
Definiendo la receta de cada plato — qué ingredientes y en qué cantidad lleva. Cada venta en el TPV descuenta automáticamente esos ingredientes del inventario, sin que nadie tenga que anotar consumo a mano.
¿Cómo se calcula el margen real por plato?
Cruzando el coste de los ingredientes de la receta (actualizado con precios de compra reales) con el precio de venta de cada plato. Eso permite ver qué platos rentan de verdad y cuáles se venden con margen ajustado o negativo, algo que un TPV que solo cobra nunca muestra.