Un restaurante presente en tres plataformas de reparto acaba normalmente con tres tabletas en una estantería, cada una con su sonido, cada una exigiendo que alguien acepte el pedido y lo lea en una pantalla. Funciona hasta que dos de ellas suenan a la vez en pleno servicio.
Respuesta corta: pon un agregador entre las plataformas y la cocina, y luego envía una llamada de impresión por pedido. Las plataformas conservan sus apps para estados y soporte, pero el ticket que llega a la cocina tiene un solo formato, un solo sonido y ninguna pantalla que vigilar.
Dónde duelen de verdad las tabletas
| Problema | Por qué pasa | Qué cambia |
|---|---|---|
| Tres formatos de ticket distintos | Cada app compone el suyo | Una plantilla única que controlas tú |
| Pedidos perdidos en hora punta | Dos tabletas suenan a la vez, una se ignora | El ticket es físico y no hay que acusarlo |
| Volver a teclear en el TPV | La tableta es una isla aparte | El agregador empuja el pedido hacia delante |
| Ningún rastro de lo que llegó | El historial vive en tres apps | Un historial de impresión, una referencia de pedido |
El patrón detrás de los cuatro es el mismo: una tableta es una pantalla para una persona, y una cocina en hora punta no tiene personas de sobra.
La arquitectura
Tres piezas, y solo la del medio es una decisión:
- Las plataformas. Glovo, Just Eat, Uber Eats y las demás exponen sus pedidos a través de su integración de partner.
- Un agregador. HubRise y equivalentes normalizan esos flujos en un único formato de pedido, que es lo que hace posible una plantilla de ticket única. Esta es la pieza que ahorra el trabajo.
- Una llamada de impresión. Un POST por pedido a una impresora accesible por internet. Sin software local, sin tabletas.
Si tus plataformas ya están unificadas en un TPV, el paso del agregador puede sobrar y la llamada de impresión puede colgar del TPV. La pregunta es simplemente dónde se juntan ya los pedidos, y enganchar ahí la impresión en vez de construir una cuarta isla.
Para plataformas que solo exponen un webhook, una herramienta de automatización como Zapier tiende el puente sin código, a cambio de unos segundos de latencia.
Lo que el ticket necesita y un pedido web no
Los tickets de reparto llevan información que un pedido de tienda nunca tiene, y omitirla es lo que provoca las llamadas:
- El nombre de la plataforma y su propia referencia de pedido, impresos en grande. Cuando un repartidor llega preguntando por el pedido 4471, nadie quiere buscar en tres apps.
- Reparto o recogida, arriba. Cambia el embalaje.
- La hora solicitada, no solo la hora del pedido. Un pedido anticipado para las 20:30 que entra a las 19:00 no debe prepararse de inmediato, y este es el error más común al abandonar las tabletas.
- Las opciones en su propia línea sangrada, porque un lector con prisa toma una opción pegada por otro artículo.
- La nota del cliente, entera, abajo.
El resto de la maquetación sigue las mismas reglas que cualquier ticket de cocina, y el marcado está en la referencia de maquetación.
Tratar los fallos propios del reparto
Cancelaciones después de imprimir. Una plataforma puede cancelar un pedido que ya está en el pase. Imprimir un ticket de cancelación en la misma impresora merece la pena: es más ruidoso que una notificación que nadie mira.
Modificaciones. Algunas plataformas dejan que el cliente cambie el pedido antes de la preparación. Imprime la modificación como un ticket nuevo que referencia al original, en vez de reimprimir el pedido entero, para que la cocina no lo prepare dos veces.
Duplicados por reintentos. Los webhooks de agregador reintentan. Pon la referencia de pedido de la plataforma en origin para que un repetido sea detectable en el historial en vez de reimpreso. La guía de fiabilidad detalla el patrón.
Pedidos anticipados. Decide si el ticket sale al recibirlo o a la hora de preparación. Sacarlo al recibirlo es más simple y va bien con volúmenes pequeños; programar la impresión con una antelación sobre la franja solicitada es mejor cuando los pedidos anticipados se vuelven habituales, y en ambos casos la hora solicitada debe estar en el ticket.
Lo que sigue necesitando pantalla
Imprimir no sustituye del todo a las apps de las plataformas. Marcar un pedido como listo, hablar con un repartidor y gestionar reembolsos siguen en la app, y la tableta puede irse del pase a la oficina. El objetivo no es cero pantallas; es que ninguna pantalla se interponga entre un pedido entrante y la cocina.
Imprime un ticket de reparto de prueba con el plan gratuito con una carga realista, incluyendo hora de pedido anticipado y una nota de cliente de dos líneas, antes de cablear el agregador. Los defectos de maquetación cuestan mucho menos si se encuentran un martes por la tarde.
FAQ
¿Puedo imprimir los pedidos de las plataformas sin una tableta por app?
Sí. Un agregador normaliza las plataformas en un único flujo de pedidos, y una sola llamada de impresión envía el ticket a la cocina. Las apps se quedan para estados y soporte, pero ya nada tiene que leerse en una pantalla para que el pedido se prepare.
¿Qué debe mostrar un ticket de reparto que un pedido de tienda no?
El nombre de la plataforma y su propia referencia de pedido en grande, reparto o recogida arriba, la hora solicitada y no solo la del pedido, las opciones en su propia línea sangrada, y la nota del cliente entera.
¿Qué pasa si una plataforma cancela un pedido después de imprimir el ticket?
Imprime un ticket de cancelación en la misma impresora. Es más ruidoso que una notificación que nadie mira, y aparece donde apareció el ticket original, que es el único sitio al que la cocina mira de verdad.
¿Cómo evito que los pedidos anticipados se preparen de inmediato?
Pon la hora solicitada en el ticket, no solo la hora del pedido, y decide si imprimes al recibirlo o programas la impresión con antelación sobre la franja. Imprimir al recibirlo sin la hora solicitada es el error más común.
¿Por qué el mismo pedido de reparto se imprime a veces dos veces?
Los webhooks de agregador reintentan cuando tu endpoint responde lento. Pon la referencia de pedido de la plataforma en el campo origin para que un repetido sea detectable en el historial en vez de reimprimirse en silencio.