Por qué la mayoría de sistemas POS dejan tirados a los restaurantes

Viernes por la noche. 180 reservas, todas las mesas ocupadas, lista de espera en la puerta. La cocina va a tope, el barman tiene tres cócteles en la mano a la vez, el equipo de sala lo está dando todo. Y entonces pasa: el router se cae durante tres segundos.

Tres segundos. Eso es lo único que hace falta.

El sistema POS se congela. El barman no puede cerrar las cuentas abiertas. La camarera no puede dividir la cuenta. La cocina deja de recibir pedidos. Y de repente estás ahí, apuntando comandas en servilletas como si fuera 1995.

Lo he vivido. No una vez, ni dos, sino tantas que dejé de contar. Años trabajando en hostelería, en restaurantes y cervecerías, después en hosteles y hoteles en tres continentes. Y siempre la misma historia: sistemas POS que fallan justo cuando más los necesitas.

El problema no es que no existan sistemas POS. Hay cientos. El problema es que la mayoría no fueron diseñados para la hostelería. No de verdad. Fueron diseñados para demos, para presentaciones a inversores y para stands de ferias. Y cuando llega el viernes por la noche y 200 personas quieren pedir a la vez, se ve lo que realmente valen.

La promesa frente a la realidad

Todos los sistemas POS quedan genial en la demo. Interfaz limpia, animaciones bonitas, todo responde al instante. El comercial hace clic en un par de pedidos, enseña los informes, quizá abre una reserva de mesa. Tiene buena pinta. Me lo llevo.

Pero las demos no tienen 200 comensales. En las demos nadie derrama una cerveza encima del terminal. En las demos no hay un camarero nuevo que está en su primera noche y que, bajo presión, pulsa los botones equivocados. En las demos no se atasca la impresora de tickets, no se cae el WiFi y ningún jefe de cocina grita porque no le llegan las comandas.

Es exactamente en ese hueco entre la demo y el servicio del sábado noche donde la mayoría de sistemas POS hacen aguas. Y ese hueco es enorme.

Un sistema que funciona en condiciones de laboratorio no sirve de nada si se viene abajo en condiciones reales. La hostelería no es retail. La hostelería es caos que gestionas en tiempo real. Cada segundo que tu sistema tarda en responder te cuesta dinero y nervios. Cada clic de más que un camarero estresado tiene que dar es un error que va a ocurrir.

He visto sistemas que iban de maravilla en un iPad nuevo de paquete. Y luego llevas seis meses usándolo, el iPad tiene arañazos, la memoria está llena, el WiFi tiene interferencias de tres redes vecinas. De repente cada pedido tarda cuatro segundos en vez de uno. Cuatro segundos no parece nada. Multiplícalo por 300 pedidos en una noche. Son más de 20 minutos de tiempo perdido. Por turno.

Modo offline que no es tal

"Nuestro sistema también funciona offline." Esta frase la escucho en cada feria y en cada reunión de ventas. Es la mentira más repetida del sector.

Lo que la mayoría de proveedores venden como "modo offline": el sistema no se congela del todo cuando se cae internet. Eso es todo. No se bloquea. Pero tampoco funciona de verdad.

Lo que pasa en la realidad cuando se cae el WiFi y tu sistema supuestamente funciona offline:

• Los pedidos se pierden en cuanto vuelve la conexión. El sistema no sabe reconciliar los datos locales con los del servidor. Resultado: pedidos que desaparecen o duplicados.
• Los pagos con tarjeta no funcionan. El terminal necesita internet. El cliente está en la barra queriendo pagar con tarjeta y tú tienes que decirle: "Solo efectivo ahora mismo." En 2026.
• Los datos se desincronzan. Dos terminales han registrado pedidos diferentes durante la caída. Cuando vuelve la red, el sistema tiene dos versiones de la realidad. ¿Cuál es la correcta? Ninguna. Te toca cuadrar todo a mano el resto de la noche.
• O lo peor de todo: el sistema muestra una pantalla de carga. Sin modo offline, sin alternativa, sin mensaje de error. Solo un círculo girando mientras la cola en caja llega hasta la puerta.

Un modo offline de verdad significa que el sistema sigue funcionando al cien por cien en local. Puedes tomar pedidos, gestionar mesas, imprimir tickets, generar facturas. Todo se guarda en local. Y en cuanto vuelve la conexión, todo se sincroniza automáticamente en segundo plano. Sin pérdida de datos, sin duplicados, sin que tengas que hacer nada.

Esto no es un lujo. Para un negocio de hostelería es un requisito básico. Tu internet se va a caer. La pregunta no es si, sino cuándo. Y cuando pase, tu sistema tiene que seguir funcionando sin más.

Dependencia del hardware y costes ocultos

Firmas un contrato para un sistema POS. La cuota mensual parece razonable. Y entonces llega la lista de hardware.

Un terminal propietario que cuesta el triple que una tablet estándar. Un lector de tarjetas que solo funciona con ese sistema. Una impresora que no es de un fabricante normal, sino un aparato rebrandeado que solo puedes pedir a través del proveedor, con recargo, por supuesto.

Y entonces estás atrapado. No puedes cambiar de sistema porque tienes hardware por miles de euros que no funciona con nada más. Ni siquiera puedes cambiar de procesador de pagos, porque el terminal solo soporta uno. Estás encadenado a un proveedor, no porque sea el mejor, sino porque cambiar te saldría demasiado caro.

Luego están los costes ocultos. El sistema empieza en 29 euros al mes. Suena bien. Pero entonces necesitas gestión de mesas: recargo. Necesitas varios terminales: recargo por dispositivo. Quieres exportar informes: recargo. Necesitas integración con tu programa de contabilidad: también recargo. Al cabo de un año estás pagando 150 euros al mes por funciones que necesitabas desde el primer día.

Y las comisiones por transacción. "Gratis" dice la web. Sin cuota mensual. Lo que no dice: 1,9 por ciento por transacción. Para un restaurante que procesa 30.000 euros al mes en pagos con tarjeta, eso son 570 euros. Cada mes. El sistema "gratuito" te cuesta casi 7.000 euros al año solo en comisiones.

Calcula siempre el coste total a 12 meses. Hardware, software, comisiones, complementos. El precio real es casi siempre bastante más alto de lo que dice la web. Y si eliges un proveedor transparente donde ves desde el principio lo que pagas, te ahorras sorpresas desagradables y, casi siempre, dinero de verdad. En nuestra guía de sistemas POS para 2026 entramos en detalle sobre estas trampas de costes.

Software de retail disfrazada de hostelería

Aquí está el verdadero problema de muchos sistemas POS: no fueron desarrollados para la hostelería. Fueron construidos para el retail, y luego alguien puso un icono de restaurante en la web y renombró un par de campos.

Reconoces estos sistemas por una serie de síntomas.

La gestión de mesas se siente como un añadido. En vez de que el plano de mesas sea el corazón del sistema, parece un parche de última hora. Quizá puedes crear mesas, pero la interacción es tosca: abrir mesa, tomar pedido, guardar, volver atrás, siguiente mesa. Lo que en un buen sistema de hostelería son dos gestos, aquí cuesta cinco clics.

No existe concepto de tiempos de servicio. En un restaurante los clientes piden un primer plato y un segundo. La cocina necesita saber qué preparar y cuándo. Los sistemas de retail no entienden eso. Para ellos solo hay un pedido, una lista de artículos. ¿Orden de servicio? Nada. Te toca apuntarlo en el campo de comentarios o gritárselo al cocinero.

Dividir cuentas es un suplicio. Cuatro personas en una mesa, cada una quiere pagar lo suyo y el postre a partes iguales. En un buen sistema: tres toques. En un sistema de retail reconvertido: seis pantallas, cinco diálogos de confirmación, y al final el importe no cuadra porque el sistema calcula mal la propina y los descuentos al dividir.

Los modificadores son un parche. "Filete poco hecho, sin salsa, con ensalada en vez de patatas." Eso es un pedido normal en hostelería. En sistemas de retail, los modificadores son una solución improvisada. O solo hay un campo de texto libre, o configurarlos es tan engorroso que tu equipo ni los usa y pasa las modificaciones a la cocina de palabra.

El enrutamiento a cocina no existe o apenas funciona. En un negocio de hostelería real, el entrante va a la partida de fríos, el filete a la parrilla, el postre a repostería y las bebidas a la barra. Un buen sistema envía cada parte del pedido automáticamente a la estación correcta. Un sistema de retail imprime todo en un solo ticket y tu equipo lo clasifica a mano.

Y luego está el tema de las cuentas abiertas. Un cliente se sienta en la barra, pide cinco copas a lo largo de la noche y paga al final. Eso es una cuenta abierta. Para hostelería es lo más normal del mundo, para el software de retail es un concepto ajeno. En su lugar tienes que cerrar cada consumición como una operación independiente o recurrir a atajos que nadie quiere entender.

La próxima vez que evalúes un sistema, pregúntate: ¿fue construido para mi negocio, o fue construido para una zapatería y luego le dieron una mano de pintura?

Actualizaciones que nadie pidió

Lunes por la mañana, 9 en punto. Abres el sistema para preparar el día. La interfaz se ve diferente. Los botones ya no están donde estaban ayer. El esquema de colores ha cambiado. Algún elemento del menú se llama de otra forma.

¿Qué pasó? Una actualización automática. De madrugada. Sin aviso, sin registro de cambios, sin posibilidad de rechazarla.

Tu equipo ha pasado semanas aprendiendo dónde está cada botón. La camarera nueva por fin domina el flujo. El cocinero sabe exactamente dónde ver sus pedidos. Y ahora todo está cambiado. No de forma radical, solo lo justo para confundir a todos y provocar errores todo el día.

Lo peor: a veces desaparecen funciones. Una función que usas a diario, de repente ya no está. No rota, simplemente desaparecida. Porque el proveedor decidió que ya no encajaba en el producto. O porque ahora solo está incluida en el plan premium.

Conozco negocios donde llegó una actualización en pleno servicio. No por la mañana, no de madrugada, sino durante la cena. El sistema se actualizó durante dos minutos y no estuvo disponible. Dos minutos a las 20:00 un sábado. Haz el cálculo de lo que eso cuesta.

Las actualizaciones de software son necesarias. Sin duda. Pero en hostelería tienen que ser planificables, transparentes y controlables. Tú tienes que decidir cuándo actualizas. Tienes que saber de antemano qué cambia. Y tienes que poder posponer una actualización si no encaja con la operativa de tu negocio.

Soporte que solo responde a partir de premium

Es sábado por la noche, 20:30. Tu sistema POS muestra un error que nunca habías visto. Los pedidos no llegan a cocina. Tienes 25 mesas esperando. Necesitas ayuda ahora.

Abres el portal de soporte. "Por favor, describa su problema. Tiempo medio de respuesta: 48 horas."

48 horas. Tu servicio de cena acaba en tres horas. En 48 horas el daño ya estará hecho: reseñas negativas en Google, clientes frustrados, equipo frustrado, facturación perdida.

Pero claro, tienes el plan básico. Soporte por email, respuesta en dos días laborables. Para soporte telefónico tienes que subir de plan. Para soporte prioritario, otro más. ¿Y el "soporte premium con tiempo de respuesta garantizado"? Otros 50 euros al mes por encima.

Es como si te vendieran un seguro que solo cubre cuando compras el seguro más caro.

Buen soporte en hostelería significa que alguien contesta. No mañana, no en 48 horas, sino ahora. Y la persona al otro lado entiende lo que significa "hora punta". No te sugiere reiniciar el dispositivo mientras tienes 50 clientes esperando. Entiende que cada minuto cuenta y que tu problema no puede esperar al lunes.

Cuando un proveedor esconde su soporte detrás de muros de pago, eso te dice algo sobre sus prioridades. Y no eres tú.

Cómo se ve un sistema pensado para hostelería

No te voy a leer una lista de funcionalidades. Lo que quiero es describir cómo reconoces que un sistema fue realmente diseñado para la hostelería. No para una feria, no para un inversor, sino para el viernes por la noche con 200 comensales.

Lo construyeron personas que han trabajado en hostelería. No personas que cenaron una vez en un restaurante y pensaron "esto se podría mejorar". Sino personas que han recogido mesas, han escrito comandas, han cobrado bajo presión y al final del turno han fregado el suelo. Personas que saben lo que se siente cuando el sistema no responde en el peor momento.

La funcionalidad offline no es una función, es la arquitectura. El sistema fue diseñado desde cero para funcionar sin internet. No como modo de emergencia, no como versión reducida, sino como operación completa. Internet es un bonus para la sincronización, no un requisito para funcionar.

Funciona con hardware estándar. Sin terminales propietarios, sin impresoras especiales, sin lectores de tarjetas que solo funcionan con ese sistema. Una tablet normal, periféricos estándar. Si un dispositivo se rompe, vas a la tienda más cercana y compras otro. Sin llamar al proveedor, sin esperar envíos, sin ataduras.

Precios transparentes. Lo que dice la web es lo que pagas. Sin recargos ocultos por funciones básicas, sin tarifas que cambian a los seis meses, sin paquetes "starter" a los que les falta la mitad. Ves el precio, conoces el precio, pagas el precio.

El soporte trata tu caída del sábado noche como una emergencia. Porque lo es. No como un ticket de baja prioridad, no como un email que se atiende el lunes. Como lo que es: un problema grave que paraliza tu negocio y necesita solución inmediata.

Esto no son expectativas irreales. Son lo básico. Y si tu sistema actual no cumple con lo básico, quizá va siendo hora de preguntarte por qué sigues usándolo.

Construimos Kotao porque estábamos hartos de trabajar con sistemas que no estaban hechos para nosotros. Si quieres saber de dónde venimos y por qué lo enfocamos de otra manera, lee nuestra historia.