Al elegir un sistema de gestión de restaurantes conviene empezar no por las funciones que necesita, sino por ver dónde guarda hoy cada información. Si la carta está en un sitio, las reservas en otro, los pedidos en el TPV y los datos de cliente en un cuarto sistema, la misma información hay que actualizarla y comprobarla más de una vez.
Por eso, al evaluar un sistema es más útil mirar dónde se van a guardar la carta, el pedido, la mesa, la reserva, el cliente y el personal. Para cada uno, aclare dos cosas: qué sistema guarda el registro principal y si los demás pueden leerlo desde ahí. Esas respuestas son la base de su lista de requisitos.
Qué hace un sistema de gestión de restaurantes
Piense en cambiar un precio. Cuando el sistema funciona, el cambio se hace una vez y aparece a la vez en la carta que ve el cliente, en el listado de reparto y en el informe de la semana. Cuando no funciona, el mismo cambio se hace en tres sitios, uno se queda sin tocar, y suele ser justo el que el cliente tiene delante.
El término se usa con bastante holgura. Hay fabricantes que venden debajo una suite entera y otros que llaman igual a un solo módulo, así que la comparación se ordena preguntando de qué registros se hace cargo cada uno.
Conviene contar también con lo que el software no resuelve. Un canal de pedido digital acorta la espera del pedido, no la de la comida: si la cocina no puede seguir el ritmo con el que entran las comandas, la espera se traslada de la mesa al pase y el cliente la nota igual, solo que más tarde.
El alcance: los registros que el sistema guarda
Los nombres de los módulos que ve en las páginas de producto cambian de un sistema a otro: lo que uno llama gestión de pedidos, otro lo llama pantalla de ventas. En cambio, la información de carta, pedido, mesa y reserva hay que guardarla en algún sitio, elija el sistema que elija. Escribir la lista de requisitos alrededor de esa información le permite comparar sistemas con las mismas preguntas.
| Registro | Qué tiene que guardar | Quién lo lee después |
|---|---|---|
| Artículo de la carta | Nombre, descripción, foto, un precio por cada tamaño, extras, alérgenos e información nutricional, y las horas en las que se puede pedir | Carta del cliente, web, listado de reparto, informes de ventas |
| Pedido | Canal, mesa o dirección, artículos con sus extras, estado, forma de cobro | Cocina, caja, contabilidad, informes |
| Mesa y zona | En qué zona está, cuánta gente sienta, su código y en qué estado se encuentra ahora mismo | Sala, pedidos, reservas |
| Reserva | Hora, número de personas, duración prevista, notas del cliente, señal si la hay | Plano de sala, ficha del cliente |
| Cliente | Contacto, consentimiento, historial de pedidos, opiniones y valoraciones de artículos | Promociones, segmentación, recuperación tras un mal servicio |
| Personal | Rol y permisos, quién puede enviar un pedido y quién puede anularlo | Pedidos, informes, relevo de turno |
El artículo de la carta es el registro del que dependen más cosas y también el que peor se especifica. Escrito como un nombre y un precio, produce un sistema que no sabe decirle a un cliente si un plato lleva frutos secos, que no puede esconder los desayunos a las tres de la tarde y que no sabe qué tamaño se vende de verdad. Escrito entero, lleva precio por tamaño, extras, alérgenos, información nutricional y las franjas horarias en las que el artículo se puede pedir. Todo lo que viene después lee de ahí.
Las reglas de negocio: la mitad que las listas de requisitos olvidan
Un registro dice qué existe. Una regla dice qué tiene que hacer el sistema cuando pasa algo, y ahí está la diferencia entre un pliego de requisitos y una carta a los Reyes.
La mayoría de esas reglas ya gobiernan su casa. Viven en la cabeza de alguien, se le explican a cada persona que entra nueva y nunca se han escrito. Póngalas todas con la misma forma: cuando pase esto, el sistema tiene que hacer aquello, y estas personas pueden saltárselo.
- Horarios. Qué días y entre qué horas se puede pedir cada artículo. Los desayunos cierran a las once y el menú del día solo existe a mediodía.
- Umbrales. Importe mínimo para aceptar un pedido a domicilio, coste de envío, tiempo de preparación y tiempo de trayecto. La suma de esos dos últimos es la promesa que le hace al cliente.
- Quién puede pedir qué. Verificación de edad en el alcohol, un código promocional que vale en reparto y no en sala, un descuento que se abre a partir de cierto importe.
- Permisos. Quién envía un pedido, quién lo anula y hasta qué punto del paso por cocina se puede anular.
- Dinero. Precio por tamaño, cargos que se suman a la cuenta y en qué canales se aplican, cómo se reparte una cuenta entre varias personas.
- Estados. Qué pasa cuando el cliente cancela, qué pasa con un artículo que se agota a mitad de servicio, si la mesa sigue abierta después del cobro.
Aquí es donde un sistema falla sin hacer ruido. Una regla que el software no sabe expresar vuelve a depender de que alguien la recuerde en pleno servicio, y a esa hora la memoria compite con otras veinte cosas.
Cómo armar la lista de requisitos sin adivinar
No hace falta una plantilla. Hace falta un servicio entero y una libreta.
Siéntese a ver un servicio de principio a fin y apunte cada vez que un mismo dato se teclea en un segundo sitio. Una comanda que se lee en papel y se vuelve a meter en la caja. Una reserva que se coge por teléfono y se copia en el libro. Un precio que se cambia en la pizarra y no en la aplicación. Cada una de esas veces es una línea de requisitos, y es una línea que puede defender porque la ha visto pasar.
Después siga un solo pedido desde que se toma hasta que aparece en la contabilidad y cuente por cuántos sitios pasa. Cuantos más sean, antes tiene que aparecer la integración en el pliego, porque cada salto es una copia que alguien mantiene a mano.
Quedan dos preguntas. Para cada registro de la tabla: ¿quién lo mantiene hoy y quién debería mantenerlo después? Y para cada regla que haya apuntado: ¿el software sabe expresarla o se queda en la cabeza de alguien?
Estas preguntas sirven igual si en lugar de contratar un sistema va a encargar que se lo desarrollen. Lo que entrega a quien lo programe es esta misma lista, y un desarrollo a medida se encarece justo donde la lista está a medias, porque cada registro mal definido se arregla más tarde y con la casa ya funcionando.
Apunte también lo que la sala no va a aceptar. No todas las mesas quieren pedir desde el móvil: los grupos grandes, los clientes mayores y ciertas celebraciones siguen esperando a alguien, y un montaje que da por hecho que todo el mundo escaneará un código se acaba sorteando la primera semana.
El orden en el que conviene montarlo
El orden no es una preferencia. Cada paso lee del anterior, así que saltárselo suele significar hacer el trabajo dos veces.
- Ficha del local y horarios de apertura. De aquí lee todo lo demás, incluido lo que se genere más tarde.
- La carta: secciones, artículos, precio por tamaño, extras, alérgenos e información nutricional. Es con diferencia el paso más largo y conviene terminarlo antes de encender nada.
- Mesas y zonas: a qué zona pertenece cada mesa, cuánta gente sienta y con qué código se identifica.
- Canales: sala, reparto, recogida y tablet, y qué carta ve cada uno de ellos.
- Reglas: la lista de la sección anterior, metida como ajuste y no explicada de palabra al personal.
- Integraciones: caja, cobro, impresora. Compruebe los sistemas que ya usa contra la lista compatible antes de firmar nada.
- Informes. Antes de salir en vivo, elija un día que ya haya pasado y pídaselo al sistema artículo por artículo. Si tiene que exportarlo y rehacerlo en una hoja de cálculo, los informes todavía no están dentro del alcance, diga lo que diga la lista de funciones.
Lo que se genera va al final: la web, las fotos, las traducciones. Todo eso lee de los registros de arriba, y lanzarlo antes es la manera más común de acabar haciéndolo dos veces. Los límites de uso, como el número de artículos, de mesas o de idiomas, dependen del plan contratado, así que mírelos en la página de precios antes de montar la carta entera.
Cómo funciona esto en FineDine
En FineDine la ficha de un artículo guarda la descripción y la foto, un precio por cada tamaño, los extras, los alérgenos y la información nutricional por tamaño, los días y las horas en las que se puede pedir y, para una cafetería, la cafeína en miligramos. La carta del cliente, los canales de pedido, la web y los informes leen esa misma ficha, de modo que el cambio se hace una vez. Si la carta ya existe en foto, PDF o una hoja de cálculo, el creador de menús con IA saca de ahí las secciones, los artículos y los precios y usted corrige lo que haga falta; el centro de traducción mantiene después la carta en varios idiomas sin duplicarla, con el porcentaje completado a la vista.
Las mesas y las zonas se definen en la gestión de mesas, y de ahí salen los códigos con los que se identifica cada una. Los canales de pedido se activan por separado y cada uno arrastra sus propias reglas, que viven como ajustes y no como instrucciones para el turno: importe mínimo, coste de envío, tiempo de preparación y de trayecto, verificación de edad y códigos promocionales que se pueden limitar a un solo canal.
El marketplace lista las cajas registradoras, las pasarelas de pago y la impresora de tickets con las que conectamos, con proveedores de cobro pensados para Turquía y Oriente Medio junto a los globales. Algunas conexiones vienen incluidas y otras se pagan aparte, así que compruebe las que le afectan en la página de precios. Los informes llegan en dos capas: el resumen, el informe por artículo y el de negocio por un lado, y encima una capa de IA que se actualiza cada hora en vez de una vez por la noche.
Si quiere ver cómo quedarían su carta, sus mesas y sus reglas dentro de un mismo sistema, puede pedirnos una demostración con su propio servicio como ejemplo.
Preguntas frecuentes sobre los sistemas de gestión de restaurantes
- ¿Un sistema de gestión de restaurantes es lo mismo que un TPV?
- No exactamente, y la diferencia está en qué registros guarda cada uno. El TPV se hace cargo de la transacción: el cobro, la caja, el ticket. El sistema de gestión guarda la carta, el canal por el que entra el pedido, la mesa a la que pertenece y el cliente que hay detrás. Muchos locales tienen los dos funcionando a la vez. La pregunta útil es cuál de ellos guarda la versión buena de la carta, porque ese es el registro que más cambia.
- ¿Y si el TPV que uso no está en la lista de integraciones?
- Entonces el registro del pedido se parte en dos y alguien lo introduce por segunda vez. En un local pequeño se sobrelleva; en uno con volumen sale caro. Antes de darlo por bloqueante, mire qué necesita cruzar de verdad. En bastantes restaurantes es el total de ventas del día y no cada línea, y para eso basta con una conciliación diaria sin conexión en vivo.
- ¿Una cafetería pequeña necesita uno?
- Si la misma persona toma el pedido, lo prepara y lo cobra, y no hay nada que se escriba dos veces, la ganancia es pequeña. La cosa cambia cuando el mismo dato empieza a vivir en dos sitios, o cuando responder qué se vendió el martes pasado significa ponerse a contar tickets.
- ¿Cuánto se tarda en montarlo?
- La configuración es corta. La carta no. El tiempo se va en fotografiar platos, decidir los tamaños y rellenar los alérgenos, y ese trabajo le espera con cualquier sistema que elija. Subir la carta que ya tiene, en foto, PDF u hoja de cálculo, deja un borrador que se corrige en lugar de una lista vacía, y eso acorta bastante la primera vuelta.
- ¿Puede la misma carta funcionar en varios idiomas?
- Puede, y conviene saber qué implica. La traducción va campo por campo, así que cada nombre de plato y cada descripción es una tarea en sí misma. Se lleva bien cuando el centro de traducción muestra el porcentaje completado de cada idioma y deja filtrar lo que sigue sin traducir. La traducción automática da una primera vuelta que hay que repasar a mano, sobre todo en nombres de plato y alérgenos, y cuántos idiomas puede tener depende del plan que contrate.
