Delivery-Aggregator-Bestellungen und Bestand: Warum Marketplace-Verkäufe Bestandszählungen umgehen und den echten Wareneinsatz verbergen

Wo Aggregator-Verkäufe verschwinden, bevor sie Ihren Bestand erreichen

Delivery-Aggregator-Bestellungen beeinflussen Ihren Bestand nur dann, wenn jeder Verkauf mit einem Rezept verknüpft und in Ihr Bestandssystem eingespeist wird. Wenn eine Marketplace-Bestellung diese Verknüpfung umgeht, weil die Plattform nicht mit Ihrem Kassensystem verbunden ist oder die Integration Daten nur exportiert, werden die verbrauchten Zutaten niemals abgezogen, sodass Ihre Lagerbestände und Ihr Wareneinsatz stetig von der Realität abweichen.

Dies ist die Lücke, auf die Betreiber zuerst stoßen. Eine Multi-Standort-Poké-Kette mit einer zentralen Produktionsküche stand in Verhandlungen mit mehreren Delivery-Marktplätzen und betrieb ihre Kassen mit einem marktüblichen Kassensystem, nur um festzustellen, dass einige der evaluierten Plattformen keine Verbindung zu diesem Kassensystem hatten. Jede über diese Kanäle verkaufte Bowl verließ die Küche, aber kein System zog die verwendeten Proteine, Grundzutaten und Toppings ab. Die Zentralküche produzierte weiterhin nach einem Plan, dem die eigenen Verkaufsdaten still widersprachen.

Die Kosten dieses blinden Flecks sind messbar. Ein Multi-Channel-Betreiber stellte fest, dass rund 30 % des Bestellumsatzes, der über Delivery-Kanäle fließende Anteil, für das Back-of-House-System unsichtbar war, da diese Bestellungen nie das Bestandssystem erreichten. Wenn ein Drittel des Umsatzes den Bestand nicht verringert, basieren Abweichungsberichte, Nachbestellungsempfehlungen und der theoretische Wareneinsatz alle auf einem unvollständigen Bild. Die Zählungen wirken falsch, und niemand weiß warum.

Die Lösung besteht darin, diese Verknüpfung herzustellen, bevor Sie der nächsten Zählung vertrauen: Jeder Delivery-Kanal benötigt eine Live-Verbindung, die jede Bestellung in einen Bestandsabzug auf Rezeptebene überführt, sodass eine über einen Marktplatz verkaufte Bowl dieselben Proteine, Grundzutaten und Toppings abzieht wie eine an der Kasse verkaufte. Sobald jeder Kanal den Bestand abzieht, tauchen die verschwundenen 30 % als echter Verbrauch wieder auf, und Ihre Abweichungs-, Nachbestellungs- und Wareneinsatzberichte basieren endlich auf dem gesamten Betrieb statt nur auf dem Vor-Ort-Geschäft. Diese Lücke ist es, die Supy schließt: Es verbindet Ihr Kassensystem und Delivery-Aggregatoren und ordnet jedes Menüelement einem Rezept zu, sodass Marketplace-Bestellungen den Bestand automatisch abziehen, anstatt einen blinden Fleck in Ihren Zählungen zu hinterlassen.

Warum Modifier- und Build-Your-Own-Bestellungen die falschen Zutaten abziehen

Auch wenn Aggregator-Verkäufe Ihr System erreichen, sind High-Modifier-Menüs der Bereich, in dem die Abzüge falsch werden. Eine Build-Your-Own-Bowl oder ein Burrito ist kein einzelnes Gericht, sondern Dutzende von Zutatenkombinationen, die unter einem einzigen Menünamen verkauft werden. Wenn das Delivery-Menü nicht auf Modifier-Ebene mit Rezepten verknüpft ist, zieht jede Bestellung dieselben Standard-Zutaten ab, unabhängig davon, was der Gast tatsächlich gewählt hat.

Betreiber spüren diesen Druck an der Kasse. Eine Schnellverpflegungsgruppe stellte fest, dass es für das Personal zu langsam war, bei einem High-Modifier-Artikel jede Zutatenwahl zu erfassen, sodass sie für jedes Menüelement ein Rezept auf Basis der häufigsten Wahl erstellten, die rund 75 % der Bestellungen ausmachte, und den Bestand für die Ausnahmen manuell anpassten. Das funktioniert, bis es nicht mehr funktioniert: Die manuellen Anpassungen werden in der Stoßzeit vernachlässigt, und die 25 % der Bestellungen mit einer anderen Grundlage verfälschen langsam sowohl die Inventur als auch die Rezeptkosten.

Dies ist das Abzugsproblem im Kleinen. Wenn ein Menüelement auf Modifier-Ebene mit Rezepten verknüpft ist, zieht jeder Verkauf, ob vor Ort oder per Delivery, genau die verwendeten Zutaten ab, einschließlich Wechsel und Extras, sodass die Zählung widerspiegelt, was tatsächlich das Regal verlassen hat. Diese Verknüpfung ermöglicht es auch, dass eine Delivery-Bestellung und eine In-Store-Bestellung desselben Gerichts den Bestand korrekt aus demselben Rezept verbrauchen. Ohne sie gilt: Je mehr Ihr Menü den Gästen Anpassungsmöglichkeiten bietet, desto schneller werden Ihre Zahlen unzuverlässig.

Die Wareneinsatzzahl, die die Delivery-Provision unbemerkt verfälscht

Delivery verzerrt nicht nur Ihre Bestandszählungen, sondern auch Ihren Wareneinsatz in Prozent, und zwar in einer Richtung, die die Zahl beschönigt. Marketplace-Plattformen erheben eine Provision von rund 25 bis 35 % des Bestellwerts, bevor Sie bezahlt werden. Wenn Sie den Wareneinsatz am Bruttobestellwert der Plattform berechnen statt am tatsächlich einbehaltenen Nettoumsatz, erscheint jeder Delivery-Verkauf profitabler, als er ist.

Die Mathematik ist unerbittlich. Eine Delivery-Marke, die einen Wareneinsatz von 28 % am Bruttoumsatz ausweist, hat bei einer Take-Rate von 30 % tatsächlich einen Wareneinsatz von fast 40 % am einbehaltenen Umsatz. Das ist der Unterschied zwischen einem profitablen Kanal und einem, der bei jeder Bestellung Verluste macht, und er ist vollständig verborgen, wenn Ihre Berichterstattung Brutto- und Nettoumsatz nie trennt. Ghost Kitchens und Delivery-First-Marken sind am stärksten betroffen, weil Delivery bei ihnen nicht ein Kanal unter vielen ist, sondern das gesamte Geschäft.

Die Lösung besteht darin, Delivery-Artikel gegen den einbehaltenen Umsatz zu kalkulieren und diesen Kanal separat vom Vor-Ort-Bereich zu beobachten, dieselbe Disziplin, die Sie anwenden würden, wenn Sie den theoretischen vs. tatsächlichen Wareneinsatz nach Standort isolieren. Ein gemischter Wareneinsatz über alle Kanäle mittelt das Delivery-Problem zur Unsichtbarkeit; eine kanalspezifische Ansicht macht es sichtbar.

Einweg-Export vs. Zweiweg-Synchronisation: Was Sie vor dem Vertrauen in eine Integration prüfen sollten

Da so vieles davon abhängt, dass Daten tatsächlich in Ihr Bestandssystem fließen, ist die Richtung einer Kassen- oder Aggregatorverbindung wichtiger als deren bloße Existenz. Ein Betreiber wurde im Verkaufsgespräch informiert, dass sein Kassensystem Live-Verkäufe automatisch in seine neue Bestandsplattform einspeisen würde, um nach Vertragsunterzeichnung festzustellen, dass die Integration nur Daten exportierte. Der einzige Weg hinein war ein manueller Dateiupload. Er sagte offen, er hätte nicht unterschrieben, wenn er das gewusst hätte.

Einschränkungen von Drittanbietern verschärfen dies. Einige Kassen- und Aggregatoranbieter bieten keine offene API an oder können die SKU- und Modifier-Details nicht liefern, die ein Bestandssystem für genaue Abzüge benötigt, eine Einschränkung, die der Betreiber nicht allein lösen kann. Bevor Sie sich festlegen, bestätigen Sie, dass die Verbindung eine Live-Zweiweg-Synchronisation ist, kein reiner Export; dass sie auf Artikel- und Modifier-Ebene detaillierte Daten überträgt, nicht nur Bestellsummen; und dass sie Sie vor einem doppelten manuellen Import warnt, der den Bestand doppelt abzieht. Dies sind dieselben Fragen, die entscheiden, ob ein Kassensystem-Feed Ihren Bestand korrekt halten oder still korrumpieren wird.

Hier zahlt sich auch die Breite nativer Verbindungen aus. Eine Plattform, die POS-, Online-Bestell- und Aggregatorkategorien über 75+ Integrationen abdeckt, hat mit viel größerer Wahrscheinlichkeit eine echte Zweiweg-Verbindung zu den spezifischen Plattformen, die Sie betreiben, als eine, die für jede einen individuellen Connector entwickeln muss.

Um herauszufinden, ob dies in Ihrem Betrieb passiert, stimmen Sie einen einzelnen delivery-intensiven Tag ab: Rufen Sie die von jedem Aggregator gemeldeten Bestellungen ab und prüfen Sie, ob diese genauen Verkäufe als Bestandsabzug erscheinen und ob die abgezogenen Zutaten dem entsprechen, was diese Gerichte tatsächlich verwenden. Wenn das Delivery-Volumen Ihre Zählungen nicht bewegt, ist der Feed unterbrochen oder nur ein Export. Wenn Ihr Wareneinsatzbericht eine gemischte Zahl zeigt, erstellen Sie ihn kanalweise gegen den Nettoumsatz und sehen Sie, wo Delivery tatsächlich steht. Und wenn Ihre High-Modifier-Artikel einem einzigen Standard-Rezept zugeordnet sind, ordnen Sie sie auf Modifier-Ebene zu, bevor Sie der nächsten Zählung vertrauen.

Delivery richtig hinzubekommen ist kein Marketingprojekt, sondern ein Back-of-House-Datenproblem. Wenn Aggregator-Verkäufe in Bestandsabzüge auf Rezeptebene fließen und gegen den einbehaltenen Umsatz kalkuliert werden, wird Delivery zu einem weiteren Kanal, den Sie tatsächlich managen können, und nicht zu einem Loch in Ihrem Bestand und Wareneinsatz. Supy verbindet Kassensysteme und Delivery-Aggregatoren, ordnet Menüelemente auf Modifier-Ebene Rezepten zu, sodass Verkäufe die richtigen Zutaten abziehen, und hält den kanalspezifischen Wareneinsatz korrekt.