Qué pasa con un pedido desde que el cliente pulsa «Pedir»

Un cliente sentado en su mesa acaba de pulsar «Pedir». A partir de ese momento y hasta que el plato llega a la mesa pasan entre diez y treinta cosas, casi todas invisibles, y de cómo estén resueltas depende que el pedido llegue entero, llegue una sola vez y llegue a quien tiene que prepararlo.

Esta guía sigue un pedido concreto de principio a fin: qué se envía exactamente, por qué no se cobra en ese instante, qué ve la cocina, qué ocurre cuando falla la red, cuando la tablet está apagada, cuando nadie acepta la comanda o cuando el plato se ha terminado justo entonces. Es la parte que casi nadie explica, porque casi ninguna herramienta la resuelve del todo.

La escribimos desde una plataforma que vende exactamente esto. Lo decimos al principio por dos razones: para que sepa desde dónde se le habla, y porque hay decisiones en este recorrido que no tienen una única respuesta correcta, y vamos a señalar cuáles son en lugar de presentar las nuestras como la única forma posible.

¿Cuál es el recorrido completo, en una línea?

El cliente elige, confirma y autoriza el pago; el pedido viaja al sistema del local; el sistema lo pone en una cola; la cola lo entrega a las pantallas de cocina y barra; alguien lo acepta; en ese momento se cobra; se prepara; se entrega; se cierra. Nueve pasos. Los ocho primeros ocurren en segundos y el cliente solo ve dos de ellos.

Cada uno de esos pasos puede fallar, y la diferencia entre una herramienta seria y una improvisada no está en lo que hacen cuando todo va bien —ahí se parecen todas— sino en lo que hacen cuando algo se rompe. Por eso el resto del artículo dedica más espacio a los fallos que al camino feliz.

¿Qué ocurre en el móvil del cliente antes de que se envíe nada?

Nada sale del móvil hasta que el cliente pulsa el botón. Mientras elige, todo ocurre en su propio teléfono: la carta ya está descargada, el carrito vive en el navegador y ni el local ni nosotros sabemos que está mirando. Esto importa por una razón práctica: si el cliente se levanta y se va sin pedir, no queda rastro de nada, y eso es lo correcto.

También importa por una razón técnica. Como la carta ya está cargada, el cliente puede seguir leyéndola aunque la cobertura se le caiga. Lo que necesita red es enviar el pedido, no mirarlo. Una herramienta honesta se lo dice con esas palabras en lugar de fingir que el pedido ha salido.

La última pantalla antes del botón es la que más se subestima. Ahí el cliente tiene que ver tres cosas sin buscarlas: qué ha pedido, cuánto va a pagar y a qué mesa va. Si falta la tercera, el pedido llegará a la cocina sin saber dónde entregarlo, y la única forma de arreglarlo será que alguien salga a preguntar en voz alta quién ha pedido una caña.

¿Qué viaja exactamente cuando se pulsa «Pedir»?

Viaja una lista de líneas, un punto de pedido y una clave. Nada más. La lista de líneas es qué producto, cuántas unidades y con qué opciones elegidas. El punto de pedido es la mesa, la hamaca o la barra desde la que se ha escaneado. Y la clave es lo que impide que el mismo pedido se cree dos veces, de lo que hablamos más abajo porque merece su propio apartado.

No viajan los datos de la tarjeta. Esto no es un detalle de confianza sino de arquitectura: los datos de una tarjeta bancaria no pasan por el sistema del restaurante ni por el nuestro, y no se registran en ningún sitio. El cliente los introduce en el formulario del proveedor de pagos, y lo que vuelve al sistema es una autorización, es decir, un «sí» con un identificador. Si alguna vez le ofrecen un sistema donde el número de tarjeta pasa por el servidor del local, esa es una respuesta suficiente para levantarse de la mesa.

Tampoco viaja el nombre del cliente, salvo que la operativa lo exija. Para un pedido en mesa no hace falta: la mesa identifica el pedido mejor que un nombre. Para una recogida en barra sí, porque alguien tiene que llamar a alguien. Cuanto menos dato se pida, menos dato hay que proteger después.

Conviene saber. Un pedido sin punto de pedido es un pedido que alguien tendrá que adivinar. Compruebe en cualquier demostración que la mesa viaja dentro de la comanda y no en un campo de comentario libre.

¿Por qué no se le cobra al cliente en ese mismo momento?

Porque el local todavía no ha dicho que sí. Cuando el cliente confirma, su banco reserva el importe pero no lo mueve: es lo que se llama una autorización o retención. El dinero sale de verdad solo cuando alguien del local acepta el pedido. Entre esos dos momentos el importe está comprometido pero no cobrado.

Esto no es una sutileza contable. Es la diferencia entre un cliente al que hay que devolverle el dinero y un cliente al que nunca se le cobró. Si se ha terminado el pescado, usted rechaza el pedido, la retención se libera y el cliente no tiene que reclamar nada, ni llamar al banco, ni escribir una reseña de una estrella porque le cobraron algo que no llegó a comer.

La consecuencia práctica para el local es que cobrar deja de depender de que alguien se acuerde de cobrar. Y la consecuencia para el cliente es que el importe que ve retenido en su aplicación bancaria puede tardar unas horas en desaparecer si el pedido se rechaza: el banco lo libera a su ritmo, no al nuestro. Conviene que el personal lo sepa, porque es la pregunta que hará el cliente.

Dónde va la pantalla, por qué tiene que sonar y cómo se reparte entre partidas

¿Qué ve la cocina y en qué orden?

Ve una comanda escrita, con el punto de pedido en grande, las líneas tal como las eligió el cliente y las opciones que marcó. No ve el precio: a quien cocina el precio no le sirve para nada y ocupa el sitio de algo que sí importa. Y las ve en el orden en que llegaron, que es el único orden defendible cuando hay cola.

Lo que cambia respecto al papel no es la velocidad sino la ambigüedad. Una comanda escrita a mano depende de la letra de quien la escribió, de que haya oído bien y de que no se le haya caído al suelo. Una comanda digital dice exactamente lo que el cliente pulsó, incluidas las opciones que en el trato verbal se pierden: «sin cebolla» deja de ser algo que el camarero tiene que recordar y pasa a estar escrito en la línea.

Hay un detalle de operativa que conviene decidir antes de empezar y que casi nadie decide: qué pasa cuando un mismo pedido lleva cosas de la barra y cosas de la cocina. Lo razonable es que cada puesto vea solo lo suyo, y que el pedido no se considere completo hasta que ambos hayan terminado. Si su sistema manda la comanda entera a los dos sitios, uno de los dos aprenderá a ignorar la mitad de la pantalla, y ese hábito es el origen de la mayoría de los platos olvidados.

¿Qué pasa si nadie acepta el pedido?

Se cancela solo y se libera la retención. Tiene que haber un plazo, tiene que ser usted quien lo fije, y tiene que ser corto. Un pedido que lleva veinte minutos en la pantalla sin que nadie lo toque ya no es un pedido: es un cliente que se ha ido o que está a punto de hacerlo.

La razón de que el plazo lo fije el local y no el proveedor es que depende del sitio. Un chiringuito con dos personas en barra a las tres de la tarde necesita más margen que una pizzería con la cocina a dos metros de la pantalla. Cinco minutos es un punto de partida razonable para un bar; en temporada alta conviene revisarlo.

Ojo. Pregunte qué ocurre exactamente al vencer el plazo. «Se cancela» no es respuesta suficiente: hay que saber si se libera el dinero, si el cliente recibe un aviso y si al local le queda constancia de que aquello pasó. Las tres cosas, o no está resuelto.

¿Y si se le cae la cobertura al cliente a mitad de envío?

Lo correcto es que el pedido no se envíe y que se le diga con claridad. Lo peligroso es lo contrario: una pantalla que dice «pedido enviado» porque el botón se ha pulsado, no porque el servidor haya contestado. El cliente se queda esperando algo que nunca salió y el local no sabe que existe.

La prueba es fácil de hacer y conviene hacerla antes de firmar nada: ponga el móvil en modo avión con la carta abierta y pulse pedir. Si la pantalla dice que el pedido ha salido, el sistema está mintiendo en el único momento en que no puede permitírselo. Si dice que hace falta conexión y mantiene el carrito intacto para reintentarlo, va bien.

Hay un caso intermedio que es el más difícil: el pedido sí llegó al servidor, pero la respuesta no volvió al móvil. Desde el punto de vista del cliente parece un fallo; desde el del servidor, un pedido válido. Sin protección, el cliente pulsa otra vez y se crean dos pedidos idénticos. Cómo se evita eso es el siguiente apartado.

¿Puede un pedido enviarse dos veces?

No debe, y la forma de impedirlo es que el móvil genere una clave única para ese intento concreto y la envíe junto con el pedido. Si el servidor recibe dos veces la misma clave, entiende que es el mismo pedido y no crea el segundo. Devuelve el primero. En la jerga se llama idempotencia y es una de esas palabras feas que describen algo muy simple: repetir la orden no repite el resultado.

Sin eso, el doble pedido no es una rareza sino una consecuencia normal de una red mala, y la red es mala precisamente en las terrazas y en los sitios con paredes gruesas, que es donde están sus clientes. El cliente pulsa dos veces porque no pasó nada la primera; cocina recibe dos comandas iguales; alguien tiene que decidir si son dos personas que han pedido lo mismo o un fallo.

La misma protección debe existir en el pago. Un cobro repetido se devuelve, pero devolverlo cuesta tiempo, cuesta credibilidad y a veces cuesta comisión. Pregunte por ello en la demostración con estas palabras: «si pulso dos veces, ¿qué pasa?».

Dónde desaparece un pedido y las cinco pruebas que lo comprueban en una demostración

¿Qué es una cola de pedidos y por qué debería importarle?

Es lo que separa «el pedido está guardado» de «el pedido está en la pantalla de cocina». Son dos cosas distintas y confundirlas es el error más caro de todo este recorrido. Guardar un pedido es instantáneo y casi nunca falla. Llevarlo hasta una pantalla concreta, que puede estar apagada, sin batería o sin wifi, falla a menudo.

Una cola hace que ese reparto no dependa de que todo funcione en el mismo segundo. El pedido entra en la cola, y la cola lo intenta hasta conseguirlo: ahora, dentro de dos segundos, dentro de diez. Si la tablet vuelve a encenderse a los tres minutos, el pedido aparece. Sin cola, ese pedido simplemente no existió para la cocina y nadie se entera hasta que el cliente pregunta.

Para usted, la pregunta práctica no es si hay cola —casi todos dirán que sí— sino qué pasa cuando la cola se rinde. Un sistema serio no se rinde en silencio.

¿Qué pasa cuando ni siquiera la cola consigue entregar el pedido?

Tiene que saltar una alarma visible para una persona. No un registro en un archivo que nadie mira, no un correo a soporte: una señal en la pantalla, con sonido distinto, que diga que hay un pedido aceptado que no ha llegado a su sitio. Porque en ese momento hay un cliente sentado esperando algo que nadie está preparando.

Los pedidos que fracasan después de todos los reintentos se apartan a un sitio aparte —en la jerga, una cola de descartes— para que no se pierdan ni bloqueen a los siguientes. Eso está bien como mecanismo interno, pero es insuficiente como respuesta al local: lo que el local necesita es enterarse en el minuto, no que quede bien archivado.

Esta es, en nuestra experiencia, la pregunta que mejor separa las herramientas serias de las demás, y casi nadie la hace: «si un pedido aceptado no llega a la cocina, ¿cómo me entero yo?». Si la respuesta tarda en llegar o se convierte en una explicación técnica, tiene delante un sistema que confía en que eso no pase.

Los estados de un pedido, uno por uno

Un pedido no está «hecho» o «no hecho». Pasa por estados, y cada cambio de estado es un momento en el que alguien decide algo o el sistema decide por plazo. Saber cuáles son le sirve para dos cosas muy concretas: entender qué le están enseñando en una demostración y saber qué preguntar cuando algo se atasca.

Fíjese en la diferencia entre «rechazado» y «anulado». En el primero nunca se cobró; en el segundo hubo que devolver. Son dos operaciones distintas, con dos consecuencias distintas en su cuenta y en la del cliente, y un sistema que las llama igual le está escondiendo información que usted necesita al cuadrar la caja.

¿Y si el plato se acaba justo mientras el pedido está en camino?

Pasa constantemente y es uno de los momentos que mejor distingue una herramienta pensada para hostelería de una adaptada desde otro sector. El pedido ya salió; el producto ya no está. La respuesta correcta es que usted pueda rechazar ese pedido, o esa línea concreta, sin que el cliente tenga que reclamar nada.

La prevención es marcar el producto como agotado en cuanto se sabe, no cuando hay un hueco. Desde ese momento deja de ofrecerse y el problema no vuelve a ocurrir. Es un gesto de dos segundos desde la barra, y su valor está en que lo pueda hacer quien se entera, que rara vez es quien administra el sistema.

Lo que no debe pasar nunca es que el producto siga en la carta con una nota diciendo que a veces no hay. Una carta que no se puede creer del todo obliga al cliente a preguntar, y preguntar es exactamente el trabajo que se quería quitar de encima.

Cómo saber que ha salido bien. En una demostración, pida que agoten un producto delante de usted y compruebe cuánto tarda en desaparecer de la carta abierta en el móvil. Si hay que recargar la página a mano, en su local nadie lo hará.

Qué pasa cuando el plato se acaba con pedidos ya en marcha

¿Qué ocurre cuando el cliente quiere añadir algo después?

Hay dos formas y ninguna es obviamente mejor. La primera es tratar cada envío como un pedido nuevo e independiente: llega a cocina por separado, se cobra por separado y se entrega cuando esté. La segunda es acumular todo lo de esa mesa en una cuenta abierta y cobrar al final.

La primera encaja con el consumo rápido: cañas, cafés, tapas sueltas, playa. Cada cosa se paga cuando se pide y no hay nada pendiente si el cliente se levanta y se va. La segunda encaja con una comida larga, donde cobrar cuatro veces a la misma mesa resulta absurdo.

Lo importante es que la elección sea suya y no venga impuesta por una limitación técnica disfrazada de decisión de producto. Y que sea coherente con quién cobra: si el pedido se paga al enviarlo, la cuenta al final deja de tener sentido, y si hay cuenta abierta, alguien tiene que cerrarla antes de que la mesa se levante.

¿Cómo sabe el cliente que su pedido avanza?

Por una pantalla de estado que se actualiza sola. Es una pieza pequeña con un efecto desproporcionado: mientras el cliente ve que algo pasa, no pregunta. En cuanto la pantalla se queda quieta sin explicar por qué, levanta la mano, y con eso se pierde el motivo por el que se puso el sistema.

Lo que esa pantalla debe decir es poco y exacto: que el pedido llegó, que alguien se hizo cargo y que está servido. Lo que no debe decir es cuánto falta. Un contador que promete doce minutos crea una expectativa que la cocina no ha firmado, y cuando se incumple —y se incumple— el cliente no recuerda que era una estimación: recuerda que le dijeron doce minutos.

Hay un caso que merece atención especial: el cliente que cierra el navegador. Volverá a abrirlo, o no; su pedido tiene que seguir existiendo igual y su estado tiene que poder recuperarse. Si la única forma de saber en qué punto está es la pestaña que se acaba de cerrar, el sistema está atando información importante a algo tan frágil como un gesto de pulgar.

Y un detalle de sala que no es técnico pero cambia el resultado: cuando el cliente ve «servido» en su móvil y el plato aún no ha llegado, la culpa pasa a ser del sistema. Conviene que ese estado lo marque quien entrega, no quien termina de cocinar.

¿Quién puede cambiar un pedido y hasta cuándo?

Una vez enviado, el cliente no lo cambia. Puede pedir más, que es otro pedido, o puede pedir que le anulen el suyo, que es una conversación con una persona. Esta limitación no es pereza de diseño: si el cliente pudiera editar un pedido que ya está en la plancha, el sistema estaría prometiendo algo que la cocina no puede cumplir.

Del lado del local, la regla razonable es que se pueda intervenir mientras el pedido no esté aceptado, y que después cada cambio deje rastro. Quitar una línea de un pedido aceptado significa devolver dinero, y devolver dinero es una operación contable, no un botón de edición.

Conviene preguntar quién tiene permiso para qué. En un local pequeño todo el mundo hace de todo y está bien que así sea; en uno con quince personas en plantilla, que cualquiera pueda anular pedidos ya cobrados es un agujero. No por desconfianza: porque cuando algo sale mal hay que poder saber qué pasó, y un registro donde todos son «el local» no responde a esa pregunta.

¿Qué pasa cuando llegan veinte pedidos a la vez?

Se ponen en cola por orden de llegada y se muestran todos. Suena obvio y no lo es: la tentación de agrupar, priorizar o esconder pedidos «para no agobiar» produce el peor resultado posible, que es un pedido escondido detrás de otra pantalla mientras alguien lo espera en la mesa nueve.

El orden de llegada es el único criterio que no hay que explicarle a nadie y el único que el cliente percibe como justo. Cualquier otro —primero lo rápido, primero lo caro, primero las mesas de dentro— es una decisión de negocio legítima que alguien tendrá que defender delante de una mesa que lleva veinte minutos esperando mientras salen platos de las de al lado.

Lo que sí ayuda en hora punta es que la pantalla diga cuánto lleva esperando cada pedido. No cuánto falta: cuánto lleva. Es un dato que el sistema conoce con certeza, a diferencia del otro, y basta para que quien está en el pase sepa cuál coger a continuación sin que nadie le ordene nada.

Y hay un límite que conviene tener presente antes de la primera temporada alta: el cuello de botella deja de ser el sistema mucho antes de lo que parece. Cuarenta pedidos en pantalla no los resuelve un programa; los resuelve una cocina. Lo que el programa evita es que además haya que averiguar cuáles son.

¿Cuánto tarda de verdad todo el recorrido?

La parte digital tarda segundos y es la que menos importa. Lo que decide la experiencia del cliente son dos esperas humanas: cuánto tarda alguien en aceptar el pedido y cuánto tarda la cocina en prepararlo. La primera es la que el sistema puede mejorar de verdad; la segunda no depende de él.

Merece la pena medir el cuarto tramo durante la primera semana. Si aceptar un pedido tarda sistemáticamente más de un par de minutos, el problema no es la herramienta sino dónde está la pantalla, quién la mira y si suena lo bastante. Suele arreglarse moviendo una tablet medio metro.

¿Cómo sabe el sistema de qué mesa viene el pedido?

Del código que el cliente escaneó. Cada punto de pedido —cada mesa, cada hamaca, cada barra— tiene el suyo, y el código lleva esa identidad dentro. No es que el cliente elija su mesa en una lista: es que la mesa viene con el enlace, y por eso no se equivoca.

De aquí salen tres consecuencias prácticas que conviene tener claras antes de imprimir nada. La primera: si dos mesas comparten pegatina, comparten identidad, y los pedidos de una aparecerán como de la otra. La segunda: si mueve la pegatina, mueve la mesa. La tercera: si un cliente comparte el enlace por mensaje con alguien que está en otro sitio, ese pedido entrará como si viniera de esa mesa.

Esa tercera consecuencia asusta menos de lo que parece, porque el pedido hay que aceptarlo y hay que entregarlo en esa mesa. Pero explica por qué el código no debería publicarse en redes sociales: para la ventana al público está el enlace de la carta sin mesa, que enseña todo y no deja pedir.

Conviene saber. Si dos clientes de la misma mesa escanean cada uno con su móvil, son dos pedidos distintos de la misma mesa. No se mezclan y no se pisan: cada uno paga lo suyo. Para una mesa que quiere una sola cuenta, eso hay que decidirlo antes, no después.

¿Y si alguien pide cuando el local está a punto de cerrar?

El sistema tiene que saber el horario y dejar de aceptar pedidos fuera de él. Parece un detalle menor hasta la primera vez que entra una comanda a la una y media de la madrugada de un cliente que se quedó con la carta abierta en el móvil, y alguien tiene que decidir a esa hora si la prepara o devuelve el dinero.

Lo razonable es cerrar la puerta un rato antes del cierre real, no en el minuto exacto: entre que se pide y se prepara hay un tiempo, y la última comanda debería poder salir con la cocina todavía encendida. Ese margen lo fija el local, porque solo él sabe cuánto tarda su plato más lento.

Lo que no debe ocurrir es que el cliente descubra que el local está cerrado después de pagar. Si no se acepta el pedido, tiene que decirse antes del botón y con la razón escrita: cerrado, no un error genérico.

Dónde se rompe una comanda y qué lo arregla en cada punto

¿Hace falta que la comanda salga impresa en papel?

Depende de la cocina, y la respuesta honesta es que hay locales donde la pantalla no basta. En una parrilla con humo, grasa y las manos ocupadas, un ticket que se clava en una barra y se rompe cuando el plato sale es un sistema de organización que lleva un siglo funcionando y no es fácil de mejorar.

En otros locales pasa lo contrario: el papel se pierde, se moja, se queda pegado a otro, y una pantalla donde la comanda no se puede caer al suelo resuelve más de lo que complica. No hay una respuesta universal, y desconfíe de quien se la dé.

Si su cocina funciona con papel, pregunte por ello explícitamente y pida verlo funcionando con la impresora que usted tiene, no con una de muestra. Las impresoras de comandas son un mundo de conectores, protocolos y modelos descatalogados, y «es compatible» es una afirmación que conviene comprobar antes y no durante el primer servicio.

Conviene saber. En nuestro caso la impresión automática de comandas todavía no está disponible; el trabajo está hecho pero no lo hemos probado en impresoras reales, y hasta entonces no lo ofrecemos. Lo decimos aquí porque es exactamente el tipo de cosa que conviene saber antes de contratar.

Comanda digital y comanda en papel: qué gana cada una

¿Qué pasa con las propinas cuando se paga desde el móvil?

Es una de las preguntas que más rápido aparece y una de las que peor se resuelven. Al desaparecer el momento de pagar en la mesa desaparece también el momento en que se deja la propina, y en un sitio donde la propina era parte del sueldo real del personal, eso no es un detalle de interfaz.

La solución técnica es sencilla: ofrecer la propina en la pantalla de pago, con cantidades sugeridas y la posibilidad de no dejar nada sin tener que dar explicaciones. Lo que no es sencillo, y no es un problema de software, es decidir cómo se reparte después. Conviene tenerlo hablado con el equipo antes de encender el sistema, no después del primer cierre de mes.

Una advertencia práctica: una propina sugerida demasiado alta o marcada por defecto molesta más de lo que recauda. El cliente que se siente empujado no deja menos propina esa vez, deja de volver.

El cierre del turno: ¿qué se hace con lo que queda abierto?

Al final del servicio siempre queda algo: un pedido aceptado que nunca se marcó como servido, una cuenta abierta de una mesa que se fue, un pedido que caducó a las once y nadie miró. Un sistema que no obliga a resolver eso deja que se acumule, y al cabo de un mes el historial deja de servir para cuadrar nada.

Lo razonable es que el cierre de turno enseñe lo que queda pendiente y pida una decisión sobre cada cosa. No para castigar a nadie: para que la cifra del día sea la cifra del día. Un resumen que dice que se han cobrado ochocientos euros mientras hay tres pedidos colgados en un estado intermedio no dice ochocientos euros, dice aproximadamente ochocientos.

Y conviene mirar una cosa cada semana, aunque cueste: los pedidos rechazados y caducados, con su motivo. Son la lista de las veces que un cliente quiso darle dinero y no pudo. Suele ser una lista corta y aburrida —se acabó el pescado, cerramos la cocina— hasta que un día deja de serlo.

¿Qué pasa con los alérgenos durante todo este recorrido?

La información de alérgenos tiene que estar disponible antes de pedir, no después. Es una obligación legal en la Unión Europea desde el Reglamento 1169/2011, y en un pedido digital se cumple de una forma muy concreta: el cliente puede verla en la ficha del producto sin registrarse, sin descargar nada y sin preguntar a nadie.

Lo que ocurre durante el recorrido es menos evidente y más importante: esa información no viaja con el pedido a la cocina, porque en cocina no aporta nada —quien cocina ya sabe qué lleva su plato—. Donde sí tiene que estar es en el momento de elegir. Un sistema que enseña los alérgenos solo en la confirmación llega tarde: el cliente alérgico ya ha invertido tiempo en un plato que no puede comer.

Hay un matiz que conviene exigir a cualquier proveedor: que el sistema distinga «no contiene» de «no consta». Son cosas distintas y confundirlas es peligroso. Una casilla sin marcar no significa que el plato sea seguro; significa que nadie ha contestado. Tratamos esto a fondo en la guía sobre alérgenos en la carta, y es el único punto de todo el recorrido donde una decisión de diseño se mide en salud y no en comodidad.

Ojo. Los nombres de los catorce alérgenos no se traducen automáticamente. «Nuez» y «nueces» no son intercambiables en todos los idiomas y una traducción automática puede convertir un aviso en una lista distinta. Si su proveedor traduce la carta entera a máquina sin excluir el listado de alérgenos, pregúntele quién responde de eso.

¿Qué queda registrado y para qué sirve después?

Queda el pedido con su hora, su punto de pedido, sus líneas, quién lo aceptó y cuándo cambió de estado. Sirve para tres cosas distintas y conviene no mezclarlas: cuadrar la caja al final del turno, entender el negocio al final del mes y defenderse si algún día hay una reclamación.

Para cuadrar la caja importa una sola pregunta: cuánto se cobró de verdad. Los pedidos rechazados no cuentan porque nunca se cobraron; los anulados sí aparecen, pero restando, y con su motivo al lado. Un resumen que mezcle las tres cosas en una sola cifra no sirve para cuadrar nada.

Para entender el negocio importan los cortes: por horas, por puntos de pedido, por productos. Aquí es donde un local descubre cosas que no sospechaba, como que la mesa del rincón pide la mitad que las demás porque el código no se ve bien desde la silla, o que el segundo café de la sobremesa desaparece a partir de las cuatro.

Y para defenderse importa que ese registro no se pueda reescribir. Un historial que cualquiera puede editar no es un historial: es una opinión con fecha.

¿Y si el cliente se cambia de mesa a mitad?

Pasa todos los días en una terraza: llega el sol, se libera una mesa mejor, la mesa de al lado se va y el grupo se junta. El pedido ya enviado sigue apuntando a la mesa desde la que se escaneó, porque esa es la información que viajó con él, y nadie en el sistema sabe que el cliente se ha movido.

La solución no es técnica sino de sala: quien entrega tiene que poder cambiar la mesa de un pedido en un gesto, y ese cambio tiene que quedar registrado. Si para corregirlo hay que anular y rehacer, nadie lo corregirá: se apañarán de memoria, y al tercer traslado del día alguien entregará una cosa en el sitio equivocado.

Para el siguiente pedido el problema se resuelve solo: el cliente escanea el código de su mesa nueva. Merece la pena decírselo cuando se cambia de sitio, y es una de las tres frases que conviene que todo el equipo tenga aprendidas.

Si se cae la red justo al pagar: qué pasa con el dinero

¿Qué datos del cliente se guardan y cuánto tiempo?

Los mínimos y el tiempo que hagan falta, y ambas cosas deberían estar escritas en algún sitio que el cliente pueda leer. Para un pedido en mesa basta con el punto de pedido, las líneas y el identificador del pago. No hace falta nombre, ni teléfono, ni correo, y pedirlos «por si acaso» convierte al local en responsable de unos datos que no necesitaba.

Donde sí aparecen datos personales es en lo que los exige: una recogida para llevar necesita un nombre o un número para avisar; una reserva necesita un teléfono. En cuanto eso ocurre, el local pasa a ser responsable del tratamiento a efectos del Reglamento General de Protección de Datos, y eso implica tres obligaciones concretas: decir para qué se usan, decir cuánto se guardan y poder borrarlos si alguien lo pide.

La parte que casi nadie resuelve es la tercera. Un sistema que guarda los teléfonos de las reservas para siempre no cumple, por mucha política de privacidad que tenga colgada. Lo correcto es que el propio sistema borre los datos de contacto pasado un plazo que el local fija, y que lo haga solo, sin que nadie se acuerde. El pedido en sí puede quedarse —hace falta para la contabilidad—; el teléfono de quien lo hizo, no.

Pregunte con estas palabras: «¿cuánto tiempo se guardan el nombre y el teléfono de un cliente, quién lo decide y qué pasa cuando vence el plazo?». Si la respuesta es que se guardan indefinidamente, el problema legal será suyo, no del proveedor.

El día que el sistema no está disponible

Va a pasar alguna vez, y conviene haberlo pensado antes con la cabeza fría en lugar de a las dos de un sábado. Un corte de luz, una avería del proveedor de internet, un fallo en el servidor: la diferencia entre un mal rato y un mal día está en si el local tiene una forma de seguir trabajando sin el sistema.

La respuesta honesta es la más antigua: bloc y bolígrafo. Un local que sabe volver a tomar nota a mano durante una hora pierde una hora; uno que ha desmontado del todo esa capacidad pierde el servicio. No hace falta ensayarlo: basta con que el equipo sepa que es lo que se hace y dónde está el bloc.

Del lado del proveedor, lo que conviene preguntar no es si se cae —todo se cae— sino dos cosas más útiles: cómo se entera usted de que está caído, y qué pasa con los pedidos que estaban a medias cuando volvió. Un sistema que al recuperarse duplica los pedidos que ya se habían servido es peor que uno que estuvo caído veinte minutos.

Y una tercera, más incómoda: qué pasa con su carta si el proveedor cierra la empresa. La respuesta útil es un fichero que usted pueda descargarse hoy, no una promesa de que eso no va a ocurrir.

Qué cambia en la sala cuando los pedidos entran solos

Qué mirar en una demostración de media hora

Una demostración se prepara para que todo salga bien, y por eso enseña poco. Estas seis pruebas se hacen en minutos, no requieren conocimientos técnicos y enseñan lo que la presentación no enseña. Puede pedirlas sin sentirse incómodo: un proveedor que las tiene resueltas disfruta enseñándolas.

1. Pida desde el móvil con el modo avión activado y mire qué dice la pantalla.
2. Pulse el botón de pedir dos veces seguidas y cuente cuántas comandas aparecen.
3. Apague la tablet de cocina, haga un pedido, y encienda la tablet: compruebe si el pedido aparece.
4. Rechace un pedido y mire qué le pasa al importe retenido y qué ve el cliente.
5. Agote un producto desde la barra y compruebe cuánto tarda en desaparecer de un móvil que ya tenía la carta abierta.
6. Abra el resumen del día y busque, por separado, lo cobrado, lo rechazado y lo anulado.

Si alguna de las seis termina con «eso normalmente no pasa», tiene delante un sistema construido para el caso bueno. El caso bueno no es donde se pierde dinero.

Cómo saber que ha salido bien. Haga las pruebas con su propio móvil y su propia cobertura, en su propio local si es posible. Una terraza con paredes de piedra y una sala con fibra son dos mundos distintos, y el suyo es el que cuenta.

Qué no resuelve este recorrido

Conviene decirlo con la misma claridad con la que se cuenta lo demás, porque la mitad de los disgustos con estas herramientas vienen de esperar de ellas cosas que nunca prometieron.

• No sustituye a una caja registradora ni a un TPV. Son categorías distintas: una recoge y reparte pedidos, la otra lleva la caja y la facturación.
• No lleva el almacén. Saber que se han vendido cuarenta croquetas no es lo mismo que saber cuántas quedan en el congelador.
• No hace reparto a domicilio. Un pedido desde la mesa y un pedido a diez calles son dos problemas con poco en común.
• No sustituye al personal. Quita viajes a la mesa para tomar nota; no quita el trabajo de preparar, servir y atender.
• No arregla una carta mal hecha. Si los platos no se entienden por escrito, el cliente seguirá preguntando, solo que ahora en voz alta y con el móvil en la mano.

Diez preguntas para hacerle a cualquier proveedor

Están ordenadas por lo que más duele cuando falla. Valen para nosotros y para cualquier otro; si alguna respuesta se convierte en una explicación larga sobre lo improbable que es ese caso, ya sabe cuál es la respuesta.

1. Si un pedido aceptado no llega a la cocina, ¿cómo me entero yo, y en cuánto tiempo?
2. Si el cliente pulsa dos veces, ¿se crean dos pedidos?
3. Si el cliente se queda sin cobertura al enviar, ¿qué ve en la pantalla?
4. ¿En qué momento exacto se le cobra al cliente: al pedir o al aceptar?
5. Si rechazo un pedido, ¿el cliente tiene que reclamar el dinero o se libera solo?
6. ¿Cuánto tiempo tengo para aceptar antes de que caduque, y lo fijo yo?
7. ¿Puede quien está en barra agotar un producto, o hace falta entrar en la administración?
8. ¿La cocina y la barra ven cada una lo suyo o las dos ven el pedido entero?
9. ¿Dónde se ve, a final de turno, lo cobrado de verdad separado de lo anulado?
10. Si mañana dejo de trabajar con ustedes, ¿me llevo la carta y el historial, y en qué formato?

Conviene saber. La última pregunta incomoda a mucha gente y por eso vale la pena hacerla. Una respuesta tranquila indica un proveedor que no basa la relación en lo difícil que resulta irse.

Cómo está resuelto esto en QuickOrder

Hasta aquí hemos descrito la categoría. Este apartado es sobre nosotros, y va al final a propósito: si lo de arriba no le ha servido, esto tampoco le va a servir.

El dinero no se mueve hasta que el local acepta. Al confirmar se retiene el importe; al aceptar se cobra; si nadie acepta dentro del plazo que usted fija, se cancela solo y la retención se libera. Los datos de la tarjeta no pasan por nuestros servidores en ningún momento.

Cada creación de pedido y de pago lleva su clave de repetición: pulsar dos veces no crea dos pedidos. El reparto a las pantallas va por cola con reintentos, y un pedido aceptado que no consigue llegar a su destino genera un aviso visible para el personal, no una línea en un registro. La cocina y la barra ven cada una lo suyo.

La carta se cambia desde el propio local: agotar un producto es un gesto desde la barra y desaparece de los móviles que ya tienen la carta abierta. Los alérgenos tienen tres estados y no dos, y un producto sin respuesta explícita en los catorce no se publica: preferimos una carta incompleta a una carta que diga «no contiene» porque nadie contestó.

Y lo que no hacemos está igual de claro: no somos una caja, no llevamos almacén y no hacemos reparto. Su cocina y su caja siguen donde están.

Preguntas frecuentes

En resumen

El código QR es la puerta, no el producto. Lo que decide si esto funciona en un servicio de viernes no es la carta bonita sino lo que pasa en los ocho segundos siguientes al botón: que el pedido salga una sola vez, que llegue entero a quien lo prepara, que el dinero no se mueva hasta que alguien diga que sí, y que si algo se rompe se entere una persona y no un archivo de registro.

Todo lo demás —idiomas, fotos, estadísticas— se construye encima de eso. Si eso no está resuelto, lo demás decora un problema.