Feature Subsets
Status: ACTIVE // DRAFT
Busflow's Modular Monolith architecture — with strictly segregated Bounded Contexts (Backoffice, Commerce, Operations, Communications) communicating via domain events — natively supports developing and offering independent feature subsets. This document maps each commercial product subset to its authoritative domain documentation, enabling "wedge" sales to Legacy Operators without requiring a full-platform migration on day one.
IMPORTANT
This document is a routing table, not a specification. Each feature links to its authoritative source. Do not duplicate domain definitions here — update the source docs and keep this index in sync.
Subset Overview
| # | Subset | Primary Context | Wedge Target | Horizon |
|---|---|---|---|---|
| 1 | E-Commerce & Revenue Engine | Commerce | Patchwork Operators lacking online sales | [v0.1]–[v0.2] |
| 2 | Digital Fulfillment & Premium Passenger Experience | Commerce + Communications | Operators sending PDF tickets via email | [v0.1]–[v0.2] |
| 3 | Driver-First Execution Hub | Operations | Operators with clipboard-based fleet execution | [v0.2]–[future] |
| 4 | Crisis Management & Automated Communications | Communications | Operators drowning in WhatsApp/email chaos | [v0.2]–[future] |
| 5 | AI-Powered Backoffice | Backoffice | Operators drowning in manual data entry | [v0.2]–[future] |
| 6 | Kalkulations- & Finance Engine | Backoffice + Commerce | Operators lacking margin visibility and tax automation | [v0.2]–[future] |
| 7 | Zero-Integration Onboarding (Email-as-API) | Backoffice + Commerce | Patchwork Operators refusing to change tools | [v0.2] |
| 8 | Compliance & Audit-Readiness | Backoffice + Operations + Commerce | Legacy Operators fearing audits and fines | [v0.2]–[future] |
NOTE
Sellable now vs. future wedges: Only Subsets 1 and 2 contain [v0.1] features and are pitchable at/near launch. Subsets 3–8 are [v0.2]+ wedges — real entry points, but gated on later delivery. Read the GTM table with this timing in mind.
Inter-Context Dependencies
Each subset maps to one primary Bounded Context but may consume events or read models from others. The table below tracks these cross-context requirements so engineering and sales teams understand what ships independently and what requires co-deployment.
| Subset | Required Contexts | Key Domain Events Consumed | Notes |
|---|---|---|---|
| 1. E-Commerce Engine | Commerce, Backoffice (upstream) | TourDeparturePublished, PriceMatrixPublished | Backoffice owns product data; Commerce owns checkout. The engine requires published tours to sell. |
| 2. Digital Fulfillment | Commerce, Communications | BookingConfirmed, ServiceLegDelayed | Wallet pass generation is Commerce; dynamic delay updates route through Communications. |
| 3. Driver Hub | Operations, Backoffice (upstream) | LegAssignmentCreated, CrewScheduleUpdated | Receives dispatch assignments from Backoffice. Emits ExpenseSubmitted, OnboardSaleRecorded back to Commerce. |
| 4. Crisis Communications | Communications, Operations (upstream) | IncidentCreated, ServiceLegDelayed | Operations produces the incidents; Communications delivers the broadcasts. |
| 5. AI Backoffice | Backoffice | — (self-contained) | Emits TourDeparturePublished downstream but does not consume cross-context events. |
| 6. Kalkulations-Engine | Backoffice, Commerce (downstream) | BookingConfirmed, ExpenseSubmitted, OnboardSaleRecorded | Backoffice owns cost planning (CostingSheet) and price generation (PriceMatrix). Commerce owns post-departure actuals (FinancialLedger). |
| 7. Email-as-API | Backoffice, Commerce | — (ingestion source; produces drafts) | Front door, not a consumer. Forwarded emails become draft TourTemplates (Backoffice) and draft Bookings (Commerce). Shares the AI parser with Subset 5's Magic Upload. |
| 8. Compliance & Audit-Readiness | Backoffice, Operations, Commerce | BookingConfirmed, ExpenseSubmitted, CrewScheduleUpdated | Cross-cutting. Composes features owned by Subsets 5 (EU-561) and 6 (§ 25 UStG, DATEV, period locks); introduces no new domain entities. |
See event-catalog.md for the full event registry and domain-model.md for the context map.
1. E-Commerce & Revenue Engine
For operators whose legacy software lacks modern online sales capabilities — a "Shopify for Bus Tours" that instantly boosts conversion rates.
Primary Context: Commerce · Wedge Target: Patchwork Operators · Horizon: [v0.1]–[v0.2]
| Feature | Horizon | Authoritative Source |
|---|---|---|
| High-Conversion Booking Widget — Fast, SEO-optimized, embeddable checkout with frictionless guest checkout. | [v0.1] | STRATEGY_platform-vision.md §H1 · differentiators.md §1 |
| Interactive Seat Selection — Visual seat maps where seats are database-locked for the duration of the checkout session. | [future] | domain-commerce.md → SeatReservation · ADR-013 |
| Modern Payment Stack — Localized gateways via Mollie handling Apple Pay, Google Pay, Klarna (BNPL), and SEPA, alongside automated deposit and final balance logic. | [v0.1] | PRODUCT_mollie-integration.md · domain-commerce.md → Payment |
| B2B Agency Portal — A white-label API portal allowing partner travel agencies to book directly on commission. | [v0.2] | domain-backoffice.md → Reseller · Journey 4: B2B API & Fleet Re-routing |
CAUTION
Wedge risks — Booking Widget deployed alongside Kuschick BusPro.net®:
- Sync Back to Kuschick — When the widget sells a seat, the operator's existing Kuschick instance must reflect that booking so BusPro.net® remains source-of-truth during the wedge phase (dispatch, manifests, accounting, § 25 UStG calculation all still run there). No documented inbound integration path exists. Open: ingestion mechanism (CSV/Access import, Pressmind IBE middleware, direct SQL Server write, file-drop), conflict semantics (double-booking against Kuschick-originated sales, refund and cancellation propagation), and reconciliation cadence. See competitor-kuschick.md for the legacy stack profile and kuschick-integration-research.md for open research leads.
- Laws & Co. — Can Kuschick shut us out? Kuschick's license terms for BusPro.net®, the Pressmind/truetravel IBE contract, and any DPA between operator and Kuschick may restrict third-party integration, data extraction, or competitive interoperability on an operator's own instance. Legal leeway around operator-owned data export (GDPR Art. 20 portability, German competition law, EU Data Act §IV interoperability obligations) versus vendor lock-in clauses needs counsel review before pitching the wedge.
NOTE
Open item: PD-1 tracks the agency commission ↔ margin interplay — this needs resolution when channel pricing (Pricing Hierarchy Level 2/3) begins.
2. Digital Fulfillment & Premium Passenger Experience
Elevates the customer journey to airline standards and drastically reduces inbound support calls.
Primary Context: Commerce + Communications · Wedge Target: Operators sending PDF tickets · Horizon: [v0.1]–[v0.2]
| Feature | Horizon | Authoritative Source |
|---|---|---|
| Passwordless Passenger Portal — A "Magic Link" hub where passengers retrieve PDFs, manage bookings, and make self-service balance payments. | [v0.2] | STRATEGY_platform-vision.md §H1 · Journey 3: Onboard Revenue |
| Dynamic Digital Ticketing & Offline Validation — Automated Apple and Google Wallet passes that update dynamically on delays. Includes cryptographic passenger-side offline credential validation (CBOR/CWT/COSE) for low-connectivity boarding. | [v0.1]–[v0.2] | domain-commerce.md → Ticket · Journey 2: Alpine Stau |
| Live ETA Tracking — A secure "Where is my Bus?" web link providing passengers with live maps and exact arrival times. | [v0.2] | domain-operations.md → TelemetryPoint, RouteWaypoint · event-contracts-operations.md §Consumer ETA Tracking |
NOTE
Live ETA Tracking depends on the TelemetryPoint high-frequency GPS ingestion pipeline. See domain-driven-design.md §5 for the fast-ingest architecture.
3. Driver-First Execution Hub
Even if a legacy system handles bookings, this mobile-first ecosystem modernizes fleet execution, eliminates clipboards, and attracts digitally native drivers.
Primary Context: Operations · Wedge Target: Operators with clipboard-based execution · Horizon: [v0.2]–[future]
| Feature | Horizon | Authoritative Source |
|---|---|---|
| Offline-First Driver PWA — A mobile app functioning fully offline, featuring QR-code boarding and digital passenger manifests. | [v0.2] | domain-operations.md → BoardingEvent · domain-operations.md §Offline Sync · offline-sync-protocol.md |
| Onboard POS (Bordverkauf) — A tap-to-add interface for selling snacks or upsells mid-trip, utilizing digital payment links or cash. | [v0.2] | domain-operations.md → OnboardSale · Journey 3: Onboard Revenue |
| AI Receipt Capture — Native camera OCR that extracts fuel and toll receipt data, instantly pushing it back to accounting. | [v0.2] | domain-operations.md → ExpenseReceipt · event-catalog.md → ExpenseSubmitted |
NOTE
The V0.1 scope (STRATEGY_platform-vision.md §H1) defers the full PWA Driver App to V0.2+, recommending "simple mobile web for now if needed." The features above represent the target-state architecture; initial delivery will likely start with a simplified mobile web interface.
4. Crisis Management & Automated Communications
An intelligent communication wrapper that solves the WhatsApp and email chaos plaguing dispatchers during day-of-departure crises.
Primary Context: Communications · Wedge Target: Dispatchers managing crises via personal WhatsApp · Horizon: [v0.2]–[future]
| Feature | Horizon | Authoritative Source |
|---|---|---|
| Omnichannel Inbox — Consolidates WhatsApp, Email, and SMS into a single dispatcher UI, utilizing AI to draft contextual responses. | [v0.2] | domain-communications.md · communications.md |
| 1-Tap Incident Reporting — Drivers drop a GPS pin to report traffic or breakdowns, triggering a high-priority alert to the back office. | [v0.2] | domain-operations.md → Incident · event-catalog.md → IncidentCreated |
| Communication Decision Engine — Resolves cross-context notification conflicts via Supersession Rules and Freshness Gates before they reach the passenger. | [v0.2] | ADR-033 |
| Proactive Crisis Broadcasts — Incident reports trigger AI-drafted WhatsApp broadcasts to waiting downstream passengers. | [v0.2]–[future] | event-catalog.md → IncidentCreated · Journey 2: Alpine Stau |
| Trigger-Based Automation — Event-driven messages like T-24h pre-departure reminders and automated review requests post-trip. | [v0.2] | domain-backoffice.md → NotificationTemplate · workflow-orchestration.md |
NOTE
The broadcast pipeline itself (IncidentCreated → WhatsApp) targets [v0.2]. STRATEGY_platform-vision.md tags the "Crisis Agent" — which AI-drafts messages autonomously — as [future]. Initial delivery requires dispatcher-authored or template-based messages with manual approval.
5. AI-Powered Backoffice
For operators drowning in manual data entry — AI tools that halve operational overhead without touching their existing booking or accounting systems.
Primary Context: Backoffice · Wedge Target: Patchwork Operators doing manual PDF transcription · Horizon: [v0.2]–[future]
| Feature | Horizon | Authoritative Source |
|---|---|---|
| "Magic Upload" Parser — An AI engine that ingests unstructured partner PDFs and instantly extracts dates, waypoints, and descriptions to auto-draft structured tours. | [v0.2] | domain-backoffice.md → TourTemplate · differentiators.md §2 · STRATEGY_platform-vision.md → Upload Agent |
| Compliance Copilot — A background engine that monitors EU 561/2006 driving and rest hours, flagging violations before dispatch. | [v0.2]–[future] | domain-operations.md → CrewDutyLog · domain-operations.md §Compliance Rules · differentiators.md §2 |
| Collaborative Trip Planning — CRDT-based multi-user concurrent editing for tour templates and group charters. | [v0.2] | ADR-032 |
| Human-AI Co-Creation — AI agents participate as synchronous actors in CRDT-based trip planning sessions, resolving intent conflicts with human dispatchers and enabling selective rollback of agent contributions (Agentic Undo). | [future] | ADR-032 · agentic-led-company-spec.md |
IMPORTANT
Compliance Copilot phased delivery: Phase 1 provides heuristic warnings based on the single-timestamp CrewDutyLog model (11h daily rest check). Phase 2 introduces the full DutyActivity entity with duration-based logging and source-agnostic compliance evaluation via a stateless ComplianceEvaluator domain service — enabling deterministic dispatch blocking. See EU-561 research §6.
6. Kalkulations- & Finance Engine
Full-cycle tour profitability — from pre-departure cost planning (Vorkalkulation) through dynamic pricing to post-departure Soll/Ist reconciliation (Nachkalkulation) and tax-compliant export.
Primary Context: Backoffice + Commerce · Wedge Target: Operators lacking margin visibility and tax automation · Horizon: [v0.2]–[future]
| Feature | Horizon | Authoritative Source |
|---|---|---|
| Cost Planning (Vorkalkulation) — Aggregates own costs and third-party procurement via Supplier/Allotment, applies FX risk buffers, and validates break-even thresholds. | [v0.2] | domain-backoffice.md → CostingSheet · kalkulations-engine.md · ADR-006 |
| Dynamic Price Generation (Preisgestaltung) — Generates a full PriceMatrix with demographic, seasonal, and early-bird variants from the cost base, applying operator-defined margin rules. | [v0.2] | domain-backoffice.md → PriceMatrix · kalkulations-engine.md |
| § 25 UStG Tax Automation — Automatically discriminates Eigenleistung (standard VAT) from Fremdleistung (margin taxation) based on Supplier linkage, producing compliant TaxLedgerEntries. | [v0.2]–[future] | domain-commerce.md → TaxLedgerEntry · ADR-012 |
| Post-Departure Reconciliation (Nachkalkulation) — Auto-creates a per-departure profitability ledger aggregating actual revenues and expenses, computing Soll/Ist deltas for cost, revenue, and margin. | [v0.2]–[future] | domain-commerce.md → FinancialLedger · ADR-002 |
| DATEV Export & Period Locking — Generates DATEV-compliant CSV exports and enforces immutable period locks to prevent post-export mutations. | [future] | domain-commerce.md → LedgerPeriodLock · Journey 6: Financial Reconciliation |
7. Zero-Integration Onboarding (Email-as-API)
The lowest-friction wedge: operators forward the emails they already send to smart Busflow addresses and get structured tours and bookings back — no UI to learn, no API to build, no behavior to change.
Primary Context: Backoffice + Commerce · Wedge Target: Patchwork Operators refusing to change tools · Horizon: [v0.2]
| Feature | Horizon | Authoritative Source |
|---|---|---|
Supplier Itinerary Ingestion (upload@) — Forward supplier PDFs or emails to upload@<operator>.busflow.app; the system auto-parses them and creates draft TourTemplates for review. | [v0.2] | Journey 10: Email-as-API Ingestion · STRATEGY_platform-vision.md §H1 · domain-backoffice.md → TourTemplate |
Passenger Request Ingestion (bookings@) — Forward scattered passenger booking requests to bookings@<operator>.busflow.app; the system extracts passenger intent and data to create draft Bookings. | [v0.2] | Journey 10: Email-as-API Ingestion · domain-commerce.md → Booking |
NOTE
Relationship to Subset 5 (AI Backoffice): Email-as-API shares the same AI parser as Subset 5's "Magic Upload," but is a distinct wedge — Magic Upload is the in-app upload tool, whereas Email-as-API requires zero UI adoption: the operator never opens Busflow. This is the sharpest counter to the Patchwork Operator's #1 objection — "We can do this for free in our inbox" → "Can your inbox read the email and generate the tour?" See differentiators.md §1.
CAUTION
Journey 10 is still a placeholder — the bookings@ ingestion narrative and conflict/review semantics need full step-by-step definition before this wedge is demo-ready.
8. Compliance & Audit-Readiness
A fear-driven wedge for operators nervous about tax audits and driver-hours fines — Busflow keeps the books and the rosters audit-safe in the background, without replacing the existing booking or accounting system.
Primary Context: Backoffice + Operations + Commerce · Wedge Target: Legacy Operators fearing audits and fines · Horizon: [v0.2]–[future]
| Feature | Horizon | Authoritative Source |
|---|---|---|
| EU 561/2006 Driver-Hours Monitoring — Background engine monitoring driving and rest hours, flagging violations before dispatch. | [v0.2]–[future] | domain-operations.md → CrewDutyLog · EU-561 research |
| § 25 UStG Margin-Tax Automation (TOMS) — Discriminates Eigenleistung from Fremdleistung based on Supplier linkage, producing compliant TaxLedgerEntries. | [v0.2]–[future] | domain-commerce.md → TaxLedgerEntry · ADR-012 |
| GoBD-Compliant Audit Trail & Period Locking — Immutable change-event audit trail plus DATEV export with immutable period locks preventing post-export mutation. | [future] | domain-commerce.md → LedgerPeriodLock · ADR-019 |
NOTE
Composes features owned by Subsets 5 and 6. This wedge introduces no new domain entities — it re-packages EU-561 monitoring (Subset 5) and § 25 UStG / DATEV / period-locking (Subset 6) as a single "stay audit-safe" sale, primarily for Legacy Operators whose stated objection is risk. Keep feature definitions in the source subsets; this section is a sales lens, not a new spec. Aligns with the Automated Compliance & Audit-Readiness value pillar in PRODUCT_identity.md.
GTM Wedge Strategy
The modular monolith's event-driven boundaries enable selling individual subsets as "wedge" products to legacy operators. The system seamlessly imports existing data while proving the platform's value before a full migration.
| Entry Point | Target Pain | Expansion Path |
|---|---|---|
| E-Commerce Engine (Subset 1) | "We have no online booking" | Operator sees conversion data → adopts Digital Fulfillment (2) → adopts Kalkulations-Engine (6) for margin control |
| Digital Fulfillment (Subset 2) | "We email PDF tickets and field constant 'where's my bus?' calls" | Passengers self-serve via portal and wallet → operator adds E-Commerce (1) for direct sales → Live ETA pulls in Operations (3) |
| Driver Hub (Subset 3) | "Our drivers hate clipboards" | Drivers adopt the app → dispatchers see real-time data → adopt Crisis Communications (4) → full platform |
| Crisis Communications (Subset 4) | "Dispatchers run day-of chaos through personal WhatsApp" | Comms wrapper proves value → 1-tap incident reporting pulls in Operations (3) → full platform |
| Magic Upload (Subset 5) | "We spend 2 hours per tour typing from PDFs" | Backoffice efficiency → operator publishes tours → needs a booking engine (1) → full platform |
| Kalkulations-Engine (Subset 6) | "We don't know our real margins until it's too late" | GF gains margin visibility → wants automated booking (1) → wants automated comms (4) → full platform |
| Email-as-API (Subset 7) | "We can do this for free in our inbox" | Forwarded emails become structured tours and bookings → operator trusts the parser → adopts in-app Backoffice (5) and booking engine (1) |
| Compliance & Audit-Readiness (Subset 8) | "We're terrified of a tax audit or an EU-561 fine" | Background compliance proves trustworthy → operator adopts Kalkulations-Engine (6) → full finance and booking platform |
See PRODUCT_migration-and-onboarding.md for the zero-downtime migration pipeline and concierge onboarding strategy that supports wedge-to-platform expansion.