La próxima app de domicilios puede ser el chat de tu restaurante

Durante años, pedir comida significó abrir una app, aceptar sus reglas y pagar por el acceso a una demanda que el restaurante muchas veces ya había creado. Ahora el pedido puede empezar en una conversación con IA y llegar directamente al sistema del restaurante. No es una promesa futurista: ya hay pruebas funcionando en Estados Unidos.

Bites, una startup de diez personas, había reportado alrededor de 300 restaurantes inscritos en la Bahía de San Francisco, según The Verge el 7 de octubre de 2026. Su modelo contempla una tarifa fija de US$1 por pedido —normalmente pagada por el cliente, aunque algunos restaurantes la cubren— frente a las comisiones de entrega del 15%, 25% o 30% publicadas por DoorDash para sus planes de marketplace. Square anunció en julio integraciones con ChatGPT y Claude para que restaurantes elegibles muestren su menú y reciban órdenes sin una comisión adicional de marketplace. Son señales estadounidenses, no disponibilidad para Colombia. Pero la dirección es clara: el chat puede convertirse en una puerta de entrada al canal propio.

La app era el mostrador; la conversación puede ser la nueva puerta

Un restaurante independiente no empezó a usar una app de domicilios para enamorarse de una comisión. La usó porque necesitaba aparecer donde ya estaban los clientes, mostrar un menú y recibir pedidos sin construir toda la infraestructura desde cero. La plataforma resolvía descubrimiento, pago, soporte y, en algunos casos, logística. El precio era ceder margen, relación y datos.

La novedad de los agentes no consiste simplemente en poner un chatbot sobre el menú. Consiste en que una persona pueda decir “quiero ramen para dos, sin maní, cerca de Chapinero y antes de las ocho” y recibir opciones, confirmar disponibilidad, pagar y obtener seguimiento sin abandonar la conversación. Si el pedido termina en el POS del restaurante en vez de pasar por un marketplace, el canal económico cambia.

La diferencia importante no es la interfaz. Es quién posee el contexto que hace posible la orden: el menú actualizado, el inventario, los horarios, las zonas, las reglas de sustitución, el pago y la relación posterior.

Bites no es DoorDash; por eso importa

En su cobertura del 7 de octubre de 2026, The Verge describió a Bites como una startup de unas diez personas con alrededor de 300 restaurantes inscritos en la Bahía de San Francisco. Su modelo aplica una tarifa fija de US$1 por pedido —normalmente pagada por el cliente, aunque algunos restaurantes la cubren— y envía la orden al restaurante. DoorDash, por su parte, envió correos de advertencia a algunos restaurantes que aparecían en el servicio. La historia no demuestra que Bites vaya a reemplazar a DoorDash. Demuestra algo más interesante: una plataforma grande puede sentirse interpelada por una capa pequeña de software si esa capa reduce el costo de tomar una orden.

Conviene separar tres afirmaciones:

• El caso existe y es de EE. UU.
• El modelo depende de que el menú, el POS y las reglas operativas sean legibles y estén conectados.
• No sabemos todavía si la economía funciona igual en otros mercados, con otras redes de repartidores, medios de pago y normas.

Square aporta una señal menos experimental. En julio anunció una aplicación de ChatGPT y un plugin de Claude para que vendedores elegibles sean descubiertos y, en restaurantes compatibles, reciban pedidos directamente. Square dice que no cobra comisiones adicionales de marketplace por esas órdenes. La plataforma sigue participando: la diferencia es que el restaurante puede conservar más control sobre la transacción y la información.

El menú ya no es una pieza de diseño: es una interfaz operativa

Para que un agente pueda pedir, necesita mucho más que fotografías bonitas. Necesita saber:

• Qué platos existen y cuáles están disponibles hoy.
• Ingredientes, alérgenos, tamaños, guarniciones y sustituciones.
• Precio final, impuestos, recargos y costo de entrega.
• Horario real de cocina y última hora para pedir.
• Zona de cobertura, tiempo estimado y condiciones de retiro.
• Qué ocurre cuando un plato se agota o una dirección queda fuera de rango.
• Qué casos requieren una persona.

Ese conjunto de datos es el menú que una máquina puede leer. Si el restaurante publica un precio en Instagram, otro en una app y un tercero en su web, el agente no tiene un problema de creatividad: tiene un problema de operación. Una respuesta convincente con información equivocada produce una mala experiencia a escala.

El canal directo no significa hacerlo todo solo

Hay una tentación comprensible: leer la noticia como una invitación a abandonar las plataformas. No es la conclusión. Un restaurante puede necesitar marketplaces para descubrimiento, logística o cobertura en zonas donde no tiene repartidores. El canal propio puede ser mejor para clientes recurrentes, reservas, pedidos de alto margen y datos de relación. La arquitectura sensata puede combinar ambos.

La pregunta útil no es “¿app sí o no?”. Es:

1. ¿Qué parte del pedido paga realmente el cliente: descubrimiento, logística, soporte o solo intermediación?
2. ¿Qué datos quedan en el restaurante después de la orden?
3. ¿Qué reglas de marca, precio y hospitalidad puede respetar el canal?
4. ¿Qué margen queda cuando el pedido llega por cada ruta?
5. ¿Qué canal permite volver a hablar con el cliente con permiso?

Responderlas evita dos errores simétricos: construir una integración cara para un volumen inexistente o entregar toda la relación a una plataforma porque “es donde está la gente”.

Cinco preguntas para preparar el restaurante

1. ¿Cuál es la fuente única del menú? Debe existir un lugar que defina nombre, precio, disponibilidad, ingredientes y fotos. Las plataformas deberían leerlo, no convertirse en versiones rivales.

2. ¿El POS puede recibir una orden externa con contexto? No basta con un correo que alguien copia manualmente. El pedido debe llegar con productos, modificaciones, dirección, pago y estado.

3. ¿Qué decide el agente y qué aprueba una persona? Un agente puede buscar, recomendar y confirmar reglas simples. Alérgenos, cambios de precio, reembolsos y excepciones deben tener límites y handoff.

4. ¿Qué sucede con el dato? Define consentimiento, almacenamiento, acceso y uso posterior. La relación no vale si el restaurante no puede reconocer al cliente en la siguiente visita.

5. ¿Qué métrica decide si el canal merece quedarse? Mira margen por orden, repetición, tiempo operativo, errores y satisfacción. El número de pedidos, aislado, puede premiar un canal que destruye valor.

Colombia no tiene que copiar San Francisco

Las integraciones de Bites y Square citadas aquí tienen alcance estadounidense. No hay base para afirmar que un restaurante en Bogotá pueda activarlas hoy con las mismas condiciones. Sí hay una ventana para preparar lo que cualquier canal agéntico necesitará: datos coherentes, menú operativo, inventario legible, políticas explícitas, sistema de pedidos y una experiencia propia capaz de recibir al cliente cuando la conversación termine.

La ventaja no será “tener IA” como etiqueta. Será poder responder con precisión cuando alguien pregunte qué hay esta noche, cuánto cuesta, si puede llegar a su barrio y qué ocurre si cambia de opinión.

Un restaurante que quiera construir esa capacidad puede empezar por conectar el menú, los pedidos y la operación en un mismo sistema, en lugar de sumar otra pantalla aislada. Pimentone trabaja ese tipo de retos desde la arquitectura digital, los agentes de IA y los motores de conversión. La solución adecuada depende del volumen de pedidos, los sistemas actuales y el nivel de control que necesite cada negocio.