Busflow Docs

Internal documentation portal

Busflow Docs

Appearance

ADR-021: Customer Intelligence Bounded Context ​

Date: 2026-04-17 Status: Proposed [future — Phase 3]Deciders: Julian Brüning

Context ​

The Busflow platform lists "360° Customer Profile" as a core differentiator (see PRODUCT_differentiators-10-percent.md §1). The current architecture stores passenger identity data on backoffice.passenger_profiles (8 columns: name, contact info, dietary needs) and links it to Commerce bookings and Communications contacts via soft FKs.

This baseline structure captures who the customer is but provides no mechanism to capture what they do, what they prefer, or what they are likely to want next. The planned feature surface requires:

  • Intelligent per-user recommendations (personalized tour suggestions)
  • Collaborative recommendations ("passengers who booked Nordsee also booked Ostsee")
  • Behavioral aggregation (booking frequency, lifetime value, channel preference, no-show rate)
  • Proactive anticipation (pre-fill checkout, seasonal rebooking prompts)
  • Seamless cross-media experience (unified identity across booking widget, WhatsApp, email, phone)

None of these capabilities belong cleanly in any existing bounded context:

ContextWhy It Doesn't Fit
BackofficeOwns PassengerProfile as master data, but behavioral analytics and ML models are outside its cohesion boundary.
CommerceOwns bookings and payments, but recommendations span beyond purchases (boarding behavior, communication patterns, trip feedback).
CommunicationsOwns messaging delivery, but deciding what to say (personalized content) is a separate concern from how to deliver it.
OperationsOwns fleet execution. Customer analytics falls outside its responsibility.

Decision ​

We introduce a fifth bounded context — Customer Intelligence — as a [future — Phase 3] planned addition to the bounded context map. It operates as an event-sourced analytics domain that consumes activity signals from all four operational contexts and produces enrichment, segmentation, and recommendation outputs.

Subdomain Classification ​

Core Subdomain. The 360° customer profile and intelligent recommendations are key competitive differentiators. A bus-tourism-specific CDP cannot be purchased off the shelf, and it directly drives customer retention and operator revenue.

Scope ​

The Customer Intelligence context owns:

  • CustomerActivityLog — event-sourced ledger of all customer touchpoints
  • BehaviorAggregate — materialized per-customer metrics (lifetime value, booking frequency, preferred seat, preferred boarding point, no-show rate)
  • CustomerSegment — cohort definitions for targeted marketing (e.g., "frequent Nordsee travelers", "high-value one-time bookers")
  • EngagementScore — computed customer health (NPS, satisfaction, churn risk)
  • RecommendationModel — ML pipeline outputs for per-user and collaborative suggestions
  • ChannelPreference — learned preferred communication channel per customer

The Customer Intelligence context does not own:

  • PassengerProfile — stays in Backoffice (identity + operator-managed preferences)
  • Contact — stays in Communications (messaging identity + delivery)
  • Booking / Passenger — stays in Commerce (transactional records)

Event Consumption ​

The context operates as a downstream consumer of domain events from all four operational contexts:

Source ContextEvents ConsumedData Extracted
CommerceBookingConfirmed, BookingCancelled, BookingNoShow, CheckoutAbandoned, AncillaryPurchased, PaymentCompletedBooking frequency, revenue, cancellation patterns, upsell behavior
OperationsBoardingEventCreated, OnboardSaleRecorded, ServiceLegCompletedBoarding behavior, onboard purchases, trip completion
CommunicationsMessageDelivered, MessageRead, ConversationResolvedChannel preference, response rates, engagement patterns
BackofficePassengerProfileUpdatedIdentity changes, dietary preference updates

Enrichment Outputs ​

The context produces enrichment signals consumed by other contexts:

Target ContextOutputPurpose
CommercePersonalizedOfferGeneratedTour recommendations for booking widget personalization
CommunicationsEngagementTrigger, ChannelPreferenceResolvedOptimal channel selection, re-engagement timing
BackofficeProfileEnrichmentAvailableAggregated metrics surfaced on the CRM screen and CTI pop-up

Relationship to PassengerProfile ​

PassengerProfile remains the identity anchor in Backoffice. Customer Intelligence reads it (via PassengerProfileUpdated events) but never writes to it. Instead, CI exposes a CustomerInsight read model that the Workspace UI consumes alongside the PassengerProfile — giving dispatchers the full 360° view without coupling Backoffice to analytics logic.

┌─────────────────────────────────────────────┐
│            Workspace UI (CRM Screen)        │
│                                             │
│  ┌──────────────┐   ┌───────────────────┐   │
│  │ Passenger     │   │ Customer Insight  │   │
│  │ Profile       │   │ Read Model        │   │
│  │ (Backoffice)  │   │ (CI Context)      │   │
│  │               │   │                   │   │
│  │ Name, email,  │   │ Lifetime value,   │   │
│  │ phone, DOB,   │   │ booking count,    │   │
│  │ dietary needs │   │ preferred seat,   │   │
│  │               │   │ NPS score,        │   │
│  │               │   │ recommendations,  │   │
│  │               │   │ churn risk        │   │
│  └──────────────┘   └───────────────────┘   │
└─────────────────────────────────────────────┘

Consequences ​

Positive ​

  • Clean separation of concerns: Operational contexts remain focused on their core workflows. Analytics logic does not bloat Backoffice or Commerce.
  • Event-sourced by design: The CustomerActivityLog can retroactively replay historical events once the context starts, filling the behavioral history from day one data.
  • ML-ready architecture: Dedicated context provides a natural home for recommendation models, feature stores, and training pipelines without polluting operational schemas.
  • GDPR-compliant by design: All customer analytics data concentrates in one context, simplifying erasure cascades and consent management.

Negative ​

  • Not implemented in Phase 1 or Phase 2. The operational contexts must emit the consumed events regardless — this creates a "publish now, consume later" pattern. All events listed above should already exist in the event catalog for operational purposes; CI simply adds a new consumer.
  • Cross-context read model complexity. The CustomerInsight read model requires Hasura Remote Relationships or a dedicated API endpoint to join with Backoffice data in the Workspace UI.

Risks ​

  • Premature optimization. Building the full CI context before understanding real usage patterns could lead to wrong aggregation choices. Mitigation: defer to Phase 3, let Phases 1–2 generate real data.
  • Event schema coupling. CI depends on a stable event schema from all four operational contexts. Breaking changes to event payloads affect CI consumers. Mitigation: event contracts are already versioned (see event-catalog.md).

Preparation (Phase 1–2) ​

While the full CI context is deferred, the following actions during Phases 1–2 lay the groundwork:

  1. Ensure all events listed above are emitted by their source contexts (most already exist in the event catalog).
  2. Add marketing_consent and locale to passenger_profiles — these are identity-level fields that belong on the profile regardless of CI.
  3. Document the Contact ↔ PassengerProfile merge strategy — ensure Communications auto-links new Contacts to existing profiles by email/phone match.
  4. Keep PassengerProfile lean — resist the temptation to add aggregated fields (lifetime_value, booking_count) directly to the profile. These belong in CI.

References ​

Internal documentation — Busflow

© 2026 MLP Software Development