Saltar al contenido
megapromotingVamos a hablar
Productos Menú QR

Herramientas para hostelería Desarrollo y demostraciones

El menú, la mesa y el equipo, en un mismo flujo.

Construimos una plataforma para menús digitales y operaciones accesibles mediante QR. El cliente llega a la información desde el teléfono, y el equipo administra el menú y las solicitudes.

  1. 1Cod la masă
  2. 2Meniu în browser
  3. 3Solicitare către echipă
Schemă explicativă ·Menú QR

Menú QR

De la información al trabajo hecho.

01

Scanezi

El código en la mesa abre el menú en el navegador.

02

Alegi

Exploras las categorías, las opciones y la información disponible.

03

El equipo continúa

Las solicitudes y los estados se organizan en la configuración del local.

Dónde resulta útil.

Menú digital

La administración de productos, imágenes y variantes.

Interacciones en la mesa

Escenarios para solicitar al personal, la cuenta o el pedido.

Operațiuni

Roles y conexiones adaptados al modo de trabajo del local.

Los pedidos, los pagos y la conexión con el sistema de gestión se confirman para cada implementación.

Menú QR en detalle

Qué puedes hacer con este proyecto.

Meniu QR es la plataforma mediante la cual un cliente escanea el código de la mesa, abre el menú en el teléfono sin instalar nada, hace un pedido, llama al camarero o pide la cuenta. El código no es solo un enlace: puede estar vinculado a una mesa, a una zona, a una ubicación o a un servicio, y ese contexto sigue con cada solicitud, así que el personal sabe de dónde viene.

Por detrás, la estructura sigue cómo es realmente un local: restaurante, ubicaciones, zonas (interior, terraza, bar, VIP, exterior), mesas, y sobre ellas personal con rol — camarero, barman, hookah, cocinero, administrador o rol propio — y asignación por mesas. El pedido tiene siete estados con marca de tiempo para cada transición: nuevo, confirmado, en preparación, listo, entregado, pagado, cancelado. La llamada al camarero tiene su propio ciclo: pendiente, tomada, resuelta.

El personal no necesita una aplicación nueva: las notificaciones llegan por Telegram, con reglas configuradas por evento — pedido nuevo, pedido no confirmado, llamada a la mesa, feedback negativo, pago exitoso o fallido. Si nadie lo toma en el intervalo establecido (por defecto cinco minutos), la notificación se escala al administrador.

01

Código QR con contexto, no solo un enlace

Cuatro tipos de código: mesa, zona, ubicación y servicio. Los códigos se generan en la plataforma, se pueden exportar como PDF para imprimir, y el enlace construido lleva consigo el local y la mesa.

02

Menú con traducciones separadas del contenido

Las categorías y los productos tienen sus propias tablas de traducción, así que el texto en otro idioma no sobrescribe el original. La traducción automática pasa primero por Anthropic (`claude-sonnet-4`), y si falta esa clave, por Google (`gemini-2.0-flash`). La interfaz tiene rumano, ruso e inglés.

03

Pedido con estados y marca de tiempo

Siete estados, cada uno con su momento registrado: confirmación, preparación, entrega, pago. Los productos del pedido tienen su propio estado y sus propias opciones elegidas, lo que permite que una parte del pedido vaya al bar y otra a la cocina.

04

Notificaciones por Telegram, con escalado

Bot construido sobre grammy, en régimen webhook. Las reglas se configuran por restaurante y por evento, y si nadie confirma en el intervalo configurado — por defecto cinco minutos — la solicitud sube al administrador. Cada notificación enviada queda en el registro.

05

Pagos con las cuentas del local, no a través de nosotros

La plataforma no intermedia el dinero: el restaurante usa sus propias credenciales. Están implementados los adaptadores para Stripe, efectivo y transferencia. MAIB existe como esqueleto, marcado en el código como inacabado.

06

Funciones activadas por suscripción, no todas a la vez

Cada restaurante tiene un conjunto de interruptores — pedido, llamada al personal, pagos en línea, feedback, varios idiomas, integración con la caja registradora, cuenta dividida, reserva de mesa, promociones. Por defecto solo están activados la llamada al personal y el pago en efectivo; el resto se activa según el plan. El límite de mesas se verifica al añadir, no al final de mes.

Datos y funcionamiento

Qué entra en el sistema. Qué hay que verificar.

Un solo lugar para todos los locales, separados entre sí
PostgreSQL mediante Prisma, con el identificador del restaurante en todas las tablas y políticas de acceso a nivel de fila. La autenticación de los administradores se hace mediante Supabase, el personal entra por Telegram, y el cliente de la mesa no tiene cuenta en absoluto.
El cliente permanece anónimo
El visitante recibe un identificador de sesión en una cookie httpOnly, válido durante 24 horas, marcado `secure` en producción. No pide cuenta, no pide teléfono, no instala nada. El pedido y la llamada al camarero se vinculan a esa sesión y a la mesa.
El menú sigue siendo del local
Las categorías, productos, grupos de opciones y opciones son editados por el restaurante. Las traducciones se guardan en tablas separadas, así que una traducción automática incorrecta se corrige sin tocar el original.
Lo que no está conectado automáticamente
Los tipos de pago reconocidos en el código son ocho, pero existen adaptadores escritos para cuatro, y el de MAIB está inacabado. Para los demás —Moldindconbank, Paynet, Netopia, MobilPay— solo existe el nombre en la lista, no la integración. Es una distinción que hay que hacer antes de prometer algo a un local.

De la exploración a la implementación

Cómo preparamos un proyecto con Meniu QR.

01

Cartografiamos el local antes del menú

Ubicaciones, zonas, mesas, personal y sus roles. Los códigos QR se generan sobre esta estructura; si la estructura es incorrecta, el contexto de cada solicitud también es incorrecto.

02

Elegimos qué se pone en marcha desde el inicio

Los pedidos, el pago online y la integración con la caja registradora son interruptores separados. Para un primer local, la llamada al camarero y el menú digital son suficientes para probar el flujo con personal real.

03

Terminamos la parte de pago y de caja registradora, para ese local

El adaptador MAIB y el encaje de las mesas con el sistema de caja son trabajo por hacer, no configuración. Se estima según el proveedor concreto del local, con sus credenciales y su documentación.

04

Probamos con el personal, en turno real

El flujo se rompe en las personas, no en el código: quién confirma, en cuánto tiempo, qué pasa cuando nadie responde. La escalada a cinco minutos es un punto de partida que se calibra en el local.

Preguntas que vale la pena aclarar.

¿Puede un local usarlo mañana?

No. Es un prototipo completo en cobertura, pero inacabado y no lanzado: una sola migración de base de datos, del 4 de abril de 2026, ningún commit después de ese día, ninguna prueba automática y ninguna instalación pública. Lo que se puede hacer mañana: una demostración sobre la estructura de un local real, para ver el flujo de principio a fin y estimar qué más falta.

¿Tiene que instalar el cliente una aplicación?

No. Escanea el código y se abre en el navegador. Recibe un identificador de sesión en una cookie httpOnly válida durante 24 horas — sin cuenta, sin teléfono, sin datos personales. El pedido y la llamada al camarero se vinculan a esa sesión y a la mesa del código.

¿Se puede pagar en línea?

Depende del proveedor, y vale la pena decirlo exactamente. El adaptador de Stripe es funcional, al igual que el efectivo y la transferencia. El adaptador de MAIB está escrito como esqueleto y marcado en el código como inacabado — necesita el SDK del banco y certificados TLS. Para Moldindconbank, Paynet, Netopia y MobilPay solo hay nombres en la lista de tipos, sin integración. Importante tener en cuenta: la plataforma no retiene el dinero; el local usa sus propias credenciales.

¿Se conecta con la caja registradora del restaurante?

Parcialmente, y la parte que falta es la que importa. Hay adaptadores escritos para iiko (Syrve) y para Poster, con autenticación e intercambio de token implementados, así que el menú se puede traer desde su sistema. El envío del pedido de vuelta no está listo: la correspondencia de la mesa del local con la mesa y el grupo de terminales de su sistema aún está por resolver. Así que importación sí, sincronización completa todavía no.

¿Cómo sabe el personal que alguien ha pedido o ha llamado al camarero?

Por Telegram, con un bot propio en modo webhook — sin nueva aplicación que instalar en sus teléfonos. Las reglas se configuran por restaurante y por evento: pedido nuevo, pedido no confirmado, llamada a la mesa o al administrador, feedback negativo, personal en pausa, pago exitoso o fallido. Si nadie lo toma en el intervalo establecido, por defecto cinco minutos, la solicitud escala al administrador, y cada notificación enviada queda en el registro.

¿En qué idiomas funciona el menú?

La interfaz tiene rumano, ruso e inglés. El menú tiene tablas de traducción separadas para categorías y productos, así que la traducción no sobrescribe el texto original y se puede corregir manualmente. La traducción automática intenta primero Anthropic (`claude-sonnet-4`) y, si esa clave falta, Google (`gemini-2.0-flash`).

¿Es lo mismo que MEGA QR?

No. MEGA QR genera códigos y transfiere datos ópticamente. Meniu QR es una plataforma de hostelería: menú, pedido, llamada al personal, notificaciones en turno y pagos. Lo único en común es el código de la mesa.

Ejemplo ilustrativo

Una llamada desde la mesa que no se pierde

Un escenario de uso, sin datos de cliente ni resultados comerciales atribuidos.

Situación inicial

Un cliente escanea el código de la mesa 12 en la zona de terraza y pulsa «llamar al camarero».

Cómo funciona

La solicitud entra vinculada a la sesión anónima del cliente y a la mesa del código, con el estado «en espera». La regla de notificación del restaurante envía el mensaje por Telegram al personal asignado a esa zona.

Rezultatul

El camarero confirma desde Telegram y la solicitud pasa a «tomada», luego a «resuelta». Si nadie confirma en el intervalo configurado, por defecto cinco minutos, la solicitud sube al administrador. Cada notificación queda en el registro, así que después se puede ver qué se retrasó.

Ce este necesar:Structura localului introdusă (locație, zone, mese), personal înregistrat în bot cu rolurile lui, reguli de notificare setate pe evenimente și codurile QR tipărite pe mese. Comenzile și plata online sunt comutatoare separate, care pot rămâne închise la primul local.

Posibilidades de colaboración

Meniu QR, en el contexto de tu organización.

Puntos de acceso y transferencia local

Códigos para acceso a información pública, instrucciones o contactos; transferencia óptica de archivos entre dispositivos compatibles, con evaluación de las políticas de seguridad de la institución.

Empresas privadas

Definimos un piloto en torno a un proceso real: usuarios, datos, integraciones, costes y criterios de aceptación. La ampliación sigue después de evaluar el resultado.

Instituciones y empresas públicas

Establecemos los requisitos de accesibilidad, alojamiento, protección de datos e interoperabilidad. Cualquier conexión con servicios AGE o STISC requiere la validación de la elegibilidad, el acceso y las aprobaciones.

Estos son escenarios de adaptación, no declaraciones sobre contratos o colaboraciones existentes. Las funciones propuestas se confirman en el ámbito de trabajo del proyecto.

Habla de un piloto

Parte de un ecosistema.

¿Qué te gustaría que funcionara mejor?

Cuéntanos tu proceso. Juntos decidimos qué merece la pena construir, qué podemos conectar y cómo verificamos el resultado.

Vamos a hablar