Case Study: Wie ein Maklerbuero mit Knowledge Graph die Prozesszeit um 70% reduziert
Von 6 Stunden auf 108 Minuten pro Expose: Wie Context Injection — nicht ein besseres Tool — den entscheidenden Unterschied macht.
TL;DR
Context Injection (Knowledge Graph mit kodifiziertem Expertenwissen) reduzierte die Expose-Erstellung um 70% und steigerte den AI-Hebel um Faktor 11 — nicht durch ein besseres Modell, sondern durch strukturierten Kontext.
Wichtigste Erkenntnisse
70% Zeitreduktion
Expose-Erstellung von 6 Stunden auf 108 Minuten. 63 Stunden pro Monat zurueckgewonnen. ROI: 6-fach in drei Monaten.
Context, nicht Tools
11-fache Leverage-Steigerung. Nicht durch ein besseres Modell. Durch strukturierten Kontext, der vorher nur implizit existierte.
Der Engpass war nicht die Technologie
Der Engpass war die Interpretation: Welche Informationen gehoeren in welcher Form in das Expose? Das war Expertenwissen. Jetzt ist es Graph-Wissen.
Die Ausgangssituation
6 Stunden fuer ein Expose. Das war Normalitaet. Jetzt sind es 108 Minuten.
Das ist keine Marketing-Zahl. Das ist die gemessene Prozesszeit eines Maklerbueros in Norddeutschland, vor und nach der Implementierung einer Intelligence Layer.
Die Frage ist nicht "wie?". Die Frage ist "warum dauerte es vorher 6 Stunden?"
Die Diagnose: Wo war der Engpass?
Das Maklerbuero arbeitete mit einem Standard-CRM, hatte Zugang zu allen relevanten Daten, und die Mitarbeiter waren erfahren. Trotzdem dauerte jedes Expose 6 Stunden.
Der Grund war nicht Datenmangel. Es war der "Interpretation-Engpass": Die Daten existierten in verschiedenen Systemen (CRM, Kataster, Energieausweis, Fotos, Grundriss). Ein erfahrener Mitarbeiter musste sie zusammenfuehren, interpretieren, und in eine Expose-Struktur bringen.
Die Zeitverteilung:
- 2h Daten zusammensuchen (CRM, Portal, Unterlagen)
- 1.5h Informationen interpretieren und strukturieren
- 1.5h Text schreiben und formatieren
- 1h Review und Korrekturen
Der Engpass war nicht das Schreiben. Der Engpass war das Zusammensuchen und Interpretieren — 3.5 von 6 Stunden.
Die Loesung: Context Injection statt Tool-Wechsel
Der erste Impuls war: "Wir brauchen ein besseres CRM" oder "Wir brauchen eine AI, die Texte schreibt."
Beides haette das Problem nicht geloest. Ein besseres CRM haette die Daten schneller gezeigt — aber nicht die Zusammenhaenge. Eine Text-AI haette Exposees generiert — aber ohne das Kontextwissen.
Die Loesung war ein Knowledge Graph, der drei Dinge tat:
1. Objektwissen strukturiert speichern.
Nicht "Feld: Wohnflaeche = 120qm", sondern: Objekt → hat_Eigenschaft → Wohnflaeche_120qm → relevant_fuer → Familien_mit_Kindern → weil → Mindestanforderung_nach_Erfahrungswert.
2. Expose-Expertise kodifizieren.
Was macht ein gutes Expose? Durch strukturierte Interviews (Paarvergleich von 10 Exposees) wurden 12 Kerndimensionen extrahiert. 4 davon erklaerten 80% der Qualitaetsunterschiede.
3. Kontext an das LLM liefern.
Das LLM bekommt nicht "schreib ein Expose". Es bekommt: Hier sind alle relevanten Objektdaten (aus dem Graph), hier sind die 4 Qualitaetsdimensionen (aus dem Graph), hier ist die Zielgruppe (aus dem Graph). Schreib.
Die Ergebnisse
| Metrik | Vorher | Nachher | Delta |
|---|---|---|---|
| Expose-Erstellung | 6h | 1.8h (108 Min) | -70% |
| Daten zusammensuchen | 2h | 0.1h | -95% |
| Interpretieren/Strukturieren | 1.5h | 0.2h | -87% |
| Text schreiben | 1.5h | 0.8h | -47% |
| Review | 1h | 0.7h | -30% |
| Monatlich gespart (10 Exposees) | 63h | ||
| Monetaer (bei 50 EUR/h) | 3.150 EUR/Monat | ||
| ROI | 6-fach in 3 Monaten |
Die groesste Einsparung (95%) war beim Zusammensuchen — genau der Schritt, der vorher den Engpass bildete. Der Knowledge Graph eliminiert ihn fast vollstaendig.
Der Review-Schritt sank nur um 30%. Das ist beabsichtigt. Review ist ein Typ-2-Prozess: Agent schlaegt vor, Mensch entscheidet. Das ist kein Overhead — das ist ein Quality Gate.
Die Leverage-Analyse
Vorher: L = F(hoch) x r_context(0.1) x r_process(0.3) x r_action(0.5) = niedrig
Nachher: L = F(hoch) x r_context(0.8) x r_process(0.7) x r_action(0.7) = hoch
Die 11-fache Leverage-Steigerung kam primaer durch r_context — den Sprung von 0.1 auf 0.8. Nicht durch ein besseres Modell. Durch Context Injection.
Was haben wir gelernt?
1. Der Engpass ist selten dort wo man ihn vermutet.
Das Team dachte, der Engpass sei das Schreiben. Die Analyse zeigte: Es war das Zusammensuchen und Interpretieren. Ohne Diagnose haetten wir das falsche Problem geloest.
2. Implizites Wissen ist der groesste Hebel.
Die 12 Qualitaetsdimensionen des Senior-Maklers waren Gold. Aber sie existierten nur in seinem Kopf. Die Externalisierung dieses Wissens hat den groessten einzelnen Effekt auf die Qualitaet.
3. Automatisierung ist der letzte Schritt.
Die Reihenfolge war: Verstehen → Strukturieren → Vereinfachen → Automatisieren. Haetten wir direkt automatisiert, haetten wir einen schnelleren kaputten Prozess gebaut.
Takeaways
- Context schlaegt Modell. 11-fache Leverage-Steigerung durch r_context-Optimierung, nicht durch ein besseres LLM.
- Diagnose vor Intervention. 70% Zeitersparnis, weil wir den echten Engpass identifiziert haben, nicht den offensichtlichen.
- Expertenwissen ist kodifizierbar. 12 Dimensionen, 4 davon erklaeren 80% der Qualitaet. Das ist kein Verlust an Menschlichkeit — das ist die Skalierung von Expertise.
Häufig gestellte Fragen
Sind diese Zahlen repraesentativ?
Die 70%-Reduktion ist spezifisch fuer Expose-Erstellung mit diesem Profil (5 Mitarbeiter, 40 Objekte/Jahr, Standard-CRM). Bei anderen Prozessen und Profilen variiert das Ergebnis. Der Mechanismus — Interpretation-Engpass durch Context Injection loesen — ist repraesentativ fuer wissensintensive Prozesse.
Wie wurde das Expertenwissen extrahiert?
Paarvergleiche: Zwei Exposees nebeneinander, der Senior-Makler erklaert was das bessere besser macht. Ueber 10 solche Vergleiche kristallisierten sich 12 Dimensionen heraus. Das ist keine Befragung — es ist Verhalten beobachten und Kriterien destillieren.
Was kostet der Aufbau einer solchen Intelligence Layer?
Der ROI von 6-fach in drei Monaten erklaert sich dadurch, dass der Grossteil des Aufwands in der Wissens-Elicitation liegt — nicht in der Technologie. Die Technologiekosten (Neo4j, LLM-API) sind vergleichsweise gering.