Ein Kontaktformular ist das erste, was in einem neuen Shop gebaut wird – und das letzte, an das jemand denkt. Es steht in den Erlebniswelten, es funktioniert, es schickt Mails an info@. Zwei Monate später sieht die Lage anders aus: Der Vertrieb bekommt Reklamationen, der Support bekommt Preisanfragen, niemand weiß, ob die Anfrage von letzter Woche beantwortet wurde, und die Bewerbung mit dem angehängten Lebenslauf ist gar nicht erst angekommen, weil das Formular keine Dateien annimmt.
Das ist kein Konfigurationsfehler. Das ist die Stelle, an der ein Standard-Formular an seine Grenze kommt.
Dieser Artikel zeigt, was Shopware 6 von Haus aus mitbringt, wo im Alltag die Reibung entsteht – und wie sich die typischen Fälle lösen lassen.
Was das Shopware-Standardformular kann
Fangen wir fair an: Für den Grundfall ist Shopware gut ausgestattet. Über das CMS-Element Formular legen Sie in den Erlebniswelten ein Kontakt- oder Newsletter-Formular an, ziehen es in ein Layout, definieren eine Empfängeradresse – fertig. Die Mail-Vorlage ist übersetzbar, der Captcha-Schutz kommt aus den Grundeinstellungen, und die Ausgabe passt sich dem Theme an.
Für „Schreiben Sie uns“ reicht das vollkommen aus. Wer nichts weiter braucht, braucht auch kein Plugin.
Die Reibung beginnt an drei Punkten – und zwar bei fast jedem Shop, der ernsthaft Anfragen bearbeitet.
Punkt 1: Alles landet in einem Postfach
Ein Empfänger pro Formular bedeutet in der Praxis: ein Sammelpostfach, in dem Service, Vertrieb und Buchhaltung durcheinanderlaufen. Die Sortierung übernimmt ein Mensch – jeden Morgen, per Hand, per Weiterleitung.
Der übliche Workaround ist, mehrere Formulare zu bauen: eins für Service, eins für Vertrieb, eins für Reklamationen. Das verlagert die Arbeit nur zum Kunden, der jetzt raten muss, welches der drei Formulare für sein Anliegen das richtige ist. Und raten heißt: falsch raten.
Die saubere Lösung ist ein Formular mit Regeln dahinter. Genau dafür gibt es in unserem Formular-Werkzeug die Mail-Routen. Eine Route ist ein Empfänger plus eine Bedingung:
- Route „Service“ →
support@ihr-shop.de, Bedingung: Auswahlfeld Anliegen =Service - Route „Vertrieb“ →
sales@ihr-shop.de, Bedingung: Auswahlfeld Anliegen =Angebot - Route „Alle anderen“ →
info@ihr-shop.de, ohne Bedingung
Bei jeder Einsendung werden die Routen ausgewertet; jede passende Route verschickt ihre Mail. Als Bedingungen stehen gleich, ungleich, enthält, enthält nicht, leer und nicht leer zur Verfügung – kombinierbar über mehrere Felder. Dazu kommen CC- und BCC-Empfänger pro Route, etwa für die Teamleitung bei Reklamationen.
Der Kunde füllt weiterhin ein Formular aus. Die Sortierung passiert vor dem Postfach, nicht darin.
Punkt 2: Die Mail landet im Spam – oder man kann nicht antworten
Ein Klassiker, der viel Zeit kostet und selten verstanden wird.
Damit ein Mitarbeiter auf eine Formularmail einfach mit „Antworten“ reagieren kann, setzen viele Lösungen die vom Kunden eingetragene Adresse als Absender der Benachrichtigung ein. Technisch heißt das: Ihr Server verschickt eine Mail, die vorgibt, von kunde@gmx.de zu kommen. Genau dieses Muster prüfen SPF, DKIM und DMARC – und werten es als Spoofing. Ergebnis: Die Mail landet im Spam-Ordner oder wird still verworfen. Die Anfrage ist weg, und niemand merkt es.
Der akzeptierte Standard für Kontaktformulare ist ein anderer: Absender bleibt die Shop-Adresse, die Kundenadresse wird als Reply-To-Header gesetzt. Die Zustellung ist damit sauber authentifiziert, und ein Klick auf „Antworten“ richtet die Antwort trotzdem direkt an den Kunden.
In unserem Plugin wählen Sie dafür pro Mail-Route einfach das Formularfeld aus, das die Kundenadresse liefert. Enthält es beim Absenden keine gültige Adresse, wird ohne Reply-To versendet, statt die Mail zu riskieren.
Ein Detail, das im Tagesgeschäft niemand sieht – bis man ausrechnet, wie viele Anfragen dadurch nie ankamen.
Punkt 3: Kein Nachweis, keine Historie
Solange eine Anfrage nur als Mail existiert, ist sie so zuverlässig wie das Postfach, in dem sie liegt. Sie kann im Spam landen, versehentlich gelöscht werden oder im Urlaub eines Kollegen liegen bleiben. Und die Frage „Wie viele Produktanfragen hatten wir im letzten Quartal?“ ist schlicht nicht beantwortbar.
Deshalb wird bei uns jede Einsendung zusätzlich zur Mail in der Shopware-Datenbank gespeichert und ist in der Administration einsehbar – mit allen übermittelten Feldern, Sprache, Verkaufskanal und Zeitpunkt. Jede Einsendung hat einen Status (neu, gelesen, beantwortet), sodass ein Team sichtbar dieselbe Liste abarbeitet. Für Auswertungen oder die Übergabe ins CRM gibt es den CSV-Export.
Die Mail bleibt der schnelle Kanal. Die Datenbank ist das Gedächtnis.
Formulare, die Menschen auch ausfüllen
Bis hierhin ging es um das, was nach dem Absenden passiert. Genauso wichtig ist, dass überhaupt abgesendet wird.
Die wirksamste Maßnahme ist nicht, Felder wegzulassen, sondern sie erst dann zu zeigen, wenn sie relevant sind. Ein Häkchen bei „Rückruf gewünscht“ blendet das Telefonfeld ein – vorher steht es niemandem im Weg. Diese bedingte Feldlogik konfigurieren Sie im Formular-Editor pro Feld, ohne eine Zeile JavaScript.
Bei umfangreichen Formularen – Bewerbung, Konfigurationsanfrage, Reklamation – hilft zusätzlich die mehrstufige Ansicht: Das Formular wird in Schritte mit Fortschrittsanzeige zerlegt. Statt einer einschüchternden Wand aus 20 Feldern sieht der Besucher drei überschaubare Abschnitte.
Dazu kommen die Bausteine, die ein Formular lesbar machen: 14 Eingabetypen (Text, mehrzeilig, Zahl, Zahlenbereich, Auswahl, Checkbox-Gruppe, Radio-Buttons, Schalter, Datum, Anrede, E-Mail, Telefon, Datei-Upload, Datenschutz-Zustimmung) und 9 Struktur-Elemente (Überschriften, Trenner, Abstände, Fließtext, Erklärungen sowie Hinweisboxen in vier Stufen). Felder lassen sich in Zeilen nebeneinander legen und zu Gruppen bündeln – ein Formular sieht damit aus wie ein Teil der Seite und nicht wie ein Fremdkörper.
Die spezialisierten Feldtypen zahlen sich vor allem mobil aus: Ein E-Mail- oder Telefonfeld öffnet auf dem Smartphone die passende Tastatur – und wird serverseitig validiert, nicht nur im Browser.
Datei-Uploads funktionieren dabei genau so, wie man es erwartet: Lebenslauf, Schadensfoto, Druckdatei. Welche Dateiendungen erlaubt sind, legen Sie zentral in den Plugin-Einstellungen fest – der Hinweis in der Storefront und die serverseitige Prüfung stammen aus derselben Quelle. Die hochgeladenen Dateien sind nur aus der Administration heraus abrufbar, nicht über eine öffentliche URL.
Der Spam-Schutz bleibt übrigens der Ihre: Das Formular bindet die in den Shopware-Grundeinstellungen aktivierten Captcha-Verfahren ein. Kein zweites System, keine zusätzliche Drittanbieter-Einbindung.
Der Fall, der am schnellsten Geld bringt: die Produktanfrage
Nicht jedes Produkt lässt sich in den Warenkorb legen. Erklärungsbedürftige Artikel, Sonderanfertigungen, Staffelpreise für Geschäftskunden, „Preis auf Anfrage“ – überall dort ist die Anfrage der eigentliche Conversion-Punkt.
Genau dafür gibt es den Formulartyp Produktanfrage: ein Formular, das automatisch auf der Produktseite erscheint, ohne dass Sie in den Erlebniswelten jedes Layout anfassen müssen. Wo es erscheint, steuern Sie über Bedingungen – nach Kundengruppe (nur für B2B-Kunden), nach Verkaufskanal, für einzelne Produkte oder für einen kompletten Dynamischen Produktgruppe (Product Stream), etwa „alle Artikel der Kategorie Sonderanfertigung“.
Der Produktkontext wird dabei automatisch mitgeschickt: Ihr Vertrieb sieht in der Anfrage, um welchen Artikel es geht, statt nachfragen zu müssen.
Und danach: das Formular als Auslöser
Eine Einsendung muss nicht bei einer Mail enden. Beim Absenden wird das Event „Formular wurde abgesendet“ im Flow Builder ausgelöst – ab da gehört der Ablauf Ihnen:
- Bestätigungsmail an den Kunden, in der Sprache seiner Storefront (die passende Aktion liefern wir mit, ein Standard-Flow wird bei der Installation gleich eingerichtet)
- Benachrichtigung ins Team-Chat-System
- Kunden-Tag setzen, um Interessenten später gezielt anzusprechen
- Übergabe an ein CRM oder Ticketsystem per Webhook
Für Mail-Vorlagen steht dabei nicht nur die vollständige Liste aller übermittelten Felder zur Verfügung, sondern auch der gezielte Zugriff auf ein einzelnes Feld – etwa für einen persönlichen Betreff: „Neue Anfrage von Anna Muster zu Artikel XY“ statt „Neue Formular-Einsendung“.
Ein Wort zum Datenschutz
Viele Shops lösen anspruchsvollere Formulare über externe Dienste – Google Forms, Typeform und ähnliche. Das ist schnell eingerichtet und bedeutet zugleich: Ihre Kundendaten verlassen den Shop, Sie brauchen einen Auftragsverarbeitungsvertrag, eine Rechtsgrundlage für die Übermittlung und einen Absatz in der Datenschutzerklärung. Für ein Kontaktformular ist das ein bemerkenswerter Aufwand.
Bei einer Lösung innerhalb von Shopware bleiben die Daten dort, wo Ihre Bestell- und Kundendaten ohnehin liegen. Für die Einwilligung gibt es einen eigenen Feldtyp mit Verlinkung auf Ihre Datenschutzerklärung, die Einsendungen sind in der Administration einsehbar – und damit auch gezielt löschbar, wenn jemand von seinem Auskunfts- oder Löschrecht Gebrauch macht.
Kurz-Checkliste für Ihr Formular
- Ein Formular statt drei – die Sortierung erledigen Regeln, nicht der Besucher.
- Reply-To statt gefälschtem Absender – sonst landen Anfragen im Spam.
- Felder bedingt einblenden, statt sie wegzulassen.
- Lange Formulare in Schritte teilen.
- Jede Einsendung speichern, nicht nur mailen.
- Bestätigungsmail an den Kunden – sie verhindert die Nachfrage „ist das angekommen?“.
- Mobil testen, nicht nur am Desktop.
Fazit
Das Shopware-Standardformular ist ein solider Startpunkt. Sobald aus Anfragen aber ein Prozess wird – mit Zuständigkeiten, Nachweisen, Anhängen und Auswertungen – fehlen ihm die Werkzeuge, und der Unterschied wird täglich in Arbeitszeit bezahlt.
Unser Formular-Werkzeug für Shopware 6 schließt genau diese Lücke: 23 Feld- und Struktur-Elemente, bedingte Feldlogik, mehrstufige Formulare, Mail-Routen mit Bedingungen, Produktanfragen auf Produktseiten, ein Einsendungs-Postfach mit Status und CSV-Export sowie eine vollständige Flow-Builder-Anbindung. Entwickelt für Shopware 6.7 und headless-fähig, weil die gesamte Logik in eigenen Routes liegt.
