Un programa de lealtad para tus clientes de Uber Eats: que pidan directo

Una noche movida en Uber Eats puede parecer crecimiento puro: cuarenta pedidos, una cocina que no para, un teléfono que no deja de sonar hasta el cierre. Lo que normalmente no es, son cuarenta relaciones nuevas. Un cliente que le pide al mismo restaurante cuarenta veces a través de una plataforma de entregas puede seguir siendo, para el restaurante, un completo desconocido — el mismo desconocido que después del primer pedido. Eso no es un problema de marketing del restaurante. Es lo que la API de la plataforma está construida para permitir.

Lo que los datos de pedido de Uber Eats realmente contienen

Vale la pena mirar qué le llega de verdad a un restaurante cuando entra un pedido, según la documentación pública de la API de Uber Eats — no según lo que un dueño supone que debe estar ahí. El webhook que se dispara en el momento en que llega un pedido no trae ningún dato del cliente: es el pedido en sí, nada sobre quién lo hizo. El endpoint de detalles del pedido que un restaurante puede consultar después devuelve un nombre, una inicial de apellido, y un número de teléfono anonimizado — pasa por el propio sistema de Uber Eats y necesita un código para marcarse, no un número que llame al cliente directamente. No hay ningún correo electrónico en esos datos en ningún momento. Y el único identificador de cliente que expone la API está documentado como único para ese pedido en particular: no es el mismo valor que aparece la próxima vez que esa persona pide, así que no existe ningún campo que le permita a un restaurante hacer la conexión de "este es el mismo cliente habitual de la semana pasada", ni por accidente.

Cuarenta pedidos, cero contactos

Al juntar esos tres hechos, el problema deja de ser vago. Un restaurante puede atender a la misma persona cuarenta veces a través de Uber Eats y aun así no tener ninguna forma de contactarla fuera de la plataforma. Ni un mensaje, ni una oferta de cumpleaños, ni un "te extrañamos, vuelve" — no hay ningún campo en los datos que le permita a un restaurante siquiera intentarlo. La mayoría de los dueños sienten este problema sin poder nombrarlo: los clientes habituales que reconocen en un turno del viernes no aparecen como habituales en ningún lado del panel de la plataforma, porque para la plataforma no es un cliente que regresa — es un pedido que se repite.

Por qué es así a propósito, no un descuido

Nada de esto es un error que Uber Eats olvidó corregir. Todo el valor de una plataforma, para sí misma, viene de ubicarse entre un restaurante y las personas que le piden — el día en que un restaurante pueda contactar a ese cliente directamente y saltarse a la plataforma en el próximo pedido es el día en que la plataforma tiene menos razones para cobrar por ese pedido. La API es detallada con el pedido y escasa con la persona, a propósito. No es descuido; es el modelo de negocio.

Qué es lo que realmente recupera a un cliente

Nada de esto significa que un restaurante esté atrapado esperando una integración que nunca va a existir. Significa que el contacto tiene que construirlo el propio restaurante, en el único momento que todavía controla por completo: cuando el pedido sale de la cocina. Una tarjeta o un pequeño inserto con un código QR, metido en la bolsa, envía a ese cliente a una página que el restaurante controla — un registro a su propia tarjeta de lealtad — y de ahí en adelante, el restaurante tiene exactamente lo que el cliente decida entregarle directamente, no lo que una API estuvo dispuesta a exponer. Ese es también el momento en que un cliente de entregas se convierte en alguien que podría pedir directo la próxima vez, porque ahora existe una forma de recordarle que el restaurante existe fuera de la aplicación por la que pidió.

Por qué el uso único es lo que de verdad importa

El detalle que decide si esto funciona de verdad es el uso único. Un código QR genérico impreso una vez y pegado en el mostrador, o reutilizado en cada bolsa durante un mes, tiene un hueco evidente: cualquiera puede fotografiarlo, publicarlo o pasárselo a un amigo, y el restaurante termina regalando la misma recompensa a gente que nunca atendió. Un código válido para un solo canje no tiene ese problema — está limitado por la cantidad que el restaurante realmente imprimió, no por qué tan lejos llegue una foto. Esa es toda la diferencia entre un código insertado en la bolsa como truco publicitario y como algo que de verdad protege los números de un programa de sellos.

Para eso existen los códigos de sellos imprimibles de Ruffus: códigos QR de uso único generados en lotes, pensados para deslizarse dentro de bolsas de entrega o pedidos en línea, para que un cliente que viene de una plataforma pueda escanear uno, registrarse y juntar un sello — sin ninguna aplicación que instalar, sin ninguna integración que construir con la plataforma, porque no existe ninguna que construir. Funciona con la misma mecánica de toque-y-listo que ya existe en el mostrador, aplicada a un canal que no tiene mostrador. Lo que un restaurante haga con ese contacto después es decisión suya — una tarjeta de sellos, un mensaje ocasional, nada en absoluto — pero por primera vez, es una decisión que le toca tomar al restaurante.

En pocas palabras

La API de Uber Eats no esconde el contacto de un cliente por accidente — nunca fue diseñada para entregarlo, porque el negocio de la plataforma depende de mantenerse entre el restaurante y la persona que pidió. La solución no es pedir con más insistencia ni esperar una integración que no va a llegar. Es un código de uso único en el único lugar que un restaurante ya controla — la bolsa que sale de la cocina — que por fin le permite a ese cliente elegir una relación que la plataforma nunca le iba a regalar.