00 / Fallstudie
Das CRM ändert sich.
Die Website folgt.
DigitalHappy gestaltet und baut Websites für Immobilienmakler in ganz Spanien, von Inselspezialisten bis zu landesweiten Maklerhäusern. Jeder dieser Makler pflegt seine Objekte in einem Immobilien-CRM, und die Website ist nur dann etwas wert, wenn sie von selbst aktuell bleibt. Seit 2024 bin ich der Entwickler, der die Websites mit den Systemen dahinter verbindet: Importe, die Objekte hereinholen, Formulare und Feeds, die Daten wieder hinausschicken, und die Such- und Übersichtsseiten, die darauf aufbauen.
-
10
Websites für
DigitalHappy -
10
Angebundene
Systeme -
2,600+
Objekte immer
synchron -
05
Sprachen auf
einer Website
- Kunde
- DigitalHappy
- Rolle
- Backend-Entwickler
- Stack
- Statamic, Laravel
- Zeitraum
- 2024 bis heute
01 / Ausgangslage
Immobilienmakler führen ihr Geschäft im CRM. Dort entstehen die Objekte, dort werden sie bepreist, übersetzt und als verkauft markiert, und niemand im Büro möchte davon irgendetwas ein zweites Mal eintippen. Die Website muss dem CRM von allein folgen, jede Nacht, ohne dass eine Redaktion etwas hinüberkopiert.
Ein einheitliches CRM gibt es nicht, und einen einheitlichen Zugriff auf die Daten ebenso wenig. Jedes Maklerhaus arbeitet mit eigenen Systemen (unter anderem Infocasa, Mobilia und Inmoweb) und jedes gibt seine Objekte anders heraus: ein vollständiger XML-Export, der jede Nacht bereitgestellt wird, ein eigener XML-Dienst, der eine Abfrage nach der anderen beantwortet, eine JSON-Schnittstelle hinter einem Zugangsschlüssel, Fotos, die separat angefragt werden müssen. Jedes hat seine eigene Struktur für Orte, Objektarten und Übersetzungen, und die Dokumentation ist dünn, wo es überhaupt eine gibt.
Daten müssen auch in die andere Richtung fließen. Was Besucher über ein Formular schicken, gehört in die Systeme des Maklers und nicht in ein Postfach, eine Kartenzahlung zählt erst, wenn die Bank sie bestätigt hat, und manche Objekte müssen zusätzlich an ausländische Immobilienportale gehen, in genau dem Format, das diese Portale erwarten.
Die Käufer kommen aus ganz Europa, dasselbe Objekt existiert also in bis zu fünf Sprachen, und jeder Makler wollte seine eigene Art, nach Region, Ort und Objektart zu stöbern.
02 / Anforderungen
- Der Feed bestimmt, was es gibt
- Ein im CRM verkauftes Objekt muss bis zum nächsten Morgen von der Website verschwinden, und ein neues muss erscheinen. Dasselbe gilt für jede Preissenkung, jedes neue Foto und jede geänderte Beschreibung, in jeder Sprache, die das Objekt hat.
- Die Redaktion behält ihre Arbeit
- Die Maklerhäuser ergänzen rund um importierte Objekte eigene Texte, SEO-Felder und Landingpages. Ein nächtlicher Import darf nur die Felder anfassen, die ihm gehören.
- Ein abgebrochener Import ändert nichts
- Bricht ein Import auf halber Strecke ab, sehen Besucher die Objekte von gestern und nicht die Hälfte von heute und für den Rest eine Fehlerseite.
- Nichts scheitert stillschweigend
- Jeder Import führt sein eigenes Protokoll darüber, was er geholt, geändert und übersprungen hat. Ein Fehler wartet nicht darauf, dass jemand ein fehlendes Objekt bemerkt: Er geht per E-Mail an die Personen, die es betrifft.
03 / Was ich gebaut habe
-
B/01
Objektimporte
Fünf Importe nach demselben Muster: Feed holen und archivieren, auf Vollständigkeit prüfen, mit dem Bestand der Website vergleichen. Dann in einer Warteschlange Einträge anlegen, einzeln aktualisieren und löschen. Nur Objekte, die sich am Vortag geändert haben, werden neu geschrieben. Ein inkrementeller Lauf aktualisiert so nur eine Handvoll Objekte in wenigen Sekunden, nicht den kompletten Katalog.
-
B/02
Jede Sprache
Dasselbe Objekt in bis zu fünf Sprachen, mit Titeln, Beschreibungen und SEO-Texten auf die Sprachversionen von Statamic abgebildet, und Ortsverzeichnisse, die pro Sprache von der Provinz bis zur Gemeinde neu aufgebaut werden.
-
B/03
Übersichtsseiten aus Daten
Bei vier der Maklerhäuser wird jede Kombination aus Ort und Objektart zu einer eigenen Seite mit Titel, Anzahl der Objekte und Links zu den Nachbarn. Die Seiten entstehen aus den importierten Daten und werden nach jedem Import in den statischen Cache vorgewärmt.
-
B/04
Eine Suche, die die Karte kennt
Wer eine Region wählt, bekommt jeden Ort darunter mit dazu. Die Suche arbeitet mit CRM-Kennungen statt mit Slugs und übersteht damit jeden erneuten Import, und dieselbe Ortsstruktur speist die Vorschläge im Suchfeld.
-
B/05
Alte Links funktionieren weiter
Suchaufträge und Portale zeigen noch auf Adressen der früheren Websites. Bei zwei Maklerhäusern werden diese alten Adressen über die CRM-Nummer dem Objekt zugeordnet und so automatisch und dauerhaft weitergeleitet.
-
B/06
Objekte vollständig
Fotos, 360-Grad-Aufnahmen, Videos und virtuelle Rundgänge kommen mit jedem Objekt und werden aus dem CRM ausgeliefert, Energieausweise kommen mit den übrigen Daten, und wo das Maklerhaus es wollte, beschreibt schema.org-Auszeichnung jedes Objekt für Suchmaschinen.
-
B/07
Formulare direkt ins CRM
Anfrage- und Bewerbungsformulare laufen direkt ins CRM statt in ein Postfach, wobei wiederkehrende Kontakte über die E-Mail-Adresse zugeordnet statt doppelt angelegt werden. Bewerbungen landen in Salesforce, der Lebenslauf liegt in einem privaten Speicher und nie auf dem Webserver.
-
B/08
Feeds und Schnittstellen
Ein OpenImmo-Feed, über den die Objekte der Resort-Entwicklung an deutsche Portale gehen können. JSON-Ortsfeeds hinter den Suchvorschlägen. Der HubSpot-Blog des Resorts über dessen Schnittstelle eingebunden, und aktuelle Objekte aus der Schnittstelle eines landesweiten Maklerhauses mitten in dessen Blogbeiträgen.
-
B/09
Zahlungen
Kartenzahlungen über Redsys, jeder Versuch protokolliert und als Bestellung erfasst. Erst die signierte Bestätigung der Bank markiert eine Bestellung als bezahlt und verschickt die E-Mails an beide Seiten, nicht die Rückkehr des Besuchers auf die Website.
04 / Unsaubere Daten
Feeds kommen nicht immer so an, wie sie sollten. Der Server ist überlastet, Feeds brechen auf halber Strecke ab oder kommen leer zurück, und ein CRM schickt manchmal eine völlig gültige XML-Datei, in der statt Objekten eine Fehlermeldung steht. Naiv gelesen sieht alles davon nach einem Maklerhaus aus, das über Nacht alles verkauft hat. Die Importe prüfen daher jeden Feed, bevor sie handeln, und wenn etwas nicht stimmt, ändern sie nichts und melden es.
Die Daten darin sind genauso ungleichmäßig. Übersetzungen fehlen ohne Vorwarnung, dasselbe Feld kommt beim einen Objekt als einzelner Wert und beim nächsten als Liste, Beschreibungen kommen als ein Block, den verirrte Zeilenumbrüche zusammenhalten, und jedes CRM schreibt seine Datumsangaben anders. All das wird bereinigt und vereinheitlicht, bevor irgendetwas gespeichert wird. Die Website und der Kunde bekommen davon also nichts zu sehen.
05 / Laufende Arbeit
Import, Suche und Übersichtsseiten für das Maklerhaus in Barcelona stehen bereit, der Start der Website ist geplant.
Auf der Mallorca-Website liegt eine Überarbeitung der Geschwindigkeit von Such- und Übersichtsseiten zur Abnahme bereit.
06 / Kundenstimme
“Alexander hat für uns Add-ons entwickelt, die Drittanbieter-APIs anbinden. Sein Verständnis für unsere Anforderungen und die Qualität der gelieferten Arbeit waren hervorragend. Er hat ausgewiesene Expertise im Statamic- und Laravel-Umfeld gezeigt, und die Zusammenarbeit war durchweg positiv.”
Creative Director, DigitalHappy
07 / Mitwirkende
Gestaltet und gebaut wurden die Websites von DigitalHappy. Mein Teil war die hier beschriebene Arbeit im Backend.
08 / Nächster Schritt
Eure Website und Euer CRM sind sich uneinig?
Objekte, die nach dem Verkauf online bleiben, Preise, die voneinander abweichen, Übersetzungen, die nie ankommen. Nennt mir das CRM, mit dem Ihr arbeitet, und was in welche Richtung wandern muss. Das genügt, um den Abgleich zwischen beiden einzuschätzen.