Shopware Support automatisieren: SEP-konform, mit KI und ohne Ticket-Chaos
Freitagnachmittag, 16:30 Uhr. Eine E-Mail landet in deinem Postfach: „Neues Ticket im Shopware Store.“ Du loggst dich in den Producer-Account ein, liest den Verlauf, tippst eine Antwort ins Textfeld, klickst auf Senden. Zurück zur eigentlichen Arbeit. Zwanzig Minuten später: die nächste Mail, dasselbe Ritual. Kommt dir das bekannt vor?
Wenn du eigene Shopware-Extensions im Store vertreibst, kennst du diesen Ablauf. Und du weißt: Die SLA-Uhr läuft schon ab der ersten E-Mail. Kein Team-Workflow, keine Zuweisung, kein SLA-Tracking, keine Automatisierung. Pro Extension, pro Kunde, jeden Tag. Bei mehreren Produkten wird der Store-Support zu einem eigenen Kanal, den du neben E-Mail, Chat und allem anderen mitschleppst.
Lass uns anschauen, warum das kein Nebenschauplatz ist, welche Wege es gibt, den Support zu automatisieren, und woran du eine gute Lösung erkennst.
Warum Store-Support kein Nebenschauplatz ist
Der Support für deine Extensions ist keine freiwillige Zugabe. Er ist Teil dessen, wozu du dich als Shopware Extension Partner (SEP) verpflichtet hast. Und Shopware hat handfeste Gründe, das ernst zu nehmen.
Es gibt feste Fristen
Die SEP-Vereinbarung schreibt Reaktionszeiten vor. Für die Erstreaktion auf ein Ticket hast du bis zu 4 Arbeitstage Zeit. Für die Behebung eines Mangels sieht der Vertrag 6 Arbeitstage vor. Die öffentliche Doku nennt an manchen Stellen abweichende Werte (etwa 8 Tage für Bugfixes), aber maßgeblich ist der Vertrag, den du unterschrieben hast. Im Zweifel gilt: nachlesen, nicht raten.
Diese Fristen sind kein Richtwert für gute Laune. Sie sind eine Verpflichtung, und die Uhr startet mit dem Eingang des Tickets, nicht mit dem Moment, in dem du dich das nächste Mal einloggst.
Tempo ist verkaufswirksam
Shopware belohnt schnelle Antworten sichtbar. Im Store-Listing gibt es Badges wie „responds quickly“ (Antwort innerhalb von rund 3 Tagen) und „responds very quickly“ (Durchschnitt unter 24 Stunden). Diese Abzeichen stehen direkt bei deinem Produkt. Ein Interessent, der zwischen zwei ähnlichen Extensions wählt, sieht sofort, wer schnell reagiert.
Support ist damit nicht nur Pflicht. Er ist ein Verkaufsargument, das direkt im Listing sichtbar wird.
Du musst im Kanal bleiben
Ein Punkt, der oft unterschätzt wird: Der schriftliche Support muss über das Shopware-Ticketsystem laufen (SEP 1.3.7). Und in deinen Antworten darfst du keine Werbung machen oder auf Kontaktmöglichkeiten außerhalb des Ticketsystems verweisen (SEP 1.3.13).
Das heißt konkret: Du darfst Kunden nicht in ein externes Tool ziehen, und du darfst keine fremden Signaturen, CTAs oder „Schreib uns doch direkt an support@…“-Hinweise in deine Ticket-Antworten packen. Wer das macht, riskiert einen Verstoß gegen die Partnervereinbarung.
Die Verantwortung bleibt bei dir
Shopware formuliert das klar: „the support is your responsibility.“ Egal, welches Tool du einsetzt oder ob eine KI mitschreibt, die Verantwortung für die Antworten liegt bei dir als Partner. Das ist wichtig, wenn wir gleich über Automatisierung reden.
Die realen Optionen im Überblick
Es gibt mehrere Wege, den Store-Support zu skalieren. Keiner ist perfekt. Schauen wir sie ehrlich an, mit Vor- und Nachteilen.
Option A: Alles händisch lassen
Der Status quo. Funktioniert, solange du wenige Tickets hast und immer verfügbar bist. Das Problem: Er skaliert nicht. Jede Standardfrage („Wo trage ich meinen Lizenzschlüssel ein?“) frisst Zeit, oft die von teuren Entwicklern. Und sobald jemand im Urlaub ist oder ein Release ansteht und die Tickets sich stapeln, wird die SLA schnell zum Risiko.
Für ein einzelnes Plugin mit gelegentlichen Anfragen ist das vertretbar. Bei mehreren Produkten und wachsendem Kundenstamm wird es zum Bremsklotz.
Option B: Selbst bauen auf der Account-API
Der Reflex vieler Entwickler: „Das automatisiere ich mir schnell selbst.“ Shopware dokumentiert tatsächlich eine Account-API, über die sich externe Ticketsysteme anbinden lassen. Aber hier lohnt ein genauer Blick.
Die API ist offiziell „not supported“ und primär auf Migration und Lesezugriff ausgelegt. Einen sauberen, dokumentierten Endpoint zum Schreiben bzw. Beantworten von Tickets gibt es nach aktueller Recherche nicht. Ein echter Zwei-Wege-Autoreply über die API bewegt sich damit in einer technischen Grauzone, mit dem Risiko, dass sich das Verhalten ohne Vorwarnung ändert oder ganz bricht.
Der robuste Weg zurück ins Ticket ist die E-Mail-Antwort: Shopware importiert E-Mail-Antworten in den passenden Ticket-Thread. Damit bleibst du im Kanal und umgehst das API-Schreibproblem. Nur baust und pflegst du dann trotzdem alles selbst: Sync-Logik, Statusabgleich, Anhänge, die KI-Anbindung, die Guardrails, die AVV-Kette mit dem LLM-Anbieter. Das ist kein Wochenendprojekt, sondern ein bewegliches Ziel, das du dauerhaft am Laufen halten musst.
Option C: Middleware zu einem bestehenden Helpdesk
Der naheliegende Gedanke: „Ich habe doch schon Zendesk (oder Freshdesk). Ich verbinde die Store-Tickets einfach damit.“
Technisch geht das über Zwischenlösungen, aber es ist nie wirklich nativ. Feld-Mapping und Status-Sync bleiben brüchig, weil die generischen Helpdesks nichts über den Shopware-Producer-Account wissen. Und es gibt eine Compliance-Falle: Diese Tools sind darauf gebaut, Kunden in die eigene Oberfläche zu holen. Fremde Signaturen, „Ticket ansehen“-Links und CTAs landen schnell mit in der Antwort. Genau das kollidiert mit SEP 1.3.13.
Support per E-Mail ist als optionaler Zusatzkanal erlaubt. Der Shopware-Ticket-Thread bleibt aber der verpflichtende Hauptkanal. Eine Middleware, die das nicht respektiert, verschiebt das Compliance-Risiko auf dich.
Option D: Ein zweckgebautes, natives Tool
Die vierte Möglichkeit: ein Tool, das den Producer-Account und die SEP-Pflichten von Grund auf kennt. Das ergibt aber nur dann Sinn, wenn es tatsächlich im Kanal bleibt und die Regeln respektiert, statt sie zu umgehen. Ein Tool, das dich in dieselbe Falle wie eine generische Middleware laufen lässt, hilft nicht.
Woran erkennst du, ob eine Lösung dieser Aufgabe gewachsen ist? Dafür gibt es eine klare Checkliste.
Was eine gute Lösung können muss
Diese Kriterien gelten unabhängig davon, ob du selbst baust oder ein fertiges Tool einsetzt. Sie sind der neutrale Kern der Frage.
Antworten landen im Shopware-Ticket, als Producer-Antwort. Kein externer Redirect, keine Fremd-Werbung in der Antwort. So bleibst du SEP-konform, ohne dir Gedanken machen zu müssen, was die Signatur gerade mit anhängt.
Status wird in beide Richtungen gespiegelt. Offen, gelöst, geschlossen, und zwar synchron zwischen deinem Tool und dem Store. Dazu die Anhänge und die komplette Historie. Wenn du ein Ticket bei dir schließt, muss es auch im Store geschlossen sein, sonst hast du zwei Wahrheiten.
KI mit Guardrails und Human-in-the-Loop. Weil die Verantwortung bei dir bleibt, darf eine KI nicht blind alles rausschicken. Der sinnvolle Default ist ein KI-Entwurf, den ein Mensch freigibt. Und bei sensiblen Themen (Geld, Recht, Zugangsdaten) sollte die KI automatisch an einen Menschen übergeben. Mehr dazu, wie sich autonome Agenten mit zwei Guardrails absichern lassen, haben wir im Beitrag zu DSGVO-konformem KI-Support beschrieben.
Datenschutz sauber gelöst. Ticketinhalte sind personenbezogene Daten. Das heißt: Du brauchst eine saubere AVV-Kette (du als Partner, der Tool-Anbieter, das LLM). Die Subprozessoren müssen benannt sein, und EU-Verarbeitung sollte der Default sein, nicht eine Option, die man erst suchen muss.
Store-Tickets vereinheitlicht mit den anderen Kanälen. Kein zweites Postfach. Deine Store-Tickets gehören in denselben Posteingang wie E-Mail, Chat und Web-Formular, mit denselben Regeln, SLA-Einstellungen und Zuweisungen.
Schnelles Onboarding. Eine Lösung, deren Einrichtung selbst zum monatelangen Projekt wird, verfehlt den Zweck. Verbinden, Tickets fließen rein, loslegen.
Warum wir inbrix gebaut haben
An dieser Stelle die offene Karte: Genau für diese Aufgabe haben wir inbrix gebaut.
Wir sind selbst zertifizierter Shopware-Extension-Partner, seit 2013. Wir vertreiben eigene Plugins im Store (unter anderem AutoInvoice) und kannten das Ticket-Chaos aus erster Hand. Für uns war der Store-Support lange ein separater Kanal, den wir neben allen anderen Produkten pflegen mussten: einloggen, lesen, tippen, wiederholen. Vor jedem Release die Frage „welche Shopware-Version hat der Kunde eigentlich?“. Wir sind unser erster Kunde.
Unser internes Ziel war, das in einem Tool zusammenzuführen. inbrix zieht die Tickets aus dem Producer-Account, beantwortet sie KI-gestützt mit Guardrails und spiegelt Status und Anhänge zurück. Wichtig dabei: Die Antwort landet als Producer-Antwort im Shopware-Ticket, du bleibst also im Kanal. Die Inferenz läuft standardmäßig in der EU, DSGVO-konform und made in Germany, gehostet in Frankfurt. inbrix ist KI-first, aber auch komplett ohne KI nutzbar, wenn du lieber jede Antwort selbst schreibst.
Das haben wir für uns gebaut und bieten es jetzt auch anderen Shopware-Agenturen an. Wer mehr über den Hintergrund unseres DSGVO-Ansatzes lesen will, findet Details auf der Seite zum Datenschutz-Helpdesk. Und wenn du mehrere Kunden gleichzeitig betreust, ist der Helpdesk für Agenturen einen Blick wert.
Häufige Fragen zum Shopware-Support
Darf ich Shopware-Support-Tickets mit KI beantworten?
Ja. Die SEP-Vereinbarung verbietet keine KI-Unterstützung. Sie verlangt, dass der Support über das Shopware-Ticketsystem läuft (SEP 1.3.7) und dass du für die Antworten verantwortlich bleibst. Sinnvoll ist deshalb ein KI-Entwurf mit menschlicher Freigabe statt eines blinden Autoreplys, besonders bei sensiblen Themen.
Muss ich im Shopware-Ticketsystem bleiben?
Für den schriftlichen Support: ja. Der Ticket-Thread im Producer-Account ist der verpflichtende Hauptkanal (SEP 1.3.7). Support per E-Mail ist als optionaler Zusatzkanal erlaubt, ersetzt den Ticket-Kanal aber nicht. Und du darfst in deinen Antworten nicht auf Kontaktwege außerhalb des Ticketsystems verweisen (SEP 1.3.13).
Welche Reaktionszeiten schreibt Shopware vor?
Die SEP-Vereinbarung sieht eine Erstreaktion innerhalb von bis zu 4 Arbeitstagen und eine Mängelbehebung innerhalb von bis zu 6 Arbeitstagen vor. Öffentliche Dokumente nennen teils abweichende Werte; maßgeblich ist der Vertrag, den du unterschrieben hast. Schnellere Antworten werden zusätzlich mit Store-Badges belohnt.
Ist die Automatisierung DSGVO-konform?
Sie kann es sein, wenn die Grundlagen stimmen. Ticketinhalte sind personenbezogene Daten, du brauchst also eine saubere AVV-Kette mit allen Beteiligten, benannte Subprozessoren und idealerweise EU-Verarbeitung als Default. inbrix ist genau darauf ausgelegt: Verarbeitung in der EU, Hosting in Deutschland. Das ist kein Rechtsrat; im Zweifel kläre die konkrete Konstellation mit deinem Datenschutzbeauftragten.
Kann ich Tickets automatisch beantworten lassen?
Technisch möglich, aber mit Bedacht. Ein echter Zwei-Wege-Autoreply direkt über die Account-API bewegt sich in einer Grauzone, weil ein offiziell unterstützter Schreib-Endpoint fehlt. Der robuste Weg ist die E-Mail-Antwort, die Shopware in den Ticket-Thread importiert. Weil die Verantwortung bei dir bleibt, ist der KI-Entwurf mit Freigabe meist die klügere Voreinstellung als vollautomatisches Versenden.
So geht es weiter
Wenn du den Store-Support skalieren willst, ohne die SEP-Pflichten zu verletzen, lohnt der Blick auf die Details der Anbindung. So funktioniert die Shopware-Anbindung zeigt Schritt für Schritt, wie Tickets reinfließen, wie der Status gespiegelt wird und wie die Antwort im Kanal landet.
Am schnellsten geht es live: In einer Demo zeigen wir dir den Sync an deinen echten Tickets, 20 Minuten, dein Account, deine Fragen. Für Shopware-Agenturen, die früh dabei sind, gibt es außerdem einen Founding-Zugang mit vollem Funktionsumfang und kostenlosem Umzug aus dem alten Helpdesk.
Hinweis: inbrix ist keine offizielle Shopware-Integration. Die Anbindung erfolgt über den öffentlich zugänglichen Producer-Account. Shopware und das Shopware-Logo sind Marken der shopware AG. Dieser Artikel ist keine Rechtsberatung; für verbindliche Auskünfte zu deinen SEP-Pflichten wende dich an Shopware oder eine rechtliche Beratung.