Un programme de fidélité pour vos clients Uber Eats : les faire commander direct

Un vendredi soir occupé sur Uber Eats, ça peut ressembler à de la croissance : quarante commandes, une cuisine qui n’arrête pas, un téléphone qui n’arrête pas de sonner jusqu’à la fermeture. Ce que ce n’est habituellement pas, c’est quarante nouvelles relations. Un client qui commande au même restaurant quarante fois via une plateforme de livraison peut rester, aux yeux du restaurant, un parfait inconnu — le même inconnu qu’après sa première commande. Ce n’est pas un problème de marketing du côté du restaurant. C’est ce que l’API de la plateforme est construite pour permettre.

Ce que les données de commande d’Uber Eats contiennent vraiment

Ça vaut la peine de regarder ce qui parvient vraiment à un restaurant quand une commande arrive, selon la documentation publique de l’API d’Uber Eats — pas selon ce qu’un propriétaire suppose que ça doit contenir. Le webhook qui se déclenche au moment où une commande atterrit ne transporte aucune donnée client : c’est la commande elle-même, rien sur qui l’a passée. Le point d’accès de détails de commande qu’un restaurant peut interroger ensuite retourne un prénom, une initiale de nom de famille, et un numéro de téléphone anonymisé — il passe par le système d’Uber Eats et exige un code pour être composé, pas un numéro qui rejoint le client directement. Il n’y a aucune adresse courriel nulle part dans ces données. Et le seul identifiant client que l’API expose est documenté comme unique à cette commande précise : ce n’est pas la même valeur qui apparaît la prochaine fois que cette personne commande, donc aucun champ ne permet à un restaurant de faire le lien « c’est le même habitué que la semaine dernière », même par accident.

Quarante commandes, zéro contact

En mettant ces trois faits ensemble, le problème cesse d’être vague. Un restaurant peut servir la même personne quarante fois via Uber Eats et n’avoir toujours aucun moyen de la rejoindre en dehors de la plateforme. Ni texto, ni offre d’anniversaire, ni petit mot du genre « reviens-nous voir » — il n’existe aucun champ dans les données qui permettrait à un restaurant d’essayer. La plupart des propriétaires sentent ce problème sans pouvoir le nommer : les habitués qu’ils reconnaissent lors d’un quart du vendredi n’apparaissent nulle part comme des habitués dans le tableau de bord de la plateforme, parce que pour la plateforme, ce n’est pas un client qui revient — c’est une commande qui revient.

Pourquoi c’est voulu, pas un oubli

Rien de tout ça n’est un bogue qu’Uber Eats a oublié de corriger. Toute la valeur d’une plateforme, pour elle-même, vient du fait de se placer entre un restaurant et les gens qui commandent chez lui — le jour où un restaurant peut rejoindre ce client directement et sauter la plateforme à la prochaine commande, c’est le jour où la plateforme a moins de raisons d’être payée pour cette commande-là. L’API est précise sur la commande et minimaliste sur la personne, volontairement. Ce n’est pas de la négligence ; c’est le modèle d’affaires.

Ce qui ramène vraiment un client

Rien de tout ça ne veut dire qu’un restaurant est coincé à attendre une intégration qui n’arrivera jamais. Ça veut dire que le contact doit être bâti par le restaurant lui-même, au seul moment qu’il contrôle encore entièrement : quand la commande quitte la cuisine. Une carte ou un petit encart avec un code QR, glissé dans le sac, envoie ce client vers une page que le restaurant possède — une inscription à sa propre carte fidélité — et à partir de là, le restaurant a exactement ce que le client choisit de lui donner directement, pas ce qu’une API a bien voulu exposer. C’est aussi le moment où un client de livraison devient quelqu’un qui pourrait commander directement la prochaine fois, parce qu’il existe maintenant une façon de lui rappeler que le restaurant existe en dehors de l’appli par laquelle il a commandé.

Pourquoi l’usage unique est ce qui compte vraiment

Le détail qui décide si tout ça fonctionne vraiment, c’est l’usage unique. Un code QR générique imprimé une fois et collé au comptoir, ou réutilisé dans chaque sac pendant un mois, a une faille évidente : n’importe qui peut le prendre en photo, le publier ou le passer à un ami, et le restaurant finit par donner la même récompense à des gens qu’il n’a jamais servis. Un code valide pour un seul échange n’a pas ce problème — il est limité par le nombre que le restaurant a réellement imprimé, pas par la distance que peut parcourir une photo. C’est toute la différence entre un code glissé dans un sac comme gadget et comme quelque chose qui protège vraiment les chiffres d’un programme basé sur l’étampe.

C’est exactement à ça que servent les codes d’étampage imprimables de Ruffus : des codes QR à usage unique, générés par lots, pensés pour être glissés dans des sacs de livraison ou des commandes en ligne, pour qu’un client venu d’une plateforme puisse en scanner un, s’inscrire, et collecter une étampe — sans application à installer pour lui, sans intégration à bâtir avec la plateforme pour le restaurant, parce qu’il n’y en a aucune à bâtir. Ça repose sur la même mécanique tap-and-go déjà en place au comptoir, simplement appliquée à un canal qui n’a pas de comptoir. Ce que fait un restaurant avec ce contact par la suite, c’est son choix — une carte fidélité, un message à l’occasion, rien du tout — mais pour une fois, c’est un choix que le restaurant peut faire lui-même.

En résumé

L’API d’Uber Eats ne cache pas les coordonnées d’un client par accident — elle n’a jamais été conçue pour les donner, parce que le modèle d’affaires de la plateforme dépend du fait de rester entre le restaurant et la personne qui a commandé. La solution n’est pas de demander plus fort ou d’attendre une intégration qui ne viendra pas. C’est un code à usage unique dans le seul endroit qu’un restaurant contrôle déjà — le sac qui quitte la cuisine — qui permet enfin à ce client de choisir une relation que la plateforme n’allait jamais lui offrir.