Property Decision Support
Immobilienberatung · Serviceplattform
Ich habe Property Decision Support für einen unabhängigen Immobilienberater entwickelt, der Käufer und Verkäufer auf Malta und Gozo begleitet.
[ Projektüberblick ]
Gute Immobilienberatung hängt stark vom Kontext ab. Käufer und Verkäufer brauchen unterschiedliche Unterstützung, während der Berater die wichtigsten Informationen vor dem Termin benötigt.
[ Zusammenarbeiten ]
Ich kann helfen, den Weg hinter der Leistung in ein Produkt zu übersetzen, das von Anfang bis Ende funktioniert.
Eine kommerzielle Serviceplattform mit getrennten Käufer- und Verkäuferprozessen, Online-Zahlung, geschütztem Buchungszugang, verfügbaren Terminen in Echtzeit, strukturiertem Intake, privaten Dokumenten-Uploads und transaktionaler Kommunikation.
Produktabläufe und UX/UI, Frontend und Backend, Buchungsarchitektur, Zahlungen, private Daten, Zugriffssicherheit, Terminplanung, Formulare, CMS-Architektur, Integrationen, SEO, Infrastruktur und Produktion.
[ Die Herausforderung ]
Property Decision Support ist bewusst keine Immobilienagentur, keine Maklerleistung, kein formelles Wertgutachten und keine technische Gebäudeprüfung. Der Berater arbeitet unabhängig für eine Seite der Entscheidung.
Ein Käufer möchte vielleicht verstehen, was vor einem Angebot noch unklar ist. Ein Verkäufer möchte wissen, was vor dem Marktstart vorbereitet werden sollte oder warum ein laufender Verkauf an Dynamik verliert.
Die Website musste deshalb die Leistung erklären, die passende Unterstützung zeigen, die Zahlung abwickeln und gleichzeitig genug Kontext in den eigentlichen Termin tragen. Ich habe die Buchung als durchgängigen Prozess gebaut und nicht als getrennte Website-, Checkout-, Kalender- und Formularfunktionen.
[ Käufer und Verkäufer brauchen unterschiedliche Abläufe ]
Die einfachste Lösung wäre ein allgemeines Immobilienformular gewesen, bei dem einige Felder je nach Leistung ein- oder ausgeblendet werden. Dagegen habe ich mich bewusst entschieden.
Bei einem Käufer sind die Immobilie, der Angebotspreis, die Finanzierung, ein bereits abgegebenes Angebot, der aktuelle Stand im Kaufprozess, offene Fragen und persönliche Bedenken relevant.
Ein Verkäufer bringt einen anderen Kontext mit: Eigentumsverhältnisse, Verkaufsstatus, Angebotspreis, bekannte Probleme, frühere Einwände von Interessenten, bereits ausgeführte Arbeiten und das gewünschte Ergebnis.
Diese Unterschiede enden nicht im Frontend. Käufer- und Verkäuferdaten werden auch im Backend getrennt validiert und modelliert. Die öffentliche Kommunikation folgt derselben Logik: fundierter entscheiden für Käufer, bessere Vorbereitung und mehr Kontrolle für Verkäufer.
[ Eine Zahlung musste die richtige Buchung freischalten ]
Bevor der Checkout startet, legt die Anwendung eine eigene Buchungsreferenz mit Leistung und erwartetem Betrag an. Diese Referenz wird an Stripe weitergegeben.
Die Rückkehr des Browsers vom Checkout reicht nicht aus, um eine Buchung als bezahlt zu behandeln. Der Server muss prüfen, welche Buchung bezahlt wurde und ob die Zahlung zu den erwarteten Daten passt.
Der Stripe-Webhook prüft Buchungsreferenz, Zahlungsstatus, Betrag und Währung, bevor der Buchungsstatus geändert wird. Bereits verarbeitete Webhook-Events werden berücksichtigt, weil Stripe dasselbe Event erneut senden kann. Zustandsänderungen sind zusätzlich gegen konkurrierende Requests geschützt.
Erst nach bestätigter Zahlung wird der nächste Teil des Ablaufs freigeschaltet.
Leistung auswählen
[ Inhalte und Kundendaten brauchen eine klare Trennung ]
Eine Buchung kann Kontaktdaten, Immobilienadressen, Preisvorstellungen, Finanzierungsstatus, den Stand der Transaktion, persönliche Bedenken und Zugangsinformationen enthalten. Zusätzlich können Kunden Dokumente für die Vorbereitung des Termins hochladen.
Öffentliche Inhalte
Website & CMS
Private Vorgänge
Buchungs- und Kundendaten
Private Dateien
Kundendokumente
Öffentliche Inhalte
Website & CMS
Private Vorgänge
Buchungs- und Kundendaten
Private Dateien
Kundendokumente
Stripe verarbeitet Zahlungen, Cal kümmert sich um Verfügbarkeiten und Termine, Resend um transaktionale E-Mails. Jeder Dienst bleibt auf seine Aufgabe begrenzt.
[ Die Vorbereitung beginnt vor dem Vor-Ort-Termin ]
Nach bestätigter Zahlung und verifiziertem Zugriff sieht der Kunde die verfügbaren Termine und wählt einen passenden Slot. Danach folgt je nach Leistung der Käufer- oder Verkäufer-Intake.
Das Formular ist bewusst ausführlich, weil jede Information einen konkreten Zweck erfüllt. Der Berater soll vor dem Termin wissen, wo der Kunde im Prozess steht, was bereits geklärt ist, wo Unsicherheit besteht und worauf besonders geachtet werden sollte.
Uploads werden nicht nur im Browser geprüft. Auch auf dem Server werden Dateigröße und Formate validiert. Zusätzlich wird der tatsächliche Dateiinhalt geprüft, statt nur Dateiname oder MIME-Type zu vertrauen.
Nach erfolgreicher Übermittlung wird der Termin mit Buchung, Kundendaten und Intake verknüpft. Wenn der Berater den Termin öffnet, sollte der organisatorische Teil bereits erledigt sein.
[ Was in Produktion zusätzlich passieren kann ]
Keines dieser Probleme gehört nur zu einem einzelnen Screen. Deshalb wird der Buchungsstatus zentral geführt. Das Backend entscheidet anhand dessen, was bereits passiert ist, welche Aktion als Nächstes erlaubt ist.
Dazu gehören Zahlungsstatus, Zugriff und Session, gebuchte Leistung, Terminstatus und der Stand der finalen Übermittlung. Für eine einmalige Beratung braucht der Kunde kein dauerhaftes Konto: Der Zugriff arbeitet mit zeitlich begrenzten Zugangsdaten und einer kurzen authentifizierten Session.
Rückerstattungsanfragen werden einer bestehenden Buchung zugeordnet und über die hinterlegte E-Mail verifiziert.
[ Das Ergebnis ]
Ein Kunde kann die passende Leistung verstehen, bezahlen, einen Termin wählen und den Vor-Ort-Besuch vorbereiten, ohne dass zwischen jedem Schritt ein manueller Übergang nötig ist.
Der Berater erhält den Termin zusammen mit dem notwendigen Kontext, statt Zahlung, Kalendereintrag, E-Mail-Verlauf, Formular und Dokumente selbst zusammenzuführen.
Die öffentliche Website bleibt über Sanity editierbar. Private Buchungsdaten und Unterlagen bleiben davon getrennt im operativen Teil des Systems.
[ Mein Anteil ]
Ich habe zunächst definiert, wie die Dienstleistung online funktionieren soll, und diesen Ablauf durch Produktdesign, Frontend, Backend, Datenarchitektur und Produktion umgesetzt.
Dazu gehörten Käufer- und Verkäuferprozesse, Zahlungs- und Buchungsstatus, das Modell für private Daten, sicherer Buchungszugriff, Kalenderintegration, strukturierter Intake, private Dateiablage, transaktionale E-Mails, Sanity-Content-Architektur, Recht und Consent, SEO sowie Deployment und Infrastruktur.
[ Technologien ]
Käuferkontext
Verkäuferkontext
Sicher bezahlen
Zahlung bestätigt
Zahlung nicht abgeschlossen
Kein Buchungslink
Buchungslink erhalten