Einen KI-Chatbot erstellen heißt im Großhandel nicht, ein Tool zu konfigurieren, sondern eure Datenquellen anzubinden: ERP, Dateiablage, Preislisten, samt Berechtigungen. Bluebatch baut den Piloten in fünf Arbeitstagen auf eurer eigenen Infrastruktur, mit fertigen Connectoren zu e.bootis, Microsoft Navision und SharePoint, für 1.000 € Setup und 50 € Betrieb pro Monat.
Jede Anleitung im Netz endet bei „Baukasten öffnen, Fragen hinterlegen, Widget einbinden“. Das funktioniert für einen Bot, der eure Öffnungszeiten kennt. Diese Seite beschreibt den anderen Fall: einen Chatbot, der auf die Frage „Sind die 200 Stück lieferbar und was kosten sie für diesen Kunden?“ eine Zahl nennt, die stimmt.
Nämlich darin, woher der Chatbot seine Antwort nimmt. Alles andere, Oberfläche, Sprachmodell, Design, ist inzwischen austauschbar.
| Weg | Woher die Antwort kommt | Trägt, wenn | Scheitert an |
|---|---|---|---|
| Baukasten-Tool | Hinterlegte Frage-Antwort-Paare und eure Website-Texte | Die Fragen sich wiederholen und die Antwort sich selten ändert: Öffnungszeiten, Versandbedingungen, Ansprechpartner | Jeder Frage nach einer Zahl, die im ERP steht |
| Sprachmodell mit hochgeladenen Dateien | Ein Dokumentenstapel, den jemand manuell hochlädt | Es um einen abgeschlossenen Text geht, etwa ein Handbuch oder eine Norm | Aktualität und Berechtigungen: die Preisliste von gestern und jeder sieht alles |
| Chatbot auf euren Systemen | Live-Abfrage in ERP, Dateiablage und Shop, gefiltert nach Benutzerrechten | Die Antwort tagesaktuell und kundenabhängig sein muss: Lagerbestand, Konditionen, Auftragsstatus | Einem ERP ohne Schnittstelle, sonst an nichts |

Die 18 Ergebnisse, die Google zu „KI-Chatbot erstellen“ ausspielt, beschreiben durchgehend die ersten beiden Wege. Für einen Händler mit gepflegtem Artikelstamm und kundenindividuellen Preisen ist das die falsche Anleitung, nicht weil sie schlecht wäre, sondern weil sie eine andere Aufgabe löst.
Wir haben noch kein Chatbot-Projekt an der Technik scheitern sehen. Gescheitert sind die, bei denen eine dieser drei Fragen offen blieb.

Nicht „unser ERP hat eine Schnittstelle“, sondern ein Benutzer mit Leserechten, dessen Zugang tatsächlich offen ist. Bei e.bootis, Navision und SharePoint bringen wir den Connector mit, bei anderen Systemen läuft es über REST oder OData. Hat euer ERP keine API, raten wir ab, statt am Vorbei einen Direktzugriff auf die Datenbank zu bauen.
Jemand muss sagen, welche Felder der Bot lesen darf und welche nicht. Deckungsbeitrag, Einkaufspreis und Kreditlimit stehen im selben Datensatz wie der Lagerbestand. Diese Entscheidung kann niemand von außen treffen, und sie ist der häufigste Grund, warum ein Projekt zwei Wochen liegen bleibt.
„Der Bot soll alles können“ ergibt einen Bot, der nichts richtig kann. Startet mit einer Gruppe und ihren zehn häufigsten Fragen: meist der Innendienst mit Bestand, Preis und Lieferzeit. Alles Weitere kommt danach dazu, das ist billiger als der Versuch, es vorher zu erraten.
Ein Chatbot auf euren Daten ist kein Modell, das etwas gelernt hat, sondern eine Kette, die bei jeder Frage neu durchlaufen wird. Genau deshalb ist die Antwort tagesaktuell, und deshalb lässt sich nachvollziehen, woher eine Zahl stammt.
Das ist kein Richtwert, sondern der Zuschnitt, in dem wir den Piloten anbieten. Voraussetzung sind die drei Punkte von oben. Fehlt der API-Zugang, verschiebt sich alles ab Tag 2.
Open WebUI als Chat-Oberfläche auf eurem Server, dazu Azure AD oder euer bestehendes SSO. Ab hier ist klar, wer fragt, und das ist die Grundlage für jede Berechtigungsregel danach.
API-Zugang einrichten und die erste Datenquelle verbinden, in der Regel Artikelstamm und Lagerbestand. Am Ende des Tages beantwortet der Bot die erste echte Bestandsfrage.
Preise und Konditionen, Auftragsstatus, Dokumente aus SharePoint. Hier wird festgelegt, welche Rolle welche Felder sieht, und hier entscheidet sich, ob der Bot im Kundenkontakt einsetzbar ist.
Wir fahren die zehn häufigsten Fragen gegen den Bot und vergleichen jede Antwort mit dem ERP. Was abweicht, wird nachgeschärft. Dieser Tag entscheidet über das Vertrauen der Sachbearbeiter, nicht das Design der Oberfläche.
Einweisung der Sachbearbeiter, Beispiel-Prompts für die typischen Fragen, Übergabe der Workflows. Die liegen in n8n auf eurer Infrastruktur und gehören euch, auch wenn ihr danach ohne uns weitermacht.
Der Aufwand auf eurer Seite ist überschaubar, aber er ist nicht null. Diese Punkte lassen sich nicht auslagern, weil nur ihr sie beantworten könnt.
| Aufgabe | Bei euch | Bei uns |
|---|---|---|
| Server und Betrieb | Linux-Server mit Docker bereitstellen, oder wir hosten mit | Installation, Updates, Monitoring des Chatbots |
| ERP-Zugang | Technischen Benutzer mit Leserechten anlegen und freischalten | Connector konfigurieren, Felder mappen, Abfragen bauen |
| Sichtbarkeit von Feldern | Entscheiden, welche Rolle Einkaufspreise, Margen und Belege sieht | Die Entscheidung in Regeln übersetzen und testbar machen |
| Fachliche Prüfung | Zwei Sachbearbeiter, die an Tag 4 die Antworten gegenlesen | Abweichungen nachschärfen, bis die Antworten tragen |
| Nach dem Piloten | Entscheiden, ob und welche Quellen dazukommen | Betrieb für 50 € im Monat, Erweiterung nach Aufwand |
Wir bauen keinen Chatbot, wenn ein Baukasten die Aufgabe erledigt. Die Trennlinie ist ziemlich scharf.
Bestand, Lieferzeit, Auftragsstatus, offene Posten. Alles, was sich täglich ändert, kann nur aus dem System kommen, nicht aus einer gepflegten Antwortliste.
Preislisten, Rabattstaffeln, Rahmenverträge. Sobald zwei Kunden dieselbe Frage stellen und zwei verschiedene Zahlen bekommen müssen, ist ein Baukasten raus.
Einkaufspreise, Margen, fremde Belege. Ein Chatbot ohne Berechtigungslogik ist im Mehrkunden-Kontext kein Werkzeug, sondern ein Datenschutzvorfall mit Chat-Oberfläche.
Self-hosted auf eurer Infrastruktur, Workflows in n8n, kein Artikelstamm bei einem SaaS-Anbieter. Für viele Händler ist das die Bedingung, unter der das Thema überhaupt startet.
Öffnungszeiten, Versandkosten, Ansprechpartner, Rückgabebedingungen. Dafür genügt ein Baukasten-Tool, und der ist in einem Nachmittag eingerichtet.
Ohne API bleibt nur ein Direktzugriff auf die Datenbank oder ein nächtlicher Export. Beides bauen wir nicht, weil beides beim ersten Update bricht.
Ein Chatbot macht schlechte Stammdaten sichtbar, er repariert sie nicht. Wenn Bestände regelmäßig nicht stimmen, ist das zuerst ein Datenthema.
Arbeitstage bis Go-live
Setup, einmalig pauschal
Betrieb pro Monat
Systeme im Piloten angebunden
Hier finden Sie die Antworten auf häufig gestellte Fragen.
In drei Schritten, und der erste hat nichts mit dem Chatbot zu tun. Erstens: festlegen, welche Fragen er beantworten soll und aus welchem System die Antwort kommt. Zweitens: die Datenquellen anbinden, also ERP, Dateiablage oder Shop, samt Berechtigungslogik. Drittens: eine Chat-Oberfläche davorsetzen. Der dritte Schritt ist der einfachste, er dauert bei uns einen halben Tag. Die ersten beiden entscheiden, ob der Chatbot brauchbare Antworten gibt oder plausibel klingende falsche.
Für einen Chatbot auf öffentlichen Texten ja, dafür reicht jeder Baukasten. Sobald der Bot Bestände, kundenindividuelle Preise oder Auftragsstatus beantworten soll, braucht es einen API-Zugang zum ERP und eine Logik, die prüft, wer welche Zahl sehen darf. Das ist keine Programmierarbeit im klassischen Sinn, wir bauen es in n8n zusammen, aber es ist auch nichts, was man in einem Baukasten zusammenklickt.
Drei Dinge: einen Linux-Server mit Docker (oder wir hosten mit), einen technisch freigeschalteten API-Zugang zu eurem ERP und eine benannte Person, die entscheidet, welche Felder der Bot lesen darf. Der dritte Punkt ist erfahrungsgemäß der, der Projekte aufhält, nicht die Technik.
Der Pilot ist in fünf Arbeitstagen live, wenn die API-Zugänge stehen. Tag 1 Installation und SSO, Tag 2 der erste Connector ins ERP, Tag 3 und 4 die weiteren Systeme plus Test mit echten Daten, Tag 5 Onboarding der Sachbearbeiter. Was danach dauert, ist nicht der Bau, sondern das Nachschärfen der Antworten im echten Betrieb.
Für einmalige Fragen an ein Dokument ja. Für den laufenden Betrieb nicht, weil eine hochgeladene Preisliste am nächsten Tag veraltet ist und weil jeder Nutzer alles sieht, was in der Datei steht. Im Großhandel scheitert genau daran der Ansatz: Kunde A darf Kunde Bs Konditionen nicht sehen, und der Bestand von gestern ist keine Auskunft, sondern ein Risiko.
Fertige Connectoren haben wir für e.bootis, Microsoft Navision und SharePoint, damit ist dieser Block Konfiguration statt Projektarbeit. Andere Systeme binden wir über deren REST- oder OData-Schnittstelle an. Wenn euer ERP gar keine API hat, ist das der Punkt, an dem wir ehrlich abraten, statt einen Datenbank-Direktzugriff zu bauen.
Bei uns 1.000 € einmalig für den Piloten inklusive einer Datenquelle und 50 € pro Monat Betrieb, ohne Mindestlaufzeit. Die Marktpreise und die Rechnung dahinter stehen auf unserer Seite zu den Chatbot-Kosten.
Passend dazu
Was der fertige Chatbot beantwortet: Stammdaten, Bestände, Aufträge, Belege, Preise und Lieferanten im Überblick.
Marktpreise, die drei echten Kostentreiber und die Rechnung, ab wann sich der Pilot trägt.
Die Abgrenzung zwischen regelbasiertem Bot, Sprachmodell und KI-Agent, und wann welche Stufe genügt.
