Die Immobilie zu kennen heißt noch nicht, dass man weiß, wie man sie verkauft.dass man weiß, wie man sie verkauft.

Ich habe mit der echten Aufgabe des Verkäufers begonnen und nicht mit der fertigen Immobilienanzeige.

Die Immobilie durchläuft zuerst einen Vorbereitungsprozess, bevor sie für Käufer sichtbar werden sollte. Der Verkäufer hat zwei Wege, um dorthin zu kommen.

Der manuelle Weg führt Schritt für Schritt durch die wichtigsten Daten, Preis, Standort, Räume, Gebäudedetails, Energieinformationen, Medien, Dokumente, Sichtbarkeit und Kontakt-Einstellungen. Pflichtfelder werden in jedem Schritt geprüft, damit der Verkäufer erst weitergehen kann, wenn dieser Teil der Immobilie vollständig ist.

Der zweite Weg ist Sellumo. Statt die Immobilie nur über ein Formular zu bearbeiten, kann der Verkäufer sie in normaler Sprache beschreiben und über das Gespräch denselben strukturierten Immobilienzustand aufbauen.

Dieser Weg bringt eine andere Art von Wert. Eine Information zu kennen und zu wissen, wie man sie gut präsentiert, sind zwei verschiedene Dinge. Ein Verkäufer weiß vielleicht, dass die Heizung erneuert wurde, dass der Garten am Nachmittag Sonne bekommt oder dass eine bestimmte Renovierung wichtig ist. Sellumo kann helfen, daraus eine klarere Präsentation für Käufer zu machen, wichtige Details hervorzuheben und die Vorbereitung weniger technisch wirken zu lassen.

Beide Wege arbeiten mit demselben Immobilienmodell. Der Unterschied ist nur, wie der Verkäufer seine Immobilie vorbereiten möchte.

Auch Verkäufer- und Käuferseite arbeiten mit diesem gemeinsamen Modell. Der Verkäufer sieht den privaten Vorbereitungsstand, während der Käufer später nur die freigegebene Darstellung auf dem Marktplatz sieht. Nachrichten, Benachrichtigungen und AI können dadurch dieselbe Immobilie nutzen, ohne mehrere Versionen der Wahrheit zu erstellen.

Ein Käufer kann den Eigentümer direkt über eine Immobilie kontaktieren, aber ich habe diese erste Interaktion nicht sofort als offenen Chat aufgebaut.

Die erste Nachricht erstellt eine Kontaktanfrage zu genau dieser Immobilie, und das Gespräch beginnt mit dem Status „ausstehend“. Der Verkäufer bekommt damit einen klaren Entscheidungspunkt: Anfrage annehmen und weiterschreiben oder ablehnen, ohne dass jede Anfrage automatisch zu einem aktiven Gespräch wird.

Nach der Annahme wird derselbe Thread zum gemeinsamen Kommunikationsbereich für Käufer, Verkäufer und Immobilie. Die Anwendung kann dadurch zwischen neuem Interesse, angenommenem Kontakt, abgelehntem Kontakt und laufender Kommunikation unterscheiden, statt jede Nachricht gleich zu behandeln.

Bevor Gesprächsdaten zurückgegeben werden, prüft das Backend, ob der aktuelle Nutzer wirklich Teil dieses Gesprächs ist. Die Anfrage bleibt außerdem mit der Immobilie verbunden, über die sie erstellt wurde. Diese Verbindung wird an vielen Stellen im Produkt wichtig: Benachrichtigungen wissen, zu welcher Immobilie eine Anfrage gehört, der Verkäufer versteht den Kontext des Käufers, und spätere Analysen können die Interaktion zusammen mit der jeweiligen Immobilie auswerten.

Nach der Annahme einer Anfrage verhält sich das Produkt wie ein echter Chat und nicht wie ein Kontaktformular mit einem Nachrichtenverlauf darunter.

Nachrichten kommen über private Realtime-Kanäle an. Beide Seiten können sehen, ob die andere Person online ist, gerade schreibt und ob eine gesendete Nachricht gelesen wurde. Die Oberfläche aktualisiert sich für den Absender sofort, während das Backend weiterhin dafür verantwortlich ist, die Nachricht zu speichern und den Gesprächsstatus zu aktualisieren.

Der Online-Status ist mehr als nur ein UI-Detail. Dieselbe Information hilft später bei der Entscheidung, ob eine weitere Benachrichtigung oder E-Mail überhaupt noch sinnvoll ist. Wenn der Empfänger bereits im Gespräch ist, sollte sich das System nicht so verhalten, als wäre diese Person nicht da.

Auch den Nachrichtenverlauf habe ich als nutzerspezifischen Zustand behandelt. Ein Teilnehmer kann eine einzelne Nachricht aus seiner eigenen Ansicht entfernen, ohne zu verändern, was die andere Person sieht. Ein Absender kann seine eigene Nachricht für beide Seiten löschen, und mehrere Nachrichten können gemeinsam ausgewählt und entfernt werden. Auf Gesprächsebene kann jeder Teilnehmer den Thread unabhängig archivieren, und eine neue Nachricht kann ein archiviertes Gespräch wieder in den aktiven Bereich bringen.

Diese Details haben Messaging zu einem eigenen Produktbereich gemacht: Realtime-Zustellung, Berechtigungen, Schreiben- und Online-Status, Lesestatus, persönlicher Verlauf und gemeinsamer Gesprächsstatus mussten zusammenpassen.

Im Kommunikationssystem entstehen unterschiedliche Ereignisse. Die erste Nachricht kann eine neue Kontaktanfrage sein, spätere Nachrichten sind normale Gesprächsereignisse, und auch das Annehmen oder Ablehnen einer Anfrage erzeugt einen neuen Status, über den die andere Seite Bescheid wissen sollte.

Ich habe die Benachrichtigungen um genau diese Unterschiede aufgebaut. Eine Benachrichtigung kann Informationen zur Person, zum Gespräch, eine kurze Vorschau der Nachricht und den Immobilienkontext enthalten. Nutzer können außerdem festlegen, ob Nachrichten und Kontaktanfragen zusätzlich per E-Mail ankommen sollen.

Die interessantere Entscheidung war, wann keine Benachrichtigung nötig ist. Bevor das System eine weitere Gesprächs-Benachrichtigung erstellt, prüft es, ob der Empfänger online ist und genau dieses Gespräch gerade geöffnet hat. Wenn ja, würde eine weitere Benachrichtigung nur mehr Lärm bringen, aber keine neue Information.

So reagiert das Produkt auf das, was passiert ist, ohne zu ignorieren, was der Nutzer gerade schon macht.

Für jede Nachricht sofort eine E-Mail zu senden, wäre einfach gewesen. Es hätte Messaging aber direkt von einem externen Zustelldienst abhängig gemacht und aus einigen schnellen Chat-Nachrichten schnell mehrere E-Mails gemacht.

Ich habe diese Wege getrennt.

Wenn eine Offline-Benachrichtigung eventuell eine E-Mail braucht, erstellt die Anwendung einen geplanten Zustell-Eintrag mit eigener Zeit und eigenem Status. Ein Background Worker verarbeitet ihn später, wenn das System genug Kontext hat, um zu entscheiden, ob die E-Mail noch sinnvoll ist.

Vor dem Versand prüft der Worker die Einstellungen des Nutzers erneut, kontrolliert, ob die Person wieder online ist, gruppiert zusammengehörende Ereignisse nach Gespräch, unterdrückt wiederholte E-Mails innerhalb eines Anti-Spam-Zeitraums und erstellt eine kompakte Nachricht, statt jedes Ereignis als eigene E-Mail zu behandeln.

Jeder Queue-Eintrag erhält einen klaren Status wie gesendet, übersprungen oder fehlgeschlagen. Zustellprobleme können dadurch überwacht und erneut versucht werden, ohne den eigentlichen Chat zu beeinflussen.

Beim Löschen eines Gesprächs gibt es zwei verschiedene Aufgaben.

Wenn ein Teilnehmer einen Thread löscht, kann die Anwendung ihn aus dessen Arbeitsbereich entfernen, ohne das gemeinsame Gespräch sofort auch für die andere Person zu zerstören. Erst wenn auch der letzte Teilnehmer es löscht, geht das Gespräch in einen eigenen Archivierungsprozess, statt direkt im Request gelöscht zu werden.

An diesem Punkt kann eine asynchrone AI-Analyse mit dem Gespräch und einer reduzierten Momentaufnahme der betreffenden Immobilie arbeiten. Diese Momentaufnahme lässt einige operative oder sensible Felder weg, enthält aber genug Kontext, um zu verstehen, ob die Fragen und Einwände des Käufers sowie die Antworten des Verkäufers zur Immobilie gepasst haben.

Das Ergebnis ist keine weitere Kopie des Live-Chats. Es ist ein kleinerer, strukturierter Datensatz mit den wichtigen Signalen aus der Interaktion: Wie hat sich das Gespräch entwickelt? Was war dem Käufer wichtig? Gab es eine Verhandlung? Welche Stärken der Immobilie wurden genutzt oder übersehen? Wie klar hat der Verkäufer geantwortet? Und wie sieht das wahrscheinliche Ergebnis aus?

Diese Signale können später Produktanalysen, Evaluationen und Seller-Coaching unterstützen, ohne dass rohe Chat-Verläufe dauerhaft die Grundlage für Analysen bleiben müssen.

Erst nachdem der strukturierte Archiv-Datensatz erstellt wurde, verlässt das operative Gespräch die Live-Messaging-Daten. Der abgeleitete Datensatz folgt danach seinem eigenen Aufbewahrungsprozess.

So entsteht eine klarere Trennung zwischen Kommunikationsdaten, die für das Gespräch gebraucht werden, und abgeleiteten Erkenntnissen, die einen anderen Zweck haben, kleiner sein sollten und separat verwaltet werden.

Der Verkäufer sollte nicht wissen müssen, welche interne Funktion eine Anfrage bearbeitet. Für ihn ist es ein Gespräch. Im Hintergrund haben Immobilienerstellung, Marktrecherche und allgemeine Unterstützung für Verkäufer aber unterschiedliche Datenanforderungen und unterschiedliche Rechte.

Ich habe deshalb eine Orchestrierungsschicht zwischen der Verkäufer-Erfahrung und diesen Funktionen aufgebaut.

Bevor das System entscheidet, wer eine Nachricht bearbeitet, lädt es den passenden Verkäufer- und Produktkontext. Dazu gehören die aktive Immobilie, die dauerhafte Seller Memory und ein strukturierter Workflow, falls bereits einer läuft. Wenn der Verkäufer mitten in einer Aufgabe ist, kann dieser Workflow zuerst fortgesetzt werden, bevor die Nachricht als komplett neue Anfrage behandelt wird.

Bei neuen Anfragen nutzt das Routing das stärkste vorhandene Signal. Eine klare Aktion im Produkt kann die Absicht direkt mitgeben. Eindeutige Fälle werden deterministisch geroutet. Eine Modell-Klassifizierung wird nur für wirklich unklare Anfragen verwendet.

So wird kein zusätzlicher Modellaufruf für eine Entscheidung verbraucht, die das Produkt bereits kennt, während normale Sprache weiterhin flexibel verarbeitet werden kann.

Auch der Orchestrierungsweg ist sichtbar. Die Anwendung speichert, welche Route die Anfrage bearbeitet hat, woher die Routing-Entscheidung kam und ob ein Workflow gestartet oder fortgesetzt wurde. Wenn etwas schiefgeht, kann ich den Weg prüfen, statt das Problem nur als „die AI hat schlecht geantwortet“ zu sehen.

Sellumo ist ein zusätzlicher Weg zur Erstellung neben dem geführten manuellen Ablauf und kein Ersatz dafür.

Gerade bei der Immobilienerstellung stößt ein einfacher Chatbot-Ansatz schnell an Grenzen.

Ein Verkäufer kann mehrere wichtige Fakten in einem Satz nennen, ein Pflichtfeld auslassen, nur einen Teil einer Rückfrage beantworten oder später zurückkommen und weitermachen. Das Produkt braucht trotzdem zuverlässige, strukturierte Daten, bevor eine Immobilie erstellt werden kann.

Ich habe diesen Ablauf deshalb als fortsetzbaren Workflow aufgebaut und nicht als eine lange AI-Generierung. Das System liest die Informationen aus der letzten Nachricht und verbindet sie mit dem bereits gesammelten Zustand. Danach prüft normale Anwendungslogik diesen gesamten Zustand gegen die Pflichtfelder des Immobilienmodells.

Wenn etwas fehlt, pausiert der Workflow und fragt nur nach den noch fehlenden Informationen. Der bisherige Zustand wird gespeichert. Sobald der Verkäufer antwortet, wird derselbe Workflow fortgesetzt, ergänzt die neuen Informationen und prüft erneut. Erst wenn alle notwendigen Daten vollständig sind, darf der Workflow die kontrollierte Produktaktion aufrufen, die den Immobilienentwurf erstellt.

Dasselbe Immobilienmodell behandelt Energieinformationen als strukturierte Daten und unterstützt Dokumente wie Grundrisse, Energieausweise und andere Dateien, die mit der Immobilie verbunden sind. Damit gibt es eine gute Grundlage, um die Erstellung mit Dokumenten später natürlicher zu machen, ohne hochgeladene Dateien automatisch als sichere Wahrheit zu behandeln.

Optionale Unsicherheit darf optional bleiben. Pflichtdaten nicht.

Beim Preis kann sich ein privater Verkäufer sehr sicher fühlen und trotzdem falsch liegen. Eine Zahl aus dem Verkauf des Nachbarn, den Renovierungskosten oder einigen Anzeigen reicht allein nicht aus.

Ich habe die Markt-Funktion so gebaut, dass eine Preiseinschätzung erst nach aktuellen Belegen kommt. Wenn der Verkäufer wissen möchte, was die Immobilie wert sein könnte, Hilfe beim Angebotspreis braucht oder bereits einen Preis im Kopf hat, recherchiert der Agent zuerst den aktuellen Markt rund um diese Immobilie.

Die Recherche arbeitet mit Standort und Immobilientyp und sucht nach den relevantesten verfügbaren Informationen in Stadt, Bezirk oder Nachbarschaft. Dazu gehören €/m²-Spannen und lokale Vergleichssignale. Wenn der erste Rechercheweg zu wenig oder unvollständige Daten liefert, kann das System die aktuelle Recherche erweitern, statt auf Modellwissen zurückzufallen.

Aktualität und lokaler Bezug sind beide Pflicht. Wenn nicht genug aktuelle Informationen für eine sinnvolle Aussage vorhanden sind, soll das System das klar sagen, statt eine genaue Zahl zu erfinden.

Wenn der Verkäufer noch keinen Angebotspreis hat, wird die lokale Spanne zum Ausgangspunkt. Sellumo kann erklären, wo vergleichbare Immobilien liegen, welche Eigenschaften diese Immobilie innerhalb der Spanne nach oben oder unten bewegen könnten und welcher Einstiegspreis sinnvoll sein könnte.

Wenn bereits ein Preis vorhanden ist, berechnet das System die €/m²-Position der Immobilie, vergleicht sie mit der aktuellen lokalen Spanne und ordnet den Angebotspreis als unter, im oder über dem Markt ein. Sellumo erklärt danach, was diese Position für Nachfrage, Vermarktungsdauer, möglichen liegen gelassenen Wert und Verhandlungsspielraum bedeuten kann.

Die Aufgabe des Modells beginnt erst nach den Belegen. Es verbindet aktuelle Marktinformationen mit der konkreten Immobilie und macht daraus eine Erklärung, mit der der Verkäufer arbeiten kann.

Der Verkaufsprozess passiert nicht in einer einzigen Chat-Sitzung.

Die Vorbereitung einer Immobilie kann Tage oder Wochen dauern, und die Fragen verändern sich mit dem Fortschritt des Verkaufs. Der Verkäufer sollte nicht bei jedem neuen Besuch wieder dieselbe Immobilie, dasselbe Ziel oder dieselben Vorlieben erklären müssen.

Die Memory-Architektur trennt deshalb mehrere Arten von Kontext. Aktuelle Nachrichten halten die direkte Unterhaltung fest. Structured Working Memory speichert nützlichen Verkäufer-Kontext wie die aktive Immobilie, den Stand der Vorbereitung, fehlende Informationen, Verkaufsziele, Zeitraum, Kommunikationswünsche und wichtige Meilensteine.

Semantic Recall kann frühere relevante Momente wieder hervorholen, wenn sie später nützlich werden. Observational Memory ergänzt das, indem längere Gesprächsverläufe in wichtigere Beobachtungen zusammengefasst werden, statt den Haupt-Agenten jedes rohe Gespräch immer wieder neu lesen zu lassen.

Dadurch fühlt sich die Nutzung zusammenhängender an. Sellumo kann behalten, was bereits beantwortet wurde, wichtige Ziele im Blick behalten und die Kommunikation anpassen, ohne dass Memory zu einer weiteren Quelle für Produktwahrheit wird.

Eine gespeicherte Vorliebe kann den Ton oder die Detailtiefe beeinflussen. Sie darf aber keine Berechtigung umgehen, keine Immobiliendaten ändern und keine aktuellen Marktinformationen ersetzen.

Die Plattform hat mehrere mögliche Fehlerbereiche: Browser-Fehler, API-Fehler, Hintergrundzustellung, Performance-Probleme, falsches AI-Routing, Workflow-Fehler und schwache Tool-Ergebnisse. Ich habe das Monitoring um diese Bereiche aufgebaut und mich nicht nur auf normale Application Logs verlassen.

Auf der Client-Seite erfasst das Produkt Browser-Fehler, unbehandelte Promise Rejections, Verstöße gegen Sicherheitsrichtlinien, Seitenverhalten und Dead-Click-Signale. Session Replay kann zusätzlichen Kontext liefern, wenn ein Problem schwer nachzustellen ist. Sensible Bereiche können dabei ausgeblendet werden.

Serverseitige Fehler nutzen einen eigenen Reporting-Weg für kurze Serverless-Requests. Dadurch können wichtige Fehler erfasst werden, ohne dass das Monitoring selbst den Request kaputtmacht. Real-User-Performance-Monitoring ergänzt Ladezeit, Reaktionsfähigkeit und Layout-Stabilität aus der echten Nutzung statt nur aus lokaler Entwicklung.

Auch der AI-Pfad hat eigene Telemetrie für Routing, gewählte Absicht, Quelle der Route, Confidence wenn vorhanden und den aktiven Workflow-Status. Wenn Sellumo sich falsch verhält, kann ich prüfen, ob das Problem beim Routing, im Workflow-Zustand, bei einem Tool-Aufruf oder in der zuständigen Funktion entstanden ist.

Hintergrundsysteme speichern ebenfalls einen klaren operativen Zustand. Ein E-Mail-Fehler macht eine erfolgreich gesendete Chat-Nachricht nicht rückgängig. Jobs für Gesprächsanalysen können erneut versucht werden. Die Marktrecherche kann einen anderen aktuellen Datenweg nutzen. Für die AI gibt es außerdem einen Fallback-Modellpfad, der mit derselben Seller Memory weiterarbeiten kann.

Diese Signale helfen nicht nur bei Fehlern. Wiederholte Probleme, langsame Wege, falsche Routing-Entscheidungen und AI-Fehler werden zu konkreten Hinweisen für die nächste Produkt- oder Evaluation-Änderung.