Mandantenfähiges CMS mit White-Label-Tarifrechner, um damit 25% mehr Neukunden zu generieren
Jahr
2022 - heute
Kunde
rhenag
Sektor
Energie
Herausforderung
Komplexe Produkte digital verkaufen
Technologien
Diverse Back- und Frontend-Technologien
Unsere Rolle
Konzeption, Architektur, Projektbegleitung und Pflege
Die Situation:
rhenag bietet dutzende Tarife mit unterschiedlichen Zielgruppen und Preismodellen an. Arbeitspreise, Grundpreise, zeitabhängige Komponenten. Kombiniert mit PLZ-Prüfungen, Verbrauchsvalidierungen und kundenspezifischen Anforderungen. Dazu kommt ein Solarrechner mit ROI-Berechnungen und eine Bestellstrecke, die direkt mit dem internen ERP-System kommuniziert.
Die Herausforderung:
Standard-Tools stoßen hier schnell an ihre Grenzen. Kunden brachen Bestellvorgänge ab, nicht aus Desinteresse, sondern weil die Orientierung fehlte. Welcher Tarif passt zu welchem Verbrauch? Was bedeutet der Unterschied zwischen den Optionen?
Die Folge:
Niedrige Conversion-Raten und qualifizierte Leads, die an Vergleichsportale verloren gingen.
Die Situation:
Die rhenag-Gruppe umfasst verschiedene Marken mit jeweils eigenen Anforderungen. Separate Website-Installationen wären wartungsintensiv und teuer. Standard-Multisite-Lösungen bieten nicht die nötige Flexibilität für mandantenspezifische Anpassungen bei gleichzeitiger zentraler Verwaltung.
Die Herausforderung:
Wie lässt sich ein System bauen, das zentral wartbar ist, aber lokalen Teams trotzdem Autonomie gibt? Ohne dass jedes Update zum IT-Projekt wird?
Die Folge:
Ohne passende Lösung: IT-Bottleneck, inkonsistente Markendarstellung und hohe Betriebskosten.
Die Situation:
rhenag bietet den Tarifrechner als Service für andere Stadtwerke an. Jedes Stadtwerk bringt eigene Tarifstrukturen, individuelles Branding und spezifische Validierungslogiken mit. Die Implementierung sollte idealerweise innerhalb weniger Wochen erfolgen.
Die Herausforderung:
Jede individuelle Entwicklung pro Stadtwerk wäre wirtschaftlich nicht darstellbar. Code-Duplikate führen zu Wartungsproblemen. Gleichzeitig müssen fachliche Anforderungen präzise abgebildet werden.
Die Folge:
Ohne skalierbare Lösung: Lange Time-to-Market und hohe Entwicklungskosten pro neuem Partner.
Die Situation:
rhenag strukturierte strategisch um: rhenag.de blieb als B2B-Plattform bestehen, rhenag-energie.de wurde als neue Kundenplattform aufgebaut. Eine klare Markenstrategie, aber SEO-technisch eine Herausforderung.
Die Herausforderung:
Eine neue Domain startet normalerweise bei null. Aufbau von Rankings dauert Monate. Für ein aktives Vertriebsgeschäft bedeutet jeder Tag ohne Sichtbarkeit verlorene Leads.
Die Folge:
Ohne durchdachte SEO-Strategie: Wochenlanger Traffic-Verlust und verzögerter ROI.
Check mal unsere Disziplinen Konzeption
und Strategische Beratung aus!
Die Dimension hinter dem Projekt – oder warum "komplex" nicht "kompliziert zu bedienen" bedeuten muss
Technisch möglich gemacht durch Custom-Architektur.
Neos CMS bot von Haus aus keine Multi-Mandanten-Funktionalität. Wir haben das System entsprechend erweitert: zentrale Verwaltung, dezentrale Steuerung. Die technische Herausforderung lag darin, Mandanten-Logik tief ins System zu integrieren, ohne zukünftige Updates zu blockieren. Jeder Mandant erhält eine dedizierte Konfigurationsebene über YAML-Strukturen, die Theme, Asset-Verwaltung und Berechtigungen steuert.
Das Besondere:
Shared Components werden einmal entwickelt und über ein Vererbungssystem mit mandantenspezifischen Overrides versehen. Bei jedem Rendering prüft das System, ob ein mandantenspezifisches Template existiert. Wenn nicht, greift es auf das Basis-Template zurück. Cache-Management war dabei eine größere Herausforderung.
Der Vorteil für rhenag:
Neue Marken lassen sich in Tagen statt Monaten ausrollen. Geringere Betriebskosten, schnellere Markteinführung neuer Angebote und keine redundante Entwicklung.
– alle in Vanilla JavaScript statt React oder Vue.
Wir haben bewusst auf Framework-Abhängigkeiten verzichtet. Der Grund: Langfristig stabile Codebasis ohne Breaking Changes bei Updates, minimale Bundle-Größen. Die technische Herausforderung bestand darin, komplexe Interaktionen ohne die Komfort-Layer moderner Frameworks zu bauen.
Der Tarifrechner arbeitet mit einer Rule-Engine, die Business-Logik als JSON-Konfiguration behandelt. Jede Rule besteht aus Conditions (Wann gilt sie?) und Actions (Was passiert?). Besonders komplex waren Datumslogiken wie "Lieferbeginn in 6 Wochen" unter Berücksichtigung von Feiertagen und Schaltjahren.
Die Validierung erfolgt zweistufig: Frontend für sofortiges UX-Feedback, Backend für Business-Logic und Sicherheit. Erst wenn beide Ebenen grünes Licht geben, erfolgt der API-Call. Validierungsfehler sollten idealerweise nicht auftreten – wenn doch, werden sie geloggt und analysiert, um die Validierungslogik zu verbessern.
Der Vorteil für Nutzer:
Schnelle Reaktionszeiten und ein flüssiges Nutzererlebnis ohne Wartezeiten zwischen den Schritten. Weniger Abbrüche, mehr Conversions.
Die SEO-optimierte Architektur wurde von Anfang an mitgedacht.
Nach dem Launch erfolgte kontinuierliche Optimierung basierend auf Search Console Daten.
Der Vorteil für den ROI:
Die conversion-optimierte UX und kurze Ladezeiten tragen messbar zur Steigerung der Abschlussquoten bei.
ohne IT-Abhängigkeit.
Das Marketing-Team arbeitet mit vorgefertigten Komponenten im Drag & Drop-Verfahren. Die Component-Library basiert auf einem durchdachten Design-System: Jede Komponente folgt klaren Prinzipien, ist responsive und accessibility-optimiert. Preview-Funktionen ermöglichen Prüfungen vor der Veröffentlichung, während Versionierung und Rollback-Mechanismen Sicherheit geben.
Die technische Herausforderung lag darin, genug Flexibilität für kreative Freiheit zu bieten, ohne dass das System "kaputtgemacht" werden kann. Komponenten haben definierte Grenzen: Farben folgen dem Marken-Theme, Abstände sind systematisiert, Schriftgrößen kommen aus einem Type-Scale. So bleibt Markenkonsistenz gewahrt, auch wenn nicht-technische Teams Seiten bauen.
Der Vorteil für Geschwindigkeit:
Marktveränderungen können zeitnah berücksichtigt werden ohne Entwickler-Kapazitäten binden zu müssen. Keine IT-Abhängigkeit mehr für Content-Updates.
Die Kommunikation mit rhenags Systemen arbeitet synchron, aber mit automatischen Wiederholungen bei Fehlern. Bei einem fehlgeschlagenen API-Call verwendet das System Exponential Backoff: 1. Versuch sofort, 2. Versuch nach 2 Sekunden, 3. nach 5 Sekunden, 4. nach 10 Sekunden, 5. nach 20 Sekunden.
Der Vorteil für Zuverlässigkeit:
99,9% der Bestellungen werden erfolgreich durchgeführt. Temporäre Fehler werden automatisch abgefangen.
Multi-Mandanten-Architektur funktioniert dann, wenn sie von Anfang an mitgedacht wird.
Check mal unsere Disziplin Technische Entwicklung aus!
