Salesforce Marketing Cloud Next: Der neue E-Mail-Editor im Realitätscheck

Die „Brand“-Komponente: Eine gute Idee mit Umsetzungsschwächen

Eine zentrale Neuerung in Next ist die sogenannte „Brand“-Komponente, über die sich übergeordnete „Styles“ konfigurieren lassen, die anschließend in allen Templates und E-Mails zur Verfügung stehen. Konzeptionell ist dies tatsächlich eine begrüßenswerte Innovation gegenüber dem Content Builder. Die Idee dahinter: Bei einer Anpassung des Corporate Designs (CD) müssen nicht mehr sämtliche Templates und laufende E-Mail-Journeys mit hohem manuellem Aufwand aktualisiert werden. Es genügt eine einzige Anpassung an zentraler Stelle, die dann in allen template-basierten E-Mails automatisch und sofort greift.

Die praktische Umsetzung dieser Idee greift für professionelle Werbetreibende jedoch zu kurz. Die gestalterische Freiheit wird dadurch eingeschränkt, dass die Auswahl der definierbaren Elemente vom Editor starr vorgegeben ist. Konkret lassen sich primär Basis-Parameter wie Standardfarben, grundlegende Typografie oder einfache Button-Eigenschaften (z. B. Padding und Eckenradius) einstellen. Sobald das Corporate Design jedoch komplexere Anforderungen stellt – etwa spezifische Hover-Effekte, Farbverläufe oder detailliert abweichende Formatierungen für verschiedene Überschriften-Ebenen (H1, H2, H3) –, stößt man an harte Grenzen. Das Resultat ist, dass E-Mail-Template-Entwickler keine volle Kontrolle mehr über das finale Layout der E-Mail haben.

Mangelhafte CSS-Generierung und fehlender Code-Zugriff

Diese Limitierung wird durch die technische Architektur des Editors weiter verschärft. Die von Salesforce global generierten CSS-Definitionen, die im Hintergrund aus den Eingaben in der „Brand“-Komponente erzeugt werden, bleiben derzeit zu unserer Überraschung hinter gängigen Best-Practice-Standards der E-Mail-Entwicklung zurück. Die Konsequenz daraus sind Darstellungsmängel in bekanntermaßen problematischen E-Mail-Clients wie Microsoft Outlook. Auch die spezifischen HTML- und CSS-Eigenheiten regionaler Mailbox-Provider scheinen vom generierten Code bislang nicht konsequent adressiert zu werden. Das kritische Problem für den Kunden: Er kann diese Darstellungsdefizite nicht selbstständig beheben. Da es sich bei den neuen „Styles“ lediglich um Konfigurations-Metadaten handelt, gibt es im Rahmen der Template-Entwicklung keinen Zugriff mehr auf das zugrundeliegende CSS der Standardkomponenten. Ein manuelles Eingreifen, um beispielsweise spezifische Outlook-Hacks per Code zu ergänzen, ist in den Drag-and-Drop-Blöcken schlicht nicht vorgesehen.

Rückschritte bei der mobilen Optimierung

Auch bei der responsiven Steuerung für Desktop- und Mobil-Darstellungen zeigt sich ein reduzierter Funktionsumfang gegenüber dem SFMC Content Builder.

• Im Content Builder ließ sich bislang frei konfigurieren, wie spezifische Blöcke auf mobilen Endgeräten angeordnet oder ausgeblendet werden.
• Im Next-Editor beschränkt sich die Auswahl lediglich auf die Optionen „Stack on Mobile“ (untereinander anordnen) und „Resize“ (Größe anpassen).

Eine granulare, zielgruppengerechte Optimierung der User Experience auf mobilen Geräten ist mit diesen stark vereinfachten Werkzeugen kaum realisierbar.

Workflow-Brüche: HTML-Einbahnstraße und fehlende Block-Speicherung

Wer versucht, diese Limitierungen durch den Einsatz von reinem HTML zu umgehen, muss deutliche Hürden im Workflow in Kauf nehmen:

• HTML als Einbahnstraße: Zwar ist die Nutzung von HTML-Templates weiterhin möglich, der Wechsel in den HTML-Modus lässt sich jedoch nicht rückgängig machen. Wer einmal im Code arbeitet, kann nicht mehr in den Drag-and-Drop-Editor zurückkehren. Dies gilt auch für einzelne Content-Blöcke.
• Fehlende Block-Bibliothek: Häufig verwendete Blöcke ließen sich im Content Builder unkompliziert speichern und wiederverwenden. In Next ist es nicht mehr ohne Weiteres möglich, Blöcke direkt aus dem Template abzuspeichern.
• Erschwertes Testing: Ein Testversand funktioniert in Next nur noch mit einem Test-Segment, das mindestens einen Kontakt enthält. Dies setzt zwingend eine funktionierende Anbindung an Salesforce Data 360 (ehemals Data Cloud) voraus, andernfalls sind keine realen Testläufe möglich.

Für die Praxis ergeben sich daraus harte Konsequenzen. Wer pixelperfekte, client-übergreifend fehlerfreie E-Mails benötigt, muss entweder „freestyle“ auf Basis von HTML-Vorlagen arbeiten. Dabei verliert das Team jedoch den gesamten Komfort des Drag-and-Drop-Editors und ist auf HTML-versiertes Personal angewiesen. Der einzige Ausweg, um Komfort und fehlerfreien Code zu verbinden, ist derzeit die Nutzung externer, template-basierter E-Mail-Editoren, die vollen CSS-Zugriff erlauben und deren fertige HTML-Exporte dann lediglich in die Marketing Cloud geladen werden.

Ein Lichtblick: Striktere Qualitätssicherung

Neben den aufgeführten kritischen Punkten bietet der Next-Editor auch funktionale Vorteile. So lässt sich im neuen Template-Editor die Bearbeitung einzelner Abschnitte deutlich restriktiver einschränken als zuvor. Für Marketer lässt sich das Template so konfigurieren, dass in der täglichen Arbeit lediglich Inhalte befüllt werden können, ohne dass das Risiko besteht, die grundlegende Struktur versehentlich zu verändern. Gerade in größeren Teams stellt dies einen echten Zugewinn an Qualitätssicherung dar.

Fazit

Der Salesforce Marketing Cloud Next-Editor erfordert von Nutzern des Content Builder ein Umdenken und zwingt zu schmerzlichen Kompromissen bei der gestalterischen und technischen Flexibilität. Eine sorgfältige Konzeption und eine klare Template-Strategie sind essenziell, um mit den neuen Vorgaben arbeitsfähig zu bleiben. Da Salesforce dem Next-Editor mit den jüngsten Releases aber wichtige Feature-Updates wie AMPscript-Support und eine Textversion spendiert hat, bleibt zu hoffen, dass auch die Schwächen im CSS-Rendering und der Code-Zugänglichkeit in kommenden Versionen behoben werden.