Account Intelligence Platform

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. Churn entsteht, wenn ein CSM das Risiko sieht, aber nicht handelt.

Force24 brauchte eine Account-Intelligence-Plattform für CSMs, Accounts und Stakeholder, die diese Lücke schließt. Die Plattform sollte Daten aus dem gesamten Tech-Stack einlesen, sie in analysetaugliche Kundensichten transformieren, handlungsrelevante Erkenntnisse sichtbar machen, zum Handeln auffordern und das Ergebnis erfassen. Wir haben sie als Greenfield-Projekt in 16 Wochen gebaut und 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 Orchestrierung gewählt, dbt für Transformation, das Layered-Warehouse-Muster (raw, staging, intermediate, marts) auf PostgreSQL.
• Jeden Python-Extractor gegen die Quellsysteme 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 im gesamten Warehouse materialisiert und die wiederkehrenden Runs geplant.
• Dagster auf einer VM mit Caddy davor aufgesetzt, für Admin-Authentifizierung 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 vom System vorgeschlagene Actions (Smart Suggestions), die auf Churn-Risiko und Account-Health-Score basieren. Admins weisen Actions konkreten CSMs zu. Für jede zugewiesene Action fasst der CSM beim Account nach, hält Notizen zur Umsetzung fest und erfasst das Ergebnis.
• Die Smart-Suggestion-Logik materialisiert, die die Ansicht für empfohlene Actions antreibt.
• Weitere Features und Erweiterungen über die Dashboard-Ansicht ausgeliefert, wo die Datenebene Upstream-Änderungen brauchte.

Cross-Layer-Integration.

Der Rest der Plattform nutzte die Daten aus der Datenebene. 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.

Ein Dashboard, das nur Daten anzeigt, hilft Nutzern nicht, danach zu handeln. Der Action Tracker fordert CSMs auf, auf erkannte Risiken zu reagieren, erfasst das Ergebnis und speichert jeden Schritt als strukturierte Daten.

Operativ verhindert er verpasste Follow-ups, indem er Ownership explizit und nachverfolgbar macht. Jedes Risiko wird zu einer Aufgabe mit einer verantwortlichen Person, die sie bearbeitet und abschließt.

Architektonisch erzeugt er Action-Context-Outcome-Tripel, die mit wachsendem Volumen zum gelabelten Trainingsdatensatz für ein kausales Modell werden, das Interventionen vorschreibt, statt nur Risiken zu markieren. Die aktuelle Plattform markiert Risiken. Eine künftige Version, die mit diesen Daten trainiert wird, kann die 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-Orchestrierung auf einer VM mit Caddy-Auth, eigenentwickelte Python-Extractors gegen mehrere Quellsysteme, PostgreSQL-Warehouse im Layered-Muster mit dbt über raw, staging, intermediate und marts.
• Service-Schicht. FastAPI-Backend mit meinen Beiträgen zu Endpoints der Datenebene, Redis-Caching und Scheduled Jobs.
• Frontend. Angular-Dashboard mit Action Tracker plus weiteren Features und Erweiterungen, die ich ausgeliefert habe.

Mit Docker habe ich alle drei Schichten gemeinsam betrieben. Das Dagster-on-VM-Automatisierungs-Framework war meines.

Ergebnisse.

• Über 40 dbt-Modelle auf einer deduplizierten Account-Spine.
• Fünf tägliche Dagster-Schedules.
• Etwa 95 Prozent geringere Kosten für den nächtlichen Betrieb, nachdem ich die hochvolumigen Revenue-Modelle als inkrementell auf einer Append-Only-Raw-Schicht neu aufgebaut habe.
• 123 dbt- und 82 pytest-Tests sichern jeden Build in GitHub Actions CI ab. Sie haben 22 Datenqualitätsfehler aus dem ersten Produktions-Release herausgehalten.
• Die Plattform läuft 24/7 bei null Infrastrukturkosten auf Oracle Cloud.

Erkenntnisse.

Nutzer bemerken die Datenebene erst, wenn sie falsche Zahlen liefert. Diese hier habe ich mit der Lineage gebaut, die belegt, dass die Marts korrekt sind, mit der Orchestrierung, die jeden Re-Run ab jedem Fehlerpunkt erlaubt, und mit den Auth-Kontrollen, die manuelle Runs ermöglichen, ohne den automatisierten Schedule zu kompromittieren. Der Rest der Plattform hängt von dieser Routinearbeit ab.

Ein Dashboard, das nur Daten anzeigt, hilft Nutzern nicht, danach zu handeln. Der Action Tracker hat mich gelehrt, Analytics-Ansichten um die Handlung zu gestalten, die der Nutzer ausführen soll, wobei die angezeigten Daten diese Handlung unterstützen. Der First-Order-Gewinn ist operativ: CSMs bearbeiten 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 · Oracle Cloud · GitHub Actions · Git