In B2B-Implementierungen sehen wir immer dieselbe Schlüsselszene: Zwei Einkäufer öffnen denselben Shop, tippen denselben Suchbegriff — und sehen unterschiedliche Trefferlisten, unterschiedliche Preise, manchmal sogar unterschiedliche Produkte. Das ist kein Fehler im System, das ist die Anforderung. Im B2B definiert der Vertrag, welches Sortiment sichtbar ist; die Pricing-Engine, welcher Preis gilt; das ERP, welcher Bestand greift. Die Suche ist das Frontend, an dem diese drei Welten zusammenkommen müssen — synchron, performant und nachvollziehbar. In diesem Beitrag zeigen wir drei Implementierungs-Muster für kundenspezifische Suchindizes, wie Kontraktpreise sichtbar in Trefferlisten landen, und welche Sync-Strategien zwischen ERP, PIM und Suchindex tragen. Wer einen Schritt weiter zurück will — wie die Daten-Foundation in der B2B-Industrie aussieht, die solche Setups speist — findet das im Beitrag Daten-Foundation für B2B-Industrie.
Drei Muster für kundenspezifische Suchindizes
Wer kundenindividuelle Sortimente abbilden will, hat im Kern drei architektonische Optionen — und keine davon ist universell richtig. Die Wahl entscheidet sich an Sortimentsgröße, Anzahl der Kundengruppen, Vertragsdynamik und Performance-Budget.
Muster 1: Multi-Tenant-Indizes — ein Index pro Kundengruppe. Jede Kundengruppe (oder im Extremfall jeder Großkunde) erhält einen eigenen Index, der ausschließlich das für sie sichtbare Sortiment enthält. Der Vorteil: Eine Suchanfrage trifft nur den relevanten Index, ohne nachgelagerte Sichtbarkeits-Filter. Das skaliert in Performance — bis zur Index-Explosion. Wer mehrere tausend Kunden mit jeweils eigenem Sortiment hat, stößt schnell an die Grenzen der Cluster-Metadata, wie Elastic in seinem Leitfaden zu Multi-Tenancy mit Elasticsearch und OpenSearch ausführlich beschreibt.
Muster 2: Filtered Index — gemeinsamer Index mit Sichtbarkeits-Filter. Ein einziger Index enthält das Gesamtsortiment; jedes Produktdokument trägt eine Liste der berechtigten Kundengruppen, Business Units oder Vertragsnummern. Zur Suchzeit wird ein Filter-Prädikat ("visibility_groups contains $customerGroup") an die Query angehängt. Das skaliert in der Anzahl der Kunden problemlos, erkauft sich die Skalierung aber mit zwei Lasten: Jedes Produkt-Update muss alle berechtigten Kunden-Gruppen pflegen, und die Trefferlisten-Sortierung muss damit umgehen, dass für unterschiedliche Kunden unterschiedliche Subsets relevant sind.
Muster 3: Server-Side Re-Ranking. Die Suche liefert ein Roh-Result-Set; eine Re-Ranking-Schicht hinter dem Index entscheidet, welche Treffer für den angemeldeten Einkäufer sichtbar sind, in welcher Reihenfolge sie ausgespielt werden und welcher Preis daneben steht. Das Muster ist die flexibelste Option — es entkoppelt Entitlement-Logik vom Index — und gleichzeitig die kritischste in Latenz und Last. Wer hier baut, kauft sich Architektur-Freiheit zum Preis von Antwortzeiten, die unter Beobachtung gehören.
In B2B-Projekten bei foobar Agency sehen wir am häufigsten Mischformen: ein gemeinsamer Index für das Standard-Sortiment plus dedizierte Indizes für die zehn bis fünfzig größten Kunden mit stark individuellen Sortimenten. Das ist die Variante, die in den seltensten Fällen "elegant" ist — aber in den meisten Fällen trägt.
Kontraktpreise sichtbar machen — Pre-Compute oder Live-Call
Sobald kundenspezifische Sortimente stehen, kommt die zweite, häufig schwierigere Frage: Welcher Preis steht neben dem Treffer? Im B2B sind Listenpreise eine fiktive Größe — was gilt, ist der Vertrag. Filter ("Preis aufsteigend"), Sortierung und das Vertrauen in die Trefferliste hängen direkt daran. Es gibt zwei tragfähige Architektur-Pfade.
Pfad A: Pre-Compute — Preise wandern in den Index. Kontraktpreise werden vorberechnet und kunden- oder kundengruppen-spezifisch in den Suchindex geschrieben. Die Trefferliste rendert in derselben Anfrage, in der sie auch die Produkte holt. Performance ist hervorragend; die Belastung verschiebt sich auf den Sync-Pfad. Bei tausenden Kunden mit individuellen Konditionen wächst der Index entsprechend, und jede Preisänderung im ERP erzeugt eine Welle von Re-Indexings. Algolia dokumentiert diesen Ansatz für B2B-Szenarien explizit über segment- oder buyer-spezifische Preisfelder; vergleichbare Patterns sind in Elastic-Setups gängig.
Pfad B: Live-Call zur Suchzeit — Preise aus der Pricing-Engine. Die Suche liefert nur die Produktinformationen; ein Pricing-Service oder das ERP wird zur Suchzeit angefragt und liefert die finalen Preise. Vorteil: kein Index-Bloat, immer aktuelle Preise. Nachteil: jeder Sucht-Request erzeugt einen synchronen Call gegen die Pricing-Engine — bei großen Trefferlisten mit Pagination ist das die Stelle, an der Latenzen kippen. In der Praxis wird dieser Pfad fast immer durch einen Caching-Layer entlastet, etwa Redis mit kurzer TTL pro Kunde-Produkt-Kombination.
Welcher Pfad trägt, hängt an drei Hebeln: Volatilität der Preise (ändern sich Kontrakte täglich oder quartalsweise?), Anzahl der Kunden mit individuellen Preisen, und die Anforderung an Echtzeit-Konsistenz (sieht der Einkäufer den Preis, der im Warenkorb fällig wird?). Eine valide dritte Option gibt es nicht: Listenpreise in der Suche zeigen und im Warenkorb korrigieren ist der schnellste Weg, das Vertrauen in den Shop zu verspielen.
ERP- und PIM-Anbindung: Wie aktuell ist aktuell genug?
Die Suche ist nur so gut wie der Sync, der sie speist. Drei Sync-Strategien stehen in B2B-Setups regelmäßig zur Wahl — sie unterscheiden sich in Latenz, Implementierungs-Aufwand und der Konsistenz, die sie garantieren können.
Event-driven Sync. ERP und PIM publishen Änderungen über einen Message-Broker (Kafka, RabbitMQ, AWS SNS/SQS); ein Consumer schreibt in den Suchindex. Latenz: typischerweise Sekunden bis sub-Minute. Voraussetzung: Die Quellsysteme können Events erzeugen — was bei modernen ERPs gegeben, bei älteren SAP-ECC-Setups oft nur über Middleware machbar ist.
Change Data Capture (CDC). Die Änderungen werden direkt aus den Transaktions-Logs der Datenbank gelesen — log-basiertes CDC mit Werkzeugen wie Debezium ist der Industriestandard. Latenz liegt im Sekunden- bis Minutenbereich, bei minimaler Belastung des Quellsystems. CDC ist die pragmatische Wahl, wenn die Quelle keine sauberen Domain-Events liefert, aber Sie nicht stundenweise nachhinken wollen. Die dbt-Labs-Übersicht zu Data-Movement-Patterns positioniert CDC explizit zwischen Batch und Streaming als das Muster, das in der Praxis am häufigsten trägt.
Batch / Scheduled Sync. Klassischer nächtlicher Full- oder Delta-Import. Latenz: Stunden bis Tage. Für stabile Stammdaten (Maße, Norm-Bezeichnungen, Konstruktions-Attribute) völlig ausreichend; für Preise und Bestände selten. Wer Bestände nur einmal pro Nacht synct, produziert Aufträge auf nicht mehr verfügbare Ware — das ist der Punkt, an dem die Suche das Vertrauen verliert, nicht das ERP.
In den meisten B2B-Implementierungen sehen wir eine Mischarchitektur: Batch für die Produkt-Stammdaten aus dem PIM (täglich, manchmal mehrfach), CDC oder Event-driven für Preise und Bestände aus dem ERP (sub-Minute). Welche Frequenz für welches Feld trägt, ist eine Entscheidung pro Feld — nicht pro System. Das gehört in die Architektur-Skizze, nicht in die Sprint-Backlog.
Wenn diese Sync-Architektur über Snowflake als zentrale Daten-Plattform laufen soll — was wir bei B2B-Industrie-Kunden regelmäßig empfehlen — finden Sie die Vertiefung im Beitrag Daten-Foundation für B2B-Industrie.
Fünf Fallen bei kundenspezifischen Suchindizes
Diese fünf Fehler tauchen in Architektur-Audits regelmäßig auf — und kosten in der Regel deutlich mehr als ein sauberer Entwurf vorab.
# | Falle | Was passiert | Was es kostet |
1 | Sichtbarkeits-Filter erst im Frontend | Der Index liefert das Gesamtsortiment, das UI versteckt unsichtbare Treffer | Falsche Trefferzahlen, falsche Sortierungen, latente Datenleaks |
2 | Listenpreis im Index, Kontraktpreis im PDP | Sortierung "Preis aufsteigend" produziert kunden-individuell falsche Reihenfolgen | Reklamationen, manuelle Korrekturen im Vertrieb |
3 | Multi-Tenant-Index ohne Index-Lifecycle | Hunderte Indizes wachsen unkontrolliert, Cluster-Metadata kippt | Performance-Einbruch, ungeplante Reindex-Migrationen |
4 | ERP-Sync ohne Idempotenz | Doppelt verarbeitete Events lassen Indizes auseinanderdriften | Schleichende Inkonsistenzen, schwer reproduzierbare Bugs |
5 | Vertretungsregeln / Stellvertreter ignoriert | Wer für einen Kollegen einkauft, sieht das eigene statt das vertretene Sortiment | Falsche Bestellungen, Schatten-Workflows per Telefon |
Customer-specific Search ist der Punkt, an dem B2B-eCommerce vom Katalog-Frontend zur echten Vertragsschnittstelle wird. Unsere Kunden sortieren diese Frage genau dann, wenn der erste Großkunde eine personalisierte Sicht erwartet — und merken im selben Moment, dass die Antwort an drei Stellen gleichzeitig hängt: Index, Pricing, Sync. Wer das jetzt sauber baut, macht die nächsten Vertrags-Eskalationen in der IT lösbar, nicht im Vertrieb.
Häufig gestellte Fragen
Die Antwort hängt am Vertragstyp. Stammkunden mit jährlich verhandelten Konditionen brauchen keine Sekunden-Aktualität — ein nächtlicher Sync reicht. Projektgeschäft mit täglich verhandelten Preisen, Spot-Konditionen oder dynamischen Mengenrabatten dagegen verlangt sub-Minute. In Mischsortimenten lohnt eine Differenzierung pro Produktkategorie: stabile Stammdaten batchweise, volatile Preise event-driven. Wichtiger als die absolute Frequenz ist, dass der Preis in der Trefferliste exakt dem entspricht, der im Warenkorb gilt.
Die Skalierungsgrenze liegt selten im Index selbst, sondern im Sync-Pfad und in der Entitlement-Logik. Multi-Tenant-Indizes skalieren bis in den niedrigen vierstelligen Bereich an Tenants gut; darüber hinaus überwiegen die Vorteile eines Filtered-Index. Bei Kontraktpreisen ist die kritische Größe das Produkt aus Anzahl Kunden mal Anzahl Artikel mit individueller Preisbildung — sobald das in den zweistelligen Millionenbereich wächst, lohnt sich eine Segmentierung in Preisgruppen statt vollständig individueller Konditionen.
Im B2B-Alltag arbeiten Einkäufer regelmäßig "im Auftrag von" — etwa wenn ein zentraler Einkauf für mehrere Standorte bestellt oder ein Vertreter eine Krankheits-Vertretung übernimmt. Die Suche muss in diesem Fall den effektiven Kontext (für welches Account, welche Business Unit, welche Vertragsnummer wird gerade gesucht?) auswerten, nicht nur die User-ID des eingeloggten Mitarbeiters. Plattformen wie commercetools und Spryker modellieren das über Business Units und Account-Wechsler im UI; die Suche muss diesen Kontext über jeden Request mittragen und im Index respektieren.
Architektur-Workshop kundenspezifische Suche
In einem zweistündigen Workshop klären wir mit Ihnen, welches Index-Muster zu Ihrer Kundenstruktur passt, wie Kontraktpreise sichtbar werden und welche Sync-Strategie zwischen ERP, PIM und Suche trägt — entlang Ihrer Plattform und Ihrer Vertragslandschaft.
Matthias Dietrich
Co-CEO
Matthias Dietrich ist Gründer und Co-Geschäftsführer der foobar Agency und begleitet seit über 20 Jahren Commerce-Projekte für Retailer und Hersteller im DACH-Raum, 2024 ausgezeichnet mit dem 1. Platz beim E-Commerce Germany Award. Als ehemaliger Entwickler weiß er, dass KI erst dann wirkt, wenn sie an den Systemen und Prozessen eines Unternehmens ansetzt. Heute beschäftigt ihn, wie Handel und Industrie KI-Agenten aus dem Pilotstadium ins Tagesgeschäft bringen: mit Daten, die zusammenpassen, Agenten, die direkt in ERP und Shop arbeiten, und einer Wirkung, die sich in der P&L zeigt.
Alle Beiträge von Matthias Dietrich