Un restaurant présent sur trois plateformes de livraison se retrouve généralement avec trois tablettes sur une étagère, chacune avec sa sonnerie, chacune exigeant que quelqu'un accepte la commande et la lise sur un écran. Cela fonctionne jusqu'au moment où deux d'entre elles sonnent en même temps en plein service.
Réponse courte : placez un agrégateur entre les plateformes et la cuisine, puis envoyez un appel d'impression par commande. Les plateformes gardent leurs applications pour les statuts et le support, mais le ticket qui arrive en cuisine a un seul format, une seule sonnerie et aucun écran à surveiller.
Où les tablettes font vraiment mal
| Problème | Pourquoi | Ce qui change |
|---|---|---|
| Trois formats de ticket différents | Chaque application compose le sien | Un seul modèle que vous maîtrisez |
| Commandes ratées au coup de feu | Deux tablettes sonnent ensemble, l'une est ignorée | Le ticket est physique et n'a pas besoin d'être acquitté |
| Ressaisie dans la caisse | La tablette est un îlot séparé | L'agrégateur transmet la commande plus loin |
| Aucune trace de ce qui est arrivé | L'historique vit dans trois applications | Un historique d'impression, une référence de commande |
Le motif commun aux quatre est le même : une tablette est un écran pour une personne, et une cuisine au coup de feu n'a personne en trop.
L'architecture
Trois éléments, et seul celui du milieu est une décision :
- Les plateformes. Uber Eats, Deliveroo, Just Eat et les autres exposent chacune leurs commandes via leur intégration partenaire.
- Un agrégateur. HubRise et ses équivalents normalisent ces flux en un format de commande unique, ce qui rend possible un modèle de ticket unique. C'est cet élément qui fait gagner le travail.
- Un appel d'impression. Un POST par commande vers une imprimante joignable par internet. Aucun logiciel local, aucune tablette.
Si vos plateformes sont déjà unifiées dans une caisse, l'étape agrégateur peut être redondante et l'appel d'impression peut s'accrocher à la caisse. La question à poser est simplement : où les commandes se rejoignent-elles déjà, et y attacher l'impression plutôt que de construire un quatrième îlot.
Pour les plateformes qui n'exposent qu'un webhook, un outil d'automatisation comme Zapier fera le pont sans code, au prix de quelques secondes de latence.
Ce que le ticket doit porter en plus d'une commande web
Les tickets de livraison portent des informations qu'une commande boutique n'a jamais, et les omettre est ce qui provoque les rappels :
- Le nom de la plateforme et sa propre référence de commande, imprimés en grand. Quand un livreur arrive en demandant la commande 4471, personne n'a envie de chercher dans trois applications.
- Livraison ou retrait, en haut. Cela change l'emballage.
- L'heure demandée, pas seulement l'heure de commande. Une précommande pour 20h30 arrivée à 19h ne doit pas être préparée tout de suite, et c'est l'erreur la plus fréquente au moment d'abandonner les tablettes.
- Les options sur leur propre ligne indentée, parce qu'un lecteur pressé prend une option accolée pour un article de plus.
- La note du client, en entier, en bas.
Le reste de la mise en page suit les mêmes règles que tout ticket de cuisine, et le balisage est dans la référence de mise en page.
Traiter les pannes propres à la livraison
Annulations après impression. Une plateforme peut annuler une commande déjà sur la passe. Imprimer un ticket d'annulation sur la même imprimante vaut la peine : c'est plus bruyant qu'une notification que personne ne regarde.
Modifications. Certaines plateformes laissent le client modifier avant préparation. Imprimez la modification comme un nouveau ticket qui référence l'original, plutôt que de réimprimer toute la commande, pour que la cuisine ne la prépare pas deux fois.
Doublons dus aux reprises. Les webhooks d'agrégateur réessaient. Mettez la référence de commande de la plateforme dans origin pour qu'un doublon soit détectable dans l'historique plutôt que réimprimé. Le guide de fiabilité détaille le motif.
Les précommandes. Décidez si le ticket sort à la réception ou à l'heure de préparation. Sortir à la réception est plus simple et convient aux petits volumes ; programmer l'impression un délai avant le créneau demandé vaut mieux dès que les précommandes deviennent courantes, et dans les deux cas l'heure demandée doit figurer sur le ticket.
Ce qui garde besoin d'un écran
L'impression ne remplace pas entièrement les applications des plateformes. Marquer une commande prête, échanger avec un livreur et gérer les remboursements restent dans l'application, et la tablette peut quitter la passe pour le bureau. L'objectif n'est pas zéro écran ; c'est qu'aucun écran ne se trouve entre une commande entrante et la cuisine.
Imprimez un ticket de livraison de test avec le plan gratuit avec une charge utile réaliste, heure de précommande et note client sur deux lignes comprises, avant de câbler l'agrégateur. Les défauts de mise en page coûtent beaucoup moins cher à trouver un mardi après-midi.
FAQ
Peut-on imprimer les commandes des plateformes sans une tablette par application ?
Oui. Un agrégateur normalise les plateformes en un flux de commandes unique, et un seul appel d'impression envoie le ticket en cuisine. Les applications restent pour les statuts et le support, mais plus rien n'a besoin d'être lu sur un écran pour que la commande soit préparée.
Que doit porter un ticket de livraison qu'une commande boutique n'a pas ?
Le nom de la plateforme et sa propre référence de commande en gros, livraison ou retrait en haut, l'heure demandée et pas seulement l'heure de commande, les options sur leur propre ligne indentée, et la note du client en entier.
Que faire si une plateforme annule après l'impression du ticket ?
Imprimez un ticket d'annulation sur la même imprimante. C'est plus bruyant qu'une notification que personne ne regarde, et cela arrive là où le ticket d'origine est arrivé, seul endroit que la cuisine regarde vraiment.
Comment éviter que les précommandes soient préparées tout de suite ?
Faites figurer l'heure demandée sur le ticket, pas seulement l'heure de commande, et décidez d'imprimer à la réception ou de programmer l'impression un délai avant le créneau. Imprimer à la réception sans l'heure demandée est l'erreur la plus fréquente.
Pourquoi la même commande de livraison s'imprime-t-elle parfois deux fois ?
Les webhooks d'agrégateur réessaient quand votre endpoint répond lentement. Mettez la référence de commande de la plateforme dans le champ origin pour qu'un doublon soit détectable dans l'historique plutôt que réimprimé silencieusement.