P103 — Customer Journey Tooling-Architektur
Navigations- und Statusübersicht. Status: draft · angelegt 2026-09-18.
Was P103 ist: CJRM und CJML sind methodische Grundlagen (Layer 0) — keine Tools. P103 klärt, welche Komponenten fehlen, um daraus ein benutzbares System zu machen: ein Datenmodell, das CJRM-Instanzen hält und nach CJML transformiert (Layer 1), ein Erfassungstool (Layer 2) und eine CJML-konforme Darstellungs-Engine (Layer 3). Ausgangspunkt war eine Marktanalyse von Customer-Journey-SaaS-Tools (Smaply, TheyDo, cxomni u. a.), die zeigte: kein Kauf-Werkzeug deckt diese Lücke.
Abgrenzung zu P96 (CJRM): P96 ist die Ontologie selbst und ihre Anwendung als internes Diagnose-Framework für Beratungsmandate — ausdrücklich nicht als eigenständiges Kundenprodukt vermarktet. P103 ist die Tooling-/Produkt-Frage: wie man CJRM (+ CJML als Darstellungsformat) technisch benutzbar macht. Eigenständiges Projekt, nutzt die P96-Ontologie als Grundlage.
Was noch fehlt
- Layer-1-Schema ist v1/Entwurf — offene Punkte: role-Taxonomie bei symmetrischen Events, Constraint-Typ für relationale Constraints, Versionierung, Persistenz-Engine
- Konkretes Angebot bei cxomni einholen; TheyDo-MCP-Trial prüfen
- Mapping-Übung TheyDo-Objekte gegen CJRM-Ontologie (Übersetzungsverlust sichtbar machen)
- Pilotversuch agentengeführtes Interview an eigener VDS-Journey, Vergleich mit dokumentenbasierter CJRM-Analyse
- Entscheidung: Layer 2 als eigenständiges Tool bauen oder bestehenden CJRM-Journey-Analysis-Skill (P96) erweitern
Nächster Schritt laut Nutzer: Darstellung (Layer 3) und Erfassung (Layer 2) konkret angehen — das Schema (Layer 1) und die Methodik-Frage (Erfassungsmethodik) sind bereits skizziert, jetzt folgt die Umsetzungsseite. Siehe Dokumente 03–05 für den aktuellen Stand beider Layer.
Vorgehen — die zehn Schritte des Interviews
Das standardisierte Vorgehen des Journey Lab, nachvollziehbar für jeden, der die Karte erstellt oder liest: was gefragt wird, in welcher Reihenfolge, und was daraus auf der Karte entsteht.
Das Interview folgt einem festen Ablauf, nicht einem freien Gespräch. Jede Frage baut auf der vorherigen auf und trägt zu einem bestimmten Teil der Karte bei. Wer die Reihenfolge kennt, kann jederzeit einordnen, an welcher Stelle der Erfassung eine Journey gerade steht — auch mitten im Interview, an einer übersprungenen Frage oder an einer nachträglich ergänzten Antwort.
Die zehn Schritte
| # | Schritt | Frage im Interview | Ergebnis auf der Karte |
|---|---|---|---|
| 1 | Reise | Welche Reise wollen wir aufzeichnen? | Titel und Rahmen der Journey |
| 2 | Beteiligte | Wer ist alles beteiligt? | Akteure — Menschen, Firmen, Abteilungen, Systeme |
| 3 | Etappen | In welche Etappen lässt sich die Reise gliedern? | Spalten der Karte, grob, drei bis sechs |
| 4 | Schritte | Was passiert je Etappe, Schritt für Schritt? | Einzelne Touchpoints je Etappe |
| 5 | Schwierigkeiten | Wo hakt es? | Pain Points, rot markiert |
| 6 | Gute Momente | Und was läuft gut? | Gains, grün markiert |
| 7 | Perspektiven | Aus Sicht der anderen Beteiligten: was passiert, wo hakt es? | Ergänzende Sicht je weiterem Akteur |
| 8 | Warum | Warum ist der schwierigste Schritt nötig, oder was würde ihn überflüssig machen? | Begründung/Constraint hinter dem größten Pain Point |
| 9 | Ideen | Was würden Sie ändern, wenn alles möglich wäre? | Verbesserungsideen, der passenden Etappe zugeordnet |
| 10 | Ergänzen | Möchten Sie etwas ergänzen oder korrigieren? | Freie Nachträge — Karte bleibt danach jederzeit direkt editierbar |
Schritt 7 (Perspektiven) erscheint nur, wenn mehr als ein Akteur benannt wurde; Schritt 8 (Warum) nur, wenn tatsächlich eine Schwierigkeit erfasst wurde. Jede Frage lässt sich überspringen — das Interview geht dann ohne Lücke zur nächsten Stufe weiter.
Einordnung: Diese zehn Schritte sind Stufe 1 der dreistufigen Erfassungsmethodik — strukturiertes Interview, gefolgt von KI-Synthese zur CJRM-Instanz und optionaler Workshop-Validierung bei mehreren Beteiligten. Die methodische Begründung, warum ein strukturiertes Interview dem klassischen Workshop vorgezogen wird, steht in Dokument 04.
Architekturmodell — Journey-Tooling-Komponenten
Ordnet CJRM und CJML als methodische Grundlage (Layer 0) ein und definiert die darüberliegenden Komponenten, die nötig sind, um aus der Ontologie ein benutzbares Journey-Tooling zu machen.
CJRM und CJML sind keine Tools, sondern methodische Grundlagen (Layer 0). Dieses Modell zeigt, welche Komponenten fehlen, um aus dieser Grundlage ein tatsächlich benutzbares Erfassungs- und Darstellungssystem zu machen, und wie sie zusammenhängen.
Layer-Übersicht
In eigenem Tab öffnen — empfohlen, das Diagramm ist hochformatig und nutzt dort die volle Bildschirmhöhe. Eingebettet interaktiv: oben die drei benannten Ansichten (Die Baulücke · Heutiger Ersatz · Zielpfad) anklicken, S wechselt den Stil, T das Theme, E öffnet den Export, +/−/0 zoomen.
Erzeugt mit Archify aus typisiertem JSON — Primärquelle liegt im Vault unter P103 …/diagrams/layer-modell.architecture.json, das Bild ist daraus reproduzierbar und maschinell auf Layout-Fehler geprüft (keine Kante läuft durch eine fremde Komponente, kein Label verdeckt eine andere Kante).
Layer 0 — Methodische Grundlage (extern, in P96 gepflegt)
| Element | Rolle |
|---|---|
| CJRM | eigene Ontologie: modelliert Goal-, State-, Constraint- und Capability-Strukturen hinter einer Journey |
| CJML | externe, formale Notation: Touchpoints/Communication Points mit Sender, Empfänger, Kanal, Status, Swimlane-Diagramme, Planned vs. Actual |
Beziehung: CJML modelliert primär die Journey selbst; CJRM modelliert die darunterliegenden Strukturen und leitet die Journey als View ab. CJML ist damit kein Konkurrent, sondern eine mögliche Zielsprache für die Darstellung dessen, was CJRM modelliert — semantic bridge, not method replacement.
Layer 1 — Datenmodell / Semantic Bridge (fehlt aktuell vollständig)
Ohne diese Schicht bleibt CJRM eine Analyse-Ontologie in Prosa/Tabellen, nicht ein darstellbares oder wiederverwendbares Modell. Aufgabe dieser Schicht:
- Persistiertes Schema für CJRM-Instanzen (Journey als Graph aus Actor-/Goal-/Event-/Constraint-Objekten)
- Transformationslogik CJRM → CJML: welche Events werden zu Communication Points, wer ist Sender/Empfänger, welcher Kanal, welcher Status
Das ist die eigentliche Bau-Lücke des Projekts — nicht Erfassung oder Darstellung für sich, sondern die Brücke dazwischen.
Layer 2 — Erfassung
Überführt eine reale Journey (Workshop, Interview, bestehende Dokumentation) in eine CJRM-Instanz.
- Heutiger Stand: CJRM-Journey-Analysis-Skill (P96) — liest bestehende Journey-Dokumentation und modelliert sie gegen die Ontologie. Text-zu-Text, LLM-gestützt, ohne strukturierte Persistenz in Layer 1.
- Marktoptionen: Smaply/UXPressia/Custellence als visuelle Erfassungs-Frontends — eigenes proprietäres Datenmodell, bräuchten Export + Mapping auf Layer 1. TheyDo/cxomni näher an einem objektbasierten Modell, aber Enterprise-Preisniveau bzw. Preis nicht öffentlich.
Layer 3 — Darstellung
Rendert aus Layer-1-Daten CJML-konforme Diagramme (Swimlanes, farbcodierte Touchpoints, Status).
- Kein untersuchter SaaS-Anbieter deckt das nativ ab.
- Referenzkandidat geprüft: offener, React-basierter CJML-Editor (cjml.no/tools). Website-Inhalt CC-BY-SA-4.0 (SINTEF Digital), aber kein auffindbarer Quellcode/Repository für den Editor selbst — kostenlos nutzbar, aber nicht forkbar.
Layer 4 — Anwendung
- Diagnose in Beratungsmandaten (P96s eigentlicher, bereits validierter Anwendungsfall — bewusst nicht als eigenständiges Kundenprodukt vermarktet)
- Reporting: Messlücken, Planned-vs-Actual-Abgleich (sobald Layer 1 strukturierte Events/Evidence hält)
- Perspektivisch: AI-/Agentic-Tooling über dem Core
Nicht Teil dieser Architektur
delight.ai und vergleichbare AI-Concierge-/Agenten-Plattformen gehören nicht zu Layer 2/3. Sie sitzen innerhalb eines einzelnen Touchpoints (führen die Konversation über Chat/Voice/SMS), nicht auf Ebene der Journey-Modellierung.
Offene Fragen
- Layer 1 ist die eigentliche Kernarbeit — sollte vor Layer 2/3 priorisiert werden.
- Ist Layer 2 besser als eigenständiges Tool zu bauen oder als Erweiterung des bestehenden CJRM-Journey-Analysis-Skills?
- Layer 3 muss eigenständig gebaut werden — der offene CJML-Editor ist nur Referenz, kein Fork-Kandidat.
- Verbindungen
- → Journey-SaaS-Marktlandschaft
- → TheyDo & cxomni Vertiefung
- P96 CJRM Hub, P96 Prior Art (Vault)
Journey-SaaS-Marktlandschaft
Kartiert den SaaS-Markt für Customer-Journey-Werkzeuge und ordnet die Anbieter den Layern aus dem Architekturmodell zu, um zu prüfen, ob eine Kauf-Option die Bau-Lücke schließt.
Marktsegmentierung
Drei Tiers mit unterschiedlicher Zielgruppe, Preislogik und Datentiefe:
- Pure-play Visualisierungstools (Smaply, UXPressia, Custellence) — günstig, workshop-tauglich, deckt oberflächlich Layer 2 + 3 ab, aber mit proprietärem Dokumentenmodell statt CJML-Notation.
- Journey-Management-Plattformen (TheyDo, cxomni) — strukturieren Journeys als wiederverknüpfte Datenobjekte statt Diagramme; am nächsten an Layer 1, ohne CJML-Kompatibilität.
- Enterprise Journey Analytics & Orchestration (Adobe, CSG, Qualtrics, Medallia, Genesys, Salesforce) — Layer 4, datengetrieben, in CX-/CDP-Suiten eingebettet.
Kein untersuchter Anbieter implementiert CJML als Notation (Layer 3) oder bietet ein offenes, CJRM-kompatibles Datenmodell (Layer 1). Die Bau-Lücke ist am Markt nicht schließbar — höchstens einzelne Bausteine sind als Referenz nutzbar.
Datenqualität: Marktgrößen-Schätzungen verschiedener Research-Häuser streuen stark (985 Mio. USD bis 16,46 Mrd. USD für 2025/26), weil „Customer Journey [Mapping] Software" uneinheitlich definiert wird. Für strategische Zwecke ist die Richtung (zweistelliges CAGR-Wachstum, 15–20 %) belastbarer als die absolute Zahl.
Tool-Landschaft nach Architektur-Layer
| Tier | Anbieter | Layer-Abdeckung | Preisniveau |
|---|---|---|---|
| 1 · Visualisierung | Smaply | 2+3 (oberflächlich) | ab €390/Jahr |
| 1 · Visualisierung | UXPressia | 2+3 (oberflächlich) | Free / $160–360/User/Jahr |
| 1 · Visualisierung | Custellence | 2+3 (oberflächlich) | ab $28/Monat |
| 2 · Journey-Mgmt | TheyDo | 1+2 (kein CJML) | $25/User/Mo · Enterprise ~$3k/Mo* |
| 2 · Journey-Mgmt | cxomni | 1+2 (kein CJML) | ab €2.000/Jahr |
| 3 · Enterprise | Adobe Journey Optimizer | 4 | Enterprise, individuell |
| 3 · Enterprise | CSG (Xponent) | 4, Telco/CSP | Enterprise |
| 3 · Enterprise | Qualtrics (ex-Usermind) | 4 | oft 5-stellig USD/Jahr |
| 3 · Enterprise | Medallia (ex-Thunderhead) | 4 | Enterprise |
| 3 · Enterprise | Genesys (ex-Pointillist) | 4, Contact-Center | ab $75/User/Mo |
| — | delight.ai | kein Journey-Layer | Enterprise |
| Referenz L3 | CJML Editor (cjml.no) | 3, nicht forkbar | kostenlos |
*Erinnerungswert TVE, nicht öffentlich verifiziert — strukturell plausibel, s. Dokument 03.
Konsolidierung
Genesys ← Pointillist, Medallia ← Thunderhead, Qualtrics ← Usermind: Enterprise-Suiten (Layer 4) kaufen sich Journey-Fähigkeiten zu oder bauen sie nativ (Adobe Journey Optimizer Pro, Oracle CX Cloud, beide seit 2025). Gartner veröffentlichte im März 2026 den ersten Magic Quadrant „Customer Journey Analytics and Orchestration" (8 Anbieter, Leader: Adobe, CSG). Layer 1–3 sind davon unberührt — dort investiert der Markt nicht.
Standout-Anbieter
Adobe / CSG — stärkste Layer-4-Positionen laut Gartner. Für die aktuelle Projektphase überdimensioniert.
TheyDo — konzeptionell der interessanteste Layer-1/2-Kandidat: einziger Anbieter, der Journeys als strukturiertes, wiederverwendbares Datenmodell statt als Diagramm behandelt, zusätzlich mit nativer AI-/MCP-Anbindung. Kein CJML-Rendering. Preislich faktisch Enterprise-Tier.
cxomni — zweiter Layer-1/2-Kandidat, mit Branchen-Fit: explizite Financial-Services-Ausrichtung, DACH-Kundenbasis, deutlich günstigerer öffentlicher Einstiegspreis.
Strategische Implikation
- Layer 1 ist die eigentliche Bau-Lücke — kein Anbieter deckt sie ab.
- TheyDo und cxomni verdienen eine vertiefte Einzelanalyse — bislang einzige Anbieter mit journey-als-Objekt- statt journey-als-Bild-Ansatz.
- cxomni hat den stärkeren Branchen-Fit; sollte vor TheyDo geprüft werden, falls CJRM primär im Banking-/Finance-Kontext eingesetzt werden soll.
- Layer 3 hat keinen kommerziellen Kandidaten — der offene CJML-Editor bleibt die einzige bekannte Referenz.
- Verbindungen
- → Architekturmodell
- → TheyDo & cxomni Vertiefung
TheyDo und cxomni — Vertiefte Analyse
Vertieft die engsten Layer-1-Kandidaten — Datenmodell, API/Integrationstiefe, tatsächliche Preisrealität — und klärt die Lizenzlage des offenen CJML-Editors für Layer 3.
TheyDo
Datenmodell: Journey aus drei Kernelementen — Phases (große Etappen) → Steps (einzelne Touchpoints) → Lanes (Insights, Opportunities, Solutions, Metrics, Experience-Curve, Tags, Text). Hierarchische Journey-Ebenen L0–L3: Lifecycle → Macro → Micro. Geteilte, wiederverwendbare Bibliothek: Goals, Insights, Opportunities, Solutions, Metrics.
CJRM-Fit: Steps ≈ CJRM Event; Insights/Opportunities decken einen Teil von Claim/Evidence ab. Es fehlt ein explizites Actor-Goal-State-Constraint-Capability-Graphmodell — näher am Business-/Design-Thinking-Vokabular als an einer formalen Ontologie. Kein CJML-Rendering.
API/Integration: TheyDo Agent (eigener AI-Agent) + TheyDo MCP — nativer Model-Context-Protocol-Server, öffnet TheyDo-Daten direkt für Claude, ChatGPT, Copilot. Bei Lizenzierung ließe sich Layer 4 ohne eigene Integrationsarbeit anbinden.
Preis-Realität: Öffentlich Free / Pro ~$25/User/Monat. Enterprise „contact us" mit Pro-Journey-Preismodell (nicht pro Seat) und Mengenrabatt — typische Kunden starten mit 60–80 Journeys im ersten Jahr, skalieren auf ~200. Bei dieser Größenordnung ist ein vierstelliger Monatsbetrag strukturell plausibel.
Reviews: G2 4,5/5 (62 Reviews) — Stärke bei Administration/Governance für große Organisationen.
cxomni
Datenmodell: Journey Mapping Framework mit unternehmensspezifischer Taxonomie/Terminologie, frei konfigurierbaren Feldern statt fixer Objektklassen. Kein öffentlich dokumentiertes formales Objekt-/Relationsmodell wie TheyDos Phases/Steps/Lanes.
CJRM-Fit: Sprache („konsistente Taxonomie, klare Ownership, Lifecycle-KPIs") liegt näher an dem, was CJRM leisten soll — aber als Konfigurationsfreiheit umgesetzt, nicht als festes Beziehungsmodell.
API/Integration: Vorgefertigte Konnektoren — Google Analytics 360, Adobe Analytics, Salesforce Commerce Cloud, VoC-/Service-Center-Plattformen. Bidirektionale Jira-Integration, ServiceNow u. a. Keine Hinweise auf AI-Agenten-/MCP-Unterstützung.
Preis-Realität: Deutlich günstiger als angenommen — Einstiegspreis öffentlich mit €2.000/Jahr. Kundenbasis regional konzentriert in Österreich, Schweiz, Deutschland; 33 % der Kunden 101–1.000 Mitarbeitende, 67 % 1.001–10.000.
Reviews: G2 4,8/5 (15 Reviews) — einfacher in Einrichtung/Nutzung, besserer Business-Fit und Support als TheyDo laut Reviewern; UX vereinzelt als „etwas klobig" beschrieben.
Direktvergleich
| Kriterium | TheyDo | cxomni |
|---|---|---|
| Datenmodell | formal: Phases→Steps→Lanes, hierarchisch | flexibel: Custom-Taxonomie, kein festes Objektmodell |
| CJML-Rendering | nein | nein |
| AI/Agentic | TheyDo Agent + MCP | keine Hinweise |
| API-Konnektoren | nicht im Detail dokumentiert | GA360, Adobe Analytics, Salesforce, Jira, ServiceNow |
| Einstiegspreis | ~$25/User/Monat | €2.000/Jahr |
| Enterprise-Realität | mehrere Tsd. $/Monat (Pro-Journey) | nicht verifiziert, deutlich günstiger im Einstieg |
| G2-Bewertung | 4,5/5 (62) | 4,8/5 (15) |
| Branchen-Fit | keiner erkennbar | DACH + Financial Services |
cxomni ist der bessere erste Pilotkandidat (Preis, DACH-/Financial-Services-Fit, Review-Qualität). TheyDo bleibt die strategisch relevantere Referenz für Layer 1/4 (formales Datenmodell + native MCP-Anbindung), aber nur mit klarem Business Case zu rechtfertigen. Beide lösen Layer 3 nicht.
CJML-Editor — Lizenzprüfung (Layer 3)
- Website-Inhalt (Spezifikation, Templates): CC-BY-SA-4.0, Copyright SINTEF Digital
- Editor-Tool selbst: kein Quellcode, kein Repository, kein Lizenzhinweis auffindbar — weder auf cjml.no noch auf cjmlui.netlify.app
Das Tool ist kostenlos nutzbar, aber nicht forkbar oder als Codebasis wiederverwendbar. Nur als Interaktions-/Format-Referenz (xCJML) brauchbar — Eigenbau der Rendering-Logik bleibt nötig.
Nächste Schritte
- Konkreten Preis bei cxomni erfragen (Financial-Services-Referenzkontext UNIQA/Generali als Einstieg)
- Prüfen, ob TheyDo MCP im Rahmen einer Trial-Lizenz zugänglich ist
- Mapping-Übung: TheyDo-Objekte formal gegen CJRM-Ontologie abbilden
- Bei SINTEF anfragen, ob Quellcode-Zugriff zum CJML-Editor möglich ist
- Verbindungen
- → Architekturmodell
- → Journey-SaaS-Marktlandschaft
Erfassungsmethodik — Vom Workshop zur Interview-Synthese
Prüft, ob der klassische Customer-Journey-Workshop noch das richtige Erfassungsformat für Layer 2 ist.
These
Der klassische Customer-Journey-Workshop ist ein Sense-Making-Format (funktionsübergreifendes Alignment, politisches Buy-in), kein Erhebungsformat. CJRM als formale Ontologie braucht primär Präzision, Konsistenz und Skalierbarkeit — worin der Workshop strukturell schwach ist. Er neigt zu vorzeitiger Konvergenz: Gruppendynamik glättet Widerspruch weg, bevor er sichtbar wird — im Gegensatz zur CJRM-Trennung von Claim und Evidence.
Alternative: dreistufige Erfassung
Stufe 1 — Interview-Protokoll aus der Ontologie ableiten. Kein offenes Gespräch, sondern strukturiertes Laddering entlang der Core Objects: Job → Goal → beobachtete Event-Sequenz → je Event „warum existiert dieser Schritt" → Laddering bis zum Constraint → „was müsste wahr sein, damit das entfällt" → Capability-Lücke. Im Kern JTBD/ODI-Laddering, human- oder agentengeführt.
Stufe 2 — KI-Synthese zu CJRM-Instanzen. Transkript → Actor/Goal/State/Constraint/Event, mit expliziter Claim/Evidence-Trennung. Technisch eine Erweiterung des bestehenden CJRM-Journey-Analysis-Skills (P96) — vorgezogen auf rohe Interview-Transkripte statt fertiger Dokumentation.
Stufe 3 — Workshop als Validierungs- und Konflikt-Loop. Nicht mehr „Journey gemeinsam entdecken", sondern gezielt: Stellen mit niedriger Evidence-Dichte, und vor allem Goal conflicts-with Goal zwischen Actor-Perspektiven.
1:1-Interviews sind strukturell schlechter darin, Spannungen zwischen Actors sichtbar zu machen als ein Raum voller Beteiligter. Die KI-Synthese muss das aktiv suchen (Cross-Actor-Abgleich), sonst werden Konflikte nicht gelöst, sondern nur unsichtbarer.
Ob ein KI-Agent tatsächlich bis zum echten Constraint bohrt statt bei der ersten plausiblen Antwort aufzuhören, ist nicht validiert. Test vor Kundeneinsatz an eigener, unkritischer Journey nötig.
Bezug zur Agentic-Transformation-Diskussion
Die Verschiebung von Workshop zu Interview+KI-Synthese ist selbst eine Instanz von „Agency Transfer via Mandate" (s. Dokument B): die knappe Ressource geschulter Facilitator-Zeit wird an einen KI-Agenten delegiert. Der Workshop hat aber einen Teil-Wert (Buy-in, gemeinsame Trägerschaft), der nicht bloß constraint-induced friction ist — deshalb Stufe 3 behalten, nur neu zuschneiden.
Nächste Schritte
- Pilotversuch: agentengeführtes Interview an einer eigenen VDS-Journey testen
- Interview-Guide als konkretes Artefakt aus der Core Ontology ableiten
- Cross-Actor-Konflikterkennung als expliziten Synthese-Schritt spezifizieren
- Verbindungen
- → Architekturmodell
- → Agency Transfer via Mandate
Layer 1 — CJRM-Instanzschema und CJML-Transformation
Ein persistierbares Schema für CJRM-Instanzen (Property Graph, JSON) und eine explizite Transformationslogik von CJRM-Instanzen zu CJML-konformen Views.
Formalismus-Entscheidung: Property Graph, kein RDF/OWL
CJRM ist primär über Objekte und benannte Relationen definiert (14 Core Objects, ~28 primäre Relationen) — das ist die native Form eines Property Graph, nicht eines relationalen Schemas und nicht zwingend RDF/OWL. Beantwortet direkt die offene P96-Frage „Braucht CJRM eine formale Ontologiesprache?": für Layer 1 nein — ein dokumentiertes JSON-Schema genügt („Simple surface, rigorous substrate"). Serialisierung: JSON, text-first, git-diffbar.
Node-Schema (generisches Envelope)
{
"id": "string (stabiler Slug oder UUID)",
"type": "Actor | Job | Goal | State | Resource | Constraint |
Capability | Mandate | Event | Outcome | Metric | Value |
Claim | Evidence",
"label": "string — menschenlesbar",
"properties": { "...": "typspezifisch" },
"provenance": {
"source": "interview:<id> | document:<pfad> | workshop:<id>",
"extracted_by": "human:<name> | agent:<model-id>",
"extracted_at": "ISO-8601",
"epistemic_status": "claim | evidence-backed"
}
}provenance ist auf jedem Node und jeder Edge Pflicht — nicht optional. Grund: R8 „Evidence ≠ Interpretation" lässt sich nur durchsetzen, wenn jede Instanz nachweisbar auf ihre Quelle zurückführbar ist, besonders bei KI-synthetisierten Instanzen aus Interviews. epistemic_status: claim ist der Default; Aufwertung nur über eine explizite Evidence supports Claim-Edge.
Typspezifische Properties (Auszug)
| Type | Properties |
|---|---|
| Actor | kind: human | organization | org-unit | partner | platform | ai-agent |
| Job | scope_test_passed: bool |
| Goal | function: terminal|instrumental · origin: [job-derived, goal-derived, constraint-induced, institution-induced, provider-induced, capability-enabled] |
| State | kind: objective | subjective |
| Constraint | constraint_type: technological | organizational | institutional | economic | informational |
| Capability | capability_type: customer-side | enterprise-side | ecosystem-side |
| Mandate | authorizes_event_types · scope · revocable: bool |
| Event | event_type: Action|Interaction|ExogenousEvent · channel · timestamp · status: planned|actual |
| Outcome | polarity: contributes | impairs |
| Metric | metric_class: state|goal-attainment|outcome|resource-effort|value-economic · target |
| Value | valence: positive | negative | mixed |
| Claim | statement · confidence: low|medium|high |
| Evidence | evidence_type · relation: supports | contradicts |
Ownership (R1) und Beneficiary (R6) sind kanonisch über Edges modelliert (Actor owns Goal), nicht als Property.
Warum diese Properties mehr als Enumerationen sind
Actor.kind — ai-agent ist die Voraussetzung für die Agency-Transfer-Filterregel unten: nur ein als ai-agent markierter Actor kann ein Event aus der Customer-Journey-View heraus- und in den Agent Execution Trace hineinfiltern lassen.
Goal.function / origin — function: instrumental ohne begründende Goal supports Goal-Edge (R3) ist ein Validierungsfehler, kein Stilfehler. origin ist ein Array, weil die Dimensionen kombinierbar sind (Beispiel: „Identität verifizieren = instrumental + institution-induced").
Constraint.constraint_type — unterschiedliche Typen haben unterschiedliche Auflösungswege: technological wird meist durch neue Capability mitigiert (Constraint verschwindet), institutional eher durch Agency Transfer — die Vorschrift ändert sich nicht, nur wer sie erfüllt.
Event.event_type / status — nur Interaction wird zum CJML Communication Point. status: planned | actual unterscheidet hypothetische von beobachteten Events — Grundlage der CJML-Unterscheidung Planned vs. Actual Journey.
Edge-Schema
{
"id": "string",
"type": "eine der ~28 primären Relationen",
"source_id": "Node-ID",
"target_id": "Node-ID",
"properties": { "...": "relationsspezifisch" },
"provenance": { "wie bei Node" }
}Entscheidend für die CJML-Transformation: Event involves Actor braucht zwingend role: initiator | recipient | participant. Ohne dieses Property lässt sich kein Sender/Empfänger ableiten.
Transformationslogik: CJRM-Instanz → CJML-View
| CJML-Element | Ableitung aus CJRM-Instanz |
|---|---|
| Communication Point | Event mit event_type = Interaction |
| Sender / Empfänger | Actor via Event involves Actor, role = initiator / recipient |
| Kanal | Event.channel |
| Status | Outcome.polarity = contributes → completed · kein Outcome → missing · impairs → failing |
| Planned vs. Actual | Event.status |
| Swimlane je Akteur | Gruppierung aller Events nach beteiligtem Actor |
| Customer Journey vs. Agent Execution Trace | Events mit ausschließlich ai-agent-Actors unter Mandate werden gefiltert und separat als Agent Execution Trace gerendert |
Die letzte Zeile ist die konkrete, schema-seitige Umsetzung des Agency-Transfer-Mechanismus (Dokument B): Layer 1 entscheidet algorithmisch, nicht manuell, welcher Teil einer Journey noch „Customer Journey" ist.
Worked Example — Baufinanzierung mit delegierter Identitätsprüfung
[
{"id":"actor:kunde","type":"Actor","label":"Kunde","properties":{"kind":"human"}},
{"id":"actor:kyc-agent","type":"Actor","label":"KYC-Agent","properties":{"kind":"ai-agent"}},
{"id":"actor:bank","type":"Actor","label":"Bank","properties":{"kind":"organization"}},
{"id":"goal:g1","type":"Goal","label":"Baufinanzierung erhalten",
"properties":{"function":"terminal","origin":["job-derived"]}},
{"id":"constraint:c1","type":"Constraint","label":"Regulatorische KYC-Pflicht",
"properties":{"constraint_type":"institutional"}},
{"id":"goal:g2","type":"Goal","label":"Identität verifizieren",
"properties":{"function":"instrumental","origin":["institution-induced"]}},
{"id":"mandate:m1","type":"Mandate","label":"Mandat Identitätsprüfung",
"properties":{"authorizes_event_types":["Interaction"],
"scope":"KYC für diesen Baufinanzierungsantrag","revocable":true}},
{"id":"event:e1","type":"Event","label":"Video-Ident-Prüfung (agentengeführt)",
"properties":{"event_type":"Interaction","channel":"Agent-API","status":"actual"}},
{"id":"outcome:o1","type":"Outcome","label":"Identität erfolgreich verifiziert",
"properties":{"polarity":"contributes"}}
][
{"type":"Constraint induces Goal","source_id":"constraint:c1","target_id":"goal:g2"},
{"type":"Goal supports Goal","source_id":"goal:g2","target_id":"goal:g1"},
{"type":"Actor owns Goal","source_id":"actor:kunde","target_id":"goal:g1"},
{"type":"Actor grants Mandate to Actor","source_id":"actor:kunde","target_id":"actor:kyc-agent",
"properties":{"mandate_id":"mandate:m1"}},
{"type":"Mandate authorizes Event/Decision","source_id":"mandate:m1","target_id":"event:e1"},
{"type":"Event involves Actor","source_id":"event:e1","target_id":"actor:kyc-agent",
"properties":{"role":"initiator"}},
{"type":"Event involves Actor","source_id":"event:e1","target_id":"actor:bank",
"properties":{"role":"recipient"}},
{"type":"Event produces Outcome","source_id":"event:e1","target_id":"outcome:o1"},
{"type":"Outcome contributes-to Goal","source_id":"outcome:o1","target_id":"goal:g2"}
]event:e1 hat als initiator/recipient ausschließlich Agent und Bank — kein human-Actor direkt beteiligt. Nach der Filterregel landet es in der Agent Execution Trace. Die Customer Journey reduziert sich für diesen Teilschritt auf das Mandat-Erteilungs-Event: „grant Mandate → monitor/intervene → receive Outcome".
Offene Punkte
role-Taxonomie bei symmetrischen Events (z. B. beiderseitige Vertragsunterzeichnung) erzwingt künstliche Setzung — bestätigt in Test 1Constraint.constraint_typedeckt relationale/vertrauensbasierte Constraints nicht sauber ab — bestätigt in Test 1- Versionierung von Journeys über Zeit noch nicht entschieden
Outcome.polarity/Value.valencesind Denormalisierungen mit Drift-Risiko gegenüber den kanonischen Edges- Keine Persistenz-Engine festgelegt (Graph-DB vs. JSON-Dateien vs. eingebettete Lösung) — bewusst offen
Testinstanziierung — Beratung Premium & Signature
Testet das Layer-1-Schema an einer echten, bereits dokumentenbasiert analysierten P96-Fallstudie.
Kernbefund der Fallstudie: Die Journey folgt nicht dem Job des Kunden, sondern dem Job von VDS („Mandat gewinnen"); GF, Champion und CFO sind darin Randbedingungen, keine Träger eigener Journeys. Das Pilotformat ist constraint-induced (fehlendes Vertrauen), nicht job-derived. „Vertrauen" ist der zentrale, aber nirgends gemessene Erfolgsfaktor.
Testergebnis — was reibungsfrei ging
Der Kernbefund lässt sich strukturell erzwingen, nicht nur behaupten. Weil jeder Actor sein eigenes Job-Node bekommt statt eines gemeinsamen „Journey-Jobs", wird die Kernaussage „das ist eine VDS-Akquise-Journey" beim Modellieren selbst erzwungen — ein stärkerer Beleg als die Prosa-Analyse.
Constraint-induced vs. provider-induced trennt sauber, was im Original vermischt war — das Pilotformat (constraint-induced) und der verpflichtende MOZ-Call (provider-induced) sind beides „von VDS auferlegt", aber mit unterschiedlicher Herkunft.
Vermutete, unbelegte Objekte (der Champion-Job) brauchen keinen Sondermechanismus — das generische provenance.epistemic_status: claim reicht.
Die Metric-Lücke wird zur Query statt zur Beobachtung. „Vertrauen" hat keine eingehende Metric-Edge — algorithmisch auffindbar statt analystenabhängig.
Reibungspunkte
Constraint.constraint_type passt nicht sauber. „Fehlendes Vertrauen" wurde als informational eingeordnet, trifft es aber nicht genau — im Kern ein relationaler, nicht informationeller Zustand.
metric_class = outcome für die Pipedrive-Stufe ist selbst ein Fund. Die Pipeline misst, ob ein Event erreicht wurde, nicht ob der Zielzustand erreicht wurde — das Schema würde eine falsche Klassifizierung als goal-attainment aktiv verhindern.
role-Taxonomie bei Vertragsunterzeichnung unklar — die Unterschrift ist ein beiderseitiger Akt, „wer ist initiator" musste künstlich gesetzt werden.
Fazit
Das Schema trägt den Kernbefund ohne Verlust und macht ihn an zwei Stellen sogar strenger nachweisbar. Die gefundenen Reibungspunkte sind überschaubar und betreffen Randfälle, nicht das Grundgerüst.
- Verbindungen
- → Layer-1-Schema
- → Test — Digitalprodukte
Testinstanziierung — Digitalprodukte Direkt
Zweiter Test — an einer strukturell anderen Fallstudie (transaktionaler Funnel statt Beratungsmandat).
Kernbefunde der Fallstudie: Die „Kaufentscheidung" ist kein Ereignis, sondern ein interner Zustandswechsel, wird aber wie ein Schritt behandelt. Die Post-Purchase-E-Mail-Sequenz reagiert auf Kalendertage, nicht auf den tatsächlichen Nutzungsstand. Der MOZ-Call bestätigt sich — unabhängig von Fallstudie 1 — als bedingte Vertriebsentscheidung.
Positive Designbestätigung
Cross-Journey-Bestätigung funktioniert über geteilte Node-IDs, nicht über Duplikate. Derselbe MOZ-Call-Goal-Node wird über beide Fallstudien-Instanziierungen hinweg wiederverwendet — jede Journey liefert eigene provenance-Einträge zum selben Node. So wird „dieselbe organisationale Norm zeigt sich in zwei unabhängigen Journeys" strukturell korrekt repräsentiert: ein Node mit wachsender Evidenzbasis, nicht zwei separate Behauptungen.
VDS' Doppelziel (IP monetarisieren und Leads gewinnen) lässt sich als zwei unabhängige terminale Goals desselben Actors ohne Konflikt modellieren.
Reibungspunkte
Event-vs-State-Verwechslung ist nicht automatisch verhinderbar. Die „Kaufentscheidung" als State-Node ohne eingehende Outcome changes State-Edge lässt sich anlegen, ohne dass das Schema den fehlenden kausalen Anker erzwingt — genau der Fehler, den das Original machte. Immerhin über eine Query auffindbar: „State-Nodes ohne eingehende Outcome-Kante".
Kein Property für den Auslösemechanismus eines Events. Die zentrale Erkenntnis — Mails feuern nach Kalendertagen statt nach Nutzungsstand — lässt sich nur als Freitext ausdrücken. Vorschlag: neues Property Event.trigger_type: state-driven | time-driven | manual, das den Befund direkt abfragbar machen würde.
Klassifikation von „Produktseite prüfen" als Interaction ist eine Setzung — laut CJML-Definition wären nicht-kommunikative Aktivitäten eigentlich Action.
Vergleich der beiden Tests
| Befund | Fallstudie 1 | Fallstudie 2 |
|---|---|---|
| Grundgerüst trägt verlustfrei | ja | ja |
| Metric-/Kausal-Lücke als Query auffindbar | ja (Vertrauen) | ja (Nutzung, Kaufbereitschaft) |
| Cross-Journey-Wiederverwendung | n/a | bestätigt |
| Neuer Reibungspunkt | Constraint-Typ, role-Symmetrie | fehlendes trigger_type, Action/Interaction-Grenze |
Die beiden Reibungspunkte aus Test 1 traten in Test 2 nicht erneut auf — sie hängen an bestimmten Konstellationen, nicht generisch im Schema. Unterschiedliche Journey-Typen legen unterschiedliche Schwächen frei, nicht dieselben wiederholt.
Fazit
Zwei Tests an strukturell unterschiedlichen Fallstudien bestätigen: das Grundgerüst trägt durchgängig. Konkreter, umsetzbarer Vorschlag: Event.trigger_type als neues Property ergänzen.
- Verbindungen
- → Layer-1-Schema
- → Test — Beratung Premium
Agency Transfer via Mandate
Ergänzung zu P96s Transformation Logic — Ergebnis eines Stresstests: trägt der Journey-Begriff noch, wenn Agenten Teile davon übernehmen?
Ausgangsfrage im Chat: Der Kunde hat ein Ziel, aber die Journey hängt stark an seinen Constraints. Fallen die weg, oder übernimmt ein Agent sie, ändert sich das Bild grundlegend.
Bisheriger Mechanismus (Capability mitigates Constraint)
Capability K → mitigates → Constraint C → necessity(G) ↓ → Events verschwinden
Neuer Mechanismus: Agency Transfer
Actor A1 (Customer) grants Mandate M to Actor A2 (Agent)
→ Mandate M authorizes A2 to execute E1…En
→ Events bleiben bestehen, aber der ausführende Actor wechselt von A1 zu A2
Unterschied: Der Constraint verschwindet nicht aus der Welt — ein Formular bleibt ein Formular — sondern der Actor, der ihn bearbeiten muss, wechselt. Journey Structure ändert sich durch Delegation, nicht Elimination.
Konsequenz für die Journey-Semantik: Die vom Kunden erlebte Journey schrumpft auf grant Mandate → monitor/intervene → receive Outcome. Die delegierten Events laufen weiter, aber als Agent Execution Trace — kein Customer-Journey-Objekt mehr im engeren Sinn, sondern ein Ausführungsprotokoll unter Mandat, näher an Process Mining.
Voraussetzung ist nicht dieselbe wie bei Capability-Mitigation: nicht technologischer Fortschritt allein, sondern Trust als Actor-Actor-State und institutionelle Mandatsfähigkeit. In regulierten Kontexten (Banking: KYC, Signaturpflicht) ist diese Mandatsfähigkeit selbst oft ein Constraint, der Agency Transfer blockiert — dort verlagert sich die Reibung auf die Mandatsgrenze selbst als neuen Pain-Point-Typ.
Verhältnis zu H1–H3: Agency Transfer ist keine vierte Stufe, sondern eine zweite Achse — er beschreibt einen Wechsel des ausführenden Actors bei unverändertem Constraint, kann H1–H3 überlagern.
Neue View: Agent Execution Trace
Für Tooling-Zwecke: klassische Journey-Notation (Touchpoints, Sender/Empfänger/Kanal) bleibt für den weiterhin menschlich erlebten Teil richtig, ist aber für delegierte Ausführungsstrecken der falsche Darstellungs-Zielraum.
In regulierten Kontexten bremst institutionelle Mandatsfähigkeit den Agency Transfer — die Reibung verschwindet nicht, sie verlagert sich. Stärkt eher die strategische Relevanz von CJRM im Banking-Kontext, als sie zu schwächen.
CJML-Notation und Beispiel
Dokumentiert die CJML-Notation im Detail, anhand einer eigenen Arbeitsprobe (Swimlane-Beispiel Strombestellung).
Terminologie
- CJML ist eine formale Sprache zur Spezifikation und Visualisierung von Customer Journeys und Serviceprozessen.
- Im Mittelpunkt stehen Menschen und menschliche Aktivitäten, unabhängig von ihrer Rolle als Kunde, Nutzer, Bürger, Verbraucher, Patient oder Mitarbeiter.
- Journeys werden als Sequenzen oder Konstellationen von Berührungspunkten modelliert.
- CJML besteht aus vier Bestandteilen: Terminologie, Diagrammen, Methoden und Werkzeugen.
- Kommunikationspunkte sind Instanzen der Kommunikation/Interaktion zwischen Nutzer und Dienstanbieter.
- Aktionen sind nicht-kommunikative Ereignisse oder Aktivitäten.
„Der Umfang einer Reise sollte in Bezug auf den Zweck der Studie definiert werden" — der Scope einer Journey ist eine bewusste Abgrenzungsentscheidung, kein Naturgegebenes.
Notationselemente
| Element | Bedeutung |
|---|---|
| Kreis auf der Zeitachse | Kommunikationspunkt |
| Abgerundetes Rechteck | Aktion (nicht-kommunikativ) |
| Icon im Touchpoint-Symbol | Kanal (Person, SMS, Telefon, Computer, Bank …) |
| Swimlane | ein Akteur |
| Vertikaler Pfeil zwischen Lanes | Kommunikation — gerendert als zwei verknüpfte Boxen, eine je Akteur |
| Kreuz-Symbol | Status „missing" oder „failing" |
| Phasen-Header-Balken | Aggregation von Touchpoints zu Phasen |
| Schraffierte Fläche | Wartezeit / Idle-Periode |
Ein Kommunikationspunkt erscheint als zwei Boxen (Sender-/Empfänger-Lane) + Pfeil — nicht als ein Symbol. Das bestätigt: das Layer-1-Schema (ein Event-Node + zwei Event involves Actor-Edges mit role) reicht für die Darstellungs-Engine aus — nur das Rendering muss daraus zwei Boxen erzeugen.
Beispiel: Strombestellung bei einem Versorgungsunternehmen
„Tatsächlicher Weg der Strombestellung" — Actual Journey, fünf Akteure, vier Phasen.
| Zeitpunkt | Phase | Akteur | Ereignis | Status |
|---|---|---|---|---|
| Mo 19.03, 8:30 | Willkommen | Stromversorger → Kunde | Willkommensgruß | completed |
| Di 20.03, 14:30 | Zähler-Ablesung | Netzgesellschaft → Kunde | Benachrichtigung Zählerstand | completed |
| — | Zähler-Ablesung | Kunde | Zähler ablesen (Weg 1) | completed |
| — | Zähler-Ablesung | Kunde → Netzgesellschaft | Zähler ablesen (Weg 2, mobil) | missing/failing |
| Mo 26.03, 09:00 | Rechnung | Netzgesellschaft → Kunde | Rechnung versenden | teils durchgestrichen |
| Wartezeit — schraffiert | ||||
| Mo 16.04, 09:00 | Ziel | Kunde → Bank | Rechnung bezahlt | completed |
Die Journey zeigt zwei parallele, alternative Wege für dieselbe Aktion — im aktuellen Schema nur implizit abbildbar (zwei separate Event-Nodes mit gleichem Zeitfenster, unterschiedlichem Outcome), noch nicht als eigenes Muster dokumentiert.
- Verbindungen
- → Layer-1-Schema
- → Architekturmodell
Swimlane-Renderer — Live-Demo
Erster funktionierender Layer-3-Baustein: ein datengetriebener CJML-Swimlane-Renderer (SVG aus einem kleinen Datensatz erzeugt, kein statisches Bild).
CJML kennt zwei Hauptdiagrammtypen: das Customer Journey Diagram (eine Zeitachse, ein Akteur) und das Journey Network Diagram, meist Swimlane-Diagramm genannt — mehrere Akteure als Zeilen, Pfeile zwischen den Lanes für jede Kommunikation. Für Journeys mit mehreren Beteiligten ist Swimlane der praktisch relevante Typ — auch in der eigenen Arbeitsprobe (Dokument B) der genutzte.
Die Demo unten rendert das dortige Strombestellungs-Beispiel (leicht vereinfacht auf vier Lanes) direkt aus einem Datensatz, der der Form des Layer-1-Schemas entspricht: jede Spalte ist ein Zeitpunkt, jede verknüpfte Box-Paar ist ein Event mit zwei Event involves Actor-Kanten (Sender/Empfänger), Status und Kanal kommen direkt aus den Event-Properties.
Was das zeigt — und was noch fehlt
- Die im CJML-Dokument (B) notierte Beobachtung bestätigt sich beim Bauen: ein Kommunikationspunkt ist zwei Boxen + Pfeil, nicht ein Symbol — das Rendering liest das direkt aus zwei verknüpften Touchpoint-Einträgen.
- Status (completed/missing/failing) und Kanal-Icon kommen 1:1 aus den Event-Properties des Layer-1-Schemas — keine manuelle Stilentscheidung pro Box.
- Diese Demo ist handgesetzt (CJML-nahe Daten, nicht rohe CJRM-Instanz) — Dokument D zeigt denselben Fall jetzt durch den echten CJRM→CJML-Transform erzeugt, plus die Agent-Execution-Trace-Filterung am Beispiel.
CJRM→CJML-Transform — vom Graph zum Bild
Nimmt eine rohe CJRM-Instanz (Nodes + Edges, exakt im Format aus dem Layer-1-Schema) und erzeugt daraus automatisch die Swimlane-Darstellung — inklusive Agent-Execution-Trace-Filterung.
Implementiert die Transformationstabelle aus dem Layer-1-Schema als lauffähigen Code: Communication Point ← Interaction-Event, Sender/Empfänger ← Event involves Actor mit role, Status ← verknüpfter Outcome.polarity (oder „missing" ohne Outcome), Swimlane ← beteiligter Actor, Customer-Journey-vs-Agent-Execution-Trace ← ob ein human-Actor direkt beteiligt ist.
Die dokumentierte Transformationstabelle deckte Action-Events (nicht-kommunikativ, laut CJML ein eigenes Notationselement — abgerundetes Rechteck ohne Gegenüber) nicht explizit ab, nur Interaction. Im Code ergänzt: Action-Events werden wie Communication Points behandelt, aber ohne zweite Seite und ohne Verbindungspfeil. Sollte in Dokument 05 nachgetragen werden.
Beispiel A — Strombestellung, durch den Transform erzeugt
Dieselbe Journey wie in der Live-Demo oben, jetzt aber nicht mehr handgesetzt: die SVG unten entsteht ausschließlich aus der CJRM-Instanz rechts. Eine Besonderheit ist eingebaut, um die missing-Ableitung zu zeigen: event:zaehler-lesen1 hat absichtlich keine verknüpfte Outcome-Kante.
Für dieses Beispiel außerdem synthetisch angereichert (2026-09-19), um die Journey-Map-Ansicht an einer vollständigeren Instanz zu zeigen statt nur am kargen Live-Beispiel im Erfassungstool: drei Phasen (phase_hint), eine Ziel-Struktur auf dem fehlschlagenden Schritt (event:zaehler-lesen2 impairs goal:g-wechsel, institutionell induziert durch die gesetzliche Meldepflicht) und zwei Opportunity-Claims. Dieselbe Instanz, zweite Ansicht:
Stimmungs-Kurve wie bei Smaply: ein Punkt je Touchpoint (nicht je Phase), durchgehend verbunden — missing liegt bewusst auf der Nulllinie, nicht negativ, weil ein fehlender Outcome kein beobachteter Misserfolg ist.
…
Beispiel B — Baufinanzierung mit Agency Transfer
Erweitert das Worked Example aus Dokument 05 um ein kundenseitig sichtbares Mandat-Erteilungs-Event (event:e0), das dort nur als Prosa erwähnt, nicht ausmodelliert war. Eine Instanz, zwei gefilterte Views:
| View | Filterregel | Enthält |
|---|---|---|
| Customer Journey | mind. ein human-Actor direkt beteiligt | event:e0 — Mandat erteilen (Kunde ↔ Agent) |
| Agent Execution Trace | kein human-Actor direkt beteiligt | event:e1 — Video-Ident-Prüfung (Agent ↔ Bank) |
Customer Journey (gefiltert):
Agent Execution Trace (gefiltert):
Die Filterregel aus Dokument A ist keine Beschreibung mehr, sondern läuft: kyc-agent ist als ai-agent markiert, e1 hat keinen direkt beteiligten human-Actor → landet automatisch im Agent Execution Trace. Die Customer Journey schrumpft exakt auf das Mandat-Erteilungs-Event — „grant Mandate → receive Outcome", jetzt als tatsächlich gerendertes Bild statt als Satz.
goal:g2 („Identität verifizieren") gehört laut Actor owns Goal dem Kunde. Seit das Ziel-Struktur-Badge auf die Goal-Owner-Rolle beschränkt ist (statt auf beiden Seiten eines Kommunikationspunkts zu erscheinen), zeigt event:e1 — Kunde ist hier nicht beteiligt, nur der Agent und die Bank — folgerichtig kein Badge mehr. Das ist kein Darstellungsfehler, sondern zeigt strukturell dasselbe wie die Agency-Transfer-Filterregel selbst: Sobald ein Schritt an einen Agenten delegiert ist, verschwindet der sichtbare Bezug zum ursprünglichen, menschlichen Goal-Owner aus der Ausführungsspur — es sei denn, man verfolgt ihn bewusst über die Mandate-Kette zurück (bislang nicht gebaut, s. „Was noch fehlt").
…
Was noch fehlt
- Pro-Event nur ein Label für beide Seiten (Sender und Empfänger zeigen denselben Text) — CJML-Beispiele formulieren oft unterschiedlich („sendet" vs. „erhält"). Mögliche Erweiterung: optionales
label-Property auf derEvent involves Actor-Kante statt nur auf dem Event. - Spaltenlayout nutzt Sequenzindex (
timestampals Zahl), nicht echte Zeitabstände — eine Journey mit sehr ungleichmäßigen Pausen würde gleich breite Spalten trotzdem gleich breit zeichnen. - Keine Phasen-Header — Phase ist im Core-Ontology-Dokument ein abgeleitetes Konzept ohne eigenes Node-Property; für die Live-Demo oben (Dokument C) wurden Phasen manuell zugeordnet, hier bewusst weggelassen, um zu zeigen, was der Transform allein aus der Instanz ableiten kann.
- Ziel-Struktur-Badge folgt der Goal-Owner-Rolle strikt über
Actor owns Goal— bei Agency-Transfer-Events (wieevent:e1hier) verschwindet das Badge dadurch, weil der Owner nicht direkt beteiligt ist. Keine Mandate-Kette-Rückverfolgung zum ursprünglichen Owner gebaut.
Erfassungstool — Live-Demo
Erster funktionierender Layer-2-Baustein: ein strukturiertes Erfassungsformular, das direkt eine CJRM-Instanz aufbaut und sie live durch denselben Transform (Dokument D) in eine Swimlane rendert.
Setzt Dokument 04 in drei Varianten um — nebeneinander, nicht nacheinander entschieden: Formular (Analyst füllt die Ontologie direkt aus), Interview, Skript (Stufe 1 aus Dokument 04 pur — feste Laddering-Fragen, Antworten bleiben unstrukturierte Claims, Synthese ein separater Schritt) und Interview, KI (Stufe 1+2 zusammen — dieselben Fragen, aber Claude extrahiert am Ende strukturierte CJRM-Objekte aus dem Transkript). Alle drei speisen dieselbe Zustands- und Render-Pipeline.
1 — Akteure
„ai-agent" ist die Voraussetzung dafür, dass ein Event später als Agent Execution Trace erkannt wird (s. Dokument A/D) — nur wenn kein beteiligter Akteur human ist.
2 — Ziel-Struktur (Job → Goal ← Constraint)
Laddering aus Dokument 04: Job (lösungsstabiles Ziel eines Akteurs) → Goal (davon abgeleitet oder durch einen Constraint erzwungen) → Constraint (was diesen Schritt sonst überflüssig machen würde).
3 — Event erfassen
Laddering-Frage dahinter (s. Dokument 04): „Warum existiert dieser Schritt — und was würde passieren, wenn es ihn nicht gäbe?" Kein Outcome zu verknüpfen ist ein gültiges, oft aufschlussreiches Ergebnis.
| # | Event | Typ | Akteure | Status |
|---|
Geframed, nicht frei wie Miro — aber die Struktur ist jetzt Phasen, nicht Akteure: ein Workshop denkt zuerst in Etappen der Erfahrung, nicht in Zuständigkeiten. Eine Phase anzulegen erzeugt eine Spalte; Notizen werden hineingesetzt, frei verschoben, mit einem Akteur getaggt (Farbpunkt) wenn bekannt. Die Akteur-Lane-Struktur bleibt der Darstellungs-Engine (CJML/Swimlane) vorbehalten — genau deren Verwechslung war der Fehler im ersten Canvas-Entwurf, s. Dokument 04.
Rahmen: Phasen, Job, Akteure
Canvas
„+ Notiz" setzt eine neue Karte in die erste Phase — anklicken zum Umbenennen/Typ ändern/Akteur zuordnen/Löschen, ziehen zum Verschieben in eine andere Phase oder Position. Farbe zeigt den Typ (neutral = Fakt, rot = Problem, grün = Idee), der Punkt oben rechts den zugeordneten Akteur, falls einer getaggt ist.
Leitfaden (ohne KI)
Kein starrer Frage-für-Frage-Ablauf — ein Leitfaden orientiert an Contextual Inquiry und Journey-Archetypen (Dokument 08), in beliebiger Reihenfolge und mit eigenen Worten zu füllen, wie ein Interviewer ihn während eines echten Gesprächs neben sich liegen hätte. Jedes Feld wird als Claim gespeichert (epistemic_status: claim) — Synthese zu Job/Goal/Constraint bleibt ein separater, manueller Schritt (Wechsel zu „Formular").
Interview · KI (freies Gespräch nach Leitfaden)
Fragt zuerst nach einer konkreten Erinnerung statt nach einem abstrakten Ziel (Critical-Incident-Prinzip), hört der Geschichte zu und hakt nur bei interessanten Stellen mit „Warum war dir das wichtig?" nach (Laddering) — statt stur eine Themenliste abzufragen. Methodisches Vorbild in Dokument 08. Wenn genug zusammengekommen ist: „Mit KI strukturieren" — ein separater Aufruf (sample.json), der das ganze Gespräch in Job/Goal/Constraint/Event übersetzt und in dieselbe geteilte Instanz schreibt wie „Formular".
Live-Ergebnis
Ziel-Struktur (abgeleitet aus Job/Goal/Constraint):
Swimlane ist die CJML-konforme Darstellung (Akteur-Lanes). Journey Map ist die alternative, phasenbasierte Ansicht (Schritte/Stimmung/Pain Points/Gains/Ziele/Opportunities je Phase, wie bei Smaply/TheyDo üblich) — beide aus derselben Instanz abgeleitet, kein separates Modell.
Customer Journey:
Agent Execution Trace:
Customer Journey:
Agent Execution Trace:
…
Was noch fehlt
- Die Ziel-Struktur fließt jetzt auch visuell in die Swimlane ein (gelber Punkt auf Events, deren Outcome zu einem constraint-/institution-induced Goal führt, Hover zeigt Goal + Constraint) — Beispiel in Dokument D, Instanz B. Noch offen: das Badge erscheint auf beiden Seiten eines Kommunikationspunkts (Sender- und Empfänger-Box), auch wenn nur eine Seite das Goal „besitzt" — keine Unterscheidung nach Actor-Rolle.
- KI-Extraktion (Tab „Interview · KI") liest den bisherigen Aktoren-Bestand, schlägt aber bei neuen Akteuren nur
kind: humanvor — keine Rückfrage an die Person, ob das stimmt. - Beide Interview-Varianten fragen eine feste, kurze Sequenz ab (kein echtes, sich verzweigendes Laddering, das auf vorherige Antworten reagiert) — das eigentliche „Bohren bis zum Constraint" aus Dokument 04 ist damit nur angedeutet, nicht vollständig simuliert.
- Speicherung nur lokal im Browser (
localStorage) — kein geteilter Zustand zwischen Geräten oder Personen.
Interview-Leitfaden — Referenzmodell
Warum die erste Fassung des KI-Interviews zu sehr insistierte und zu wenig hinterfragte — und ein Customer-Journey-spezifisches Modell (nicht generische Sozialforschung), das das behebt.
Diagnose der ersten Fassung
Die ursprüngliche Instruktion gab Claude eine nummerierte Themenliste mit der Anweisung, „darauf einzugehen" — aber der Einstieg fragte direkt nach einem abstrakten Ziel, und die Liste blieb faktisch ein abzuarbeitendes Raster. Zweiter Schwachpunkt, von TVE benannt: allgemeine Sozialforschungsmethodik (JTBD, generisches Laddering) ist zu unspezifisch für Customer-Journey-Interviews — es gibt speziellere, CJ-nahe Bausteine.
Methodische Grundlage (CJ-spezifisch statt generisch)
Contextual Inquiry (Beyer & Holtzblatt, Contextual Design, 1998 — Sekundärquellen unten, Primärwerk nicht eingesehen): die etablierte Methode speziell für Akteure/Schritte im Detail. Vier Prinzipien: Context (immer an einer konkreten, tatsächlichen Instanz verankern, nie an Abstraktion), Partnership (gemeinsames Verstehen statt Abfrage), Interpretation (Verständnis laufend zurückspiegeln und bestätigen lassen), Focus (auf die Forschungsfrage steuern, ohne die Geschichte zu unterbrechen). Nutzt Five-Whys für Motivations-/Constraint-Verständnis. [1]
Journey-Archetypen (Gopaldas & Siebert — Sekundärquelle unten, Primärpublikation nicht eingesehen): vier Typen entlang zweier Achsen — Aufwand (mühelos/mühevoll) × Vorhersagbarkeit (erwartbar/überraschend): Routine (mühelos, erwartbar — wiederkehrende Alltagsaufgabe), Trek (mühevoll, erwartbar — anspruchsvolles, aber bekanntes Langfristziel), Joyride (mühelos, überraschend — Variation/Überraschung gewünscht), Odyssey (mühevoll, überraschend — Leidenschaftsprojekt). Hilft, die nötige Interviewtiefe früh zu kalibrieren. [2]
Phasen-Hypothese (Nielsen Norman Group): vor bzw. während des Interviews prüfen, ob sich die Erfahrung aus Sicht der Person in Etappen/Übergänge gliedert — deckt sich mit CJMLs Phasen-Konzept (Aggregation von Touchpoints, s. Dokument B). [3]
Obstacles & Delights (TheyDo, CJ-Interview-Praxis): explizit nach Schwierigkeiten und guten Momenten fragen, nicht nur nach Reibung — Erinnerung ist unzuverlässig, konkrete Timeline-Nacherzählung hilft dagegen. [4]
Leitfaden vs. Skript (qualitative Sozialforschung, weiterhin gültig): ein Leitfaden ist kein Fragebogen — kurze gescriptete Eröffnung, wenige offene Kernfragen, Probes situativ statt vorab fixiert. Abschweifungen gelten als Daten, nicht als Störung. [5]
[2] Harvard Business Review (2022), What You're Getting Wrong About Customer Journeys (referenziert Gopaldas & Siebert) — hbr.org/2022/07/what-youre-getting-wrong-about-customer-journeys
[3] Nielsen Norman Group, How to Conduct Research for Customer Journey Mapping — nngroup.com/articles/research-journey-mapping
[4] TheyDo (2024), 6 strategies to conduct interviews that uncover the customer journey — theydo.com/blog/articles/6-strategies…
[5] CASRAI, Designing Semi-Structured Interviews: A Practical Guide — casrai.org/guides/semi-structured-interviews-design-guide
Bei [1] und [2] sind das Sekundärquellen — die Primärwerke (Beyer/Holtzblatt 1998, Gopaldas/Siebert) selbst wurden nicht eingesehen, nur diese Zusammenfassungen. Vollständige Erfassung mit Zugriffsdatum in der zentralen Quellendatenbank des Vaults.
Acht Leitfaden-Themen (still verfolgt, nie als Agenda ausgesprochen)
- Konkrete Situation — ein bestimmtes, tatsächliches Erlebnis verankern (Contextual-Inquiry-Prinzip „Context")
- Intent — was die Person in dieser Situation eigentlich erreichen wollte
- Archetyp — Aufwand × Vorhersagbarkeit (Routine/Trek/Joyride/Odyssey), nie so benannt
- Etappen/Phasen — natürliche Abschnitte und Übergänge aus Sicht der Person
- Akteure und Schritte im Detail — wer war wann beteiligt, in welcher Reihenfolge
- Schwierigkeiten — wo es mühsam, verwirrend oder frustrierend war
- Gute Momente — was besonders schön oder positiv überraschend war
- Warum nötig — Laddering an mühsamen Schritten: „warum nötig", „was hätte es überflüssig gemacht"
Ablauf
Eröffnung mit einer konkreten Erinnerung statt einem abstrakten Ziel, dann primär zuhören — die meisten der acht Themen ergeben sich aus einer gut erzählten Geschichte von selbst. Laddering-Nachfragen nur kontingent, max. 2–3 Schritte am Stück, danach zurück zur Geschichte. Am Ende ein stiller Gap-Check: nur was aus der Geschichte nicht hervorging, wird gezielt und an das Erzählte angeknüpft nachgefragt.
Meta-Regeln
- Immer nur eine Frage stellen
- Keine Fachbegriffe (Job/Goal/Constraint/Archetyp/Ontologie nie aussprechen)
- Tangenten sind Daten, keine Ablenkung — ihnen folgen, bevor man zum Leitfaden zurückkehrt
- Nichts fragen, das schon beantwortet wurde
- Bei Sättigung (wiederholte/vage Antworten wie „weiß nicht") das Thema loslassen, nicht insistieren
- Nicht laut bewerten oder interpretieren, nur sammeln
Der Prompt im Erfassungstool, Tab „Interview · KI", folgt jetzt diesem Modell — inklusive Extraktion von Archetyp, Phasen-Hinweis, Schwierigkeiten und guten Momenten in die CJRM-Instanz (Archetyp als Job-Property, Phasen-Hinweis als Event-Property, Schwierigkeiten/gute Momente als Claim-Nodes).
- Verbindungen
- → Erfassungstool (Umsetzung)
- → Erfassungsmethodik