Vor ein paar Monaten habe ich beobachtet, wie ein vierköpfiges Team an einem Wochenende GPT verpackte. Sie stellten eine Chatbox auf der Produktlistenseite auf, fütterten sie mit dem Katalog und führten sie an einem Freitag einem sehr zufriedenen VP vor. Dann verbrachten sie die nächsten sechs Monate damit, das Ding zu hüten. Das Modell teilte einem Käufer selbstbewusst mit, ein 40V-Akku passe in ein 20V-Werkzeug. Es empfahl eine ausgelaufene SKU, weil der Prompt noch auf die Daten der letzten Saison verwies. Jemand musste die Formulierungen jedes Mal neu justieren, wenn sich der Katalog änderte. Der Wochenend-Build war echt. Das Jahr des Aufräumens auch.
Genau das ist die Falle im Zentrum jeder Entscheidung über eine KI-Produktempfehlungs-Engine, die gerade ansteht. Die Demo ist einfach. Das, was den Kontakt mit einem echten Katalog und echten Kunden überlebt, ist es nicht. Wenn Sie CTO oder Digital-Verantwortlicher einer Marke im Mittelstand sind, haben Sie drei ehrliche Wege vor sich, und sie passen zu sehr unterschiedlichen Teams. Hier erfahren Sie, welcher davon Ihrer ist.
Die drei Wege im direkten Vergleich
Bevor wir ins Detail gehen, hier die Grundform der Build-vs-Buy-Entscheidung beim Empfehlungssystem. Keiner dieser Wege ist falsch. Sie kosten nur Unterschiedliches und zahlen sich für unterschiedliche Teams aus.
| Weg | Was es wirklich ist | Time-to-Value | Für wen es passt |
|---|---|---|---|
| DIY-Chatbot-Wrapper | Eine LLM-API plus Ihre Prompts, Ihre Datenanbindung, Ihre Leitplanken | Tage bis zur Demo, Monate bis zum Vertrauen | Teams mit freien ML-Ingenieuren und einem Nischenvorsprung, den es zu verteidigen gilt |
| Generische Empfehlungs-Engine | Standardmäßiges kollaboratives Filtern, gespeist aus Klicks und Käufen | Wochen, wenn Sie Traffic-Historie haben | Stores mit hohem Traffic und einfachen, schnelllebigen Katalogen |
| Zweckgebaute Plattform | Ein System, das um die Attribute Ihres Katalogs und die Kaufabsicht herum gebaut ist | Wochen, ohne die Modellpflege selbst zu übernehmen | Marken mit technischen Produkten und begrenzten ML-Ressourcen |
Warum der DIY-Wrapper mehr kostet, als die Demo vermuten lässt
Das Argument für den Eigenbau ist verführerisch: Sie kontrollieren alles, zahlen pro Token, und Ihre Ingenieure lernen den Stack kennen. Und wenn Sie zwei ML-Ingenieure mit freien Kapazitäten und einen wirklich ungewöhnlichen Katalog haben, kann der Eigenbau die richtige Entscheidung sein. Ich will nichts anderes behaupten.
Aber die Demo verschweigt die Rechnung. Ein nacktes LLM kennt Ihre Produkte nicht. Um es nützlich zu machen, müssen Sie ihm Ihren Katalog als Kontext zuführen, diesen Kontext aktuell halten, wenn sich Preise und Bestand ändern, und es davon abhalten, Spezifikationen zu erfinden, wenn es die Antwort nicht kennt. Letzteres ist der Knackpunkt. Eine halluzinierte Produktangabe in einer Chat-Antwort ist keine niedliche Macke; sie ist ein Kunde, der das Falsche kauft, es zurückschickt und es zwei Freunden erzählt. Halluzinierte Spezifikationen sind Retouren, die nur darauf warten, einzutreten.
Dann gibt es da noch das Prompt-Drift. Die sorgfältig abgestimmten Anweisungen, die im März funktionierten, verschlechtern sich bis Juni still und leise, während Sie Produktlinien hinzufügen, die zugrundeliegende Modellversion austauschen oder auf einen Sonderfall stoßen, den niemand getestet hat. Jemand verantwortet das. Jemand schreibt Prompts um, baut Eval-Sets auf und flickt die Retrieval-Pipeline, anstatt Features zu liefern, die das Geschäft tatsächlich differenzieren. Für ein Team im Mittelstand ist genau diese Personalkapazität entscheidend. Sie haben keine ungenutzte ML-Plattform-Abteilung herumsitzen. Der Wartungsaufwand ist der Preis, und er taucht erst im dritten Monat auf.
Generische Engines und die Cold-Start-Mauer
Also überspringen viele Teams den Eigenbau und kaufen eine generische Empfehlungs-Engine. Das sind die "Kunden, die das gekauft haben, kauften auch"-Widgets, die Sie schon tausendmal gesehen haben. Sie sind ausgereift, schnell installiert und verdienen in einem Store mit hohem Volumen und einfachem Katalog ihr Geld. Wenn Sie T-Shirts verkaufen und Tausende Einheiten pro Woche umsetzen, hat kollaboratives Filtern alle Signale, die es braucht.
Die Mauer, gegen die Sie laufen, ist der Cold Start. Generische Engines lernen aus Verhalten — Klicks, Warenkörbe, Mitkäufe. Eine brandneue SKU hat davon nichts, also bleibt sie unsichtbar, bis genug Leute zufällig darauf stoßen und sie kaufen. Wenn Sie häufig Produkte einführen oder Ihr Long Tail eine Rolle spielt, verstecken Sie Ihren neuesten Bestand faktisch hinter einer Datensammlungs-Verzögerung. Die Engine empfiehlt, was bereits beliebt ist, was Beliebtes noch beliebter macht und den Rest im Dunkeln lässt.
Das tiefere Problem ist, dass diese Engines Verhalten lesen, nicht Produkte. Sie wissen nicht, dass ein Kunde, der nach einer "leisen Pumpe für ein kleines Aquarium" fragt, nach Dezibelwert und Durchflussrate filtern muss. Sie haben Ihre Datenblätter nie ausgewertet. Für einen technischen Katalog oder einen mit erklärungsbedürftigen Kaufentscheidungen — Werkzeuge, Teile, Komponenten, alles mit Kompatibilitätsregeln — ist genau diese Lücke der Ort, an dem das falsche Produkt empfohlen wird und die Retoure zwei Wochen später auftaucht. Sie erreichen Gleichstand mit jedem anderen Store, der dasselbe Plugin betreibt. Eine Antwort auf "welches davon passt eigentlich zu meiner Situation" bekommen Sie nicht.
Was zweckgebaut tatsächlich bedeutet
Der dritte Weg ist eine Plattform, die speziell für KI-gestützte E-Commerce-Produktfindung gebaut ist — eine, die von den Attributen Ihres Katalogs und der Absicht des Käufers ausgeht statt von Klick-Logs. Anstatt auf Verhaltensdaten zu warten, liest sie das Produkt: die Spezifikationen, die Kompatibilitätsregeln, die Anwendungsfälle. Wenn also jemand "leise Pumpe für ein kleines Aquarium" eingibt, schließt sie über Durchflussrate, Geräuschpegel und Beckengröße und engt auf die zwei oder drei SKUs ein, die wirklich passen — einschließlich der, die Sie gestern eingeführt haben.
Das löst beide Probleme auf einmal. Kein Cold Start, denn ein neues Produkt ist in dem Moment nützlich, in dem seine Attribute im System sind. Und ein deutlich geringeres Halluzinationsrisiko, weil die Empfehlungen in strukturierten Katalogdaten verankert sind statt in dem, was das Modell geraten hat. Sie bekommen weiterhin die Time-to-Value des Kaufens — in Wochen live, nicht in Quartalen — sparen sich aber die Pflege der Datenpipelines, des Eval-Harness und das Hamsterrad des Prompt-Drifts.
Der Haken ist real, also überspringen Sie ihn nicht. Sie sind von der Roadmap eines Anbieters abhängig, haben weniger Kontrolle über die Interna als ein Team, das das Ding selbst gebaut hat, und Ihre Datenqualität wird zur Obergrenze — eine Plattform, die über Attribute schließt, ist nur so gut wie die Attribute, die Sie ihr geben. Wenn Ihre Produktdaten ein Durcheinander aus inkonsistenten Feldern und halbleeren Datenblättern sind, rechnen Sie damit, die ersten Wochen mit dem Aufräumen zu verbringen, unabhängig davon, welchen Weg Sie wählen. Der Unterschied ist, dass bei einer zweckgebauten Plattform die Katalogpflege die ganze Aufgabe ist; bei einem DIY-Build ist sie eine Aufgabe unter einem Dutzend.
Wo RightPick ins Bild passt
OrderHUBx RightPick ist unsere Auslegung der zweckgebauten Option, gebaut um genau diese Idee: verstreute Katalogdaten in Produktintelligenz verwandeln, über die das System schließen kann, sodass ein Käufer gleich beim ersten Mal den richtigen Produkten und Mengen zugeordnet wird. Es ist gerade im Early Access, also werde ich nicht mit Konversionszahlen wedeln, die wir uns noch nicht verdient haben. Der Grund, warum es einen Blick wert ist, ist keine Statistik — es ist der Ansatz. Wenn Ihr Katalog echte Komplexität aufweist und Ihr Team keine Ingenieure entbehren kann, um Prompts zu hüten, ist eine Plattform, die Produktattribute als erstklassige Bürger behandelt, ein ehrlicherer Fit als ein Wochenend-Wrapper oder eine rein verhaltensbasierte Engine. Testen Sie es auf Herz und Nieren, bevor Sie sich festlegen.
Wie Sie ohne Reue wählen
Schält man das Rauschen weg, läuft die Entscheidung auf drei Fragen zu Ihrer eigenen Situation hinaus. Wie komplex ist Ihr Katalog — haben Produkte Kompatibilitätsregeln und Spezifikationen, die die Kaufentscheidung tatsächlich bestimmen, oder ist es überwiegend Stöbern-und-Zugreifen? Wie viel Engineering können Sie ehrlich dauerhaft entbehren, nicht nur für den Launch-Sprint? Und wie schnell führen Sie neue Produkte ein, die vom ersten Tag an auffindbar sein müssen?
Wenn Ihr Katalog einfach ist, Ihr Traffic riesig und Sie ML-Ingenieure entbehren können, kann eine generische Engine oder sogar ein sorgfältiger Eigenbau bestens funktionieren. Wenn Ihre Produkte technisch sind, Ihr Team schlank ist und Ihre neuesten SKUs sofort sichtbar werden müssen, bringt Sie eine zweckgebaute Plattform schneller ans Ziel und hält Sie mit weniger Drama dort. Das schlimmste Ergebnis ist, den Wrapper zu wählen, weil die Demo in einem Meeting jemanden geblendet hat, und dann im vierten Monat festzustellen, dass "kostenlos zu bauen" "für immer kostenlos zu warten" bedeutete. Entscheiden Sie nach der Wartungsrealität, nicht nach der Demo. Das ist der Teil, der beißt.