Delivery propio vs apps de terceros: qué debe comparar un restaurante antes de elegir

Las apps pueden aportar demanda y red; el delivery propio puede dar mayor control, pero exige capacidad, asignación, seguimiento e incidencias. Una comparación útil empieza separando qué resuelve cada alternativa y qué trabajo deja pendiente. Si solo contrastas precio o una lista de características, puedes terminar comparando productos con alcances distintos y concluir que uno es más barato cuando en realidad traslada trabajo al equipo.

El criterio rector aquí es separar adquisición de pedidos, costo por canal y capacidad operativa de entrega. Para hacerlo verificable, define una misma operación y obliga a ambas alternativas a resolverla. Solo cuenta como ventaja lo que puedas observar: menos reingreso, mejor trazabilidad, una recuperación más clara o un límite contractual que realmente se ajusta a tu volumen.

Ejecuta Canal → Pedido → Preparación → Asignación → Entrega → Conciliación con las dos alternativas. Después introduce Demanda supera capacidad propia, Comisión vuelve un producto poco rentable, Incidencia sin trazabilidad entre canales. Si una opción necesita una hoja, un chat o una segunda herramienta para completar el ciclo, inclúyelo en la comparación; no lo trates como si ocurriera fuera del costo del sistema.

Lleva además todos los precios al mismo horizonte. Separa implementación, hardware, suscripción, comisiones o servicios externos. La comparación deja de ser marketing cuando todas las alternativas responden al mismo escenario, durante el mismo periodo y con las mismas restricciones.

Evalúa Costo total, Control de cliente, Capacidad de reparto, Incidencias y registra qué alternativa deja más control sobre datos, estados y recuperación. Un sistema más automatizado no siempre es mejor si oculta por qué tomó una decisión o impide corregirla de forma segura.

Antes del cambio define también cómo volverías atrás: respaldo, exportación, corte y contingencia. La reversibilidad reduce el riesgo de probar una herramienta nueva y obliga a documentar qué información es realmente indispensable para operar.

Prueba “Costo total” usando datos que se parezcan a los de un restaurante que compara reparto propio y plataformas externas. Empieza en canal y continúa hasta pedido sin preparar el sistema para que todo salga perfecto. Cambia una condición a mitad del recorrido y revisa si “Control de cliente” sigue teniendo contexto. Incluye también el caso “Demanda supera capacidad propia”: si la recuperación exige borrar la operación o crear una segunda versión, todavía existe una debilidad que debes resolver antes de depender del flujo.

Para evaluar “Control de cliente”, observa qué ve la persona que recibe el trabajo después de pedido. No basta con que el dato exista en algún menú; debe aparecer en el momento en que cambia una decisión. Contrástalo con “Capacidad de reparto” y documenta qué sucede ante “Comisión vuelve un producto poco rentable”. Una buena implementación deja una señal comprensible, una autoridad clara para corregir y un historial suficiente para que el siguiente turno no tenga que reconstruir lo ocurrido.

“Capacidad de reparto” merece una prueba de responsabilidad: quién puede modificarlo, quién solo lo consulta y qué parte del flujo se actualiza cuando cambia. Recorre Preparación → Asignación con dos roles distintos y verifica que “Incidencias” no dependa de permisos excesivos. Después provoca “Incidencia sin trazabilidad entre canales”. Si la única forma de continuar es compartir credenciales, editar datos sin rastro o pedir a una persona concreta que intervenga, el proceso todavía no está preparado para crecer con seguridad.

Con “Incidencias” conviene mirar escala y no solo funcionalidad. Repite Asignación → Entrega varias veces, mezcla operaciones normales con “Demanda supera capacidad propia” y comprueba si “Costo total” conserva velocidad y claridad. Pregunta además qué límite contractual, técnico o de configuración cambia con más volumen. El objetivo no es exigir capacidad infinita; es saber con anticipación cuándo la operación necesitará otro plan, más hardware o una configuración distinta para seguir siendo predecible.

Simula “Demanda supera capacidad propia” durante canal. La prueba termina solo cuando la operación llega otra vez a preparación con un estado coherente. Revisa qué mensaje recibió el equipo, quién tuvo permiso para actuar y cómo quedó afectado “Control de cliente”. Esta disciplina evita aceptar una demo donde el error se resuelve reiniciando, borrando o corrigiendo directamente en base de datos: acciones que no representan una recuperación sostenible para un restaurante en producción.

Cuando ocurra “Comisión vuelve un producto poco rentable”, mide tiempo hasta detección y tiempo hasta resolución por separado. Un problema puede ser fácil de corregir pero difícil de descubrir, y esa demora puede contaminar pedido, asignación o “Capacidad de reparto”. Pide que el sistema muestre suficiente evidencia para distinguir causa de síntoma. Si todos ven que algo está mal pero nadie puede explicar por qué, el flujo todavía produce trabajo de investigación que debe formar parte de la evaluación.

Usa “Incidencia sin trazabilidad entre canales” como prueba de cambio de turno. Una persona inicia el caso en preparación y otra debe poder terminarlo en entrega sin una explicación verbal privada. Comprueba que “Incidencias” conserve contexto, que las acciones sensibles tengan autor y que los comentarios necesarios queden junto a la operación. La continuidad entre personas es una señal fuerte de que el proceso vive en el sistema y no solamente en la memoria del equipo.

Separa adquisición de demanda y ejecución de entrega. Una plataforma de terceros puede aportar visibilidad y pedidos además de reparto; una flota propia controla más la experiencia pero no genera demanda por sí sola. Compara cada componente por separado. De lo contrario puedes atribuir a la logística un valor que en realidad proviene de marketing o, al revés, subestimar la capacidad operativa que el tercero aporta.

Calcula costo por pedido con todos los componentes que puedas verificar: comisión, personal, vehículo, combustible, tiempos improductivos y soporte. No necesitas una cifra perfecta para empezar; usa rangos y sensibilidad. Pregunta qué ocurre cuando el volumen cae y cuando sube. El delivery propio tiene costos fijos y variables diferentes a una comisión porcentual, por lo que el ganador puede cambiar según densidad, zona y ticket.

Los datos del cliente y la capacidad de resolver incidencias también importan. En un canal propio puedes mantener más contexto de pedido y relación, mientras un tercero controla parte de la experiencia. Prueba cómo se gestiona cliente ausente, dirección incorrecta o reembolso. El criterio es saber quién puede actuar, qué información conserva cada parte y cómo se explica el caso al cliente sin saltar entre sistemas.

Una estrategia híbrida puede ser razonable. Usa terceros para ampliar cobertura o absorber picos y flota propia en zonas donde tienes densidad suficiente. Si eliges ese modelo, el software debe distinguir canal y responsable de entrega sin duplicar la orden. Mide tiempo, costo e incidencias por modalidad. El objetivo no es defender una filosofía de reparto, sino elegir capacidad con evidencia.