Por qué un QR que solo muestra la carta no completa la venta
Mostrar un menú y cerrar un pedido son dos trabajos distintos. Cómo formular la hipótesis, instrumentar el embudo y medirlo en tu local sin inventar resultados.
Por qué un QR que solo muestra la carta no completa la venta
Un QR puede abrir un PDF, mostrar una carta web o iniciar un flujo completo de pedido. Las tres experiencias usan el mismo gesto inicial, pero no resuelven el mismo problema.
La diferencia operativa aparece después del escaneo: ¿el comensal puede elegir opciones, confirmar, pagar y seguir el estado, o todavía necesita encontrar al mozo para cada paso?
Las fricciones que conviene observar
La decisión no se cierra en el teléfono
Si el QR solo muestra información, el pedido vuelve al circuito manual. Eso no demuestra que el QR “no convierta”; plantea una hipótesis que debe medirse con un embudo instrumentado.
La disponibilidad puede quedar desactualizada
Una carta estática obliga a editar y volver a publicar ante cada cambio. Una carta operativa debe reflejar precios, opciones y agotados desde una fuente controlada por el local.
El cliente no ve el estado
Sin seguimiento, la pregunta por el tiempo del pedido vuelve al salón. Un estado visible puede reducir consultas, pero ese efecto depende del uso real y necesita una línea de base.
El local no conoce el embudo
Para mejorar hay que distinguir, con criterios de privacidad, sesiones iniciadas, carta vista, carrito, checkout emitido, pago confirmado y pedido entregado. Contar escaneos aislados no alcanza.
Qué cambia con un flujo transaccional
En Garpalo, el comensal puede armar el pedido, elegir el medio habilitado y seguir su estado desde el teléfono. En modo prepago, la cocina recibe la comanda después de que el proveedor confirma el cobro. Si el local eligió cobro flexible, esa condición cambia y debe analizarse por separado.
No publicamos un porcentaje de mejora para este flujo porque todavía no hay un estudio aprobado con dataset, período, locales, fórmula, exclusiones y permisos reconciliados.
Cómo validar la hipótesis en tu local
Definí antes de empezar:
1. la ventana [from, through) y la zona horaria; 2. qué evento inicia y termina cada etapa; 3. qué sesiones y pedidos se excluyen; 4. cómo se tratan cancelaciones, reembolsos y pruebas internas; 5. qué dato pertenece a una hipótesis y cuál es un resultado observado.
Una fórmula útil para inspeccionar el embudo es:
pedidos pagos elegibles / sesiones elegibles que vieron la carta
Compará períodos operativos equivalentes y no mezcles demos con locales productivos. Si cambia la carta, el horario o la fuente de tráfico, documentalo como limitación.
La hipótesis es simple: integrar pedido y pago puede quitar pasos manuales. El resultado solo lo puede dar una medición reproducible en tu operación.
¿Querés instrumentarlo? [Probá la demo](/) o [creá tu local](/registro).