Ausgangslage: Support als Wachstumsbremse
Wer eine B2B-Print-Plattform betreibt, hat es mit einer sehr spezifischen Kundengruppe zu tun: Druckereien, Reseller und Shop-Betreiber — Profis, die selbst unter Produktionsdruck stehen. Wenn etwas in der Plattform nicht funktioniert oder sie ihre Shops konfigurieren möchten, zählt jede Stunde.
Die Bandbreite der Anfragen ist enorm. Sie reicht von einfachen Konfigurationsfragen über komplexe Template-Anpassungen bis hin zu Fragen, die ohne tiefes Produktverständnis schlicht nicht beantwortbar sind. Ein guter Support braucht erfahrene Mitarbeiter. Und genau die sind zu wertvoll, um täglich dieselben Standardfragen zu beantworten.
Gleichzeitig: Etablierte Plattformanbieter in der Branche bieten keinen KI-gestützten First-Level-Support. Das Ticketsystem ist Stand der Technik — und bleibt es, solange niemand etwas verändert.
Wir haben etwas verändert.
Die Plattform: Zwei Welten, eine Wissensbasis
be.print und PRINT-LOUNGE sind zwei eigenständige Shop-Systeme mit unterschiedlichen Zielgruppen: der **B2B-Closedshop** für exklusiv zugängliche Unternehmensportale, und der **DRUCKSHOP / Openshop** für öffentlich zugängliche Druckshops. Beide laufen auf demselben technischen Fundament, aber mit eigenen Konfigurationen, eigenen Templates und eigenen Kundenprofilen.
Gemeinsam ist beiden: Kunden wollen ihre Shops individuell gestalten. Layouts anpassen. HTML und CSS verändern. Vorlagen versionieren. Und genau dabei brauchen sie Support — nicht in drei Tagen, sondern sofort.
Die Lösung: Acht Bausteine, zwei Jahre Arbeit
1. Die Wissensbasis — und warum der erste Ansatz gescheitert ist
Die wichtigste Erkenntnis des gesamten Projekts war keine technische — sie war eine konzeptuelle. Und sie kam durch Scheitern.
Unser erster Ansatz war naheliegend: Support-Tickets so wie sie sind in die Datenbank übertragen. Roh, direkt, unverändert. Das klang effizient. Es hat nicht funktioniert.
Ein Support-Ticket (in unserem Fall Jira) ist kein strukturiertes Dokument. Es ist ein **Gesprächsverlauf**: eine erste Anfrage des Kunden — oft unscharf formuliert, mit Screenshots statt Beschreibungen, mit technischen Begriffen, die nicht korrekt sind. Darauf folgen interne Kommentare zwischen Mitarbeitern, externe Antworten an den Kunden, Rückfragen, Korrekturen, manchmal Umwege. Am Ende steht irgendwo die Lösung — aber vergraben in einem Thread, der für eine Maschine ohne Kontext schlicht nicht lesbar ist.
Das Ergebnis: Die Suche fand Tickets, aber die Antwortqualität war schlecht. Der Bot zog Informationen aus dem falschen Kontext, verwechselte das Problem des Kunden mit internen Diskussionen und lieferte Antworten, die zwar technisch aus dem Ticket stammten, inhaltlich aber nicht passten.
**Die Lösung war eine vollständige Neuinterpretation jedes einzelnen Tickets.**
Statt das Rohmaterial zu speichern, haben wir jeden Ticket-Verlauf durch ein Sprachmodell geschickt — mit dem Auftrag, das Gesamte zu verstehen und neu zu formulieren: die ursprüngliche Kundenanfrage, die internen Diskussionen, die externe Kommunikation, die Kommentarverläufe und die beigefügten Screenshots. Alles zusammen. Alles im Kontext.
Das Ergebnis war kein gespeichertes Ticket mehr, sondern ein **strukturiertes Wissensdokument** mit:
- – einer klaren Problembeschreibung in der Sprache des Kunden
- – einer präzisen Zusammenfassung der Lösung
- – einer Kategorisierung des betroffenen Bereichs
- – einer Einschätzung der Schwere und des Lösungsgrades
- – relevanten Suchbegriffen — einschließlich der Formulierungen, die Kunden tatsächlich verwenden, nicht die internen Fachbegriffe
Dieser letzte Punkt ist entscheidend: Wie ein Kunde fragt, ist genauso wichtig wie die Antwort. Wenn ein Kunde „mein Logo sieht komisch aus” schreibt, muss das System verstehen, dass das mit einem Ticket über „SVG-Rendering-Fehler im Headerbereich” zusammenhängt. Das gelingt nur, wenn die Kundenformulierungen Teil der Wissensbasis sind.
Dazu kamen Screenshots: Kunden hängen Bilder an, wenn sie ein Problem beschreiben — Fehlermeldungen, falsch dargestellte Layouts, unerwartetes Verhalten. Diese Screenshots wurden nicht nur anonymisiert, sondern ebenfalls **per KI interpretiert** und als beschreibender Text in das Wissensdokument integriert. Eine Fehlermeldung, die vor zwei Jahren als Bild eingereicht wurde, ist heute als Textinhalt suchbar.
Alle Dokumente wurden abschließend DSGVO-konform anonymisiert: Kundennamen, Shop-IDs, Bestellnummern — vollständig entfernt, bevor ein einziger Eintrag in die Datenbank gelangte.
Heute umfasst die Wissensbasis über **9.700 semantische Einträge** — aus Tickets, Wiki-Artikeln, Plattform-Dokumentation und Prozessbeschreibungen. Kein einziger davon ist ein Rohdatensatz.
2. Template-Wissen als eigene Dimension
Wer einen Druckshop betreibt, will ihn auch gestalten. Das Frontend von be.print und PRINT-LOUNGE basiert auf einem **Smarty/Blade-Template-System**, und Kunden stellen häufig sehr spezifische Fragen: Wie passe ich das CSS für den Warenkorb an? Wo steuere ich die Darstellung der Artikelkategorien? Welche Klassen sind im Header relevant?
Diese Fragen sind ohne das konkrete Template nicht beantwortbar — und das Template verändert sich mit jeder Version.
Deshalb haben wir die Templates gesondert behandelt: **Versioniert und als eigene Wissensquelle** in die Datenbank eingespeist. Der Bot weiß, welche Template-Version welche CSS-Klassen und HTML-Strukturen enthält. Ein Kunde, der fragt „Wie ändere ich die Hintergrundfarbe meines Headerbereichs?”, bekommt nicht eine allgemeine Antwort — er bekommt das **passende CSS-Snippet für seine exakte Template-Version**, sofort, ohne Wartezeit.
3. Mehr als Support — der Bot als Produktberater
be.print und PRINT-LOUNGE sind Cloud-Plattformen, die kontinuierlich wachsen. Jeden Monat kommen neue **Module und Addons** hinzu — kostenlos, direkt im System verfügbar, ohne Installationsaufwand. Diese Module lösen konkrete Anforderungen im modernen Web-to-Print: von der automatisierten Druckdatenprüfung über Genehmigungsworkflows bis zu spezialisierten Bestellprozessen.
Das Problem in der Praxis: Viele Kunden wissen nicht, dass eine Lösung für ihr Problem bereits existiert — und kostenlos aktivierbar wäre.
Der Bot löst genau das. Wenn ein Kunde keinen Fehler meldet, sondern einen **Umsetzungswunsch** äußert — „Ich möchte, dass meine Kunden Bestellungen freigeben müssen” oder „Gibt es eine Möglichkeit, Druckdaten automatisch zu prüfen?” — durchsucht er die vollständige Modul-Wissensbasis und schlägt **passende, sofort nutzbare Module** vor. Inklusive Beschreibung, konkretem Nutzen und Hinweis auf die kostenfreie Verfügbarkeit.
Das verändert die Rolle des Bots grundlegend: Er ist nicht nur ein Problemlöser, sondern ein aktiver **Mehrwertverteiler** — einer, der sicherstellt, dass Kunden den vollen Umfang der Plattform kennen und nutzen, statt an Anforderungen zu scheitern, die längst gelöst sind.
4. Semantische Suche statt Keyword-Matching
Der technische Kern des Systems ist ein **Retrieval-Augmented Generation (RAG)**-Ansatz, orchestriert über **n8n**, mit **Pinecone** als Vektor-Datenbank und **Claude von Anthropic** als Sprachmodell.
Was das bedeutet: Der Bot versteht Bedeutung, keine Stichwörter. „Mein Artikel ist nicht sichtbar” und „Produkt taucht im Shop nicht auf” sind für das System dieselbe Frage. Zur Qualitätssteigerung sendet der Bot automatisch mehrere semantische Varianten jeder Anfrage und kombiniert die besten Treffer — dieses Prinzip der **Query Expansion** hat die Antwortqualität messbar verbessert.
5. Der Dual-Mode — eine Wissensbasis, zwei Zielgruppen
Das Chat-Widget steht nicht nur Kunden zur Verfügung. Es gibt einen gesicherten **internen Support-Modus** für Mitarbeiter. Derselbe Bot, dieselbe Wissensbasis — aber eine andere Antwortqualität: technischer, detaillierter, mit Verweisen auf interne Prozesse und Konfigurationsmöglichkeiten.
Das hat einen konkreten Effekt: Neue Support-Mitarbeiter können vom ersten Tag an auf das kollektive Wissen des gesamten Teams zugreifen. Wissen, das sonst in Köpfen oder E-Mail-Verläufen steckt, ist sofort und strukturiert abrufbar.
6. Wenn der Bot nicht weiter weiß — automatisches Ticket mit Chat-Zusammenfassung
Kein System kann alles wissen. Wenn der Bot eine Frage nicht befriedigend beantworten kann, passiert Folgendes: Aus dem **gesamten Chat-Verlauf wird automatisch ein Support-Ticket generiert** — inklusive einer strukturierten Zusammenfassung des Gesprächs. Der Kunde muss sein Problem nicht noch einmal beschreiben. Das Support-Team bekommt sofort den vollen Kontext.
Das Ergebnis: Kein Informationsverlust beim Übergabepunkt zwischen Bot und Mensch. Die Zeit bis zur Lösung verkürzt sich, weil die manuelle Erfassung des Problems entfällt.
7. Erfolgsmessung und Feedback-Loop — die Wissensbasis wächst mit
Ein besonders wichtiges Feature ist die aktive **Erfolgsprüfung nach jedem Gespräch**. Der Bot interpretiert im Verlauf des Gesprächs, ob dem Kunden geholfen wurde — und fragt am Ende aktiv nach.
Was dann passiert, wenn der Kunde bestätigt, dass sein Problem gelöst ist, ist das eigentliche Herzstück des Systems: Der erfolgreiche Chat-Verlauf wird **automatisch anonymisiert und als neuer Wissenseintrag** in die Datenbank aufgenommen. Jede gelöste Kundenanfrage macht das System für die nächste identische Anfrage besser.
Das ist kein statisches System. Es ist ein **lernender Kreislauf**: Wissen rein → Problem gelöst → Wissen angereichert zurück → nächste Anfrage schneller gelöst.
8. Die richtige Rolle — Verstärker, kein Ersatz
Wir betreiben kein System, das vorgibt, menschlichen Support überflüssig zu machen. Unser Support-Team besteht aus Mediengestaltern und langjährig erfahrenen Mitarbeitern, die tiefes Branchenwissen mitbringen. Dieses Wissen ist nicht ersetzbar — und das ist auch nicht das Ziel.
Das Ziel ist ein anderes: Das Team soll **dort eingesetzt werden, wo es wirklich den Unterschied macht**. Nicht bei wiederkehrenden Konfigurationsfragen, sondern bei dem, was unsere eigentliche Stärke ist: Kunden dabei zu helfen, ihre Shops und Portale strategisch aufzubauen. Beratung auf Business-Ebene. Projektbegleitung. Echte Expertise statt Standardantworten.
Der Bot übernimmt die Routine. Das Team übernimmt den Mehrwert.
Das Geschenk, das wir nicht bestellt haben
Manchmal überrascht einen die eigene Technologie.
Unsere gesamte Wissensbasis — 9.700+ Einträge aus Tickets, Wiki-Artikeln und Dokumentation — ist zu 98 % in deutscher Sprache. Das war kein strategischer Entscheid, sondern schlicht die Realität: Wir sind ein deutsches Unternehmen, unsere Support-Historie ist auf Deutsch.
Was wir nie explizit konfiguriert haben: Mehrsprachigkeit. Kein Schalter, keine Übersetzungsschicht, keine Spracherkennung im Workflow.
Und trotzdem: Ein Kunde schreibt auf Englisch — der Bot antwortet auf Englisch. Auf Französisch gefragt, auf Französisch geantwortet. Das Sprachmodell hat das einfach gemacht. Still, selbstverständlich, ohne dass wir es ihm gesagt hätten.
Das Ergebnis: **Wir haben unseren Support multilingual aufgestellt, ohne es zu planen.** Was für Version 2 oder 3 auf der Roadmap stand, war plötzlich in Version 1 einfach da.
Wir erzählen das nicht, um uns zu rühmen — sondern weil es etwas Wichtiges über diese Technologie sagt: Wenn das Fundament stimmt, bringt KI manchmal mehr mit, als man erwartet hat. Nicht als Magie, sondern als Eigenschaft gut trainierter Sprachmodelle, die Sprache eben wirklich verstehen.
Es ist eine kleine Erinnerung daran, dass wir noch am Anfang stehen — und dass das Beste, was dieses System leisten wird, möglicherweise noch gar nicht auf unserer Roadmap steht.
Was wir gelernt haben
**Datenqualität ist die eigentliche Arbeit.** Die KI-Komponenten waren der einfachere Teil. Tausende Tickets zu sichten, zu bereinigen, zu strukturieren und Screenshots zu interpretieren — das war die eigentliche Investition.
**Ein Übergabepunkt ist kein Scheitern.** Der Moment, in dem der Bot an einen Menschen übergibt, ist kein Systemfehler. Es ist ein Feature — solange er es mit dem richtigen Kontext tut.
**Feedback–Loops verändern alles.** Ein System, das aus jedem gelösten Problem lernt, wird mit der Zeit nicht schlechter. Das ist der fundamentale Unterschied zu einer statischen FAQ.
**KI und Expertise schließen sich nicht aus.** Sie verstärken sich gegenseitig — wenn man die Aufgabenteilung ernst nimmt.
Fazit
Was als Frage begann — kann man historisches Support-Wissen sinnvoll als KI-Wissensbasis nutzen? — ist heute ein produktionsreifes System, das täglich im Einsatz ist. Mit einer Wissensbasis von über 9.700 semantischen Einträgen, automatischer Anreicherung durch jeden erfolgreichen Chat, Template-Intelligenz für konkrete HTML/CSS-Fragen, proaktiver Modul-Beratung bei Umsetzungswünschen und einer nahtlosen Übergabe an erfahrene Mitarbeiter, wenn der Bot an seine Grenzen kommt.
Andere Plattformen bauen ihr Support-System auf Ticketsystemen auf. Wir bauen es auf akkumuliertem Wissen, das täglich wächst.
Das ist erst der Anfang.
