Pedidos y reservas

Dos flujos distintos que conviene no mezclar: el pedido ocurre con el comensal sentado y termina en la cocina; la reserva ocurre antes de que llegue y termina en la agenda del local.

El pedido, de la mesa a la cocina

1. El comensal lo arma

Desde la carta, tocando. Cada plato entra al pedido con su cantidad, los ingredientes que se le quitaron y la nota que el comensal escribió. Abajo de la pantalla queda una barra permanente con la cantidad de ítems y el subtotal, que abre el pedido completo.

En el pedido puede todavía cambiar cantidades, quitar líneas, escribir una nota general para la cocina y declarar alergias: hay un selector de las más frecuentes —maní, gluten, lactosa, mariscos, huevo, nueces, soya, pescado— más un campo de texto para lo que no esté en la lista.

También elige la modalidad: comer en sala o para llevar. No es un detalle cosmético; de eso depende cómo se valida el pedido, y es el tema de el control de presencia.

El mesero virtual escribe en el mismo pedido. Si el comensal le dice “agregame dos casados sin ensalada”, eso aparece en la misma pantalla que él está viendo, y puede corregirlo a mano. No hay dos pedidos, uno del chat y otro de la carta: es uno solo.

2. Se envía

El botón dice “Enviar a cocina”. Lo que pasa a partir de ahí no lo decide el teléfono del comensal: lo decide el servidor, que recalcula el monto por su cuenta —nunca confía en el número que le mande el navegador— y aplica la política del local.

3. Llega a la pantalla de cocina

El pedido aparece en la pantalla de comandas del local, que es una vista del panel pensada para estar prendida en la cocina o en la barra. Está organizada en columnas por estado:

Nuevos → Confirmados → En cocina → Listos → Servidos

Cada comanda muestra de quién es (la mesa, o el nombre y teléfono si es para llevar), sus líneas con cantidades y las notas especiales, la nota de cocina, el subtotal, y cuánto tiempo lleva esperando. Ese reloj cambia de color: a los diez minutos avisa, a los veinte insiste. Es la única parte del sistema diseñada para mirarse de lejos y con las manos ocupadas.

Arriba hay un conteo de preparación —cuántas unidades de cada plato hay pedidas en total ahora mismo— que es lo que la cocina realmente necesita para organizarse, en vez de sumar comandas a ojo.

Y si la pantalla pierde conexión, lo dice. No se queda mostrando comandas viejas como si fueran las de ahora.

4. Avanza

El personal mueve la comanda de estado desde esa misma pantalla. El sistema no permite saltos ilegales: un pedido no pasa de “nuevo” a “servido” sin pasar por cocina. Cada cambio de estado queda registrado con quién lo hizo.

El ciclo completo, con sus dos finales:

Estado	Qué significa
Pendiente	Entró, la cocina todavía no lo tomó
En revisión	Entró sin ancla de pago; espera que una persona lo acepte
Confirmada	Aceptada
En cocina	Se está preparando
Lista	Lista para servir o retirar
Servida	Servida en la mesa (consumo en sala)
Entregada	Retirada por el cliente (para llevar)
Cerrada	Cuenta saldada
Cancelada	—

Un pedido de sala no se cierra con saldo pendiente. El cierre exige que el monto esté establecido, y el cobro lo hace una persona del local, fuera del sistema. Nada acá “marca pagado” por su cuenta.

Las acciones de mesa

Además de mandar el pedido, desde la mesa salen dos avisos:

• Llamar al salonero.
• Pedir la cuenta.

Los dos llegan a la pantalla de cocina como una franja de avisos en vivo, con la mesa que los pidió. Pedir la cuenta no cobra nada: notifica. Es un llamado, no una transacción.

Para llevar y el pago

Si el local tiene una pasarela de pago conectada, el pedido para llevar puede pagarse en línea antes de entrar a cocina, en el formulario del proveedor de pago. El local decide en su panel si eso es obligatorio o si prefiere cobrar al retirar.

Con una regla que no se negocia: el sistema no da un pago por confirmado. Lo confirma el aviso firmado del proveedor de pago, verificado por el servidor. Ni el mesero virtual, ni un comprobante enviado por el cliente, ni el botón que el cliente tocó. Si el proveedor no confirmó, el pedido no entra a cocina — o entra en revisión para que una persona lo acepte, si así lo configuró el local.

Cuando el pedido pasa a confirmado y cuando queda listo, el cliente que dejó su teléfono recibe el aviso. Es opcional y se enciende por local.

Reservas

Cómo se solicita

En la carta pública hay un botón para reservar. Abre un formulario corto: nombre, cantidad de personas, fecha, hora, y opcionalmente zona (salón, terraza, barra), teléfono y notas —una ocasión especial, una alergia, una preferencia—.

El sistema valida la disponibilidad contra la capacidad que el local configuró para esa franja. Si no hay campo, lo dice y ofrece probar otra hora, en vez de aceptar una reserva que después hay que deshacer.

Qué pasa después

Una reserva pedida por el cliente entra siempre como solicitada. Nunca como confirmada. Es una regla del sistema, no una configuración: la confirmación la da una persona del local, que es quien sabe si esa noche hay un evento, si la terraza está cerrada por lluvia o si ese grupo de doce no cabe.

En el panel, el local ve las reservas activas y el historial, y las mueve por su ciclo:

solicitada ──► confirmada ──► cumplida       (el grupo llegó)
     │              └──────► no se presentó
     ├──► cancelada
     └──► reprogramada ──► confirmada

Cada uno de esos pasos también está acotado: de “cumplida” no se vuelve, y de “solicitada” no se salta a “cumplida”.

Lo que la reserva no hace

El mesero virtual no reserva. Si un comensal le escribe “quiero mesa para cuatro el sábado”, entiende la intención y lo manda al botón de reservar —pero no confirma la mesa ni inventa disponibilidad—. Es deliberado: una reserva confirmada por una máquina que no puede ver el salón es una mesa que no existe.

No cobra depósito. La reserva no pide dinero por adelantado.