Pedí desde el móvil en el restaurante de mi barrio: así funciona por dentro

Aviso antes de empezar, porque cambia cómo hay que leer esto: trabajo en el equipo que desarrolla QuickOrder. No es una reseña de un cliente satisfecho ni una opinión imparcial. Es lo que vi el viernes pasado sentado a una mesa, pidiendo desde mi propio móvil, en un restaurante de mi barrio que usa el sistema que ayudo a construir.

Escribo esto porque programar una cosa y usarla son dos oficios distintos. En la pantalla del portátil un pedido es una fila en una tabla. En una mesa, con hambre, con la pareja de al lado discutiendo si compartir o no, el mismo pedido es otra cosa. Lo que sigue está ordenado por lo que fue pasando, y cada apartado responde primero y cuenta la escena después.

¿Qué ve el cliente cuando enfoca el código con el móvil?

Ve la carta del local, en su idioma, en el navegador que ya tiene abierto. No se instala nada, no hay registro, no hay contraseña y no hace falta cuenta. El código de la mesa lleva a una dirección web normal, y esa dirección ya sabe en qué mesa está sentado quien la abre.

Eso último es la parte que no se ve y que cambia el resto. El código pegado en mi mesa no era el mismo que el de la mesa de al lado: cada punto de pedido tiene el suyo. Por eso, cuando pedí, nadie tuvo que preguntarme dónde estaba sentado, y por eso el camarero no apareció con la bandeja mirando alrededor a ver quién había pedido una copa de blanco.

La pareja de la mesa de al lado hizo lo que hace casi todo el mundo y que no habíamos previsto al diseñarlo: enfocaron el código una sola vez, con un solo teléfono, y miraron la carta los dos juntos, con el móvil apoyado en la mesa entre los dos platos. No dos personas con dos pantallas. Una pantalla y cuatro ojos. Por eso las fotos importan más de lo que parece a esa distancia, y por eso el tamaño de la letra no es un detalle estético.

¿Por qué no hay que instalar ninguna aplicación?

Porque una aplicación que hay que instalar para cenar no la instala nadie. La carta es una página web: se abre en el navegador del móvil, funciona igual en iPhone y en Android, y deja de existir cuando el cliente cierra la pestaña.

Esto tiene una consecuencia práctica para el local que se nota el primer día: no hay soporte técnico que dar. Nadie va a preguntar en la barra por qué no le deja actualizar la aplicación, ni va a quedarse sin pedir porque tiene la memoria del teléfono llena. El listón es «tiene navegador», y lo cumple cualquier teléfono de los últimos diez años.

Tiene también una consecuencia menos cómoda, y prefiero decirla: sin conexión no hay carta. En una terraza con mala cobertura, el cliente no ve el menú. Por eso la página está hecha para pesar poco y cargar en una red mala, y por eso la carta en papel no desaparece del todo en muchos locales: sigue siendo el plan B más barato que existe.

¿Quién responde si un cliente tiene alergia?

El local, siempre. La plataforma no adivina alérgenos, no los deduce del nombre del plato y no los traduce a máquina. Lo único que hace el sistema es impedir que se publique un plato sobre el que nadie ha contestado.

Esta es la parte del producto en la que más discutimos internamente, y la que más me alegro de haber visto funcionando desde el lado de la mesa. La diferencia está en que un alérgeno no tiene dos estados, sino tres.

Una casilla marcada o sin marcar solo tiene dos estados, y el segundo se lee como «no lleva». Ahí está el fallo: la ausencia de dato acaba presentándose al cliente como una garantía que nadie ha dado. Por eso el tercer estado existe y por eso bloquea la publicación en lugar de mostrarse en gris.

Ojo. Los nombres de los catorce alérgenos no se traducen automáticamente en ningún idioma de la carta. Se toman de una lista fija revisada por personas. Un traductor automático puede convertir «apio» en «apio silvestre» o «altramuz» en «lupino» sin avisar, y esa palabra la lee alguien que decide con ella si come o no.

Lo que el sistema no puede hacer, y conviene decirlo en voz alta: no sabe si hoy la cocina ha usado la misma sartén para el rebozado con gluten y para el pescado sin él. La contaminación cruzada la conoce quien está en la cocina, no el programa. El sistema da el sitio para decirlo; decirlo es del local.

Hay un detalle más que solo se entiende desde dentro. Los platos con opciones —el café con leche de avena, la pizza sin queso— pueden cambiar los alérgenos según lo que elija el cliente. Por eso la pregunta sobre alérgenos no se hace solo al plato, sino también a cada opción: si el cliente cambia la leche, la lista de alérgenos que ve cambia con ella.

Y hay una decisión que costó discutir: una opción sin respuesta sobre alérgenos no bloquea la publicación del plato, mientras que un plato sin respuesta sí. La razón es práctica: si cada una de las ocho opciones de un café pudiera bloquear la carta entera, nadie publicaría nunca. Lo que sí pasa es que el cliente que elige esa opción ve, con palabras, que sobre ese cambio no hay dato confirmado. Avisar en lugar de esconder es la regla que atraviesa todo este apartado.

¿Qué pasa cuando se acaba un plato a mitad del servicio?

Alguien del local lo marca como agotado y desaparece de la carta de todos los clientes en ese momento. No hay que reeditar la carta, ni volver a publicarla, ni imprimir nada. Un toque.

Esto lo vi de refilón y es el detalle que más me gustó, porque es el que ahorra la conversación más incómoda del oficio: la de volver a la mesa a decir que lo que acaban de pedir no queda. El plato sigue existiendo en la carta del local, con su precio y sus alérgenos intactos; simplemente deja de poder pedirse hasta que alguien lo vuelva a activar.

Conviene saber. La diferencia entre quitar un plato del stop-list y borrarlo: borrar un plato se lleva por delante sus alérgenos, sus traducciones y su foto, y volver a crearlo mañana es media hora de trabajo. El stop-list no toca nada de eso.

Qué exige la ley sobre los alérgenos de esa carta

¿En qué idioma ve la carta el cliente y en qué idioma llega a la cocina?

Son dos ajustes distintos y no se mezclan. El cliente ve la carta en su idioma; la cocina recibe el pedido en el idioma de trabajo del local. Un cliente que pide en alemán no obliga a nadie en la cocina a adivinar qué es un «hausgemachte Limonade».

Parece una obviedad y no lo es: es un error clásico de los sistemas multiidioma, que traducen el pedido junto con la carta y acaban mandando a la plancha un ticket en un idioma que allí no lee nadie. El nombre del plato se guarda dos veces en el momento del pedido: en el idioma en el que el cliente aceptó, como prueba de qué pidió, y en el idioma de trabajo, para quien lo cocina.

El que me tocó de cerca fue el ruso. La mesa de al lado pidió en ruso y en la cocina siguió apareciendo en español, que es el idioma de trabajo del local. Nadie hizo nada especial para eso.

Lo mismo visto desde el otro lado de la barra: qué cambia para el local

¿Cuándo se cobra el dinero de un pedido?

Al pedir no se cobra: se retiene. El importe queda bloqueado en la tarjeta del cliente, y solo se cobra de verdad cuando el local acepta el pedido. Si el local no lo acepta, la retención se suelta y el cliente no paga nada.

Este es el punto donde más conviene ser exacto, porque suena a matiz y no lo es. Un sistema que cobra en el momento del pedido le pasa al local el problema de las devoluciones: cada plato que no se pudo servir es un reembolso, con su comisión, su papeleo y su cliente molesto. Reteniendo primero, el pedido que no se acepta simplemente no llega a ser un cobro.

1. El cliente confirma el pedido: el importe se retiene en su tarjeta.
2. El pedido aparece en la pantalla del local.
3. El local lo acepta: en ese momento se cobra.
4. El local no lo acepta o pasa el tiempo límite: la retención se suelta sola.

Los datos de la tarjeta no pasan por nosotros ni se guardan en ningún sitio nuestro. El pago lo lleva el proveedor de pagos directamente con el banco del cliente; a nosotros nos llega el resultado, no el número.

El dinero tampoco pasa por nosotros. Va a la cuenta del restaurante, no a una cuenta nuestra desde la que después se le transfiere. Esa diferencia importa el día que un intermediario tiene un problema: si el dinero de las cenas de tu local está en la cuenta de otro, el problema de ese otro pasa a ser tuyo.

Hay una consecuencia menos agradable del mismo diseño, y va aquí para que no parezca que solo cuento la parte buena: aceptar pagos con tarjeta obliga al local a darse de alta con el proveedor de pagos y a verificar su identidad. Eso son papeles y unos días de espera. Sin ese paso, la carta funciona y los pedidos llegan, pero el cobro con tarjeta no se enciende.

Qué ocurre por dentro entre «Pedir» y la cocina

¿Qué ve la cocina mientras el cliente espera?

Una pantalla con los pedidos en columnas por estado. Cada pedido se mueve con un toque, y el que lleva demasiado tiempo parado se marca con un aviso propio para que no se pierda entre los demás.

Lo importante no es la pantalla, es lo que hay detrás: un pedido aceptado no puede perderse porque falle la red un segundo. Se guarda antes de mostrarse, y si la entrega a la pantalla falla se reintenta; lo que no consigue entregarse acaba en una lista visible, no en el vacío. Poner algo en una cola no es lo mismo que haberlo entregado, y esa distinción es la mitad del trabajo de fontanería de un sistema de pedidos.

Desde la mesa esto se traduce en una cosa muy poco épica: pedí, y a los pocos segundos el estado de mi pedido cambió en mi propio móvil. No tuve que preguntar si había entrado.

Hay otra decisión que se ve poco y cambia el trabajo de la cocina: el estado no es del pedido entero, es de cada línea. La cerveza sale de la barra y el arroz de la cocina, y cada uno marca lo suyo cuando lo tiene. Un pedido que solo se puede marcar entero obliga a que el más lento decida por todos, y al final nadie lo marca hasta que ya está en la mesa, que es cuando marcarlo ya no sirve para nada.

El dinero, en cambio, sí es del pedido entero. Y es lo correcto: el cliente hizo un pago, no cuatro. Que el seguimiento vaya por líneas y el cobro por pedido es de esas cosas que parecen una inconsistencia en el diagrama y son exactamente lo que hace falta en el comedor.

¿Y si la mesa quiere pedir otra ronda?

Vuelve a pedir desde el mismo móvil y el segundo pedido se suma al primero. La mesa mantiene una cuenta abierta mientras dura la visita: no hay que volver a enfocar el código ni empezar de cero.

Esto es lo que más usamos aquella noche y lo que menos habíamos previsto al principio. Pedimos, comimos, y a la media hora pedimos postre sin levantar la vista de la mesa. Para la cocina llegó como un pedido nuevo, con su hora; para nosotros fue la misma cena.

La cuenta se cierra al final de la visita, y la siguiente persona que se siente en esa mesa empieza limpia. Parece evidente y no lo es: un sistema que ata la cuenta a la mesa en lugar de a la visita acaba enseñándole a un cliente lo que pidió el anterior.

¿Y si el cliente se arrepiente o hay que devolver parte del pedido?

Se puede devolver el pedido entero o solo una parte. La devolución parcial se hace por líneas: si de cuatro platos uno no se pudo servir, se devuelve ese y el resto sigue cobrado.

Lo que queda registrado es tan importante como el dinero. El pedido original no se reescribe: la línea devuelta se queda con su marca, y en el historial aparece qué se devolvió, cuándo y por quién. Un pedido que se puede editar por detrás deja de ser prueba de nada, y el día que haya una discusión con un cliente lo que salva al local es precisamente que no se pueda editar.

¿Por qué en la terraza y en la playa se paga por adelantado?

Porque en una hamaca no hay a quién pagarle. En la arena, el camarero que lleva la bebida no lleva datáfono, y cobrar en efectivo a veinte metros de la barra, con el cambio en el bolsillo, es la forma más rápida de perder dinero y de que la caja no cuadre al cierre.

Por eso los puntos de pedido de playa se marcan como tales y en ellos el prepago es obligatorio: el cliente paga al pedir y el camarero solo lleva. Es una decisión que suena dura hasta que uno cuenta los pasos que ahorra, y entonces deja de sonar dura.

En la mesa de un comedor, en cambio, el prepago no siempre hace falta: ahí el camarero pasa igualmente y la caja está a tres metros.

La otra mitad del problema de la playa no es el dinero, es saber dónde está el cliente. Una hamaca no tiene número por defecto, y «la tercera empezando por la izquierda» deja de funcionar en cuanto alguien mueve una sombrilla. Numerarlas y pegar el código en cada una es trabajo de una mañana que ahorra el resto del verano: el pedido llega con el número puesto y el camarero va derecho.

Y hay una tercera razón, menos evidente, para el prepago en la arena: el pedido que no se paga por adelantado se abandona más. La distancia entre pedir y recibir es mayor, el cliente se mete al agua, y quien pierde la ronda es el chiringuito.

¿Cuánto le cuesta esto al restaurante?

Se paga por punto de pedido y por día que ese punto ha estado activo, no por pedido servido. Y un mes sin pedidos pagados no se cobra: cuesta cero.

Digo esto con cuidado de no convertirlo en publicidad, así que me quedo en el hecho comprobable: un chiringuito que cierra en octubre no paga noviembre, diciembre ni enero por unas mesas que están apiladas en un almacén. No hay comisión sobre la venta: lo que cobra el banco por la tarjeta es del banco, y eso lo cobra igual cualquiera.

Conviene saber. En el resumen del local, la facturación cuenta solo los pedidos aceptados. Los que el cliente abandonó a mitad, o los que el local no aceptó, no inflan el número. Es menos vistoso y es el único número con el que se puede decidir algo.

¿Qué no hace este sistema?

No es un TPV, no lleva el almacén, no calcula escandallos y no gestiona el personal. Es un sistema de pedidos: el cliente pide, el local cobra y la cocina lo ve. Todo lo demás sigue donde estaba.

Lo escribo porque la pregunta llega siempre, y porque contestarla tarde es lo que convierte una venta en una devolución. Quien busca «software de gestión para restaurantes» normalmente busca una caja registradora con inventario. Eso es otra categoría de producto, y decirlo en la primera pantalla es más barato para todos que decirlo después de firmar.

• No sustituye al camarero: sustituye el rato en que el camarero está de pie esperando a que la mesa decida.
• No hace que se venda más por sí solo. Hace que no se pierda lo que ya se iba a vender.
• No funciona sin conexión en la mesa del cliente.
• No sabe lo que pasa en la cocina: la contaminación cruzada, el cambio de proveedor y el plato que hoy sale distinto los sabe el local.

¿Cómo se monta esto en un local que ya está abierto?

El trabajo real no es técnico: es pasar la carta. Montar las zonas, los puntos de pedido y los códigos lleva una tarde; escribir ciento y pico platos con sus precios, sus alérgenos y sus traducciones lleva días si se hace a mano.

Por eso la carta se puede subir desde un archivo, con los platos, los precios y, si están, los alérgenos y las traducciones en columnas. Y por eso el mismo archivo se puede volver a subir: la segunda vez no duplica nada, actualiza lo que coincide por categoría y nombre y crea solo lo nuevo. El día que suban los precios, eso es una columna y un botón, no ciento veinte formularios.

1. Dirección de la carta: se elige una vez y se queda. Va impresa en las pegatinas.
2. Zonas y puntos: salón, terraza, barra; dentro de cada zona, las mesas.
3. Carta: a mano o desde archivo, con precios e IVA.
4. Alérgenos: hasta que no hay respuesta, el plato no se publica.
5. Códigos QR: se imprimen todos de una vez, uno por punto.
6. Publicar: hasta ese momento, nada de lo editado llega al cliente.

Lo de la dirección merece un aviso, porque es lo único de esta lista que no se puede deshacer barato. La dirección de la carta se imprime en las pegatinas de las mesas: cambiarla después significa reimprimir y volver a pegar mesa por mesa. Se elige con calma el primer día.

Y lo de publicar es el detalle que más confunde al principio. Lo que el gerente edita no llega al cliente hasta que le da a publicar. Suena a paso de más hasta la primera vez que alguien deja una categoría a medio escribir a las ocho de la tarde: los clientes siguen viendo la carta anterior, entera.

¿Y la propina?

Se puede activar o no, y el local decide qué porcentajes se ofrecen. Si está activada, el cliente la ve al pagar, la elige o la deja en cero, y va junto con el pedido.

Aquí hay una diferencia cultural que conviene mirar antes de copiar lo que hace un sistema americano: en España la propina no es obligatoria ni esperada al mismo nivel, y una pantalla que la pide con insistencia molesta más de lo que recauda. Que se pueda apagar del todo no es un olvido, es la opción por defecto para mucha gente.

¿Y los clientes que no quieren usar el móvil?

Piden al camarero, como siempre. Un sistema de pedidos por código no obliga a nadie: es un canal más, no el único. El local que lo plantea como «o pides por el móvil o no pides» pierde clientes, y no por culpa del programa.

En la cena que cuento, de las cuatro mesas ocupadas pidieron por el móvil dos. Las otras dos llamaron al camarero. Nadie se quedó sin cenar y nadie tuvo que explicar nada. Esa es, para mí, la prueba de que está bien montado: que no se note quién usó qué.

Conviene saber. La carta en papel sigue teniendo dos usos que el móvil no cubre: el cliente sin batería y la mesa con mala cobertura. Mantener unas pocas plastificadas cuesta poco y ahorra la única situación en la que el sistema deja mal al local.

¿Qué mira el dueño a final de mes?

Cuánto se ha vendido, a qué horas, por qué puntos de pedido y en qué idiomas han mirado la carta. Los cuatro números se leen en un minuto y cada uno decide algo distinto.

El dato de idiomas fue el que me hizo entender para qué sirve medir esto. Un local puede creer que sus clientes son británicos porque el camarero habla inglés con ellos, y descubrir que la mitad abre la carta en francés. Eso cambia a qué idioma traduce primero y a quién contrata en verano.

¿Le compensa a su local? Cuatro señales y cinco casos en que no

Tres cosas que no me convencieron

Escribo esto porque un texto de alguien del equipo que solo cuenta lo que funciona no vale nada. Tres cosas me chirriaron esa noche, y las tres siguen ahí.

La primera: media carta sin fotos. Un plato sin foto se pide menos que el de al lado que sí la tiene, y eso no es un problema del local, que tiene otras cosas que hacer que montar un estudio fotográfico entre servicio y servicio. Es un problema que tenemos que resolver nosotros y todavía no está resuelto del todo.

La segunda: sin conexión no hay nada. Lo he dicho antes y lo repito aquí porque es la queja más legítima de todas. En una terraza junto al mar, con cincuenta móviles compitiendo por la misma antena, la carta tarda. Pesa poco a propósito, pero poco no es cero.

La tercera: el primer día da pereza. Pasar la carta, contestar catorce alérgenos por plato, decidir zonas. Es trabajo, y no hay forma honesta de decir que no lo es. Lo que sí puedo decir es que ese trabajo se hace una vez y que la parte más pesada, los alérgenos, hay que hacerla igual con carta de papel: la ley no distingue el soporte.

Lo que me llevé de la cena

Que la parte difícil de este oficio no es la tecnología. Es que el sistema no obligue a nadie a cambiar cómo trabaja. Nadie en aquel comedor hizo nada nuevo: el cliente miró una carta, el camarero llevó platos, la cocina cocinó. Lo único que cambió fue quién esperaba a quién.

Y que las decisiones que parecen pequeñas desde el lado del código son las que se notan desde la mesa. El tercer estado del alérgeno. El idioma que no se traduce hacia la cocina. La retención que no es un cobro. Ninguna de las tres se ve en una demo de cinco minutos, y las tres se ven el primer día que algo sale mal.