Problem.
Die meisten Customer-Success-Dashboards hören bei der Erkenntnis auf. Sie zeigen CSMs, welche Accounts gefährdet sind, und überlassen das Handeln dem Menschen. Die Lücke zwischen "Ich sehe das Risiko" und "Ich habe etwas dagegen unternommen" ist genau da, wo Churn entsteht.
Force24 brauchte eine Account-Intelligence-Plattform für CSMs, Accounts und Stakeholder, die diese Lücke schließt. Ein System, das Daten aus dem Tech-Stack einliest, sie in analysetaugliche Kundensichten transformiert, handlungsrelevante Erkenntnisse sichtbar macht, das Handeln antreibt und das Ergebnis erfasst. Greenfield, 16 Wochen, gemeinsam mit dem Engineering-Team in eine Live-Produktionsumgebung ausgeliefert.
Mein Beitrag.
Datenebene (end-to-end verantwortet).
Force24 hat PostgreSQL als Warehouse vorgegeben. Jede andere Tool-Entscheidung auf der Datenebene war meine.
- Dagster für Orchestration gewählt, dbt für Transformation, das Layered-Warehouse-Muster (raw, staging, intermediate, marts) auf PostgreSQL.
- Jeden Python-Extractor gegen die Source-Systeme geschrieben, geplant und über Dagster orchestriert.
- Jedes dbt-Modell von Grund auf gebaut: Staging-Views, Intermediate-Business-Logic-Tabellen, kuratierte Marts. Tests, Dokumentation, Lineage inklusive.
- Jeden Dagster-Job geschrieben, Assets über das Warehouse materialisiert und die wiederkehrenden Runs geplant.
- Dagster auf einer VM mit Caddy davor aufgesetzt, für Admin-Authentication bei manuellen Runs neben dem automatisierten Schedule.
Service-Layer-Integration.
Die Datenebene in den FastAPI-Service eingebunden:
- Die Endpoints materialisiert, die Marts-Tabellen ans Frontend ausspielen.
- Redis für Caching eingeführt, wo die API zu oft auf das Warehouse zugegriffen hat.
- Die Scheduled Jobs für Batch-Operationen geschrieben.
Frontend (Angular).
Force24 hat Angular vorgegeben. Meine Frontend-Beiträge:
- Action Tracker (Lead-Feature, end-to-end verantwortet). CSMs erstellen Actions manuell für jeden Account, oder akzeptieren smart-suggested Actions, die das System auf Basis von Churn-Risiko und Account-Health-Score vorschlägt. Admins weisen Actions konkreten CSMs zu. Für jede zugewiesene Action folgt der CSM beim Account nach, hält Notizen zur Umsetzung fest und erfasst das Ergebnis.
- Die Smart-Suggestion-Logik materialisiert, die das Recommended-Action-Surface antreibt.
- Weitere Features und Erweiterungen über das Dashboard-Surface ausgeliefert, wo die Datenebene upstream Änderungen brauchte.
Cross-Layer-Integration.
Die Datenebene war das Rückgrat, aus dem sich der Rest der Plattform bedient hat. Wo immer eine Schicht etwas davon gebraucht hat, lag die Integrationsarbeit bei mir. Endpoint-Shapes, Materialisierungs-Strategien, Scheduling, Caching, Auth.
Warum der Action Tracker zählt.
Dashboards, die nur informieren, sind halbfertige Produkte. Der Action Tracker schiebt CSMs von der Awareness ins Handeln, erfasst das Ergebnis und macht aus dem Loop strukturierte Daten.
Operativ verhindert er verpasste Follow-ups, indem Ownership explizit und nachverfolgbar ist. Risiko wird zu Arbeit, die jemand verantwortet, bearbeitet und abschließt.
Architektonisch erzeugt er Action-Context-Outcome-Tripel, die mit Volumen zum gelabelten Trainingsdatensatz für ein kausales Modell werden, das Interventionen vorschreibt, statt nur Risiken zu markieren. Die aktuelle Plattform markiert. Die nächste Generation, gespeist mit diesen Daten, kann die spezifische Intervention empfehlen, die einen bestimmten Account am wahrscheinlichsten hält.
Architektur.
Drei Schichten. Stack-Vorgabe von Force24 (PostgreSQL als Warehouse, Angular als Frontend), freie Wahl beim Rest.
- Datenebene. Dagster-Orchestration auf einer VM mit Caddy-Auth, custom Python-Extractors gegen mehrere Source-Systeme, layered PostgreSQL Warehouse mit dbt über raw, staging, intermediate und marts.
- Service-Schicht. FastAPI-Backend mit meinen Beiträgen zu Data-Layer-Endpoints, Redis-Caching und Scheduled Jobs.
- Frontend. Angular-Dashboard mit Action Tracker plus weiteren Features und Erweiterungen, die ich ausgeliefert habe.
Docker hat das Ganze zusammengehalten. Das Dagster-on-VM-Automatisierungs-Framework war meines.
Lehren.
Die Datenebene ist unsichtbar, bis sie falsch ist. Diese hier habe ich mit der Lineage gebaut, die belegt, dass die Marts korrekt sind, mit der Orchestration, die jeden Re-Run von jedem Failure-Punkt erlaubt, und mit den Auth-Kontrollen, die manuelle Runs ermöglichen, ohne den automatisierten Schedule zu kompromittieren. Nichts davon ist glamourös. Alles davon ist, worauf der Rest der Plattform aufsetzt.
Dashboards, die nur informieren, sind halbfertige Produkte. Der Action Tracker hat mir beigebracht, Analytics-Surfaces um die Action zu designen, die sie auslösen sollen, nicht um die Daten, die sie anzeigen. Der First-Order-Gewinn ist operativ: CSMs arbeiten ihre Accounts, Admins verteilen die Last, Follow-ups gehen nicht mehr verloren. Der Second-Order-Gewinn ist analytisch: jede erfasste Action und jedes Ergebnis wird zu einem gelabelten Datenpunkt für die nächste Generation der Plattform. Beides gleichzeitig zu designen hat verändert, wie ich das Datenmodell geformt habe.
Cross-funktionale Zusammenarbeit ist eine eigene Disziplin. Die Integrationspunkte, wo meine Datenebene die API und das Frontend gespeist hat, waren die Stellen, an denen die meiste echte Koordination stattfand. Eine Schicht sauber zu verantworten ist das, was diese Übergänge funktionieren lässt.
Stack.
Dagster · dbt · PostgreSQL · Python · FastAPI · Redis · Angular · Docker · Caddy · Git