Mockup 18: Siatka dostępności taryfowej (macierz analityczna)

Uwaga o dostępności danych: Polskie API przewoźników (RegioJet, Koleo, Leo Express) nie udostępniają kubełków taryfowych w formacie GDS — to referencja branżowa. Litery kubełków (J/C/D/I/W/E/Y/B/M/H/K/L/V/S/N/O) to konwencja lotnicza stosowana tu poglądowo. Liczby oznaczają minimum dostępnych miejsc w kubełku (konwencja GDS).

Uzasadnienie projektu

Ten mockup implementuje paradygmat „Mikroskop vs. Teleskop" zidentyfikowany w thoughts/shared/research/010_expertflyer_awardfares_ux.md.

Tryb weryfikacji (ExpertFlyer): Gęsta siatka (do 144 komórek na zapytanie) mapująca każdy dostępny kubełek taryfowy. Liczby oznaczają minimum miejsc (np. „7" = „co najmniej 7"). Służy do precyzyjnego audytu zachowań zarządzania przychodami.
Tryb odkrywania (AwardFares): Heatmapa czasowa pokazująca dostępność dla 14 klas/przewoźników w horyzoncie 30 dni. Intensywność koloru mapuje się na „zdrowie" ceny/dostępności (zielony = tania/szeroka, czerwony = droga/ograniczona).
Gęstość analityczna: Siatka weryfikacji używa 16 kolumn kubełków, pozwalając analitykom zobaczyć pełną głębokość drabiny taryfowej (od Business J po Economy Discount O) jednym spojrzeniem.
Filozofia alertów: Każda komórka jest klikalna, symulując workflow ExpertFlyer, gdzie siatka jest wejściem do trwałego alertu monitoringu.

Źródło: ExpertFlyer + AwardFares — analiza UX dla zaawansowanych analityków (cel 4)

Mockup 18 — Siatka dostępności i kubełki taryfowe SHOWCASE

Co to pokazuje

Dwa tryby: macierz GDS-style (weryfikacja kubełków per pociąg) i heatmapa czasowa (odkrywanie dostępności w horyzoncie 14 dni × 14 klas/przewoźników). Wzorzec z ExpertFlyer i AwardFares.

Status danych

Dane losowe (JS). Polskie API nie udostępniają kubełków taryfowych — to referencja branżowa. RegioJet zwraca priceFrom/priceTo, Koleo zwraca klasy biletowe, LEO zwraca klasy siedzeń. Prawdziwe kubełki GDS wymagałyby dostępu do Amadeus/Sabre.

Nakład pracy

Wysoki dla trybu weryfikacji (brak źródła danych kubełkowych). Umiarkowany dla heatmapy odkrywania — dane z daily_fetch.py dają wystarczający horyzont cen per klasa i przewoźnik.

Rezonans z zarządem

Średni — format ExpertFlyer jest znany specjalistom Revenue Management z lotnictwa, ale może być niezrozumiały dla zarządów bez doświadczenia RM. Heatmapa odkrywania jest bardziej przystępna.

Moja rekomendacja

Zachować tryb odkrywania (heatmapa) jako element głównego dashboardu. Tryb weryfikacji — jako widok ekspercki ukryty za zakładką. Nie ukrywać ograniczenia danych kubełkowych.

Kolejne kroki

Zbudować heatmapę odkrywania z realnych danych DB (ceny per korytarz, data, klasa). Dodać filtr przewoźnika. Jawnie oznaczyć kolumny jako „szacowane klasy cenowe", nie kubełki GDS.