À deux dans le camion : une commande, saisie une seule fois

À deux, ce qui casse le plus souvent, c’est le passage de main. La commande est prise, mais le « sans olives » est-il arrivé jusqu’au four ? Le client attend-il encore sa boisson ? Gardez le même repère jusqu’à la remise, et décidez qui confirme chaque changement.

Préparez cette organisation avec votre binôme, puis essayez-la avec votre propre matériel. Le logiciel Tablier prend les commandes et suit la production, seul sur une tablette ou à deux. Il n’encaisse pas : le paiement reste sur votre terminal ou votre caisse habituels.

Qui prend, qui prépare, qui remet ?

Réglez ces cinq rôles avant d’ouvrir, avec ce que votre matériel permet :

• Accueil et saisie. Qui tape la commande dans l’outil de référence, et annonce son numéro ?
• Préparation. Comment l’autre voit-il les pizzas, les modifications et leur ordre ?
• Encaissement. Qui enregistre le paiement, et distingue payé, en attente ou annulé ?
• Remise. Qui vérifie que les pizzas vont avec la bonne commande, avant de la marquer remise ?
• Rupture et incident. Qui met la carte à jour, et comment prévient-il l’autre ?

Une commande « prête » n’est pas forcément « payée », ni « remise ». Et une seule liste : pas une en caisse et une autre reconstituée de mémoire au four.

Pensez à la place de chacun : ce qu’on attrape sans se retourner, les passages, l’accès au froid, les zones chaudes, qui croise qui. En restauration rapide, les risques connus sont les manutentions, les chutes, les coupures et les brûlures (INRS — risques en restauration rapide).

Garder le même numéro jusqu’au client

Le circuit à tester : une seule saisie, puis préparation, prête, remise. Le paiement se suit à part. Décidez où chacun lit l’état de la commande, sans recopier son contenu dans un deuxième outil.

Une modification ? Ouvrez la commande existante, et faites en sorte que le changement se voie au four. Une annulation ? Gardez-en la trace, selon ce que permet votre outil, et ne créez pas de commande fantôme pour équilibrer une liste. Si la pizza est déjà lancée, traitez à part la pizza préparée et le paiement à régulariser.

Exemple fictif de test, pas un relevé d’activité. Trois commandes contiennent 2, 1 et 3 pizzas : cela fait 3 commandes et 6 pizzas. Annuler la troisième laisse 2 commandes actives et 3 pizzas à servir. Ce calcul ne dit pas si des pizzas étaient déjà préparées, perdues ou payées : regardez ces états, au lieu de les deviner à partir du nombre de commandes.

La trace d’une commande dans l’outil n’est pas une facture. Les mentions et obligations de facturation se vérifient à part (Service Public — factures).

Cinq essais avant d’ouvrir

Si votre outil a un mode d’essai, servez-vous-en, avec les règles prévues pour ne pas créer de vraies ventes. Convenez d’abord de la façon de reconnaître ces commandes d’essai.

• Deux pizzas dans une commande. Ce que vous devez voir : le même numéro à la saisie, au four et à la remise.
• Une modification après saisie. Le four reçoit le changement, sans ancienne version qui traîne.
• Une annulation après lancement. On retrouve la commande ; la pizza déjà faite et le paiement se règlent chacun de leur côté.
• Un paiement en attente. Si votre outil suit le paiement, « Prête » n’efface pas son état. Sinon, notez qui vérifie le paiement avant la remise.
• Une rupture ou un retard. L’accueil le sait avant de promettre une nouvelle pizza.

Notez où il a fallu recopier, crier une information ou chercher la bonne commande. Puis choisissez un seul correctif : la place de l’écran, qui remet, la règle pour les modifications ou le chemin de l’information. Au service suivant, regardez s’il a réglé le problème.

Le papier, en secours de panne

Le courant coupe, une tablette tombe en panne : comment finissez-vous les commandes en cours ? Préparez un secours qui va avec votre outil, et décidez comment revenir à la normale.

Si vous passez au papier pendant l’incident, notez clairement la période, les commandes concernées, ce qui est préparé et ce qui est payé. Décidez qui garde ces feuilles, et qui fait le rapprochement une fois l’outil revenu. Ne ressaisissez pas tout comme de nouvelles ventes : suivez la procédure de reprise de votre logiciel, puis cherchez les doublons et les encaissements.

Testez ce secours avant d’en avoir besoin. Un essai doit répondre à deux questions : peut-on finir les commandes en cours, puis retrouver un état juste dans l’outil principal ?

Après le service : trois faits à noter

En rangeant, notez trois choses que vous avez vues : une attente, une information perdue ou tapée deux fois, un écart entre ce qui était prévu et ce qui s’est passé. Notez des faits : « trois commandes modifiées ont dû être expliquées à voix haute » vous servira plus que « on était débordés ».

Dans Mon projet, préparez les dates, l’équipe et les hypothèses du prochain service. Cette préparation ne remplace pas le logiciel du service et ne récupère pas ses ventes automatiquement.

Checklist avant le prochain service

Prochaine action : remplissez votre organisation ci-dessous, faites les cinq essais et notez ce qui doit changer. Exportez la préparation pour la partager avec votre binôme ; le guide n’envoie aucun message.