QR del restaurante: pedido directo o aplicación de reparto

Empieza por el cliente y la promesa impresa

Quien está en el mostrador ya sabe en qué restaurante quiere comprar. Puede querer pedir para recoger después, repetir una comida conocida o encontrar la entrega que el local ya ofrece. Quien navega por un marketplace de reparto puede estar comparando restaurantes y utilizando la cuenta y las opciones de esa aplicación. Esos puntos de partida no necesitan la misma invitación.

Escribe la promesa antes de elegir la URL. “Pedir para recoger en este restaurante” debe abrir un canal configurado para recogida en el lugar correcto. “Pedir desde nuestro perfil en esta app” debe abrir el perfil actual del local. “Ver menú y opciones de pedido” puede abrir una página pública cuando el visitante realmente necesita elegir entre canales mantenidos.

El canal es más que el nombre del botón. Comprueba cómo se eligen artículos, qué opciones de recogida o entrega aparecen, qué horario aplica y dónde llega la confirmación. No llames sistema de pedidos a un PDF de menú ni presentes un mensaje de contacto como transacción terminada. Si el contacto existente recibe solicitudes, explica que el equipo confirma el pedido según su proceso.

Compara pedido directo y perfil en el marketplace

Las alternativas pueden coexistir. El restaurante puede mantener un marketplace para quien prefiere esa app y un canal directo para quien llega desde su web o material propio. La página pública ordena las opciones; los servicios de pedidos siguen recibiendo y procesando las transacciones.

“Directo” no significa que el restaurante desarrolló el software o emplea a todos los repartidores. En la descripción de Uber, Uber Direct atiende entregas originadas en sitios, aplicaciones u otros canales del comercio; Uber Eats Marketplace muestra comercios juntos para entrega o recogida. Son ejemplos específicos del proveedor, no garantía de que tu cuenta o región permita una configuración determinada.

Separa descubrimiento y entrega. El lugar donde alguien encuentra el restaurante puede diferir del sistema que recibe el pedido y del servicio que lo entrega. Confirma los tres antes de anunciar el botón. Cambiar el destino del QR no crea una operación de pedidos o reparto que todavía no existe.

Comprueba la operación detrás de cada enlace

Pide a quien opera cada canal que abra la vista real del cliente. Revisa restaurante, local, menú, horarios, instrucciones de recogida y opciones de entrega. Un perfil puede abrir y seguir mostrando menú antiguo u horario que la cocina no atiende. Hay que corregir la fuente; añadir una página pública no sincroniza esa información.

Identifica quién recibe el pedido. ¿El equipo ve la solicitud en una tableta, conexión con TPV, panel del proveedor o contacto atendido? ¿Quién lo revisa durante un turno ocupado? ¿Dónde ve confirmación el cliente y quién atiende una solicitud aún no aceptada? Utiliza registros reales del proveedor, sin considerar un escaneo o captura del cliente como prueba de pedido terminado.

Después identifica quién cumple la entrega. Para recogida, define punto y persona que entrega la comida. Para reparto, confirma qué servicio acepta la tarea y cómo prepara y entrega el pedido el equipo. No supongas que un enlace directo exige repartidor propio ni que todos los pedidos de marketplace usan la misma operación.

Menú y disponibilidad pertenecen a los sistemas utilizados. Comprueba cuál es la fuente de opciones y horarios. Si dos canales necesitan actualizaciones separadas, asigna ambas tareas expresamente. La página pública presenta enlaces y ubicación; no debería copiar detalles cambiantes a una segunda fuente que nadie mantiene.

Por último, define dónde preguntar por confirmación ausente, retraso en recogida o problema de entrega. Confirma la respuesta con el restaurante y sus proveedores. No prometas un proceso uniforme de reembolso, asistencia o repartidor entre servicios diferentes.

Un restaurante ficticio con dos canales activos

Escenario ilustrativo, no resultado de cliente VISU. Mostrador Cedro tiene un enlace configurado para recogida y un perfil actual en marketplace de reparto. La tarjeta del mostrador debe ayudar al cliente a pedir otra comida. Primero, la gerente decide si promete recogida en el local o acceso al perfil en la aplicación.

Durante el horario atendido, una tarjeta “Pedir para recoger” puede abrir directamente el canal existente. El cliente encuentra menú y opciones de recogida en ese proveedor. El personal recibe el pedido en su sistema habitual y sigue el proceso confirmado de entrega en mostrador. El QR no hace el pedido, asigna capacidad de cocina ni confirma que la comida está lista.

Para una tarjeta general, Cedro puede utilizar una página pública con enlaces identificados para recogida y marketplace, siempre que ambos se mantengan. La gerente no presenta las opciones como idénticas. El enlace de recogida abre el servicio correspondiente; el enlace con nombre de app abre el perfil correcto y sus opciones configuradas.

Cuando cambia la recogida, el equipo actualiza primero el sistema de pedidos y revisa la invitación de tarjeta y página pública. Si lo impreso promete un servicio no disponible, la gerente corrige el material que controla, sin afirmar que cualquier QR cambia solo. La gerente registra cada canal atendido y responsable de actualización para que el equipo explique las opciones y revise la invitación después de un cambio de servicio.

Da a la página pública del restaurante su propia función

La página presenta el local y ayuda a encontrar información y canales existentes. Puede mostrar enlaces de menú, ubicación, horario y opciones de pedido aprobadas. Es útil cuando alguien necesita elegir; un enlace directo puede ser más claro cuando la invitación impresa ya identifica una acción atendida.

La Solución Restaurantes actual ofrece página del local, archivo QR para imprimir y diseños de piezas especificadas, utilizando enlaces que el restaurante ya tiene. El local aporta menú, canal de pedidos y material aprobado, aprueba las piezas y organiza la impresión. Esto no implica pedidos, checkout, inventario, despacho de repartidores ni marketplace nativos de VISU.

Para página y QR con alcance definido, enumera qué enlaces aparecerán y por qué. Indica quién mantiene cada fuente y corrige los nombres públicos después de cambios. Si falta cuenta del proveedor o configuración de entrega, resuelve esa elección operativa antes de presentarla como disponible.

Prueba la experiencia del cliente y la entrega al equipo

Abre el QR en el teléfono sin iniciar sesión como empleado y lee la invitación en voz alta. Comprueba que la primera pantalla corresponde al restaurante, canal y acción de recogida o entrega prometidos. Acuerda una prueba planificada con el responsable del restaurante y el proveedor, usando la vista previa cuando exista, para evitar un pedido accidental.

Comprueba cada canal real por separado. Dos botones funcionando no prueban que la cocina pueda atender ambos a la vez. Revisa capacidad y entrega con el operador mediante el proceso real del restaurante. Publica solo promesas de recogida o reparto que el local pueda mantener.

Evalúa la Solución Restaurantes por sus entregas declaradas de página pública, QR y diseños. Proveedores y equipo siguen siendo responsables de transacción y atención del pedido. Un escaneo o clic de salida por sí solo no confirma comida pedida ni entregada.