Ein Batteriehändler, bei dem KI im Kundenservice, im Shop und in der Buchhaltung mitarbeitet.

Ausgangslage

B.I.G. verkauft Batterien für Autos, Motorräder, Wohnmobile und Rasentraktoren, im eigenen Shop und auf Amazon und eBay. Jeden Monat kommen rund zweitausend Support-Tickets rein, das Team dahinter ist klein. Die Daten liegen verteilt: Bestellungen in Shopify und auf den Marktplätzen, Rechnungen und Lager in JTL-Wawi.

Angefangen hat es Anfang 2025 mit einer einfachen Frage: Bei welchen Anfragen kann KI helfen, und wo sollte besser ein Mensch ran? Daraus ist über die Zeit ein ganzer Werkzeugkasten geworden. Ich bin dabei der Einzige auf der technischen Seite, von der ERP-Anbindung bis zum Monitoring.

Was ich hier baue

Support-KI in Zendesk

Jedes neue Ticket wird klassifiziert und an einen Ablauf pro Kategorie übergeben: Wo bleibt meine Ware, Widerruf, Garantie, Rechnung, Storno. Sichere Fälle schließt die KI selbst ab, alle anderen bekommen eine interne Notiz mit Bestellkontext und einen Antwortentwurf.

Die wichtigste Regel: Das Modell liest die Nachricht und formuliert. Ob etwas geschrieben, erstattet oder geschlossen wird, entscheidet Code anhand frischer Daten aus Shopify und JTL. Dafür gibt es ein “Ticket Context Pack”, das alle Fakten zu einem Ticket einmal sammelt. Danach fragt ein Ablauf entweder gezielt nach der einen fehlenden Angabe oder führt eine Aktion aus.

Im Juli 2026 schrieb der Bot plötzlich Vorschläge für längst gelöste Tickets. Ein LLM sollte aus dem Verlauf erraten, wer zuletzt geschrieben hat. Heute prüfen feste Regeln Status und Absender. Das Modell wird dafür gar nicht mehr gefragt.

Bei Stornos baue ich die Ticket-Seite: Erkennung, auch von Amazon- und eBay-Meldungen, und Entwürfe, die nie “storniert” behaupten, bevor es stimmt. Die eigentliche Storno-App hat das E-Commerce-Team von B.I.G. selbst gebaut.

Pfand-Erstattungen bis ins ERP

Kunden schicken einen Entsorgungsnachweis und wollen ihr Batteriepfand zurück. Der Ablauf liest den Beleg mit einem Vision-Modell, prüft Datum, Menge und ob schon erstattet wurde, zahlt in Shopify aus und legt seit September 2026 automatisch die Rückgabe in JTL an. Daraus entsteht dort die Rechnungskorrektur. Am ersten Produktivmorgen hatte jeder Fall genau eine Erstattung und genau eine Rückgabe.

Eine neue Version des Workflows lief eine Weile parallel mit 10 % der Fälle. Als der Vergleich zeigte, dass sie schlechter abschnitt und einen Fehler hatte, habe ich sie abgeschaltet.

Ein Beispiel: Ein Vision-Modell kennt das heutige Datum nicht und liest “07.10.26” schnell als falsches Jahr. Jetzt steht das Datum im Prompt, und ein Test auf echten Belegen sichert das ab.

JTL-Connector

Das ERP ist über eine schmale, abgesicherte Schnittstelle angebunden. Sie löst Bestellungen über genau eine Kennung auf, etwa Shop-, Amazon- oder Rechnungsnummer, und rät nie zwischen mehreren Treffern. Schreiben darf sie genau eine Sache: eine Pfand-Rückgabe, idempotent. Fast alles andere auf dieser Seite hängt an diesem Connector.

Rechnungen direkt im Ticket

Bittet ein Kunde um seine Rechnung, sucht ein Ablauf die passende Bestellung und genau eine gültige Rechnung in JTL. Das PDF landet als private Notiz im Ticket. Keine öffentliche Antwort, keine Statusänderung. Das Team klickt nur noch auf Senden.

Batteriefinder

Der alte Finder im Shop verkaufte praktisch nichts, die Daten waren unsauber. Ich habe ihn neu aufgebaut, mit echten Passungsdaten statt KI-Vermutungen: Herstellerkataloge, KBA-Listen und Fahrzeugbäume, abgeglichen mit den Artikeln im Shop. Kunden geben Fahrzeug oder HSN/TSN ein und sehen passende Batterien direkt im Shop, eingebaut als Shopify-App. Jede Suche bis zur Bestellung ist messbar, Lücken landen auf einer Liste, die ein Agent wöchentlich vorbereitet und ein Mensch freigibt.

Im September 2026 kam eine Nachricht: Für eine Harley-Davidson Sportster zeigt der Finder nur die Eigenmarke, nicht die passende Varta. Die Spur führte zu einer alten Varta-Artikelnummer im Katalog. Danach habe ich Katalog und Angebote neu geladen und im Live-Shop geprüft: Preis da, auf Lager, Warenkorb geht.

Preisvergleich

Preise wurden in Excel gepflegt. Bevor ich eine App gebaut habe, habe ich geprüft, ob sich die Wettbewerberpreise überhaupt zuverlässig holen lassen. Jetzt vergleicht eine Rails-App jede Woche die eigenen Preise mit eBay, Idealo und Amazon. Bewusst nur lesend. Kein automatisches Umpreisen, bis die Regeln bewiesen sind.

Rechnungsprüfung für die Buchhaltung

Die Buchhaltung prüfte Frachtrechnungen von Hand gegen Ladelisten, Bestellungen und Preisblätter. Eine Rails-App holt die Dokumente aus dem Postfach, liest sie aus und gleicht sie ab, inklusive Dieselzuschlag und doppelter Abrechnung. Die Extraktion lief anfangs über ein LLM. Für die festen Formate habe ich sie durch deterministische Parser mit Summenprüfung ersetzt, KI bleibt nur als Rückfall. Ändert ein Spediteur sein Layout, geht der Bericht in einen Fehlerzustand, statt falsche Zahlen an den Kunden zu schicken.

Interne Assistenten in Teams

Für die Mitarbeiter laufen mehrere Agenten direkt in Microsoft Teams: IT-Support mit Eskalation, ein Batterie-Experte auf Basis des technischen Handbuchs und ein allgemeiner Assistent. Die Wissensdatenbanken liegen in der eigenen Supabase, sauber nach Zweck getrennt. Den externen Vektordienst konnten wir abschalten.

Daten, Nachvollziehbarkeit, Archiv

Die Workflows schrieben anfangs in Airtable, ein Ticket über mehrere Abläufe zu verfolgen war unmöglich. Ich habe alles nach Supabase migriert und eine Spur pro Ticket gebaut, die zeigt, welcher Ablauf was getan hat. Darauf laufen ein internes Dashboard mit Automatisierungsquote und Ideen für die nächsten Kategorien, wöchentliche Reports und ein Archiv, das alle Tickets sechs Jahre aufbewahrt.

Prüfungen gegen echte Daten

Bevor ein Prompt, Modell oder Tool live geht, läuft es gegen echte historische Tickets. Ein Prüfstand spielt die Produktionslogik nach und vergleicht mit der Antwort, die das Team damals wirklich geschrieben hat. Mehrere Ideen sind deshalb bewusst nicht live, weil die Zahlen nein gesagt haben. Ein Agent, der DPD-Formulare vor dem Versand prüft, wurde gebaut, evaluiert und dann geparkt, weil er im Alltag zu wenig brachte.

Wie ich arbeite

Höchstens zwei aktive Projekte gleichzeitig, der Rest wartet mit benanntem Blocker. Pläne, Prozesskarten und Entscheidungen liegen im Repo, nicht in Tickets.

Neues geht immer erst lesend und im Schattenmodus an den Start, dann an einen kleinen Teil der Fälle, dann an alle. Nach jedem riskanten Rollout beobachtet ein Agent die nächsten Stunden jede Ausführung. Für größere Umbauten laufen mehrere Agenten parallel, jeder mit klar abgegrenztem Teil, und ich prüfe, was davon live geht.

Alle zwei Wochen sitze ich mit der Geschäftsführung zusammen. Daraus entsteht fast jede neue Baustelle.

Was dabei rauskam

Ein großer Teil der Tickets wird heute ohne Eingriff gelöst, der Rest kommt mit Kontext und Entwurf beim Team an. Die Kennzahl trennt sauber zwischen strengeren Regeln und verändertem Kanal-Mix.

Pfand-Erstattungen laufen von der E-Mail bis zur Rechnungskorrektur im ERP durch. Der neue Batteriefinder brachte schon in der ersten Woche Bestellungen, wo der alte fast nichts verkauft hatte.

Patrick Niehus, Geschäftsführer: “Er geht Schritt für Schritt an die Aufgaben heran und setzt diese mit Verstand um.”