Sales composition (current period share %)

Period-over-period comparison — Sales (Total RON)

Hour Statistics — Fleet availability vs demand

Top 25 Clients

Client LTV — retail (Public account)

Earnings (total price − driver price) generated by each registered client in the first 30 / 90 / 180 days after sign-up. Matched by phone (primary) + email (fallback). Privacy: only hash IDs shown.
Note: showing only status = 'Current' registrations — the 'New' status was dominated by spam batches in Jan/May/Jul 2025 (≈70k signups, <1% activation). Excluded by default.

OTP Airport — Pickup & Destination by Service

Job Analogue — Pivot by Service

Source files: Income Structure and Job Analogue exports for the two periods shown above.

Operational KPIs

Current period vs previous period. KPI numbering matches the spec sheet. #3 (Active cars %) needs a registered-fleet roster we don't have yet — replaced with "Unique active vehicles". #6 shows all cancelled rides for now — ~92% of cancellations have no documented reason, so a true "lack of supply" split isn't available yet (waiting on better cancel-reason data). #10 uses the spec formula Σ(Client Price − Driver Price − bonuses − adjustments) with bonuses and adjustments set to 0.

Definitions: Login h / car / day = total login hours ÷ unique vehicles with at least one DONE job ÷ 7 days. Fleet utilisation = busy ÷ online (already shown on Overview). Time to pickup uses the Response Time column on ASAP DONE jobs only. Fulfilment rate = DONE ÷ (DONE + CANCELLED).

Capacity simulation — BlackCab + Select

What-if model on top of the current period. Adjust the three levers (extra cars, hours per vehicle, rides per hour) to see how rides, sales and earnings would change if you scaled supply or productivity. All projections hold today's avg price per ride constant.

Vehicle count uses the same proxy as the Fleets tab — distinct plates from job_analogue with service ∈ {BlackCab, BlackCab 7, Select, Elite, ChildSeat, KidsCab, iDrive Your Car, MailCab, Shuttle Bus}.

Allocation logic. Every added car is discounted by the fleet overlap indicator. Two equivalent framings: each added car contributes (h/day × days × overlap) net hours, or of N added cars, only N × overlap are net effective (the rest is offset by baseline drivers leaving when newcomers join). The Vehicles row shows the post-overlap net fleet size; the hours/vehicle blended across baseline (their actual h) and net effective new cars (full h/day × days each). Total capacity = total hours × rides/hour. Baseline rides are preserved as-is; only the extra rides get split:

• Default (no cancel change): extra rides split by baseline mix — if 60% of current rides are ASAP, 60% of new rides go to ASAP, 40% to Prebook.
• Lower target ASAP cancel rate: shifts the mix toward ASAP. Rescued cancellations = baseline_ASAP_total × (base_rate − target_rate). So e.g. 100 extra rides with a small cancel reduction might split 65 ASAP / 35 Prebook instead of 60/40.
• Rescue is capped at the non-ASAP portion of extra capacity — we never claw rides back from baseline Prebook to feed ASAP.

Without extra capacity (all 3 capacity sliders at baseline), lowering the cancel rate has no effect — the rescue needs room to happen.

The New Fleet column shows what the gain over baseline would be at 100% fleet overlap indicator — i.e. the theoretical ceiling, treating every added car as a brand-new addition with zero replacement of baseline drivers. Compare it to Δ abs (the realistic gain): the difference between them is the cost of overlap for this scenario.

On-way times and Prebook cancellation rate are held constant — the current levers don't model them.