Live-ERP-Daten als Filter und Ranking-Signal: Lagerbestände in der Shop-Suche

Der teuerste Treffer ist der, den niemand bestellen kann

Viele Shop-Betreiber fragen sich: Warum zeigt meine Suche Produkte an, die im Checkout gar nicht mehr lieferbar sind? Weil die Standard-Suche nur die Produktstammdaten kennt und die Live-Verfügbarkeit aus dem ERP ignoriert — genau das ist der teuerste Fehler einer Trefferliste. Sobald Lagerbestand, Lieferzeit und Preis als Filter und Ranking-Signal einfließen, landen bestellbare Artikel oben und ausverkaufte unten. Wie sich das Gegenteil anfühlt, zeigt ein Mittwochabend um 19:42 Uhr.

Ein Mittwoch um 19:42 Uhr, ein Lebensmittel-Online-Shop mit 35.000 SKUs. Eine Kundin tippt "Mehl 1kg" in die Suchzeile. Die Trefferliste zeigt 17 Mehlsorten. Auf Platz 1 ein 1-Kilo-Weizenmehl Type 405, auf Platz 2 ein Bio-Dinkelmehl, auf Platz 3 ein glutenfreies Reismehl. Die Kundin legt das Weizenmehl in den Warenkorb. Im Checkout, drei Klicks später, kommt der Hinweis: "Leider nicht mehr verfügbar, Lieferung erst in 7 bis 10 Tagen." Sie wechselt zurück zur Trefferliste, klickt das Dinkelmehl an. Gleiche Meldung. Klickt das nächste. Gleiche Meldung. Von den 17 Treffern sind 14 nicht innerhalb der nächsten 48 Stunden verfügbar. Sie schließt den Tab und kauft bei einem anderen Anbieter.

Das ist der teuerste Fehler einer Shop-Suche: relevante Treffer zeigen, die der Kunde nicht kaufen kann. Die Standard-Shop-Suche kennt die Stammdaten der Produkte (Name, Beschreibung, Kategorie, Preis), aber sie kennt die operative Realität nicht. Sie weiß nicht, wie viele Stück im Lager liegen, wann das Produkt voraussichtlich beim Kunden ankommt, ob das gewünschte Filial-Lager gerade leer ist, ob die Versandkosten den Listenpreis verdoppeln. Diese operative Realität liegt im ERP- und PIM-System, im Warehouse-Management-System (WMS), im Versand-Dispositions-System. Sie ändert sich im Minuten- bis Stunden-Takt. Und sie entscheidet, ob ein Treffer zum Kauf führt oder zum Tab-Schließen.

Dieser Artikel beschreibt, wie Live-Daten aus dem ERP-, PIM- und Warenwirtschafts-System in die Shop-Suche kommen. Wie Lagerbestände, Lieferzeiten und Preise nicht nur als Filter abgebildet werden ("nur lieferbare Artikel zeigen"), sondern auch als Ranking-Signal funktionieren ("verfügbare Artikel nach oben, ausverkaufte nach unten"). Welche Sync-Pattern für welche Daten-Volatilität geeignet sind. Wie eine entkoppelte Infrastruktur die Last vom Shop-Backend nimmt, ohne dass die Suche zur unsichtbaren Bremse für die Datenbank wird. Und wie das alles cookieless und DSGVO-konform bleibt, weil keine personenbezogenen Daten in den ERP-Sync hineingehören.

Warum die Standard-Shop-Suche ERP-Daten ignoriert

Woran scheitert eine klassische Shop-Suche bei Live-Lagerbeständen?

Die meisten herkömmlichen Such-Lösungen sind als Volltext-Engine für statische Produktdaten gebaut. Sie indizieren Produktnamen, Beschreibungen, Kategorien, vielleicht ein paar Attribute. Diese Daten ändern sich selten, der Index wird typisch einmal pro Nacht neu gebaut. Lagerbestände, Lieferzeiten und Preise dagegen ändern sich stündlich, manchmal minütlich. Ein einfacher Volltext-Index ist dafür nicht ausgelegt.

Drei strukturelle Probleme treten auf, wenn man trotzdem versucht, Live-Daten in eine klassische Such-Architektur zu zwingen.

Erstens die Index-Update-Frequenz. Ein nächtliches Full-Reindexing reicht bei Lagerbeständen nicht. Wenn um 9:00 Uhr ein Produkt mit 200 Stück Bestand in den Index geschrieben wird und um 14:00 Uhr nur noch 3 Stück übrig sind, zeigt die Trefferliste den ganzen Nachmittag eine falsche Verfügbarkeit. Bei Top-Sellern führt das zu massiven Stornierungen im Checkout und Vertrauensverlust beim Kunden.

Zweitens die Update-Last. Wenn der Index für jede einzelne Bestandsänderung im ERP neu geschrieben wird, summieren sich die Schreiboperationen schnell auf. Ein Shop mit 35.000 SKUs und durchschnittlich 5 Bestandsänderungen pro SKU am Tag ergibt 175.000 Index-Updates pro Tag. Eine klassische Solr- oder Elasticsearch-Installation auf einem mittelgroßen Cluster kommt da unter Last in Schwierigkeiten, wenn parallel noch Such-Queries beantwortet werden müssen.

Drittens die Konsistenz zwischen Index und Quellsystem. Wenn das ERP die letzte verbindliche Wahrheit über Lagerbestände ist und der Index nur eine Kopie davon hält, gibt es immer ein Zeitfenster, in dem Index und ERP auseinanderlaufen. Bei kurzlebigen Bestandsänderungen (eine Bestellung kommt rein, das Produkt ist sofort weg) entstehen "Phantom-Bestände" im Index, die zum Checkout führen, aber dort scheitern. Die Folge ist die operativ schlimmste Variante: der Kunde glaubt, etwas gekauft zu haben, und erfährt erst nach der Bestätigung, dass das Produkt nicht lieferbar ist.

Diese drei Probleme sind nicht durch besseres Tuning zu lösen, sondern erfordern eine andere Architektur. Eine Architektur, in der die Such-Infrastruktur die Live-Daten aus dem ERP nicht als statisches Index-Feld, sondern als parallel laufende Datenquelle behandelt. Die operative Antwort darauf ist eine entkoppelte Infrastruktur, in der die Suche selbst als Such-Layer zwischen Shop-Frontend und ERP/PIM/WMS sitzt und die Live-Daten mit eigener Logik orchestriert.

Was "Live-ERP-Daten in der Suche" wirklich heißt

Welche ERP-Daten sind für die Shop-Suche überhaupt relevant?

Bevor wir auf die Sync-Pattern eingehen, lohnt die Frage, welche ERP-Daten in der Suche überhaupt relevant sind. In der Praxis sind es sechs Datenklassen, die jeweils eine andere Update-Frequenz, andere Datenstruktur und andere Sucht-Logik haben.

Erstens der Lagerbestand pro SKU. Eine Integer-Zahl (oder ein Enum: in_stock, low_stock, out_of_stock), die sich pro Lagerort und pro SKU separat führt. In B2B-Plattformen mit mehreren Distribution-Centern existieren typisch drei bis sieben Lagerorte parallel, jeder mit eigenem Bestand. Update-Frequenz: Minuten bis Stunden.

Zweitens die Lieferzeit. Eine Zeit-Angabe (in Werktagen oder Stunden), die sich aus Lagerbestand, Versand-Cutoff-Zeiten, Lager-Standort und Liefer-Adresse zusammensetzt. Eine Bestellung um 14:00 Uhr aus einem Lager mit 16:00-Uhr-Cutoff ist heute noch versandfähig, eine Bestellung um 17:00 Uhr nicht. Update-Frequenz: in der Berechnungs-Logik laufend, in der Index-Speicherung typisch täglich oder ereignis-basiert.

Drittens der Preis. Der Listenpreis ist relativ stabil (Quartal oder Aktions-Phase), aber der ausgespielte Preis kombiniert Listenpreis mit kunden-spezifischen B2B-Konditionen, Mengen-Rabatten, Promo-Codes, regionalen Mehrwertsteuersätzen. Update-Frequenz für den Listenpreis: tageweise. Für den effektiven Preis: query-zeit-basiert.

Viertens die Verfügbarkeits-Status-Flags. Eigenständige Felder wie "Nachschub erwartet am", "vorübergehend nicht lieferbar", "Auslauf-Artikel", "kommt bald wieder". Diese Status-Felder sind keine reine Mengen-Information, sondern operative Meldungen aus dem Einkauf und der Disposition. Update-Frequenz: ereignis-basiert.

Fünftens die Cross-Sell- und Substitut-Beziehungen. Wenn Produkt A out-of-stock ist, aber Produkt B als Ersatz dienen kann, soll die Suche diese Beziehung kennen und in der Trefferliste sinnvoll vorschlagen. Update-Frequenz: meist statisch (PIM-Pflege), in Spezialfällen ereignis-basiert.

Sechstens die operativen Sperr-Flags. Produkte können in einzelnen Regionen, für einzelne Kundengruppen oder für einzelne Zeitfenster gesperrt sein. Regulatorische Sperren (Jugendschutz, Exportkontrolle), kommerzielle Sperren (Vertrags-Sortiment), saisonale Sperren (Feuerwerk im November, Saisongeschirr im Sommer). Update-Frequenz: ereignis-basiert.

Diese sechs Datenklassen müssen in der Suche unterschiedlich behandelt werden. Lagerbestand ist ein numerisches Feld mit hoher Volatilität, das als Filter und Ranking-Signal dient. Lieferzeit ist ein abgeleitetes Feld, das aus Lagerbestand, Cutoff-Zeit und Liefer-Adresse berechnet wird. Preise sind eine Kombination aus statischen Listenpreisen im Index und dynamischer Personalisierung zur Query-Zeit. Status-Flags und Sperr-Flags sind Boolean-artige Felder mit ereignis-basiertem Update. Cross-Sell-Beziehungen sind Graph-Strukturen, die typisch im PIM gepflegt und im Index als Lookup-Tabelle abgelegt werden.

Sync-Pattern: Batch, Webhook, Polling, Streaming

Wie kommen die Bestandsdaten aus dem ERP eigentlich in die Suche?

Die naheliegende Frage ist, wie die Daten aus dem ERP in die Such-Infrastruktur kommen. Vier Sync-Pattern haben sich in der Praxis etabliert, jedes mit eigenen Stärken und Schwächen.

Erstens der nächtliche Batch-Push. Das ERP exportiert einmal pro Nacht den vollständigen Bestand, der Such-Index baut sich daraus neu auf. Das Pattern ist operativ einfach (eine Job-Definition, ein Export-Format, ein Import-Skript), aber es führt zu den eingangs beschriebenen Konsistenzproblemen. Tags-aktuelle Bestände stehen im Index, Live-Bestände nicht. Für Long-Tail-Sortimente mit niedriger Umschlagshäufigkeit kann das ausreichen. Für Top-Seller, Aktions-Artikel und volatile Sortimente ist es ungeeignet.

Zweitens das Webhook-getriebene Update. Das ERP feuert bei jeder Bestandsänderung ein Event-Webhook an die Such-Infrastruktur. Die Suche aktualisiert das betroffene Dokument im Index. Das Pattern ist nahezu live (typisch unter 30 Sekunden Lag), aber es erfordert, dass das ERP Webhooks unterstützt und dass die Endpunkte zuverlässig erreichbar sind. Wenn ein Webhook verloren geht (Netzwerk-Fehler, Empfänger nicht erreichbar), läuft der Index leise auseinander, ohne dass jemand es merkt. Webhook-Pipelines brauchen daher zwingend eine Deduplizierungs- und Replay-Logik.

Drittens das Polling. Die Such-Infrastruktur fragt im Minuten-Takt das ERP nach Änderungen seit dem letzten Poll. Das Pattern ist robust gegen verlorene Events, weil das nächste Polling-Fenster die Änderung nachholt. Es ist aber teurer in der ERP-Last, weil pro Poll mehrere hundert oder tausend SKUs abgefragt werden. Bei einem Polling-Intervall von 5 Minuten und 35.000 SKUs sind das 4,2 Millionen Abfragen pro Tag, was viele ERP-Systeme an die Performance-Grenze führt.

Viertens das Streaming über einen Event-Bus (Kafka, Pulsar, ein anderer Message-Broker). Das ERP schreibt Bestandsänderungen als Events in den Stream, die Such-Infrastruktur konsumiert den Stream und aktualisiert den Index. Das Pattern ist die robusteste Lösung, weil Streams replay-fähig, persistent und entkoppelt sind. Es ist aber operativ am aufwendigsten, weil ein Stream-Layer infrastrukturell betrieben und überwacht werden muss.

In der Praxis sehen wir am häufigsten eine Kombination. Stammdaten (Produktnamen, Kategorien, Bilder) kommen täglich per Batch. Lagerbestände kommen entweder per Webhook (bei modernen ERPs) oder per Stream (bei high-volume B2B-Plattformen). Preise kommen täglich per Batch für Listenpreise und query-zeit-basiert für personalisierte Konditionen. Die Sync-Architektur ist nie monolithisch, sondern eine Pipeline aus mehreren Komponenten, die jeweils auf ihre Datenklasse zugeschnitten sind.

Wir haben den verwandten Punkt zur ERP- und PIM-Sync-Pipeline im Multi-Country-Kontext in unserem Beitrag zu Multi-Country Search-Infrastruktur ausführlich behandelt. Im Multi-Country-Kontext multipliziert sich die Komplexität um den Faktor der Marktanzahl. Die Pattern bleiben dieselben, aber die Pipelines werden pro Markt parametrisiert.

Latenz vs Konsistenz: wie "live" muss live sein?

Wie aktuell müssen die Lagerbestände in der Suche tatsächlich sein?

Die unterschätzte Architektur-Frage ist, wie aktuell die Daten in der Suche eigentlich sein müssen. Die intuitive Antwort "so live wie möglich" ist meist falsch. Sie führt zu überteuerten Streaming-Pipelines, hoher Cluster-Last und einer fragilen Architektur, die bei der kleinsten Störung ins Schwitzen kommt. Die richtige Antwort hängt von der Volatilität und dem geschäftlichen Risiko pro SKU ab.

Für Top-Seller mit hoher Umschlagshäufigkeit (über 50 Bestellungen pro Tag und SKU) sind Sekunden-Latenzen sinnvoll. Wenn ein Produkt um 9:00 Uhr noch 200 Stück hat und um 11:00 Uhr ausverkauft ist, muss die Suche das im Minuten-Bereich mitbekommen. Webhook- oder Stream-Pipelines sind hier Standard.

Für mittelvolumige Sortimente (5 bis 50 Bestellungen pro Tag) reichen Minuten-Latenzen. Polling alle 5 oder 10 Minuten oder ein Webhook mit etwas Lag ist ausreichend. Die Wahrscheinlichkeit, dass ein Bestand im Polling-Fenster komplett wegläuft, ist gering genug, dass die operativen Konsistenzprobleme im akzeptablen Rahmen bleiben.

Für Long-Tail-Sortimente mit wenigen Bestellungen pro Woche sind Stunden- oder sogar Tages-Latenzen unkritisch. Nächtliche Batch-Updates reichen, weil die Bestandsänderungen pro Tag so selten sind, dass die Konsistenz nicht in Gefahr ist. Das spart Infrastruktur und Komplexität für 60 oder 70 Prozent des Sortiments.

Eine pragmatische Sync-Strategie segmentiert das Sortiment nach Umschlagshäufigkeit und ordnet jedem Segment ein Sync-Pattern zu. Top-Seller per Stream, Mittelvolumen per Webhook oder Polling, Long-Tail per Batch. Das halbiert die Streaming-Last gegenüber einer naiven "alles per Stream"-Architektur und verdoppelt die operative Robustheit, weil die kritischen Daten dedizierte Pipelines bekommen.

Die Segmentierung sollte automatisiert sein. Wenn ein Long-Tail-Artikel plötzlich zum Top-Seller wird (etwa durch eine Influencer-Erwähnung), muss die Pipeline ihn automatisch in die Stream-Klasse hochstufen. Wenn ein Top-Seller in den Long-Tail abrutscht, ebenso. Manuelle Segmentierung bricht spätestens nach drei Monaten zusammen.

Lagerbestand als Boolean-Filter vs Ranking-Penalty

Sobald die Daten in der Suche sind, stellt sich die nächste Frage: wie soll die Suche den Lagerbestand nutzen? Zwei Strategien sind etabliert, und die meisten Plattformen kombinieren beide situativ.

Die Boolean-Filter-Strategie blendet out-of-stock-Produkte komplett aus. Die Suche zeigt nur lieferbare Artikel. Vorteil: der Kunde sieht keine Frust-Treffer, jede Trefferkarte ist ein bestellbares Produkt. Nachteil: das Sortimentsbild verarmt sichtbar, wenn viele Artikel ausverkauft sind. Ein Kunde, der vergeblich nach einem speziellen Produkt sucht, sieht eine kurze Trefferliste und denkt, der Shop habe das Produkt gar nicht im Sortiment. In Wahrheit ist es nur kurzzeitig ausverkauft.

Die Ranking-Penalty-Strategie zeigt out-of-stock-Produkte weiterhin an, aber rankt sie nach unten. Lieferbare Artikel kommen zuerst, dann die low-stock-Artikel, am Ende die ausverkauften mit einem deutlichen Hinweis "Bald wieder verfügbar" oder "Über Versand-Benachrichtigung informieren". Vorteil: der Kunde sieht das volle Sortiment und erkennt sofort die Verfügbarkeit. Nachteil: die Trefferliste wird länger, und Kunden mit klarer Kaufabsicht müssen die ausverkauften Artikel scrollen.

In der Praxis ist die Wahl der Strategie kontextabhängig. Für Schnelldreher-Sortimente (Lebensmittel, Verbrauchsmaterial) ist die Boolean-Filter-Strategie meist sinnvoller, weil Kunden eine schnelle und vollständige Auswahl an verfügbarer Ware erwarten. Für langlebige Sortimente mit komplexer Konfiguration (Industriebedarf, technische Komponenten) ist die Ranking-Penalty-Strategie meist sinnvoller, weil Kunden die Sortimentsbreite kennen wollen und bereit sind, auf Nachschub zu warten.

Die elegantere Lösung ist eine vom Kunden steuerbare Strategie. Der Kunde aktiviert über einen Filter-Schalter "nur lieferbar" oder lässt ihn aus. Default ist die Ranking-Penalty (alle zeigen, ausverkaufte unten), Power-User wechseln auf den strikten Boolean-Filter. Das gibt dem Kunden die Kontrolle, ohne die Sortimentstransparenz zu opfern.

Die Ranking-Penalty selbst ist als kontinuierliches Signal sauber zu modellieren. Ein Faktor zwischen 0 und 1, der mit dem Textscore und den Smart-Listings-Signalen multipliziert wird. Lieferbar = 1.0, low_stock = 0.7, out_of_stock = 0.3. Diese Multiplikation senkt die Position out-of-stock-Treffer in der Liste, ohne sie ganz auszublenden. Wir haben die mathematische Mechanik dahinter in unserem Beitrag zu Textscore vs Smarte Listings im Detail erklärt. Live-ERP-Daten erweitern die Smart-Listings-Layer um einen Verfügbarkeits-Multiplikator, der den Textscore zwar nicht verändert, aber die finale Sortier-Reihenfolge nachweisbar verbessert.

Lieferzeit als Filter und Ranking-Signal

Zählt in der Trefferliste nur der Bestand oder auch die Lieferzeit?

Neben dem reinen Lagerbestand spielt die Lieferzeit in B2B- und B2C-Sortimenten eine zunehmend wichtige Rolle. Same-Day-Delivery, 24-Stunden-Lieferung, 48-Stunden-Lieferung, Standard-Lieferung in 5 bis 7 Werktagen. Eine moderne Shop-Suche muss diese Lieferzeit-Klassen sowohl als Filter als auch als Ranking-Signal beherrschen.

Als Filter funktioniert die Lieferzeit ähnlich wie der Lagerbestand. Der Kunde wählt im Sidebar-Filter "Lieferung bis morgen" oder "Lieferung diese Woche" und sieht nur die Treffer, die in dieser Zeitspanne ankommen. Die Berechnung kombiniert Lager-Standort, Cutoff-Zeit, Wochentag und Liefer-Adresse. Eine Bestellung am Mittwoch um 13:00 Uhr aus einem Lager mit 14:00-Uhr-Cutoff und 24-Stunden-Lieferung kommt am Donnerstag an. Eine Bestellung am Mittwoch um 15:00 Uhr aus demselben Lager kommt am Freitag an. Diese Berechnungs-Logik gehört in die Such-Schicht, nicht erst in den Checkout, weil sie die Trefferliste und die Lieferzeit-Anzeige steuert.

Als Ranking-Signal funktioniert die Lieferzeit ähnlich wie der Lagerbestand. Schnell verfügbare Treffer bekommen einen Boost, langsam verfügbare einen Penalty. Wenn zwei Mehlsorten textlich gleich relevant sind, aber die eine in 24 Stunden lieferbar und die andere in 5 Tagen, ranked die schnelle Lieferung höher. Der Effekt auf die Conversion-Rate ist messbar: Kunden klicken eher auf einen Treffer mit "Morgen lieferbar" als auf einen mit "Lieferung in 5 bis 7 Tagen", auch wenn die textliche Relevanz dieselbe ist.

Die Lieferzeit-Berechnung wird kompliziert, sobald der Shop mehrere Lager-Standorte hat. Ein Produkt kann in Lager A "Morgen lieferbar" sein und in Lager B "in 5 Tagen", weil Lager B im Ausland steht und längere Versand-Zeiten hat. Die Suche muss pro Treffer die schnellste verfügbare Lieferzeit ausweisen und im Filter-Verhalten konsistent bleiben. Ein Filter "Lieferung bis morgen" zeigt alle Treffer, die aus mindestens einem Lager innerhalb von 24 Stunden geliefert werden können, unabhängig davon, ob auch ein zweites Lager den Treffer in 5 Tagen liefern würde.

Die Versand-Cutoff-Zeit ist die operative Falle dieser Logik. Eine Cutoff-Zeit von 14:00 Uhr bedeutet, dass eine Bestellung um 13:59 Uhr noch heute versandt wird, eine Bestellung um 14:01 Uhr erst morgen. Die Suche muss diese Cutoff-Logik in die Lieferzeit-Berechnung einbauen und die Anzeige "Morgen lieferbar" oder "Übermorgen lieferbar" über den Tag hinweg verändern. Statische Lieferzeit-Anzeigen, die immer "in 1 Werktag" zeigen, sind in der zweiten Tageshälfte falsch und führen zu Beschwerden, wenn die Lieferung nicht wie versprochen ankommt.

Eine Geschäftsführung im Lebensmittel-B2C beschreibt den Effekt einer sauberen Lieferzeit-Logik in der Suche so:

"Die Suche von BatteryIncluded liefert genau, was unsere Kund:innen erwarten: schnelle, relevante Treffer auch bei tausenden Produkten und vielen Varianten. Sie versteht die Sprache unserer Sortimente und macht Stöbern intuitiv. Die Lieferzeit als Filter und Ranking-Signal hat unsere Bestell-Conversion in den schnellen Liefer-Klassen messbar gehoben."

Silkes Weinkeller

Die Lieferzeit ist ein Kauf-Treiber, den die meisten Shops in der Trefferliste schlechter ausspielen, als sie es könnten. Die Daten liegen im ERP, die Berechnungs-Logik ist bekannt, aber die Verbindung zur Suche fehlt. Eine entkoppelte Such-Infrastruktur schließt diese Lücke, indem sie die Lieferzeit als gleichwertigen Filter- und Ranking-Layer behandelt wie den Lagerbestand.

Mehrlagerlogik: ein Produkt, mehrere Lager

In B2B-Plattformen und in großen B2C-Shops mit mehreren Distribution-Centern entsteht die zusätzliche Frage, wie die Suche mit Mehrlager-Konstellationen umgeht. Ein Produkt kann in Lager A out-of-stock sein, in Lager B mit niedrigem Bestand verfügbar, in Lager C mit hohem Bestand verfügbar. Welchen Bestand zeigt die Suche an?

Drei Strategien sind etabliert.

Erstens die Gesamtbestand-Strategie. Die Suche summiert die Bestände aller Lager und zeigt den Gesamtbestand an. Vorteil: einfache Logik. Nachteil: die Verfügbarkeit bezieht sich nicht auf das Liefer-Lager des Kunden. Ein Produkt mit 500 Stück Gesamtbestand kann im für den Kunden zuständigen Lager trotzdem out-of-stock sein, was zu Cross-Border-Lieferzeit oder Frustrationen führt.

Zweitens die nächste-Lager-Strategie. Die Suche berechnet pro Kunden-Region das nächstgelegene Lager und zeigt nur den Bestand dieses Lagers an. Vorteil: die Verfügbarkeits-Anzeige ist regional korrekt. Nachteil: der Kunde sieht nicht, dass das Produkt in einem entfernteren Lager trotzdem verfügbar wäre, was bei kritischen Bestellungen ein verlorener Verkauf sein kann.

Drittens die hybride Cross-Warehouse-Strategie. Die Suche zeigt die Verfügbarkeit im nächsten Lager als primäre Information und das entferntere Lager als sekundäre Information mit längerer Lieferzeit-Angabe. Beispiel: "Lieferung aus Berlin in 24 Stunden" oder, falls Berlin out-of-stock ist, "Lieferung aus München in 48 Stunden". Vorteil: der Kunde sieht alle Bezugsoptionen und entscheidet selbst, ob ihm die längere Lieferzeit recht ist. Nachteil: die Pflege ist aufwendiger, weil pro Treffer mehrere Lager-Kombinationen geprüft werden müssen.

Die hybride Strategie ist in den meisten B2B-Plattformen die operativ richtige Wahl, weil sie den Sortimentsbreiten-Eindruck wahrt und gleichzeitig die regionale Verfügbarkeit transparent macht. Wir haben den verwandten Punkt zu Cross-Border-Spillover im Multi-Country-Kontext in unserem Beitrag zu Multi-Country Search-Infrastruktur detaillierter ausgeführt. Die Mehrlager-Logik innerhalb eines Marktes folgt derselben Mechanik, ohne die zusätzlichen Sprach-, Währungs- und Steuer-Faktoren.

Click-and-Collect: lokale Verfügbarkeit im Such-Filter

Lässt sich auch die Abholverfügbarkeit in der Filiale in die Suche integrieren?

Eine spezielle Mehrlager-Variante ist Click-and-Collect, also die Abholung im stationären Geschäft. Der Kunde will wissen, in welcher Filiale das Produkt sofort verfügbar ist und dort abgeholt werden kann. Aus Such-Sicht ist Click-and-Collect ein zusätzlicher Filter-Layer, der auf einen geocodierten Lager-Standort (die Filiale) abbildet.

Drei Mechaniken müssen zusammenspielen.

Erstens die Filial-Bestands-Erfassung. Pro Filiale wird der Bestand als eigener Lager-Standort geführt. Bei einer Kette mit 50 Filialen entstehen 50 Lager-Standorte plus eventuelle Zentral-Lager. Die Such-Infrastruktur muss pro Treffer die filialspezifischen Bestände kennen und filtern können.

Zweitens die Filial-Auswahl im Frontend. Der Kunde wählt seine bevorzugte Filiale (typisch über Geolocation oder über eine manuelle Auswahl). Die Such-Schicht erhält die Filial-ID und filtert die Trefferliste auf die in dieser Filiale verfügbaren Artikel oder zeigt pro Treffer einen "In Filiale verfügbar"-Badge.

Drittens die Lieferzeit-Anzeige für Click-and-Collect. "Heute abholbar ab 17:00 Uhr" oder "Morgen abholbar" je nach Bestellzeit und Filial-Cutoff. Diese Zeitanzeige ist analog zur Versand-Lieferzeit, aber sie bezieht sich auf die Bereitstellung im Geschäft und nicht auf die Lieferung an die Adresse.

Click-and-Collect verändert das Ranking-Verhalten der Suche signifikant. Ein Produkt, das in der bevorzugten Filiale sofort abholbar ist, soll höher ranken als ein Produkt, das per Versand erst übermorgen ankommt. Der Filter-Layer "nur in meiner Filiale verfügbar" wird zur dritten Achse neben Lagerbestand und Lieferzeit.

In der Praxis arbeiten viele Shops mit einer hybriden Verfügbarkeits-Anzeige. Pro Treffer werden drei Verfügbarkeits-Linien gezeigt: "Versand morgen", "Click-and-Collect heute ab 17:00 in Filiale Berlin-Mitte", "Click-and-Collect morgen in 12 weiteren Filialen". Der Kunde sieht alle Bezugsoptionen und wählt die für ihn passende. Die Suche liefert die strukturierten Informationen, das Frontend rendert sie.

Preise als Mischung aus Index und Query-Zeit

Gehören neben Beständen und Lieferzeiten auch die Preise in die Live-ERP-Integration?

Bisher haben wir uns auf Lagerbestände und Lieferzeiten konzentriert. Die dritte ERP-Datenklasse, die in der Suche relevant ist, ist der Preis. Preise unterscheiden sich strukturell von Lagerbeständen, weil sie eine Mischung aus relativ stabilen Listenpreisen und stark personalisierten effektiven Preisen sind.

Listenpreise gehören in den Index. Sie ändern sich quartalsweise oder bei Aktions-Phasen, und sie sind die Grundlage für Preis-Filter ("Preis bis 50 Euro") und Preis-Sortierung ("Aufsteigend nach Preis"). Im Index gespeichert sind sie schnell abfragbar, die Cache-Effizienz ist hoch.

Personalisierte Preise gehören in die Query-Zeit. B2B-Kunden mit individuellen Konditionen, Mengen-Rabatten, Vertrags-Preisen, regionalen Aktions-Preisen sehen einen anderen effektiven Preis als der Listenpreis. Diese Personalisierung gehört nicht in den Index, weil sie pro Kunde unterschiedlich ist und der Index sonst pro Kunde dupliziert werden müsste. Stattdessen berechnet die Such-Schicht zur Query-Zeit den effektiven Preis, indem sie den Listenpreis aus dem Index mit den kunden-spezifischen Konditionen verrechnet.

Die zweite Index-vs-Query-Time-Entscheidung betrifft den Brutto-Preis. Ein Nettopreis wird im Index gespeichert, der Brutto-Preis wird mit dem markt-spezifischen Mehrwertsteuersatz zur Query-Zeit berechnet. Alternativ wird der Brutto-Preis bei der Indexierung berechnet und im Index gespeichert. Die Wahl hängt von der Häufigkeit der Steuersatz-Änderungen ab. Stabile Steuersätze rechtfertigen die Indexierung, häufige Sondersätze oder Aktions-Steuern rechtfertigen die Query-Zeit-Berechnung.

Die dritte Index-vs-Query-Time-Entscheidung betrifft die Aktions-Preise. Ein Aktions-Preis mit klar definiertem Gültigkeits-Fenster (Black Friday Wochenende, Sommer-Sale-Monat) kann im Index gespeichert werden, mit einem Gültigkeits-Zeitstempel. Die Such-Schicht prüft zur Query-Zeit, ob der Aktions-Preis aktiv ist, und zeigt ihn dann an Stelle des Listenpreises. Diese Logik gehört in die Such-Schicht, weil sie sonst pro Frontend separat implementiert werden müsste und inkonsistent gerendert würde.

Die Praxis-Antwort ist eine Mischung aller drei Pattern. Listenpreis und Aktions-Preis im Index, mit Gültigkeits-Zeitstempel. Brutto-Preis-Berechnung bei der Indexierung (für stabile Steuersätze) oder zur Query-Zeit (für volatile). Personalisierte B2B-Konditionen zur Query-Zeit, aus einer kunden-spezifischen Konditions-Tabelle, die in der Such-Schicht als Lookup angebunden ist.

Cold-Start: was passiert bei neuen SKUs

Wie behandelt die Suche ein Produkt, das noch keine Klick- und Verkaufsdaten hat?

Eine unterschätzte Architektur-Frage betrifft die Behandlung neuer SKUs. Wenn ein Produkt zum ersten Mal ins Sortiment kommt, hat der Index noch keine Such-Statistik, keine Klick-Daten, keine Bewertungs-Signale. Das Smart-Listings-Modell, das normalerweise das Ranking verbessert, hat für neue SKUs nichts zu tun.

Die Standard-Antwort ist das Cold-Start-Boost-Pattern. Neue SKUs bekommen für einen definierten Zeitraum (typisch 14 bis 30 Tage) einen Ranking-Boost, der sie auf der Trefferseite künstlich nach oben zieht. Damit werden sie sichtbar, sammeln Klicks und Conversion-Daten, und das Smart-Listings-Modell hat nach Ablauf der Boost-Phase belastbare Signale für das reguläre Ranking.

Der Cold-Start-Boost ist nicht ohne Risiko. Wenn die SKU schlecht produziert ist (schlechte Bilder, schlechte Beschreibung, falsche Kategorie), führt der Boost zu vielen Klicks ohne Conversion und schadet der Trefferqualität für die nächsten Kunden. Eine Pre-Production-Qualitätsprüfung der SKU-Stammdaten ist daher Voraussetzung für sinnvolles Cold-Start-Boosting.

Im ERP-Kontext kommt eine zweite Cold-Start-Frage hinzu. Wenn eine SKU zum ersten Mal ins Sortiment kommt, ist der Lagerbestand initial 0 oder klein. Eine reine Bestands-basierte Ranking-Penalty würde die neue SKU nach unten drücken, bevor sie überhaupt sichtbar war. Die Cold-Start-Logik muss daher den Bestands-Penalty für neue SKUs temporär aussetzen oder mit dem Boost-Faktor kombinieren.

Eine pragmatische Lösung kombiniert beide Mechaniken. Neue SKUs bekommen für 14 Tage einen Sichtbarkeits-Boost, unabhängig vom Lagerbestand. Nach 14 Tagen läuft der Boost aus, und die regulären Ranking-Signale (inklusive Bestands-Penalty) übernehmen. Damit haben neue Produkte eine faire Chance auf Sichtbarkeit, und der Lagerbestand-Penalty greift erst, wenn echte Verkaufsdaten vorliegen.

DSGVO und Cookieless im ERP-Sync

Ist der ERP-Sync in die Suche datenschutzrechtlich unbedenklich?

Die ERP-Sync-Pipeline ist datenschutzrechtlich heikel, wenn nicht von Anfang an sauber gedacht. Das ERP enthält neben Produktdaten häufig auch personenbezogene Daten: Kundendaten in den Bestellungen, Vertriebs-Daten in den Konditionen, Lieferadressen in den Versand-Daten. Wenn der ERP-Sync naiv "alles, was sich ändert" in den Index pumpt, kann ungewollt eine Kunden-Datenbank in der Such-Infrastruktur entstehen, die DSGVO-rechtlich gar nicht da sein darf.

Die saubere Lösung ist eine schmale Sync-Definition. Es gehören in den Index nur produktbezogene Daten: Lagerbestand pro Lager-Standort (ohne Bezug zu konkreten Bestellungen), Lieferzeit als abgeleitete Größe, Listenpreis und Aktions-Preis, Verfügbarkeits-Status, Sperr-Flags. Keine Kunden-IDs, keine Bestellnummern, keine personenbezogenen Konditions-Markierungen.

Die personalisierten B2B-Konditionen, die zur Query-Zeit verrechnet werden, kommen aus einer separaten Konditions-Tabelle, die nur die Kunde-Produkt-Preis-Relation enthält und keine über die Authentifizierung hinausgehenden personenbezogenen Daten. Die Such-Schicht authentifiziert den Kunden über das Shop-Login, holt die Konditionen aus der Konditions-Tabelle und verrechnet sie mit den Index-Daten. Es entsteht kein User-Tracking, kein Profil-Aufbau, keine Verhaltens-Speicherung.

Diese Architektur ist strukturell cookieless und DSGVO-konform. Die Suche arbeitet auf Produktdaten und auf der aktuellen Anfrage. Sie speichert keine User-IDs, baut keine Profile auf, trackt nicht über Sitzungen hinweg. Im Vergleich zu Tracking-basierten Personalisierungslösungen ist diese strukturelle Konformität ein Wettbewerbsvorteil, weil sie ohne Cookie-Banner und ohne Opt-In-Hürden funktioniert.

Made in Germany als Hosting-Standort verstärkt das Argument im DACH-Markt zusätzlich, weil Behörden, Versicherer und mittelständische Auftraggeber zunehmend explizit nach europäischer Datenhaltung fragen. Wir haben die Mechanik der DSGVO-konformen KI-Datenverarbeitung über aggregierte Signale in unserem Beitrag zu Search-Merchandising im Backend erläutert. Im ERP-Sync-Kontext gilt dasselbe Prinzip: Aggregate aus Klick- und Conversion-Daten verbessern das Ranking, ohne dass die Suche jemals individuelle Nutzer-Profile aufbaut.

Die entkoppelte Such-Infrastruktur als ERP-Bus

Wie lässt sich die Komplexität der vielen ERP-Datenklassen in der Suche bündeln?

Die strategische Antwort auf die Komplexität der ERP-Daten in der Suche ist eine entkoppelte Infrastruktur, in der die Such-Schicht als eigenständiger Layer zwischen Shop-Frontend und ERP/PIM/WMS steht. Sie übernimmt die Live-Sync, die Lagerbestand-Filterung, die Lieferzeit-Berechnung, die Preis-Verrechnung, die Mehrlager-Logik. Das Shop-Backend liefert die Stammdaten und die Bewegungsdaten, ohne sich um die Such-Mechanik zu kümmern. Das Frontend stellt nur die Anfragen und rendert die Trefferliste.

In dieser Architektur ist die Such-Infrastruktur der Daten-Bus, über den die ERP-Realität in den Shop kommt. Sie konsumiert Streams aus dem ERP, persistiert sie in einem für Such-Operationen optimierten Index, reichert sie mit semantischen Signalen an, gibt sie als strukturierte Antworten an das Frontend zurück. Das Shop-Backend wird von der Such-Last entlastet, das ERP von wiederholten Lese-Anfragen geschont, das Frontend bekommt eine schnelle und konsistente Datenquelle.

Volt Search® von BatteryIncluded ist als solche Such-Infrastruktur konzipiert. Die ERP- und PIM-Sync-Pipelines werden über standardisierte Konnektoren angebunden, die die typischen E-Commerce-Plattformen (Shopware, Magento, WooCommerce) und die häufigen ERP-Systeme out of the box unterstützen. Lagerbestände kommen wahlweise per Webhook, Polling oder Stream rein, je nach Volatilität und ERP-Fähigkeiten. Lieferzeiten werden anhand der konfigurierten Lager-Standorte und Cutoff-Zeiten berechnet. Preise werden als Mischung aus Index-Speicherung und Query-Zeit-Berechnung behandelt, je nach Personalisierungs-Anforderung.

Die operative Konsequenz für ein DACH-Unternehmen ist, dass die Live-ERP-Integration in der Suche kein internes Engineering-Projekt ist, sondern eine Konfigurations-Aufgabe. Eine neue Lager-Aktivierung dauert nicht Wochen, sondern Tage. Eine Sortimentsänderung wirkt sich nicht auf die Stabilität anderer Daten-Pipelines aus. Eine Bestands-Volatilität in der Black-Friday-Phase skaliert über die Stream-Pipeline, ohne dass das Shop-Backend einen Performance-Einbruch hat.

Eine Geschäftsführung im DACH-Großhandel beschreibt den Effekt einer entkoppelten Such-Infrastruktur mit Live-ERP-Daten so:

"Die Produktsuche ist kein Extra, sie ist der erste Kontakt mit unseren Kund:innen. Mit BatteryIncluded haben wir bei Wurm die Kontrolle zurückgewonnen: bessere Relevanz, weniger Pflege, mehr Wirkung. Jetzt kann der Vertrieb die Suche ohne IT steuern, Marketingaktionen greifen durch und der Shop wirkt wie aus einem Guss. Eine strategisch richtige Entscheidung."

G. Wurm GmbH + Co. KG

Die Aussage "der Shop wirkt wie aus einem Guss" ist genau das, was eine sauber integrierte ERP-Sync-Pipeline für die Suche leisten muss. Der Kunde sieht eine Trefferliste, in der jeder Treffer eine reale Bestell-Option ist, mit korrektem Preis, korrekter Verfügbarkeit, korrekter Lieferzeit. Die operative Realität des Unternehmens kommt im Shop an, ohne dass das Frontend dafür separat verkabelt werden muss.

Die Hybrid LLM Search ergänzt diese Architektur um eine semantische Schicht, die die Anfragen versteht und mit den ERP-Daten verschneidet. Eine Anfrage "Mehl 1kg verfügbar in Berlin" wird semantisch interpretiert (Suche nach Weizen-, Dinkel- oder Reismehl in 1-Kilo-Packung, das im Berlin-Lager verfügbar ist), unabhängig davon, ob die Produktnamen im Index "Weizenmehl Type 405 1 kg" oder "Mehl Weizen 1000g" lauten. Die semantische Schicht reduziert den Pflege-Aufwand für Synonym-Listen und macht die ERP-Filter auch für komplexe natürlichsprachliche Anfragen brauchbar. Ein verwandter Punkt zur Einheiten-Normalisierung in Produktdaten (1000g vs 1kg, ml vs Liter, mm vs cm) wird in einem kommenden Beitrag der Reihe vertieft.

Was Sie diese Woche tun können

Wo setzen Sie an, wenn Ihre Suche die Bestände bisher nur nachts aktualisiert?

Live-ERP-Daten in der Shop-Suche sind keine Projektphase, die nebenbei läuft. Sie sind eine Architektur-Entscheidung mit Konsequenzen für Sync-Frequenz, Cluster-Last, Preis-Logik, Lieferzeit-Berechnung und DSGVO-Konformität. Wenn Sie heute mit einer nächtlich indexierten Suche arbeiten und die operative Realität Ihres Sortiments nicht auf der Trefferseite ankommt, ist die folgende Reihenfolge der pragmatischste Einstieg.

Schritt eins ist die Volatilitäts-Analyse Ihres Sortiments. Erheben Sie aus den Bestellungs-Logs der letzten 90 Tage, welche SKUs welche Umschlagshäufigkeit haben. Welche SKUs sind Top-Seller mit über 50 Bestellungen pro Tag? Welche sind Mittelvolumen? Welche sind Long-Tail? Die Antworten bestimmen, welche Sync-Pattern für welches Segment angemessen sind.

Schritt zwei ist die Lagerbestand-Sync-Diagnose. Wie aktuell sind Ihre Bestände im aktuellen Index? Wann wird der Index neu gebaut? Wie viel Verzug haben Ihre Lager-Daten zwischen ERP und Shop? Wie viele Storno-Quoten gehen auf "im Checkout nicht mehr verfügbar" zurück? Die Antworten zeigen, wo die größten Konsistenz-Probleme liegen.

Schritt drei ist die Lieferzeit-Logik-Analyse. Berechnet Ihre aktuelle Suche überhaupt Lieferzeiten? Berücksichtigt sie Cutoff-Zeiten, Lager-Standorte, Wochentage? Können Kunden nach Lieferzeit filtern und sortieren? Die Antworten zeigen, ob die Lieferzeit als Filter und Ranking-Signal aktuell ausgespielt wird oder ob hier ein blinder Fleck mit Conversion-Verlust besteht.

Schritt vier ist die Mehrlager-Bestandsaufnahme. Wie viele Lager-Standorte führen Sie? Werden die Bestände pro Lager separat indexiert? Wie regelt Ihre Suche Cross-Warehouse-Verfügbarkeiten? Falls Sie Click-and-Collect anbieten: ist der Filial-Bestand in der Suche abgebildet?

Schritt fünf ist die Preis-Logik-Analyse. Welche Preise sind im Index gespeichert (Listenpreise, Aktions-Preise, Brutto, Netto)? Welche werden zur Query-Zeit berechnet (B2B-Konditionen, regionale Mehrwertsteuer)? Funktioniert der Preis-Filter und die Preis-Sortierung für eingeloggte B2B-Kunden mit individuellen Konditionen?

Schritt sechs ist der Pilot-Test. Wählen Sie ein Sortimentssegment mit hoher Volatilität (etwa Aktions-Artikel, Lebensmittel mit kurzem Mindesthaltbarkeitsdatum, Saisonware) und bauen Sie dort die Live-ERP-Sync prototypisch nach Webhook- oder Stream-Pattern um. Messen Sie zwei Wochen lang Bestands-Konsistenz, Checkout-Storno-Quote und Trefferqualität gegen die alte Lösung. Das ist Ihr A/B-Test für die Architektur-Investition. Wenn der Pilot überzeugt, rollen Sie die Architektur auf die anderen Segmente aus.

Diese sechs Schritte sind in jedem Fall sinnvoll, unabhängig davon, ob Sie später auf eine vollständige spezialisierte Such-Infrastruktur wechseln oder Ihre vorhandene Lösung optimieren. Was sie nicht ersetzen können, ist die operative Reife einer dedizierten Search-Plattform, die die Sync-Pattern out of the box konfigurierbar macht, die Lieferzeit-Berechnung als Plattform-Funktion mitbringt und die Mehrlager- und Click-and-Collect-Logik standardisiert anbindet.

Häufige Fragen (FAQ)

Warum kennt die Standard-Shop-Suche keine Live-Lagerbestände?

Die meisten herkömmlichen Such-Lösungen sind als Volltext-Engine für statische Produktdaten gebaut. Sie indizieren Produktnamen, Beschreibungen und Kategorien, die sich selten ändern, der Index wird typisch einmal pro Nacht neu gebaut. Lagerbestände, Lieferzeiten und Preise dagegen ändern sich stündlich, manchmal minütlich. Drei strukturelle Probleme treten auf: die Index-Update-Frequenz reicht nicht, die Update-Last bei stündlichen Bestands-Updates überfordert klassische Cluster, und die Konsistenz zwischen Index und Quellsystem läuft auseinander, was zu Phantom-Beständen und Checkout-Stornos führt. Die operative Antwort ist eine entkoppelte Such-Infrastruktur, die die Live-Daten aus dem ERP nicht als statisches Index-Feld, sondern als parallel laufende Datenquelle behandelt.

Welche Sync-Pattern eignen sich für Live-Lagerbestände?

Vier Sync-Pattern haben sich in der Praxis etabliert. Erstens nächtliche Batch-Pushes: operativ einfach, aber führt zu Konsistenz-Problemen bei volatilen Sortimenten. Zweitens Webhook-getriebene Updates: nahezu live, aber benötigt zuverlässige Endpunkte und Deduplizierungs-Logik. Drittens Polling: robust gegen verlorene Events, aber teurer in der ERP-Last. Viertens Streaming über Event-Bus wie Kafka: robusteste Lösung, aber operativ am aufwendigsten. In der Praxis kombinieren erfolgreiche Shops mehrere Pattern. Stammdaten kommen per Batch, Top-Seller-Bestände per Stream oder Webhook, Long-Tail-Bestände per Polling oder Batch. Die Segmentierung nach Umschlagshäufigkeit halbiert die Streaming-Last und verdoppelt die operative Robustheit.

Wie schnell muss "live" in der Suche eigentlich sein?

Die Antwort hängt von der Volatilität und dem geschäftlichen Risiko pro SKU ab. Für Top-Seller mit über 50 Bestellungen pro Tag sind Sekunden-Latenzen sinnvoll, weil Bestände sonst innerhalb des Sync-Fensters auseinanderlaufen. Für mittelvolumige Sortimente reichen Minuten-Latenzen. Für Long-Tail-Sortimente mit wenigen Bestellungen pro Woche sind Stunden- oder Tages-Latenzen unkritisch. Eine pragmatische Strategie segmentiert das Sortiment nach Umschlagshäufigkeit und ordnet jedem Segment ein Sync-Pattern zu. Top-Seller per Stream, Mittelvolumen per Webhook oder Polling, Long-Tail per Batch.

Soll die Suche out-of-stock-Produkte ausblenden oder runter-ranken?

Beide Strategien haben Vor- und Nachteile. Die Boolean-Filter-Strategie blendet ausverkaufte Produkte aus, was eine kurze und kauf-bereite Trefferliste produziert, aber das Sortimentsbild verarmt. Die Ranking-Penalty-Strategie zeigt das volle Sortiment, rankt aber ausverkaufte Treffer nach unten und kennzeichnet sie deutlich ("Bald wieder verfügbar"). Für Schnelldreher-Sortimente ist die Boolean-Filter-Strategie meist sinnvoller. Für langlebige Sortimente mit komplexer Konfiguration ist die Ranking-Penalty-Strategie meist sinnvoller. Die elegantere Lösung ist ein vom Kunden steuerbarer Filter "nur lieferbar", mit Default-Verhalten der Ranking-Penalty.

Wie funktioniert die Lieferzeit als Filter und Ranking-Signal?

Als Filter ermöglicht die Lieferzeit dem Kunden, im Sidebar zu wählen "Lieferung bis morgen" oder "Lieferung diese Woche", und nur Treffer zu sehen, die in dieser Zeitspanne ankommen. Die Berechnung kombiniert Lager-Standort, Cutoff-Zeit, Wochentag und Liefer-Adresse. Als Ranking-Signal bekommen schnell verfügbare Treffer einen Boost und langsam verfügbare einen Penalty. Wenn zwei Produkte textlich gleich relevant sind, ranked das schneller lieferbare höher. Die Lieferzeit-Berechnung wird komplex, sobald der Shop mehrere Lager-Standorte hat, weil pro Treffer die schnellste verfügbare Lieferzeit ausgewiesen werden muss. Die Versand-Cutoff-Zeit ist die operative Falle: eine Anzeige "Morgen lieferbar" wird in der zweiten Tageshälfte falsch und muss über den Tag hinweg dynamisch nachgeführt werden.

Wie geht eine Shop-Suche mit Mehrlager-Konstellationen um?

Drei Strategien sind etabliert. Die Gesamtbestand-Strategie summiert die Bestände aller Lager (einfach, aber regional unscharf). Die nächste-Lager-Strategie zeigt nur den Bestand des nächstgelegenen Lagers (regional präzise, aber Cross-Warehouse-Verkäufe verloren). Die hybride Cross-Warehouse-Strategie zeigt die Verfügbarkeit im nächsten Lager als primäre Information und das entferntere Lager als sekundäre Information mit längerer Lieferzeit-Angabe. Die hybride Strategie ist in den meisten B2B-Plattformen die operativ richtige Wahl, weil sie den Sortimentsbreiten-Eindruck wahrt und gleichzeitig die regionale Verfügbarkeit transparent macht. Click-and-Collect ist eine spezielle Mehrlager-Variante, bei der pro Filiale ein eigener Lager-Standort geführt wird und der Kunde "in meiner Filiale verfügbar" als Filter und Ranking-Signal nutzt.

Wo gehören Preise im Such-System hin: Index oder Query-Zeit?

Eine Mischung. Listenpreise und Aktions-Preise gehören in den Index, weil sie relativ stabil sind und Preis-Filter und Preis-Sortierung schnell halten. Personalisierte B2B-Konditionen gehören in die Query-Zeit, weil sie kunden-individuell sind und der Index sonst pro Kunde dupliziert werden müsste. Brutto-Preise können wahlweise bei der Indexierung (für stabile Steuersätze) oder zur Query-Zeit (für volatile) berechnet werden. Die Such-Schicht muss markt- und kunde-aware sein und die richtige Preisspalte pro Anfrage adressieren. Personalisierte Konditionen kommen aus einer separaten Konditions-Tabelle, die nur die Kunde-Produkt-Preis-Relation enthält und keine darüber hinausgehenden personenbezogenen Daten.

Ist die ERP-Sync-Pipeline DSGVO-konform?

Wenn von Anfang an sauber gedacht: ja. Die saubere Lösung ist eine schmale Sync-Definition. In den Such-Index gehören nur produktbezogene Daten: Lagerbestand pro Lager-Standort, Lieferzeit, Listenpreis, Aktions-Preis, Verfügbarkeits-Status, Sperr-Flags. Keine Kunden-IDs, keine Bestellnummern, keine personenbezogenen Konditions-Markierungen. Personalisierte Konditionen werden zur Query-Zeit aus einer separaten Konditions-Tabelle verrechnet, ohne dass die Suche User-Tracking oder Profil-Aufbau betreibt. Diese Architektur ist strukturell cookieless und DSGVO-konform und arbeitet ohne Cookie-Banner und ohne Opt-In-Hürden. Made in Germany als Hosting-Standort verstärkt das Argument im DACH-Markt zusätzlich.

Bereit für eine Shop-Suche, die ERP-Daten als gleichwertigen Layer behandelt?

Eine sauber aufgesetzte Live-ERP-Integration in der Shop-Suche kombiniert eine differenzierte Sync-Strategie pro Sortimentssegment, eine konsistente Lagerbestand-Anzeige als Boolean-Filter und Ranking-Signal, eine berechnete Lieferzeit mit Cutoff-Logik, eine saubere Mehrlager- und Click-and-Collect-Mechanik, eine durchdachte Preis-Architektur aus Index- und Query-Zeit-Komponenten und eine schmale DSGVO-konforme Sync-Definition ohne personenbezogene Daten. Wer hier sauber baut, gewinnt Conversion-Rate über das gesamte Sortiment, weil jeder Treffer eine reale Bestell-Option ist, mit korrektem Preis, korrekter Verfügbarkeit, korrekter Lieferzeit. Volt Search® von BatteryIncluded ist als entkoppelte Infrastruktur konzipiert, die die ERP-, PIM- und WMS-Daten als Live-Strom konsumiert und in einen für Such-Operationen optimierten Index überführt. Hybrid LLM Search ergänzt die semantische Schicht, die natürlichsprachliche Anfragen mit den ERP-Filtern verschneidet. Cookieless, DSGVO-konforme KI, Made in Germany, ohne dass Sie eigene Stream-Pipelines bauen oder pro Lager-Standort ein eigenes Cluster betreiben müssen.

Zu Ihrer kostenlosen Demo und erleben Sie live an Ihren eigenen Produktdaten, wie Volt Search® die Lagerbestände aus Ihrem ERP in der Trefferliste als Filter und Ranking-Signal verwendet, wie die Lieferzeit-Berechnung pro Lager-Standort sauber funktioniert, wie die Mehrlager-Logik die Sortimentsbreite und die regionale Verfügbarkeit gleichzeitig transparent macht und wie die Preis-Architektur Listenpreise im Index und B2B-Konditionen zur Query-Zeit korrekt verrechnet. Ohne eigene Sync-Pipelines, ohne User-Tracking, ohne lange Setup-Phase.