Restaurante tailandés

El cliente es un restaurante tailandés con cocina abierta y un menú en el que la mitad de los platos necesita explicación: ingredientes poco conocidos para los clientes, niveles de picante, salsas y postres difíciles de imaginar solo con una descripción. El público es diverso: turistas para quienes el idioma del restaurante no es ni mucho menos su lengua materna y residentes que vienen a «probar Tailandia». El menú impreso tradicional causaba tres problemas a la vez: quedaba obsoleto rápidamente, pues cada cambio de precio o plato exigía volver a imprimirlo y asumir el coste; no mostraba los platos «tal como son», porque las fotos se añadían en hojas sueltas; y sobrecargaba a los camareros. En las horas punta, el cliente esperaba entre 5 y 10 minutos solo para pedir, y eran habituales los errores de «entendieron otra cosa y prepararon otra cosa». También había un problema con el control: los pedidos y los importes de cada turno se sumaban a mano, por lo que el dueño no tenía una visión precisa de la sala en tiempo real. El restaurante quería que el enlace público del menú apareciera en su ficha de Google Maps, por donde llega hoy una parte importante de quienes lo visitan por primera vez.

Diseñar y crear un sistema en el que un mismo menú funcione en dos modos y el pedido llegue a cocina sin ningún eslabón

de «retransmisión». La tarea tenía cuatro partes: primero, un menú público con un enlace permanente, apto para Google Maps, redes sociales e impresión en materiales promocionales; segundo, enlaces privados al mismo menú que, al escanear el QR de una mesa, transforman el escaparate en un pedido completo, con selección de platos y envío al bot de Telegram del personal, e incluyen el número de mesa en el propio enlace; tercero, un bot de Telegram para el equipo del restaurante que reúne los pedidos, lleva el control y calcula los importes; cuarto, un panel de administración para que el dueño añada, edite y elimine platos sin programador. El sistema debía funcionar en los dispositivos básicos del personal y no exigir al cliente nada más que la cámara de su teléfono.

Para el cliente, el sistema parece «simplemente una web con el menú», pero detrás hay una lógica bien pensada con dos modos de acceso y tres roles: cliente, personal y administrador del menú. Cada decisión técnica respondía a una pregunta: cómo eliminar fricciones del proceso de pedido.

• Diseñamos una arquitectura con dos modos sobre una sola base de contenido y dos niveles de acceso. El enlace público abre el menú de presentación: categorías, fotos, ingredientes, niveles de picante y precios, sin botones para pedir; es una presentación de la cocina para Google Maps y redes sociales. Los enlaces de las mesas incluyen un parámetro que activa el modo de pedido: aparecen el carrito, los comentarios sobre los platos y la opción de enviar el pedido. El contenido siempre es el mismo, así que no hace falta sincronizar dos menús.
• Creamos un menú público en una página adaptable y rápida, que carga en un segundo incluso con la conexión móvil de la calle; a menudo el cliente lo abre desde la ficha de Google Maps mientras está cerca del restaurante. Incluye fotos de los platos, descripciones con indicaciones sobre picante e ingredientes, categorías desde sopas hasta bebidas y postres, y precios actualizados. El alojamiento está fuera de las redes internas del restaurante, por lo que el enlace funciona con fiabilidad independientemente del Wi-Fi del local o de lo concurrida que esté la sala.
• Generamos códigos QR para cada mesa: cada uno tiene un enlace único con el número de mesa incorporado. El cliente no debe elegir «estoy en la mesa N» de una lista ni indicar el sitio al camarero; el sistema lo reconoce por el enlace. Así eliminamos la principal fuente de errores de este tipo de sistemas y el pedido queda asignado a su mesa desde el primer momento. Colocamos los carteles QR para que se puedan escanear cómodamente desde cualquier asiento.
• Creamos el carrito y el envío de pedidos sin necesidad de registrarse: el cliente añade platos, escribe comentarios («sin cacahuetes», «más picante», «la salsa aparte»), comprueba la selección y confirma. El pedido llega al bot de Telegram del personal con un número único y el número de mesa. No hay que instalar aplicaciones, introducir el teléfono ni crear una cuenta: el recorrido desde el escaneo hasta el envío dura uno o dos minutos, deliberadamente menos que cualquier alternativa.
• Desarrollamos el bot de Telegram del personal: recibe todos los pedidos en tiempo real con número único, mesa, platos, comentarios del cliente e importe. Además de recibir pedidos, lleva el control: historial por turno y día, importes por menú y plato, reenvíos y estados de procesamiento. El personal trabaja en Telegram, que ya está abierto en sus dispositivos; no necesita instalar otro programa ni aprender un sistema nuevo: la interfaz es un chat conocido.
• Creamos el panel de administración del menú: añadir platos, editar precios, descripciones, fotos y categorías, eliminar platos y marcar al instante si están disponibles. Cada cambio se refleja inmediatamente tanto en el menú público como en el modo de pedido, porque ambos son el mismo menú. El dueño gestiona la oferta desde el teléfono, sin programador ni necesidad de consultarnos por cada detalle.
• Previmos situaciones habituales de la sala: si la cocina se queda sin un plato que alguien acaba de pedir, el administrador lo oculta al instante y desaparece del modo de pedido; si el mismo pedido se envía dos veces por error, el personal ve ambos y rechaza el duplicado; si cambia un precio, se actualiza en todas partes con una sola edición. Son precisamente estas situaciones cotidianas las que determinan si el sistema arraiga en un restaurante en funcionamiento.
• Pusimos el sistema en marcha y formamos al personal: impresión y colocación de los QR, instrucciones a los camareros para trabajar con el bot, acompañamiento durante los primeros turnos, recopilación de comentarios de clientes y empleados y ajustes de interfaz según la experiencia real.

Tres decisiones determinaron el éxito del proyecto. La primera: «un menú, dos modos». El restaurante mantiene un solo contenido, por lo que la carta pública y el sistema de pedidos nunca divergen. La segunda: Telegram como terminal del personal. No hay gastos en equipos, los pedidos llegan donde ya trabaja el equipo y el historial se guarda automáticamente, sin cuadernos de control. La tercera: incluir el número de mesa en el enlace del QR, para que el sistema no pregunte al cliente algo que puede saber por sí solo. El sistema completo costó menos que una única reimpresión completa de los menús de papel y sigue funcionando sin suscripciones, servidores propios ni equipos especiales en la sala.

Próximos pasos que proponemos al restaurante:

• Pago directamente desde el menú: el cliente paga la cuenta en la mesa sin esperar al camarero, se agiliza la rotación de mesas y desaparece la cola para pedir la cuenta en horas punta.
• Varios idiomas: versiones en inglés y otros idiomas de las descripciones de los platos para los turistas, sobre la misma base de contenido con capas traducidas.
• Presencia GEO (Generative Engine Optimization): datos estructurados sobre la cocina, el menú y el ambiente para que los asistentes de IA mencionen correctamente el restaurante al responder «dónde probar comida tailandesa», un canal que cada vez más clientes usan para elegir restaurante.
• Analítica del menú: qué platos se consultan pero no se piden y cuáles elevan el importe de la cuenta; una base para optimizar la oferta y crear propuestas de temporada.