Commande en ligne multi-établissements : une seule appli pour tous vos restaurants

Passer d’un établissement à trois est la phase d’expansion la plus difficile qu’un groupe de restaurants au Royaume-Uni puisse traverser. Les systèmes conçus pour un seul site s’effondrent dès qu’un client doit choisir entre plusieurs établissements, que les prix divergent d’un site à l’autre, ou que le marketing veut envoyer une notification push à l’ensemble du groupe. Ce guide détaille ce qu’une appli de commande multi-sites doit faire, les points de vigilance, et comment les calculs changent à partir de 3 sites.

Ce que « multi-sites » implique concrètement pour une appli de commande

Une appli de commande multi-sites doit gérer proprement six choses dont les applis mono-site n’ont pas à se soucier.

• Sélecteur d’établissement à la première ouverture. Les clients voient la liste des sites à proximité (ou une carte) et choisissent où commander. Le sélecteur doit proposer par défaut le site le plus proche grâce à la géolocalisation.
• Menus par site. Le site A sert peut-être le petit-déjeuner, le site B non. Les articles peuvent être communs, mais leur disponibilité doit pouvoir varier d’un site à l’autre.
• Tarifs par site. Un établissement à Londres et un autre à Manchester n’affichent pas toujours les mêmes prix. Le système doit le permettre sans imposer deux applis distinctes.
• Horaires d’ouverture par site. Le site A est ouvert jusqu’à 23 h, le site B jusqu’à 21 h. Le parcours de commande doit respecter les horaires de chaque site.
• Fidélité à l’échelle du groupe. Un client qui atteint le niveau Bronze au site A ne doit pas perdre sa progression au site B. La fidélité se gère au niveau du client, pas au niveau du site.
• Statistiques de groupe + statistiques par site. Le responsable du site C voit ses commandes ; le propriétaire voit les trois sites.

La décision : une seule appli ou plusieurs ?

Pour un groupe de restaurants qui porte la même marque sur tous ses établissements (pensez à Honest Burgers, Pizza Pilgrims ou Patisserie Valerie), une seule appli avec changement d’établissement est la bonne réponse. Les clients la téléchargent une fois et l’utilisent partout.

Pour une holding qui exploite des marques différentes selon les sites (par exemple un italien, un thaï et un bar à cocktails), chaque marque a sa propre appli. La fidélité ne se transfère pas d’une marque à l’autre ; les clients ne le souhaitent d’ailleurs pas.

Aexir prend en charge les deux modèles. Une seule appli à votre marque avec plusieurs sites est la configuration par défaut ; le tarif exact dépend du nombre d’établissements, aux tarifs publiés, voir aexir.com/fr/pricing.

Un reporting de groupe qui vous aide vraiment à piloter l’activité

La plupart des systèmes de caisse multi-sites vous donnent un tableau de bord récapitulatif avec les totaux par établissement. C’est bien, mais insuffisant. Ce dont vous avez réellement besoin, c’est de la vue comparative : quel site surperforme le vendredi soir, lequel sous-performe le dimanche midi, lequel a du stock dormant sur les bras, lequel dépense trois fois la moyenne en coûts de livreurs.

Le tableau de bord analytique d’Aexir fait ressortir ces comparaisons nativement. Filtrez par site, par heure de la journée, par jour de la semaine. Creusez le créneau le moins performant et voyez quels articles ne se vendent pas. C’est là que se joue la marge du groupe.

Les problèmes multi-sites les plus fréquents

• Le client commande au mauvais établissement. Cause : sélecteur d’établissement enfoui dans les réglages plutôt qu’à la première ouverture. Solution : faire du sélecteur d’établissement le premier écran pour les nouveaux utilisateurs, puis mémoriser leur choix.
• Les tampons de fidélité sont « crédités deux fois » entre les sites. Cause : fidélité rattachée au site et non au client. Solution : choisir une plateforme où la fidélité est portée par le profil client, pas par le site.
• Des horaires d’ouverture différents créent de la confusion. Cause : horaires enregistrés au niveau de l’appli et non du site. Solution : des horaires d’ouverture par site, l’appli refusant les commandes en dehors de ces créneaux.
• Le responsable du site B ne peut pas consulter les rapports propres au site B. Cause : le tableau de bord d’administration n’affiche que les totaux du groupe. Solution : des accès par rôle, où les responsables de site voient leur site, les responsables régionaux leur région, et le propriétaire l’ensemble.
• Le marketing envoie la mauvaise promo au mauvais site. Cause : le ciblage des notifications push couvre toute l’appli. Solution : un ciblage des notifications push par site (seuls les clients ayant commandé au site A reçoivent la promo du site A).

Les calculs pour un groupe de 3 sites au Royaume-Uni

Prenons un exemple concret. Un petit groupe au Royaume-Uni, trois sites, 40 commandes par site et par jour en moyenne, 20 € de panier moyen. Chiffre d’affaires brut annuel du groupe : 876 000 €. Actuellement 65 % sur Uber Eats à 30 % de commission, 35 % par téléphone et sur place.

Ce qu’il faut exiger d’un créateur d’appli multi-sites

• Une base clients unique pour tous les sites. Un seul profil client, un seul solde de fidélité, un seul historique de commandes.
• Une gestion des menus par site avec une bibliothèque d’articles partagée. Modifiez le burger une fois, diffusez-le sur les sites de votre choix.
• Une cohérence de marque au niveau du groupe, avec de la souplesse au niveau du site pour les horaires, les prix et le stock.
• Des accès d’administration par rôle. Les responsables de site voient leur site, le propriétaire voit tout.
• Des notifications push ciblables par site. Mettez en avant une offre du vendredi soir dans un seul établissement sans inonder les deux autres.
• Des statistiques filtrables par site, avec des vues comparatives intégrées.
• Une tarification par établissement transparente. Évitez les plateformes qui doublent l’abonnement à chaque site ; vous devriez payer de façon incrémentale, pas multiplicative.