Floke/Brancheneinstufung2
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
dbc3ce9b34537de7f53ada6c3b5fdc70f30b7ea0
Brancheneinstufung2/Notion_Dashboard.md

9.7 KiB
Raw Blame History

Dokumentation: RoboPlanet Strategic Marketing OS (v1.0)

1. Vision & Primärauftrag

Das RoboPlanet Strategic Marketing OS ist kein reines Content-Tool, sondern das digitale Zentralnervensystem für das Growth-Marketing der RoboPlanet GmbH (Wackler Group). Es transformiert unstrukturierte Herstellerdaten und Marktschmerz-Analysen in eine skalierbare, hochgradig personalisierte Go-to-Market-Maschine.

Kern-Mission:

  • Whale Hunting: Identifikation und Durchdringung von Großkunden (Logistik >10k m², Chemieparks, Malls).
  • Wackler-Symbiose: Integration des menschlichen Service-Layers (NSL, Reinigung, Security) in das Robotik-Versprechen.
  • Hyper-Skalierung: Reduktion des Aufwands pro Kampagne bei gleichzeitiger Steigerung der Relevanz (Precision Targeting).

2. System-Architektur (The Big Picture)

Das System basiert auf einer Decoupled Architecture:

  1. The Intelligence Factory (Backend): Python-Services (Docker, SQLite) für Scraping, Data Mining, Normalisierung und KI-Generierung.
  2. The Strategic Hub (Frontend/Control): Notion als Single Source of Truth (SSoT) für Strategie, Portfolio-Management und Reporting.
  3. The Execution Channels (Outbound): SuperOffice API (CRM/Mails), WordPress API (Public Web), Messaging Matrix (Automation).

3. Funktionsmodule (Detaillierte Beschreibung)

3.1 Product Master (Hardware Truth)

Zentrale Instanz für alle technischen Spezifikationen.

  • Funktion: Automatisierte Extraktion von harten Fakten aus Hersteller-Quelltexten.
  • Normalisierung: Umwandlung heterogener Daten (z.B. "1:30h" -> 90 Min, "3000 sqm/h" -> 3000) zur direkten Vergleichbarkeit.
  • Zukunftsfähigkeit: Modularer Aufbau durch "Layer-Logik" (Cleaning-Layer, Service-Layer, Security-Layer).

3.2 Sector & Persona Master (Psychology Layer)

Das "Gehirn", das früher in YAML-Dateien gefangen war.

  • Sektoren: Definition der Zielbranchen (Hotellerie, Chemie, etc.) inklusive der "RoboPlanet-Definition" (Was bedeutet diese Branche für uns?).
  • Personas: Psychologische Profile (Housekeeping, Werkschutz, CEO) mit spezifischen Pains (Mirror) und Gains (Value).
  • Probing Questions: Branchenspezifische Fragen, die das Scraping-Tool leiten (z.B. "Hat das Hotel einen Spa?").

3.3 Messaging Matrix (The Secret Sauce)

Die Schaltstelle für die hyper-personalisierte Ansprache.

  • Logik: Trennung in Satz 1 (Individueller Hook basierend auf der aktuellen Website-Analyse des Zielkunden) und Satz 2 (Relationaler Lösungsbaustein basierend auf Branche + Produkt).
  • Voice-Ready: Vorbereitung von Skripten für den zukünftigen Voice-KI-Einsatz im Vertrieb und Support.

3.4 Competitive Radar (Market Intelligence)

Automatisierte Überwachung der Marktbegleiter.

  • Funktion: Kontinuierliches Scraping von Wettbewerber-News und Blogposts.
  • Kill-Argumente: Direkte Gegenüberstellung technischer Specs zur Erstellung von Battlecards für den Sales-Außendienst.

3.5 Enrichment Factory & RevOps

Datenanreicherung der CRM-Accounts.

  • Mining: Suche nach Umsatz, MA-Zahlen und fehlenden Ansprechpartnern via LinkedIn/SerpAPI.
  • Klassifizierung: Automatisches Mapping von Jobtiteln zu definierten Rollen im Strategic OS.
  • Reporting: Aggregation von Outbound-Metriken (Mails sent, Response Rate) zurück nach Notion für das C-Level.

4. Workflows & Datenflüsse

A. Der GTM-Prozess (Produkt-Launch)

  1. Ingest: Hersteller-URL wird in die GTM-Engine eingespeist.
  2. Extraction: Technische Specs werden normalisiert und in den Notion Product Master geschrieben.
  3. Positioning: KI matcht Specs gegen die Market Psychology DB in Notion.
  4. Generation: Erstellung von Website-Inhalten (WordPress API) und Sales-Battlecards.

B. Der Outbound-Prozess (Whale Hunting)

  1. Scanning: Enrichment-Tool liest Ziel-Accounts aus SuperOffice.
  2. Hyper-Personalization:
    • KI analysiert Kunden-Website -> Generiert Satz 1 (Operative Herausforderung).
    • System zieht Satz 2 aus der Messaging Matrix in Notion.
  3. CRM-Injection: Der finale Text wird via API in SuperOffice injiziert.
  4. Execution: Vertrieb sendet hochgradig relevante Mails direkt aus dem gewohnten CRM.

5. Outside-the-Box Hebel (Ausblick 6-12 Monate)

5.1 The Brain (Knowledge Ingestor)

Befreiung von implizitem Wissen aus WhatsApp/E-Mail-Silos. Ein Postfach-Scraper extrahiert Lösungsfragmente der Techniker und führt sie in Notion als strukturierte Wissensbasis für Support und RAG-Systeme zusammen.

5.2 Voice-Bot Integration

Nutzung der Voice Script Felder in der Messaging Matrix zur Speisung von AI-Voice-Agenten für Erstqualifizierung und Terminvereinbarung.

5.3 Combat View (Mobile Enablement)

Reduzierte Notion-Ansicht für Vertriebler vor Ort, die basierend auf dem Standort/Kunden-Sektor sofort die 3 schlagkräftigsten Verkaufsargumente liefert.

6. Notion Datenbank-Relationen (Technisches Mapping)

Um die relationale Integrität zu wahren, sind folgende Datenbanken in Notion zwingend zu verknüpfen:

  • Product Master \leftrightarrow Sector Master (Welcher Roboter passt in welchen Markt?)
  • Messaging Matrix \leftrightarrow Product Master (Welche Lösung gehört zum Text?)
  • Messaging Matrix \leftrightarrow Sector Master (Welcher Schmerz gehört zu welcher Branche?)
  • The Brain \leftrightarrow Product Master (Welches Support-Wissen gehört zu welcher Hardware?)
  • GTM Workspace \leftrightarrow Product Master (Welche Kampagne bewirbt welches Gerät?)

7. Zusammenfassung der technischen Hebel

  1. Python API Gateway: Einziger Kommunikationspunkt für alle KI-Anfragen und CRM/WP-Transaktionen.
  2. SQLite Persistence: Lokales Zwischenlagern von Scrape-Ergebnissen zur Vermeidung redundanter API-Kosten.
  3. Human-in-the-loop: Notion dient als "Freigabe-Layer" – erst nach manuellem Review in Notion triggert Python den CRM-Push oder den Website-Publish.

8. Lessons Learned & Technische Constraints (Stand Jan. 2026)

Während der initialen Prototyping-Phase wurden kritische technische Hürden identifiziert, die bei der finalen Implementierung (insb. via Gemini CLI) proaktiv adressiert werden müssen.

8.1 API-Latenz & „Eventual Consistency“

  • Problem: Wenn eine Datenbank via API erstellt wird, meldet Notion sofort den Erfolg (200 OK). Die internen Indizes der Spalten (Properties) sind jedoch oft erst 15–30 Sekunden später für Schreibzugriffe (pages.create) bereit.
  • Lösung: Nach DDL-Operationen (Erstellen/Ändern von Datenbank-Strukturen) muss zwingend ein Wait-Timer (min. 15s) eingebaut werden, bevor Daten in diese Struktur injiziert werden.

8.2 SDK vs. Native REST

  • Erkenntnis: Das offizielle Python-SDK (notion-client) verhielt sich auf der Server-Umgebung (Diskstation/Python 3.8) instabil und meldete fehlende Methoden (z.B. .query), die laut Dokumentation vorhanden sein sollten.
  • Lösung: Für geschäftskritische Prozesse und Massen-Injektionen ist der direkte Weg über die REST-API (Python requests Bibliothek) vorzuziehen. Dies eliminiert Abhängigkeiten und bietet volle Transparenz über die Fehlermeldungen von Notion.

8.3 Suchindex-Verzögerung

  • Problem: Neu erstellte Datenbanken tauchen erst mit erheblicher Verzögerung im notion.search-Index auf. Skripte, die Datenbanken „dynamisch suchen“, schlagen in der Deployment-Phase daher oft fehl.
  • Lösung: Während des Setups müssen die von der API zurückgegebenen UUIDs (IDs) direkt im Speicher gehalten und an nachfolgende Funktionen übergeben werden, anstatt sich auf Suchbegriffe zu verlassen.

8.4 Property-Namenskonventionen

  • Problem: Sonderzeichen (z.B. / in Branche/Persona) oder führende/nachfolgende Leerzeichen in Spaltentiteln führen zu 400 Bad Request Fehlern, da die API extrem sensitiv auf exakte String-Matches reagiert.
  • Lösung: Nutzung von einfachen, alphanumerischen Bezeichnern (z.B. Art, Beschreibung, Status). Die kosmetische Aufbereitung (Icons, längere Namen) sollte erst nach dem erfolgreichen API-Mapping manuell oder über ein explizites Update-Skript erfolgen.

8.5 Relation-Wiring (Das Henne-Ei-Problem)

  • Problem: Eine Datenbank kann keine Relation zu einer anderen Datenbank aufbauen, wenn diese noch nicht existiert.
  • Lösung: Zweistufiger Deployment-Prozess:
    1. Phase A: Erstellen aller 7 Datenbank-Hüllen mit Basis-Properties.
    2. Phase B: Nachträgliches „Verdrahten“ der Relationen via databases.update unter Verwendung der in Phase A generierten IDs.

8.6 Authentifizierung & Scoping

  • Erkenntnis: Notion-Integrationen benötigen explizite Freigaben pro Seite. Wenn eine Datenbank gelöscht und neu erstellt wird, muss die Verbindung in der Notion-UI oft manuell neu autorisiert werden, auch wenn die übergeordnete Seite bereits freigegeben war.
  • Lösung: Bei jedem neuen Deployment-Lauf in der Notion-UI prüfen, ob die „RoboPlanet GTM Engine“ unter den Connections der Zielseite gelistet ist.

Checkliste für den Neustart mit Gemini CLI:

  1. Requests statt SDK: Nutze die native HTTP-Library für alle Notion-Calls.
  2. ID-Persistence: Speichere IDs in einer lokalen JSON-Variable während des Laufs.
  3. Schema-Validation: Nutze einen database.retrieve Call vor dem ersten Daten-Push, um die Existenz der Spaltennamen zu verifizieren.
  4. Error-Logging: Implementiere detailliertes Logging der API-Response-Bodys, da Notion dort sehr präzise Hinweise gibt (z.B. property_not_found).

Status: Blueprint Finalisiert. Nächster Schritt: Umsetzung der Datenbank-Properties und API-Endpunkte gemäß diesem Dokument.

Reference in New Issue View Git Blame Copy Permalink