Flujos de pedido — Pay-First vs Pay-Later
Cuándo usar Pay-First frente a Pay-Later, cómo se comporta cada uno de extremo a extremo, los estados de pedido que los operadores ven en el panel de administración y los trabajos en segundo plano que mantienen los pedidos sincronizados con el POS.
Fooodo admite dos flujos de pedido diferenciados. Se distinguen en cuándo la cocina ve el pedido y cuándo se realiza el pago. La elección depende del estilo de servicio, no del restaurante: un mismo restaurante puede ejecutar flujos distintos en mesas diferentes.
- Guest scans QR, builds cart
- Guest pays
- Order is exported to R-Keeper
- Kitchen prepares
- Guest receives or collects
- Guest scans QR, builds cart
- Items go to R-Keeper kitchen immediately
- Guest adds more rounds (each one syncs)
- Guest asks to pay
- Order locked → marked paid in R-Keeper
Los flujos de pedido de Fooodo se comunican con el POS a través de un contrato de conector. R-Keeper es el conector de referencia activo hoy en día; la mecánica que se describe a continuación refleja lo que toda implementación de conector debe satisfacer.
Pay-First
Utiliza Pay-First cuando los clientes deben pagar antes de que comience el servicio: comida para llevar, servicio rápido, patios de comidas. La cocina nunca ve un pedido sin pagar; el POS recibe una única exportación de pedido por carrito; si un cliente abandona el carrito, nada llega a la línea.
Pay-Later
Utiliza Pay-Later para servicio en mesa y servicio de varias rondas. La primera ronda llega al POS en el momento en que se envía; las rondas posteriores se añaden al mismo pedido del POS de una en una. El pedido permanece abierto en el POS desde la primera ronda hasta que el pago lo cierra. Internamente, Fooodo registra qué artículos ya se han enviado para que cada ronda se sincronice una sola vez.
Por qué difieren los flujos
La diferencia mecánica es pequeña: Pay-First realiza una única exportación al POS; Pay-Later realiza muchas. La diferencia operativa es más relevante:
- En Pay-First, la cocina no realiza trabajo adicional si un cliente abandona el carrito. Sin embargo, la experiencia del cliente no es adecuada para el servicio en mesa: las personas esperan pagar al final; pedirlo por adelantado resulta transaccional, no hospitalario.
- En Pay-Later, la experiencia del cliente se corresponde con la de un restaurante normal. El operador asume un pequeño riesgo de que un pedido pueda quedar sin pagar (un cliente se marcha sin pagar, una tarjeta falla), el mismo riesgo que existe hoy con cualquier servicio de cuenta en papel.
Muchas cadenas comienzan con Pay-First en los mostradores de comida para llevar y, una vez que el personal está familiarizado con el panel de administración, incorporan Pay-Later en las mesas de servicio en sala.
Configuración del flujo
El flujo se establece por mesa o como valor predeterminado del restaurante en el panel de administración. Un restaurante puede combinar flujos; por ejemplo, mesas de servicio en sala con Pay-Later y mostrador de comida para llevar con Pay-First, ambos funcionando a través de la misma instalación de Fooodo.
Estados en la práctica
Los pedidos avanzan a través de una máquina de estados. Los nombres que aparecen a continuación son exactamente los que se muestran en el panel de administración, lo que resulta útil tanto para los operadores que consultan sus propios pedidos como para los integradores que consumen eventos de pedido.
Los estados que más interesan a los operadores:
| Estado | Significado |
|---|---|
Created | El carrito existe, aún no se han enviado artículos |
InProgress | Artículos enviados al POS, a la espera de más o del pago |
ReadyToBePaid | El cliente ha terminado de pedir, pago pendiente |
Paid | El pago se ha completado correctamente, el POS lo ha marcado como pagado |
Finished | Pedido cerrado, estado final de éxito |
Los estados relacionados con fallos:
| Estado | Significado |
|---|---|
Locked | El POS tiene el pedido abierto (un camarero lo está editando). Reintentos automáticos con retroceso exponencial. |
Error | La exportación al POS ha fallado tras todos los reintentos. Requiere intervención manual. |
Cancelled | El pedido fue cancelado o expiró sin pagar |
La mayoría de los estados Locked se resuelven en segundos. Un estado Locked persistente suele indicar que un camarero tiene el pedido abierto en el POS y ha olvidado cerrarlo.
Error es el único estado que requiere atención humana. Los registros de fallos del conector indican qué ha salido mal; la resolución habitual consiste en recrear el pedido en el terminal POS.
Qué se ejecuta en segundo plano
Un pequeño conjunto de trabajos programados mantiene la capa de pedidos sincronizada. Los operadores no necesitan memorizar estos detalles, pero los integradores que consumen datos de Fooodo deben conocer las cadencias:
| Cadencia | Trabajo |
|---|---|
| Cada minuto | Comprobación de disponibilidad del restaurante |
| Cada minuto | Cancelar pedidos que han expirado sin pago |
| Cada 2 min | Obtener actualizaciones de pedidos del POS |
| Cada 4 min | Obtener el estado de las mesas del POS |
| Cada 5 min | Sincronizar disponibilidad de artículos |
| Diariamente 09:00 | Sincronización completa del menú |
Si el POS no está disponible, los trabajos reintentarán con retroceso exponencial; los pedidos se ponen en cola en su estado actual y se reconcilian cuando el conector se recupera.
Arquitectura de Fooodo
Cómo está construido Fooodo — la división en dos servicios de la aplicación de menú y el servicio de pagos, el modelo de multi-tenancy de empresa/restaurante/mesa, el contrato de conector agnóstico de POS, y dónde se sitúa UVS.
Conector de R-Keeper
La implementación de referencia en producción del contrato de conector POS de Fooodo — qué datos cruzan el límite, las cadencias de sincronización, los precios de fidelización y cómo se reintentan los fallos en producción.