Pásate detrás del mostrador de cualquier local de comida para llevar con mucha gente y cuenta las tabletas. Normalmente hay una para Uber Eats, otra para Deliveroo, otra para Just Eat, a veces una cuarta para la plataforma que se haya lanzado aquí el año pasado, y un portátil gestionando los pedidos de la web del propio local. Cada una suena a su ritmo. Cada una tiene un nombre de usuario distinto, un menú diferente y una idea distinta de cuánto tarda en prepararse la comida. Alguien se queda ahí tecleando de nuevo los pedidos en el TPV para que la cocina reciba el ticket. Ese sistema es precisamente lo que un TPV para comida para llevar pretende acabar con, y la integración con las apps de reparto es el mecanismo que lo consigue.
Sin embargo, el término se usa de forma imprecisa, y la diferencia entre lo que los propietarios creen que están comprando y lo que realmente obtienen es donde se va el dinero. Algunas integraciones solo envían los pedidos en un sentido. Otras sincronizan tu menú, pero no tus precios. Otras envían las órdenes a la cocina, pero nunca avisan a la plataforma de que la comida está lista, así que el repartidor se queda esperando en la puerta de todos modos. Esta guía te explica qué hace realmente el sistema, dónde falla y qué preguntas marcan la diferencia entre una conexión de verdad y una simple captura de pantalla en una presentación comercial. Si estás enviando los pedidos a pantallas en lugar de a impresoras, un sistema de visualización en cocina es la otra mitad de la misma historia.
Qué es lo que realmente mueve una integración con una app de reparto
Si dejas de lado el marketing, una integración no es más que un canal de datos entre una plataforma y tu TPV. Por él circulan tres cosas, en diferentes direcciones, y un sistema puede gestionar bien una de ellas mientras que las otras las gestiona mal.
Llegan los pedidos. Un cliente pulsa «pedir» en Deliveroo y, en unos segundos, el ticket aparece en tu TPV con los artículos, las modificaciones, la nota del cliente, el nombre de la plataforma y la hora de recogida. Nadie tiene que volver a teclear nada. Esta es la dirección que todo el mundo muestra en sus demostraciones.
Los menús se publican. Cambias el precio de un shawarma de pollo una sola vez en tu TPV y ese cambio se publica en todas las plataformas conectadas. Desactivas el cordero y desaparece de todas ellas. Esta es la dirección que ahorra más tiempo administrativo y la que más probablemente esté a medio desarrollar.
Vuelve el estado de los pedidos. Tu cocina marca el pedido como listo y la plataforma lo detecta, así que se llama al repartidor en el momento adecuado y se actualiza la pantalla de seguimiento del cliente. Esta es la función que los operadores se olvidan de preguntar, y es la que determina si los repartidores se amontonan en tu puerta.
Tableview gestiona las tres opciones. Se conecta a más de 30 agregadores de reparto, como Uber Eats, Deliveroo, Just Eat, Glovo y Wolt, agrupa todos los pedidos en una única cola, sincroniza los menús con las plataformas y envía notificaciones de estado en tiempo real a la plataforma. Vale la pena decirlo sin rodeos: un sistema que hace solo una de estas tres cosas y lo llama «integración» no miente, exactamente, pero notarás que faltan las otras dos ya para el segundo fin de semana.
Cuánto cuesta realmente el montón de tabletas
Los operadores suelen describir el montón de tabletas como algo molesto. Es más que molesto: es caro, y los costes son concretos.
La reintroducción manual de datos es el más obvio. Cada pedido que se teclea a mano es una oportunidad de olvidarte de un ingrediente, y en la entrega, un ingrediente olvidado no se arregla rápido en la mesa. El cliente abre la bolsa en casa, se encuentra con que le falta algo y tú pierdes el valor del pedido, los ingredientes y, a menudo, al cliente. En segundo lugar, el tiempo de aceptación. Las plataformas miden lo rápido que aceptas los pedidos y la mayoría te clasifica en función de eso. Una tableta enterrada bajo papeles de recibos no se puede pulsar en quince segundos. En tercer lugar, y lo menos visible, la variación en el menú. Cuatro plataformas editadas a mano en momentos diferentes significan cuatro precios distintos para el mismo plato, y no te darás cuenta hasta que alguien se queje de que la app le ha cobrado más que en el local.
Luego está lo que a nadie le cuesta nada: la persona. Un viernes por la noche, hay alguien de pie en ese mostrador haciendo de «puente humano» en lugar de servir la comida. Eso es un turno, cada semana, dedicado a introducir datos.
Integración nativa con el TPV frente al middleware
Hay dos formas de hacer llegar los pedidos de los marketplaces a tu cocina, y la diferencia es más importante de lo que los proveedores admiten.
El middleware se sitúa entre las plataformas y tu TPV. Deliverect es el más conocido, pero los conectores al estilo de Otter y Deliverect cumplen la misma función. Conectas las plataformas de mercado al middleware, el middleware a tu TPV, y este se encarga de traducir entre ambos. Esto resulta realmente útil si tu TPV no tiene conexiones nativas, y es así como muchos sistemas antiguos conseguían gestionar las entregas. Las desventajas son una segunda suscripción, una segunda cola de asistencia técnica cuando algo falla y un paso más en el que un pedido puede atascarse. Cuando el middleware tiene una interrupción del servicio, te quedas sin más con las tabletas, sin previo aviso.
La integración nativa significa que el TPV se comunica directamente con las plataformas. Menos elementos que fallan, un solo proveedor al que llamar y una sincronización de menús que no tiene que pasar por una capa de traducción. El problema es la cobertura: un TPV con conexiones nativas a tres plataformas no te sirve de nada si tu cuarta plataforma es la que genera la mitad de tu volumen.
Así que la cuestión no es qué arquitectura es mejor en teoría. Se trata de si las plataformas concretas en las que operas son compatibles de forma nativa y qué pasa con las que no lo son. Pide la lista. No los logotipos de la web, la lista.
La introducción de órdenes y la trampa de la aceptación automática
Una vez que las órdenes llegan automáticamente, la siguiente decisión es si tu sistema también las acepta automáticamente, y vale la pena pensárselo bien en lugar de activarlo por reflejo.
La aceptación automática protege las métricas de tu plataforma y evita que las órdenes se queden estancadas en la pantalla mientras la cocina está desbordada. Tableview admite la aceptación automática de órdenes con reglas configurables, y esa es la clave. Una aceptación automática generalizada en una cocina que ya está al límite solo significa que has prometido comida que no puedes preparar a tiempo, y una orden tardía te perjudica más que una rechazada.
La configuración más sensata es condicional: acepta automáticamente dentro de tu volumen de trabajo habitual y deja de aceptar cuando la cocina esté realmente llena. Para eso, el sistema tiene que saber cuán llena está la cocina, lo que nos lleva a la función que casi nadie pide ver.
La limitación de pedidos, la función que nadie muestra en las demostraciones
El ajetreo de un viernes puede colapsar una cocina en unos once minutos. Los pedidos no dejan de llegar porque las plataformas no tienen ni idea de cómo está tu cocina, los tiempos estimados siguen siendo optimistas y, a las 8:30, llevas cuarenta minutos de retraso, con los repartidores acumulándose y cada uno de esos pedidos recibiendo una valoración de una estrella al entregarse.
La limitación de pedidos es la solución, y es la función de reparto más útil que nunca aparece en una demostración comercial. El motor de limitación de Tableview supervisa el recuento de pedidos activos, el tiempo medio de preparación y la carga de cada estación; a continuación, amplía automáticamente los tiempos estimados o pausa los nuevos pedidos cuando alcanzas la capacidad máxima. Puedes pausar y reanudar agregadores concretos sin tener que iniciar sesión en cada plataforma por separado, limitar los pedidos por franjas de 15 minutos, y los responsables disponen de un mapa de calor de la carga de la cocina mientras el servicio sigue en marcha.
Vale la pena detenerse en esa pausa por agregador. Sin ella, pausar Deliveroo en hora punta significa buscar la tableta de Deliveroo, iniciar sesión, ir a la configuración de la tienda y pausarlo desde allí, y luego acordarte de reactivarlo. En la práctica, nadie hace esto en plena hora punta, así que la cocina se ve desbordada. Con esta función, basta con un solo toque en la pantalla que ya tienes delante.
La sincronización del menú, y por qué la unidireccional es un problema
La sincronización del menú parece una comodidad administrativa. En realidad, es una función que garantiza la precisión, y la diferencia se nota en tu peor noche.
Se te agota algo a las 19:00. Con una configuración unidireccional o manual, ese artículo sigue estando disponible para pedir en las tres plataformas hasta que alguien se acuerda de ir a ocultarlo en cada una de ellas. Cada pedido que llega mientras tanto supone un reembolso, una llamada telefónica o una sustitución con la que el cliente no estaba de acuerdo. La sincronización bidireccional significa que lo marcas como agotado una sola vez en el TPV y desaparece en todas partes, que es exactamente lo que hace la sincronización bidireccional de menús de Tableview: actualizas un precio una vez, se publica en todas partes y la disponibilidad se actualiza automáticamente.
El mismo sistema se encarga de los casos menos obvios. Puedes mantener menús específicos para cada plataforma con precios, disponibilidad de artículos y conjuntos de modificadores diferentes, y luego actualizarlo una sola vez y enviarlo individualmente a cada agregador conectado. Esto es importante porque probablemente no deberías cobrar el mismo precio en todas partes.
Fijar precios diferentes según la plataforma
Aquí está el cálculo que la mayoría de los operadores hacen demasiado tarde. Un mercado que se lleva el 30 % de un pedido de 20 libras te deja 14 libras. Si ese plato cuesta 5,60 en ingredientes, tu coste de materia prima acaba de pasar del 28 % al 40 %, y eso sin contar el embalaje, la bolsa ni la mano de obra de un proceso de entrega independiente.
Muchos operadores responden fijando los precios de los menús de entrega a domicilio por encima de los precios de mostrador, y las plataformas lo permiten. Si deberías hacerlo o no es una decisión que debes tomar tú: los clientes se dan cuenta y algunos mercados reaccionan mal. Pero la decisión debe ser tuya y debe ser deliberada, no algo que no puedas poner en práctica porque tu sistema solo admite una lista de precios. Si nunca has analizado a fondo los aspectos económicos, nuestro desglose de la entrega a través de terceros explica detalladamente los cálculos de las comisiones, y las comisiones por procesamiento de pagos cubren la otra parte que se descuenta de cada pedido.
Las llamadas de estado y el repartidor en tu puerta
Pregunta a cualquier negocio con muchas entregas cuál es su mayor problema diario y te sorprenderá la cantidad de gente que dirá que son los repartidores. Llegan demasiado pronto, se quedan en medio, preguntan dónde está el pedido 4471 o bloquean el mostrador justo en el momento menos oportuno.
La mayor parte de eso es un problema de estado. Si tu punto de venta nunca le dice a la plataforma que la comida está lista, la plataforma hace una suposición, y esa suposición se basa en una media que no tiene nada que ver con esta noche. Las notificaciones de estado en tiempo real cierran ese bucle: la plataforma sabe cuándo el pedido está realmente listo, envía al repartidor en consecuencia y la pantalla de seguimiento del cliente refleja la realidad en lugar de una estimación.
Además, reduce discretamente tu tasa de reembolsos. Un cliente que ve un seguimiento preciso es un cliente que no abre un ticket de atención al cliente al minuto 35 preguntando dónde está su comida.
Tus propios repartidores: zonas, tarifas y asignación
La integración suele verse como un problema de los mercados online, pero muchos restaurantes gestionan su propia flota junto con las plataformas, y esa parte necesita su propia infraestructura.
Tableview gestiona las entregas propias con zonas personalizadas dibujadas como un radio o un polígono en el mapa, tarifas basadas en la distancia que se calculan automáticamente al finalizar la compra, asignación de pedidos a los repartidores con un solo toque y un panel de estado que rastrea cada uno de ellos como «en ruta», «entregado» o «devolvido». Las zonas poligonales son más importantes de lo que parece: un radio no tiene en cuenta un río, una autopista o esa urbanización donde nadie deja propina y cada entrega tarda 25 minutos. Trazar la forma real del área a la que estás dispuesto a dar servicio es la forma de dejar de perder dinero en los límites de tu mapa.
Es habitual y totalmente lógico utilizar ambos modelos a la vez. Los pedidos del mercado te dan mayor alcance, mientras que tu propia flota protege el margen con los clientes que ya tienes.
La precisión en el empaquetado también es un problema de integración
Un cliente al que le has hecho una entrega no puede señalar que falta algo. Se da cuenta en casa, y el tiempo que pasa entre la decepción y una reseña pública de una estrella es de unos noventa segundos.
Esto forma parte de la integración de una forma que suele pasarse por alto: una vez que los pedidos llegan automáticamente y el volumen aumenta, el embalaje se convierte en el cuello de botella y la fuente de errores. Tableview imprime etiquetas de embalaje por artículo con el nombre del producto, sus modificadores y alérgenos, agrupa los artículos en bolsas y muestra una pantalla de verificación final a quien se encarga de preparar el pedido, además de un resumen para el cliente en la propia bolsa. Nada de eso es glamuroso. Pero todo ello sale más barato que un reembolso.
Lo que la integración no va a solucionar
Vale la pena ser franco, porque el discurso de venta suele dar a entender lo contrario.
No reducirá la comisión. Un recorte del 25 al 30 por ciento es una condición comercial, no técnica, y por mucho que se perfeccione el sistema, eso no va a cambiar. Tampoco hará que una cocina lenta se vuelva rápida. La integración deja al descubierto tus tiempos de preparación con una claridad incómoda, lo cual es útil, pero la solución está en la cocina. No impedirá que las plataformas cambien sus API, sus estructuras de tarifas o sus reglas de clasificación, y tendrás que ir adaptándote a eso para siempre. Y no evitará que un cliente te eche la culpa por un repartidor que llevó la comida a una dirección equivocada.
Lo que sí hace es eliminar el trabajo manual, los errores de transcripción y el tener que estar pendiente de la tableta, y te da los datos para ver qué canal realmente merece la pena atender. Eso es mucho. Pero no lo es todo.
Los pedidos directos son donde realmente está el margen
Cualquier conversación sincera sobre la integración de los servicios de reparto acaba llegando a este punto. Los mercados online son un canal de captación de clientes que alquilas a un 25-30 %. Tu propia página de pedidos es la que te pertenece.
Las cifras no se pueden ni comparar. Cien pedidos a la semana a 20 libras a través de una plataforma te cuestan entre 500 y 600 libras a la semana en comisiones. El mismo volumen a través de tu propia página de pedidos te cuesta solo el procesamiento del pago y nada más. Tableview incluye pedidos web con tu propia marca en tu dominio, con tu logotipo y tus colores; programación de franjas horarias de recogida que respeta la capacidad real de la cocina; prepago con tarjeta, Apple Pay o Google Pay; y acumulación automática de puntos de fidelidad en los pedidos directos. Los pedidos mediante código QR funcionan con el mismo menú, así que tanto si un cliente escanea el código desde la mesa como si hace el pedido desde el sofá, ambos acceden al mismo sistema.
La estrategia realista no consiste en abandonar las plataformas. Se trata de utilizarlas para que te descubran, mientras vas trasladando poco a poco a tus clientes habituales a los pedidos directos, y luego medir el reparto de forma honesta. En cuanto a la gestión de tu propio canal, el TPV con pedidos online se encarga de ello, y el sistema de gestión de pedidos ofrece una visión más amplia de cómo se procesan los pedidos en el local.
Qué preguntar antes de conectar nada
Llévate estas preguntas a la demostración. Anótalas, porque las preguntas escritas obtienen respuestas más precisas que las orales.
¿Con qué plataformas te integras de forma nativa y cuáles necesitan middleware? ¿Cuánto cuesta el middleware y a quién llamo si falla? ¿La sincronización del menú es bidireccional? ¿Se sincroniza la disponibilidad o solo el precio? ¿Puedo fijar precios diferentes por plataforma? Muéstrame cómo pausar un solo agregador desde el TPV, en pleno servicio. ¿Qué pasa con los pedidos del marketplace si se me cae Internet? ¿Cómo llegan las actualizaciones de estado a la plataforma y puedo ver si ha fallado una llamada de respuesta? ¿Puedo ver los ingresos por canal, netos de comisiones, en un solo informe? Y cuando una plataforma cambia su API, ¿quién se encarga de eso, tú o yo?
Nueve preguntas. La de pausar un solo agregador es la que suele provocar una pausa interesante.
Cortes de conexión y qué pasa con los pedidos
Tu integración depende de la conectividad por partida doble: tu propia conexión y la de la plataforma. Ambas pueden fallar.
Pregunta qué hace el sistema cuando se cae Internet. Tableview da prioridad al modo sin conexión, almacenando en caché el menú, los precios y las normas fiscales de forma local para que la caja siga aceptando pedidos y pagos con tarjeta hasta 72 horas, poniendo las transacciones en cola y liquidándolas automáticamente cuando se restablezca la conexión. Una advertencia sincera, y deberías aplicarla a todos los proveedores: ningún TPV puede recibir un pedido de un marketplace mientras tu línea esté caída, porque el pedido no tiene dónde llegar. Lo que protege la funcionalidad sin conexión son tus ventas en el mostrador y tus pagos con tarjeta, para que un fallo en la banda ancha no te obligue a cerrar la tienda. Cualquiera que afirme que su sistema sigue recibiendo pedidos de Deliveroo sin Internet está describiendo algo que no puede suceder.
Ponerlo en marcha sin arruinar un viernes
Conectar las plataformas es rápido. Hacer bien el menú no lo es, y ahí es donde se va el tiempo.
Dedica la mayor parte de tu esfuerzo al menú, porque cada error de correspondencia se convierte más tarde en un pedido erróneo. Los conjuntos de modificadores son donde la cosa se complica: la forma en que una plataforma modela «sin cebolla, queso extra, grande» rara vez coincide con la de tu TPV, y hay que comprobar la correspondencia artículo por artículo en lugar de confiar en una importación. Conecta primero una plataforma, pruébala durante unos días y comprueba que los pedidos, los cambios en el menú y las notificaciones de estado funcionan correctamente antes de añadir la segunda. Ponte en marcha un martes. Mantén las tabletas antiguas enchufadas y cargadas durante una semana, porque la idea de tener un plan B es que no esperabas necesitarlo.
Una cosa que debes hacer el primer día, en lugar de dejarla para más adelante: haz un pedido de prueba real a través de cada plataforma, incluyendo uno con modificaciones complicadas, y síguelo hasta el ticket de cocina y la etiqueta de embalaje. Ese ejercicio de diez minutos te permite detectar más problemas que por mucho que leas la pantalla de configuración. Tableview funciona en la misma tableta o terminal que ya usas, así que una estación de reparto específica es opcional, no una compra que tengas que hacer antes de poder empezar.
¿Cómo se refleja esto en el coste del sistema?
Cifras concretas, ya que «ponte en contacto con nosotros para conocer los precios» es la forma habitual de eludir esta pregunta.
Tableview se cobra por local, no por TPV: el plan Starter cuesta 69 dólares al mes con dos cajas registradoras incluidas y 49 dólares por cada caja adicional, y el plan Pro cuesta 189 dólares al mes con cajas registradoras ilimitadas. No hay cuotas de alta y los planes Starter y Pro son de mes a mes. Una cosa que debes tener clara antes de comprar: el sistema de pantallas de cocina solo está disponible en el plan Pro, no en el Starter. Para una cocina con muchas entregas que distribuye los pedidos entre las distintas estaciones, ese suele ser el plan que necesitas en lugar del más barato, y es mejor saberlo ahora que después de haberlo configurado todo. El desglose completo está en la página de planes de precios de Tableview, y si estás comparando esto con tu configuración actual, lo que debes tener en cuenta es un sistema de TPV para restaurantes que trate las entregas a domicilio como un canal de primera clase en lugar de como un complemento.
Si gestionas marcas exclusivas de reparto desde un espacio compartido, la misma capa de integración gestiona los menús, los precios y los análisis de cada marca desde un único terminal, que es lo que necesita una configuración de TPV para cocina fantasma para evitar que cuatro marcas virtuales se conviertan en cuatro sistemas independientes.
Empieza por hacer una lista de las plataformas en las que realmente operas y el volumen semanal de cada una. Esa lista, y no una comparación de funciones, es lo que te dirá si un sistema concreto te conviene, y solo te llevará diez minutos escribirla.
Sigue leyendo: cocinas fantasma para el modelo de solo reparto, menús con códigos QR para la parte de consumo en local de la misma plataforma de pedidos y TPV para food trucks si tu cocina se desplaza.
