Busflow Docs

Internal documentation portal

Busflow Docs

Appearance

Core User Journeys ​

A: Dispatcher (AI-Assisted Tour Creation) ​

Upload PDF → AI extracts structured data → Review side-by-side → Assign bus + driver → Publish → Auto-generates booking link.

D: Dispatcher (AI Proactive Optimization) ​

AI analyzes commerce data → Suggests merging underperforming tours or creating new ones based on high request volume → Dispatcher reviews suggestion → 1-click apply and publish.

B: Passenger (Booking & Wallet) ​

Discovery → Select dates/pax → Visual seat selection → Apple Pay/Klarna checkout → Add to Wallet → WhatsApp confirmation.

C: Driver (Operations) ​

Open PWA → See daily assignment → QR-scan passengers at boarding → Tap "Missing Passengers" → Send WhatsApp warning.

Cross-Pillar User Stories ​

These scenarios highlight how data flows seamlessly across the Backoffice, Commerce, and Operations pillars, demonstrating the system's ability to eliminate manual bottlenecks.

Journey 1: AI-Assisted End-to-End (From Unstructured Data to Boarding) ​

Scenario: A tour operator receives a PDF itinerary from a hotel partner, turns it into a bookable tour, sells a ticket, and successfully boards the passenger. Actors: Back-Office Operator, Passenger (B2C), Bus Driver.

  1. [Backoffice] The Ingestion: The Back-Office Operator drags a partner hotel PDF into the AI Document Parser. The AI extracts dates, waypoints, and descriptions, automatically drafting a 4-day Tyrol tour. The operator links a 49-seater bus chassis and sets dynamic margin rules based on current diesel costs.
  2. [Backoffice] Tax Automation ("Leistungsmäntel"): The system identifies the hotel as a Fremdleistung (third-party procurement) and automatically wraps it in the § 25 UStG margin tax strategy via the CostComponent.service_type discriminator. The dispatcher never needs accounting knowledge — the system applies the tax wrapper transparently.
  3. [Commerce] The Conversion: A Passenger finds the tour via a dynamically generated SEO landing page. Within 60 seconds, they select the Zustiegsstelle (boarding point), pick Seat 14 on the visual chassis map, and pay the 20% Anzahlung (deposit) via Apple Pay. (NFR: Complete the end-to-end checkout including seat hold and payment initialization within 60 seconds).
  4. [Commerce → Backoffice] Digital Fulfillment & Sync: Upon payment, the Passenger instantly receives a dynamic Apple Wallet pass. Simultaneously, Busflow's CRM generates a Unified Passenger Profile, and the system automatically updates the manifest without human intervention.
  5. [Backoffice → Operations] Dispatch & Execution: The Dispatcher opens the Intelligent Dispatch Board Gantt timeline and drags Driver Klaus onto the Tyrol route. The Compliance Copilot checks Klaus's CrewDutyLog and crew_qualifications in the background — verifying rest time (EG 561/2006), Module 95 validity, and any border visa restrictions. A contextual "Dispohinweis" badge confirms Klaus has clearance. The system green-lights the dispatch.
  6. [Operations] The Boarding: At 6:00 AM in an Alpine valley with zero cell service, Driver Klaus opens the Driver Hub app. He uses the offline 1-Click Boarding scanner to scan the Passenger's Apple Wallet pass. Once the bus returns to cellular coverage, the boarding status syncs back to the Backoffice.

Journey 5: AI Proactive Tour Optimization ​

Scenario: The system autonomously identifies a way to increase capacity utilization by analyzing existing bookings and search requests, prompting the dispatcher to merge two tours. Actors: AI Agent, Dispatcher.

  1. [Backoffice] The Insight: The AI Copilot agent constantly analyzes commerce and search data in the background. It identifies that two separate "Bavarian Castles" tours scheduled for the same weekend are both only 30% filled.
  2. [Backoffice] The Suggestion: The AI proactively alerts the Dispatcher with a proposed action: "Merge Tours: Bavarian Castles 1 & 2. Both tours are under 35% capacity. Merging them onto a single 49-seater will increase net margin by 42% and free up one vehicle and driver for an additional charter request."
  3. [Backoffice] The Approval: The Dispatcher reviews the AI-generated impact analysis and clicks "Approve Merge."
  4. [Commerce & Backoffice] The Execution: The system automatically combines the passenger manifests, recalculates the routing for the Zustiegsstellen to accommodate both groups efficiently, updates the driver assignment, and drafts an automated WhatsApp notification for affected passengers about minor pickup time adjustments.

Journey 2: The "Alpine Stau" Incident Management ​

Scenario: A bus hits unexpected heavy traffic, threatening to leave down-route passengers waiting at their boarding points without information. Actors: Bus Driver, Dispatcher, Waiting Passengers.

  1. [Operations] The Incident: Driver Klaus encounters a severe traffic jam (Stau) on the Autobahn. He uses the 1-Tap Incident Reporting in the Driver Hub to drop a GPS pin and alert the back office. The live Telematics engine instantly recalculates the ETA for the remaining boarding stops.
  2. [Operations → Backoffice] The Alert: The Dispatcher's Dispatch Board flashes with a high-priority WebSocket overlay on the affected ServiceLeg block. The delayed ETA propagates from TelemetryPoint data. The Dispatcher opens the Omnichannel Inbox.
  3. [Backoffice → Commerce] 1-Click Broadcast: The AI Crisis Agent has already pre-drafted a WhatsApp/SMS message targeting all passengers at upcoming Zustiegsstellen. The Dispatcher reviews, edits if needed, and clicks "Approve" — sending the bulk update instantly.
  4. [Commerce & Operations] Dynamic Update: The passengers' Apple/Google Wallet passes dynamically update via Apple Push Notification service (APNs) and Google Wallet API. Passengers click the Consumer ETA Tracking link in their pass to watch Klaus's bus approach on a live map, preventing a flood of angry calls to the back office.

Journey 3: Onboard Revenue to Automated Accounting ​

Scenario: Managing mid-trip upsells, driver expenses, and end-of-month financial reconciliation without manual data entry. Actors: Passenger, Bus Driver, Accounting Team.

  1. [Operations] Onboard Sales & Expenses: During the trip, a Passenger in Seat 12 decides to buy a coffee and book a last-minute day excursion. Driver Klaus taps these items into the Bordverkauf (POS) interface. Later that day, Klaus fuels up the bus and uses the app's AI Receipt Capture to snap a photo of the toll/diesel receipt.
  2. [Operations → Backoffice] The Sync: As soon as the bus has signal, the POS data and OCR-extracted receipt data sync to the Backoffice.
  3. [Backoffice → Commerce] Passenger Ledger: The system adds the day excursion upsell to the Passenger's Unified Profile. An automated Trigger-Based Message goes to the passenger with a secure "Magic Link," allowing them to pay the outstanding balance for the excursion via Klarna (BNPL) from their phone.
  4. [Backoffice] Financial Reconciliation: In the Executive Control (GF View) back office, the Accounting Team does zero manual entry. The system automatically reconciles the cash box against Klaus's POS sales, allocates the diesel expense to the tour's profit margin, and maps everything to a DATEV-compliant CSV export for the tax advisor.

Journey 4: B2B API Booking & Automated Fleet Re-routing ​

Scenario: A travel agency books a large group via the B2B portal, triggering a capacity issue that requires a vehicle swap and dynamic route adjustment. Actors: Travel Agent (B2B), Dispatcher, Bus Driver.

  1. [Commerce] The B2B Transaction: A local travel agency uses the B2B White-Label API to book a group of 10 people onto a nearly full tour (🟡 color-coded as B2B Agency source), working on commission. The system auto-validates the agency's VAT ID against the EU VIES database for reverse-charge compliance.
  2. [Commerce → Backoffice] Capacity Conflict: The booking pushes the tour's passenger count to 52, but a 49-seater is currently assigned. The Dispatch Board capacity badge flashes 🔴 "52/49" on the affected ServiceLeg block.
  3. [Backoffice] The Swap: The Dispatcher opens the Passenger Reassignment View split-screen. She drags the 54-seater onto the leg and the system automatically remaps all SeatReservation entries to equivalent positions on the new vehicle's seat_map_layout, preserving all B2C and B2B booking references.
  4. [Backoffice → Operations] Commercial Re-routing: Because the 54-seater is a heavier, taller 3-axle coach, the change instantly pushes a new profile to the Driver Hub. The Commercial Routing engine automatically recalculates the turn-by-turn navigation for the morning pickup sequence, routing the driver around a low bridge that the previous 49-seater could have cleared.

Journey 6: Automated Financial Reconciliation & Bank Import ​

Scenario: End-of-month accounting reconciliation where the system auto-matches bank transactions to bookings, replacing manual bookkeeping. Actors: Accounting Team / Dispatcher.

  1. [Backoffice] Bank Import: The Accounting Team uploads an MT940/CAMT bank statement file into the Financial Reconciliation module, establishing a reconciliation_upload context.
  2. [Backoffice] Auto-Matching: The system parses each transaction and matches incoming payments to Booking or Invoice entities by reference number (Verwendungszweck). It marks matched transactions as reconciled; unmatched items surface in a review queue.
  3. [Backoffice] Margin Analysis (Soll/Ist): For each reconciled departure, the system compares CostingSheet projections against FinancialLedger actuals — surfacing deltas for diesel, driver costs, and procurement. The Accounting Team sees that the Tyrol tour exceeded its diesel budget by 12% due to a detour.
  4. [Backoffice] DATEV Export: The system exports reconciled data as a DATEV-compliant CSV, ready for the tax advisor. Zero manual data entry.

Journey 7: Customer Support & Partial Refund (Commerce Manager) ​

Scenario: A passenger calls customer service to cancel a booked optional excursion due to illness, but they are still attending the master tour. Actors: Passenger, Support Staff (Dispatcher).

  1. [Backoffice] Context Retrieval: Support staff searches the passenger's name in the workspace app. The App Shell routes this view to the Commerce domain's booking-manager feature, retrieving the unified profile and checkout history.
  2. [Backoffice] The Action: The staff selects the specific 'Zugspitze Excursion' sub-item and clicks 'Issue Partial Refund'.
  3. [Backoffice → Commerce] The Execution: The booking-manager frontend feature fires an intent directly to the Commerce backend. The backend processes the partial refund via the payment provider (Mollie).
  4. [Commerce & Notifications] Fulfillment: The passenger receives an automated WhatsApp confirmation, and their remote Apple Wallet ticket instantly removes the excursion pass. The workspace UI immediately updates the balance.

Journey 8: Marketing Promotion & Yield Management ​

Scenario: A "Spring Break" tour is under-booked 3 weeks before departure, prompting an aggressive push. Actors: Marketing Staff, Passenger.

  1. [Backoffice] The Promotion: Marketing staff opens the promo-manager feature inside the workspace App Shell. They generate a 15% discount code "SPRING15" restricted to bookings made within the next 48 hours for that specific Trip ID.
  2. [Commerce] The Conversion Surge: The discount goes live on the public booking-widget. Passengers book using the code, driving capacity utilization from 40% to 85%.
  3. [Backoffice] Yield Rebalance: The yield-manager feature (combined with the costing engine) detects the capacity threshold hit. It automatically disables the promo code and prompts the staff to approve a base price increase for the remaining 15% seats, pushing updates seamlessly to the live endpoints.

Pillar-Specific User Journeys ​

PillarAppJourneys
Backofficeapps/workspace/user-journeys.md
Commerceapps/booking-widget/user-journeys.md
Operationsapps/driver/user-journeys.md

Internal documentation — Busflow

© 2026 MLP Software Development