Ai-je toujours besoin d'un POS si j'utilise un middleware pour restaurants ?

Oui — le middleware ne remplace pas le POS. Il fonctionne en parallèle, envoyant des commandes en ligne au POS et lisant les données de vente à partir de celui-ci. Le POS reste propriétaire des tickets, du routage en cuisine et des paiements en salle.

Un local unique peut-il bénéficier du middleware ou est-ce uniquement pour les chaînes ?

Même un établissement avec deux marketplaces de livraison et un site de commande directe passe déjà un temps significatif à entrer des données en double et à synchroniser les menus. Le middleware commence à porter ses fruits à partir du deuxième canal actif. Les chaînes en tirent un avantage à grande échelle, mais ce n'est pas exclusif à elles.

Qu'est-ce que le middleware pour restaurants ?

Le middleware pour restaurants est la couche de logiciel qui se situe entre les canaux par lesquels un restaurant vend et les systèmes qui gèrent réellement l'opération. Il traduit les commandes, les menus, les prix, les modificateurs et les données de vente entre Glovo, Uber Eats, Just Eat, Deliveroo, le site de commande directe, le POS, la comptabilité, le stock et le BI — afin que l'équipe n'ait pas à gérer chaque paire manuellement.

Le problème que résout le middleware

Sans une couche middleware, chaque paire canal-système devient son propre projet. L'équipe saisit les commandes Glovo dans le POS à la main, copie les modifications de menu un panneau à la fois, exporte des CSV pour les envoyer à la comptabilité et réconcilie les paiements des marketplaces dans des feuilles de calcul. Chaque intégration est fragile, et ajouter un canal supplémentaire multiplie le travail. Le middleware pour restaurants réduit cette complexité en une connexion par canal et une connexion par système.

Ce que fait réellement un bon middleware

Un bon middleware pour restaurants fait cinq travaux opérationnels à la fois : (1) réception de commandes — accepte les commandes de chaque canal avec leur payload complet (produit, modificateurs, demandes spéciales, type, client) ; (2) publication de menu — maintient le menu, les prix et la disponibilité cohérents entre les canaux ; (3) remise au POS — envoie les commandes acceptées au POS comme si un membre de l'équipe les avait saisies ; (4) retour d'état — renvoie les statuts accepté/préparé/prêt/livré à chaque canal ; (5) mouvement de données — envoie les ventes du POS et les données de marketplace à la comptabilité, aux stocks et à la BI. Sinqro implémente ces travaux en tant que Order Hub (1-4) et Data Sync (5).

Le middleware n'est pas un agrégateur.

Un agrégateur de livraison (Glovo, Uber Eats, Just Eat, Deliveroo) opère un marketplace : il possède la relation client, gère sa propre flotte de livreurs (ou une partenaire) et facture au restaurant une commission par commande. Le middleware gère l'infrastructure du restaurant : il ne liste pas le restaurant publiquement, ne possède pas les clients et ne prend pas de commission par commande. Les restaurants utilisent généralement le middleware ET les agrégateurs ensemble : le middleware orchestre chaque canal, y compris les agrégateurs.

Où Sinqro s'intègre

Sinqro est la couche opérationnelle qui relie les canaux (marketplaces, commande directe, kiosque, QR table), les outils en restaurant (Dashboard, Work App, Rider App) et les systèmes de back-office (POS, ERP, comptabilité, stock, BI). Order Hub gère le côté des canaux. Data Sync gère le mouvement des données. Dashboard, Work App et Rider App constituent la surface des opérations quotidiennes. Cette couche opérationnelle complète est ce que la plupart des équipes appellent en abrégé 'middleware pour restaurants'.