El acuerdo de servicio define el marketplace
Un clon de Just Eat es un marketplace independiente inspirado en su modelo. No incluye tecnología, cuentas, datos de clientes ni permiso de marca de Just Eat. Define la relación operativa antes de elegir pantallas o script.
La diferencia principal es quién atiende la entrega: el cliente recoge, el restaurante usa repartidor propio o el marketplace coordina un servicio. Los tres cambian preparación, despacho, soporte y costos aunque el menú sea igual.
Define recolección y entrega explícitamente
La guía publicada para restaurantes de Just Eat en Reino Unido distingue pedidos listos para recoger y progreso de entrega propia, y remite a instrucciones separadas de Delivery Service. Ilustra la necesidad de estados por servicio; no fija un proceso o contrato universal.
Para tu marketplace, separa:
- Recoger: el restaurante acepta, prepara, marca listo y entrega contra la referencia del cliente.
- Reparto del comercio: la tienda controla preparación y conductor, mientras el marketplace recibe estados acordados y atiende al cliente.
- Reparto coordinado: la preparación debe conectarse con disponibilidad del repartidor, recogida, entrega e intervención del operador.
Muestra el servicio antes del checkout y en la confirmación. No cambies domicilio a recolección silenciosamente por falta de repartidor. Ofrece elección y concilia cualquier cambio de importe.
Incorpora al restaurante a un recorrido operativo
Recopila fuente del menú, ubicación, horarios, cobertura, opciones obligatorias, extras, mínimos aplicables, preparación y pagos. Define quién pausa tienda o producto y cómo llega el cambio al canal del cliente.
Usa un plato con elección obligatoria y extra de pago. La selección debe conservar significado en checkout, aceptación, ticket e instrucciones de entrega. Una nota libre no sustituye bien una elección estructurada faltante.
El comercio está listo cuando acepta, prepara, entrega y resuelve una prueba. Promocionarlo antes puede llevar demanda a un flujo sin responsable.
La conexión POS es una integración propia
El portal de desarrolladores de Just Eat describe JET Connect como integración de pedidos al POS. Para un builder, muestra que esa vía requiere mapeo, eventos y cuenta del restaurante, además de una tablet de pedidos.
Relaciona identificadores, modificadores, totales, impuestos, cargos, pago, servicio, datos del cliente e instrucciones. Define quién controla menú y aceptación. Separa recepción técnica, cobro y preparación.
Prueba duplicado del mismo pedido, POS desconectado, cambio de precio y cancelación después del envío a cocina. Define aviso y reintento sin crear otra venta. Inspirarse en Just Eat no concede acceso a JET Connect, y una API genérica no demuestra compatibilidad con cualquier POS.
Usa un turno con servicios mixtos como piloto
Imagina dos restaurantes: uno ofrece recolección y sus propios repartidores; el otro necesita flota coordinada. Usa dirección y hora deseada equivalentes para observar diferencias.
- Haz un pedido para recoger y confirma sucursal y referencia.
- Haz una entrega del comercio y revisa quién comunica salida y cierre.
- Haz una entrega coordinada e inspecciona preparación, asignación y recogida.
- Cierra temporalmente un restaurante y confirma que no acepte pedidos nuevos inválidos.
- Cancela un pedido prepagado y concilia dinero por separado de comida preparada.
El equipo debe distinguir «sin aceptar», «en preparación», «listo» y «excepción de entrega» desde el registro, sin adivinar por el comprobante de pago.
Elige implementación según los traspasos
Un desarrollo propio permite diferenciar descubrimiento y operación, pero exige mantener backend, pagos, integraciones, versiones móviles y herramientas de atención. Cotiza esa responsabilidad, además de la app.
Un script con licencia puede servir si código y modelo encajan. Pide derechos, archivos, dependencias, migraciones, despliegue, mantenimiento y exportación. Identifica componentes propietarios o con suscripción. Descargar no concede derechos sobre código de Just Eat ni acceso a su servicio.
Una plataforma configurada puede aportar base de cliente, comercio y reparto. Un enfoque híbrido agrega frontend o conexión POS a un único sistema de pedidos. Elige después de demostrar recolección, entrega del comercio y flota coordinada.
Modela el costo por forma de entrega
Separa software o desarrollo, incorporación, mantenimiento del menú, integración POS, procesamiento, mensajes, adquisición y soporte. Agrega reparto donde corresponde: la entrega del comercio y la coordinada no tienen iguales responsabilidades.
Define cargos al comercio y cliente, entrega, promociones, rechazos y devoluciones con propuestas y acuerdos reales. No copies comisiones ni calendarios de liquidación de Just Eat.
Compara propuestas con las mismas tiendas, menús, pago, versiones POS y fallas. La revisión de apps, datos, accesos y capacitación afectan fechas; un precio genérico de clon o plazo fijo oculta esas dependencias.
Construye pedidos sobre una base definida
Los marketplaces de Ordering.co conectan canales, herramientas del comercio, reparto y pagos configurados. Las integraciones POS tienen vías directas o por middleware específicas; confirma producto y no deduzcas soporte de esta guía.
Cada producto incluye frontend abierto. Backend y API se gestionan por defecto; el código de backend exige aprobación y licencia enterprise separadas. Es distinto de comprar un backend autoalojado sin restricciones.
Explora las demos con dos modelos de restaurante y un traspaso fallido. Elige la base que permite explicar dónde está cada pedido y quién actúa después.