Beispiel · Fallstudie
Cartpilot konvertierte gut für Menschen, aber AI-Agenten konnten Varianten, Service-Level und Bundle-Regeln nicht vergleichen. Wir bauten die Produktbelege um, klärten den Checkout und hinterließen einen wiederholbaren Agent-Readiness-Test.
Cartpilot beliefert Industrie- und Werkstattkunden mit Komponenten und Verbrauchsmaterial, 12.400 SKUs, die meisten mit zwei bis sieben Varianten. Die menschliche Conversion lag stabil bei 4,7%.
Anfang 2026 tauchten die ersten Käufe durch KI-Agenten in den Shop-Logs auf. Ihre Abschlussrate lag bei 0,4 Prozent. Die Agenten fanden Cartpilot und kauften bei der Konkurrenz.
Wir rekonstruierten 47 Agenten-Sessions der letzten 60 Tage. Drei Brüche erklärten die meisten Fehler:
Das Marketing nannte eine 'Pro'-Version, aber nichts sagte dem Agenten, welche SKU das war oder wie sie sich in Spannung, Passung oder Kapazität unterschied. Agenten wählten nach Lieferzeit, oft die falsche Variante.
Service-Stufen und Grenzen für Sets wurden erst im Warenkorb klar. Automatisierte Käufe brachen nach 30 Sekunden ab, bevor sie die Optionen sahen.
Was sich kombinieren ließ, steckte in Spec-Sheets, die der Crawler nicht zitieren konnte. Agenten bauten ungültige Bundles und werteten das als Fehler des Shops.
"Wir hatten kein Conversion-Problem. Wir hatten ein Agent-Trust-Problem. In 30 Tagen war es weg."
Vier Workstreams parallel über 30 Tage. Jeder mit klarem Owner und einem Kriterium, das vor Live-Gang erfüllt sein musste.
Wir spielten die echte Kaufaufgabe durch: einen 110V-Akkuschrauber mit Expressversand finden, der zum vorhandenen Akkusystem passt. Jede Stelle, an der ein Agent stockte, kam auf eine nach Umsatzrisiko geordnete Liste.
Methode
Wir erfassten jeden Abbruch und ordneten die zwölf wichtigsten Stellen nach Umsatzrisiko. Das Team erhielt eine klare Liste der nötigen Änderungen.
Für 11 wiederkehrende Varianten-Achsen bauten wir Distinguishing-Fact-Templates und spielten sie über 6.214 PDPs als JSON-LD ein, damit Agenten die Fakten direkt parsen statt Fließtext zu scrapen.
Methode
ProductGroup- und Product-Daten verknüpften jede Variante mit ihren klaren Merkmalen. Wir prüften alle 6.214 geänderten Seiten mit echten Kaufaufgaben.
{ "@context": "https://schema.org", "@type": "ProductGroup", "name": "Akku-Schlagbohrer", // die Achsen, die ein Agent unterscheiden muss "variesBy": ["voltage", "batterySystem"], "hasVariant": [{ "@type": "Product", "sku": "DRL-110-PRO", "name": "Schlagbohrer 110V Pro", "additionalProperty": [ { "@type": "PropertyValue", "name": "voltage", "value": "110V" }, { "@type": "PropertyValue", "name": "batterySystem", "value": "M-Core" } ] }]}Service-Level und Bundle-Grenzen wanderten auf die Produktseite, als semantische Optionen, die Agenten vor dem Commit bewerten konnten. So fiel die Entscheidung dort, wo der Agent noch Kontext hatte.
Methode
Jede Service-Stufe erhielt eine klare Bezeichnung und einen passenden Standardwert pro Kategorie. Agenten konnten alle Optionen ohne zusätzliche Seitenausführung lesen.
Die 47 Agentenaufgaben wurden zu einem CI-Check, der vor jedem Release läuft. Unter 90% Task-Completion blockiert das Deployment, so wird ein schwaches neues Produkt vor dem Launch gefangen, nicht danach.
Methode
Ein fester Agententest läuft nun vor jedem Release. Er stoppt Änderungen, die die vereinbarte Abschlussrate unterschreiten.
Drei Kennzahlen, und die wichtigste lässt sich aufschlüsseln.
−38% Agent-Abbrüche
Die 38% setzten sich aus vier Hebeln zusammen, die wir einzeln gemessen haben:
Das Bleibende war nicht das Redesign, es war der Test. Cartpilot lässt die 47 Agentenaufgaben jetzt vor jedem Release laufen, also prüft das Team Produkt-Readiness selbst, so wie es prüft, ob eine Seite rendert. Wartung: rund zwei Stunden im Monat.
Beispiel · Fallstudie
Beispiel · Fallstudie
Das Gleiche für deinen Shop?
Meinen Shop prüfen