Scanezi
El código en la mesa abre el menú en el navegador.
Herramientas para hostelería Desarrollo y demostraciones
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.
Menú QR
El código en la mesa abre el menú en el navegador.
Exploras las categorías, las opciones y la información disponible.
Las solicitudes y los estados se organizan en la configuración del local.
La administración de productos, imágenes y variantes.
Escenarios para solicitar al personal, la cuenta o el pedido.
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
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.
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.
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.
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.
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.
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.
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
De la exploración a la implementación
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.
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.
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.
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.
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.
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.
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.
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.
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.
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`).
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
Un escenario de uso, sin datos de cliente ni resultados comerciales atribuidos.
Un cliente escanea el código de la mesa 12 en la zona de terraza y pulsa «llamar al camarero».
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.
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
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.
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.
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 pilotoConstruimos agentes que atienden y lanzan llamadas, usan la información del negocio y trabajan con tus sistemas.
PlatformăUn asistente conectado a la información de tu negocio, en los canales por los que te escriben tus clientes.
PlatformăMEGA QR incluye un generador de códigos y una herramienta de transferencia óptica.
Instrument publicCuéntanos tu proceso. Juntos decidimos qué merece la pena construir, qué podemos conectar y cómo verificamos el resultado.