Qué tiene que resolver un software de gestión de mesas
Todas las herramientas dibujan una sala. Las que sobreviven un sábado resuelven tres cosas más difíciles.
Inventario que no se pueda sobrevender. Un plano solo sirve si una mesa puede comprometerse con exactamente un grupo y exactamente una ventana. Si dos anfitriones en dos dispositivos pueden dar la mesa 12 a la reserva de las 21:30, el dibujo es decoración.
Dos verdades a la vez. Una mesa tiene un futuro planificado — la reserva de las 22:00 que ya existe — y un presente físico — el grupo que sigue con el café. Los dos hechos conviven. Una herramienta que guarda solo uno olvida las reservas de esta noche o finge que la sala está vacía cuando está llena.
Un camino para quien llega igual. Los walk-ins no dejan de aparecer porque el libro esté lleno, y los clientes con reserva no dejan de llegar temprano. El piso tiene que absorber a ambos sin que nadie retipee un nombre.
Cómo funciona el plano de salón de StoveOps
Describes la sala como la nombras: primero las áreas — salón principal, terraza, barra, privado — y después las mesas de cada área, con los tamaños de grupo que de verdad sientan. Los planos tienen versiones, así que redibujar la terraza para el verano es una revisión que publicas, no una edición destructiva a mitad de servicio.
Ese plano es el inventario del que vende el motor de reservas. La disponibilidad se calcula contra mesas reales en áreas reales, y por eso quien reserva desde tu mini-sitio ve la sala que tienes y no una grilla genérica de horarios.
La reserva duplicada es una regla de base de datos, no una validación
Cuando se escribe una retención, una reserva o un bloqueo, se reclama un rango de tiempo contra una mesa. Los rangos solapados sobre la misma mesa los rechaza la base de datos, bajo carga, venga la segunda petición de la página pública, de un anfitrión en el piso o de una importación corriendo en segundo plano. Esa es la diferencia entre “lo validamos” y “no puede pasar”.
Los tres estados reales de una mesa
Durante el servicio el tablero separa lo comprometido de lo que está pasando:
- Asignada — hay una ventana futura reclamada para un grupo. Todavía no se sienta nadie.
- Ocupada — hay un grupo físicamente en la mesa ahora.
- En limpieza — el grupo se fue y la mesa aún no está lista para el siguiente.
Mantenerlos separados es lo que permite que una ocupación que se alarga y una reserva que empieza pronto convivan sin que el sistema cancele a alguien en silencio. Un turno que se pasa se le muestra al anfitrión como una decisión, nunca se resuelve a sus espaldas.
Cuando una reserva se encuentra con la sala llena
Dos momentos rompen a la mayoría de las herramientas, y los dos tienen aquí un camino definido.
La reserva llega temprano, o la mesa no está lista. El anfitrión pone al grupo en la lista de espera sobre la misma visita. La reserva sigue en pie, el cliente mantiene un solo lugar en una sola fila y el CRM registra una visita, no una reserva más una entrada misteriosa con el mismo nombre.
La noche está llena y el cliente igual quiere entrar. Puede registrar interés para una franja en lugar de irse. Cuando se libera una mesa, la franja liberada se ofrece a los clientes que encajan, con vencimiento: una cancelación de las 18:00 se vuelve un cubierto sentado a las 20:00 en vez de una mesa vacía.
Política de llegada que configuras una vez
Tres ajustes deciden cómo el piso trata el tiempo, y cada uno viene con un valor por defecto que cambias por local:
- Ventana de check-in anticipado. Cuánto antes de la hora reservada puede registrarse el propio cliente desde su enlace de confirmación.
- Tolerancia de no-show. Cuánto se sigue reteniendo la mesa pasada la hora antes de que el equipo pueda liberarla. El valor por defecto es una tolerancia de unos minutos, como se opera de verdad, en lugar de retener la mesa hasta el final de toda la ventana.
- Corte de cancelación. Qué tan cerca de la hora puede cancelar el propio cliente. El equipo nunca queda atado a ese corte; existe para que una cocina que ya compró el cubierto no se lleve una sorpresa, no para atrapar al cliente.
Lo que deliberadamente no hace
- Sin depósitos ni cubiertos prepagos. No hay retención de tarjeta sobre una reserva. Si tu modelo vive del ticket prepago, una plataforma de reservas con boletería encaja mejor.
- Sin sincronía con las cuentas del POS. El estado de mesa aquí es de sentado, no de cuenta abierta.
- Sin marketplace de comensales. Nadie te manda gente desde una red de descubrimiento ni te cobra por cubierto. La lista de clientes es tuya.
En qué plan está
Reservas — plano de salón, agenda de servicio, reserva pública y la gestión de mesas de esta página — es el módulo del plan Business. La lista de espera, los mensajes bidireccionales, el menú digital y la entrada por QR están en todos los planes, incluido Basic. Compara los planes en nuestra página de precios antes de decidir: una sala única que vive de walk-ins suele estar mejor empezando por la lista de espera y subiendo cuando el libro esté realmente lleno.
Ponerlo en marcha en un servicio
- Dibuja las áreas y las mesas como las nombra tu equipo. No modeles la sala que te gustaría tener.
- Define los períodos de servicio que de verdad sientas, y el ritmo que la cocina aguanta.
- Configura la política de llegada — check-in anticipado, tolerancia de no-show, corte de cancelación.
- Publica la página de reservas en tu mini-sitio y pon el enlace donde los clientes ya miran.
- Corre un servicio real. Mira dónde el tablero y la sala no coinciden, y corrige el plano, no el proceso.
Si todavía decides entre manejar la puerta o manejar el libro, empieza por reservas y lista de espera comparadas, y revisa el tiempo de turno, que es el número que todo esto mueve.