Zanim zbudujemy pełny system, proponujemy mniejszy, w pełni działający moduł na tej samej technologii i infrastrukturze co projekt docelowy. PoC pokrywa najtrudniejszy technicznie obszar — integrację z API armatora i pełen cykl rezerwacji z gwarancją, że żadna rezerwacja nie ginie. To nie makieta, lecz produkcyjny fragment platformy Matfill.
PoC (ang. proof of concept — dowód słuszności koncepcji, czyli mniejszy, ale realnie działający wycinek systemu) stanowi fragment docelowej platformy zbudowany na identycznej technologii i infrastrukturze co projekt pełny. Nie jest makietą ani prototypem wizualnym — to działające narzędzie pokrywające jeden, najbardziej wymagający technicznie obszar: integrację z API armatora i pełen cykl rezerwacji. Względem koncepcji wielostronnej platformy zmienia się perspektywa: PoC jest wewnętrznym narzędziem dla pracowników. Pomijamy warstwę kliencką, a całość nakładu kierujemy na rdzeń wartości i największe ryzyko techniczne — silnik rezerwacji z mechanizmem fallback.
Pełna integracja z konkretnym API armatora (Scandlines) i przeprowadzenie rezerwacji od wyboru klienta po potwierdzenie.
Architektura kolejkowa, która gwarantuje dostarczenie rezerwacji nawet przy awarii API armatora.
Zaprojektowany fallback mailowy dla armatorów bez dostępu do API — rezerwacja realizowana inną drogą.
Dostarczenie na OVHcloud, środowiska prod/test, CI/CD — spójne z projektem docelowym.
Pięć obszarów, które razem tworzą kompletną, działającą ścieżkę rezerwacji dla pracownika — od wyboru klienta po podgląd statystyk skuteczności.
Lista klientów z danymi i preferencjami przewozowymi. Rezerwacja automatycznie zaciąga dane — pracownik nie przepisuje ich ręcznie, lecz wybiera klienta. Zakres: dane firmy, pojazdy, kierowcy, typy i wymiary ładunków, preferencje (trasy, armatorzy, okna czasowe), historia rezerwacji.
Proces maksymalnie uproszczony: wybór klienta → dane zaciągają się automatycznie → punkt wyjścia, docelowy i czas → system prezentuje konkretne dostępne kursy → finalizacja → przypisanie rezerwacji do klienta.
Lista zrealizowanych rezerwacji z akcjami, podglądem statusu i szczegółów. Odzwierciedla pełen cykl życia rezerwacji.
Jeśli rezerwacja przez API nie powiedzie się po kilku próbach, system nie porzuca jej, lecz uruchamia rezerwację mailową do armatorów ją akceptujących. Realizuje zasadę „żadna rezerwacja nie ginie" i demonstruje integrację armatorów bez API.
Statystyki i podsumowania: liczba rezerwacji, skuteczność ścieżki API względem fallbacku, podział wg tras i klientów, alerty o rezerwacjach wymagających interwencji człowieka.
Po wyborze klienta i podaniu trasy system pokazuje dostępne opcje przepraw. Pracownik wybiera jedną — przygotowanie i wysłanie rezerwacji dzieje się dalej automatycznie. Dokładny zakres prezentowanych danych zależy od możliwości integracji z systemem armatora i zostanie ustalony na etapie wdrożenia.
Wartość dowodowa PoC opiera się na tożsamości infrastruktury z planowaną dla pełnej platformy. To ten sam szkielet, który opisano dla całego Matfila — PoC wypełnia jego najważniejszy segment realnym kodem.
Logika rezerwacji, orkiestracja, wewnętrzne API.
Panel pracownika oraz panel administratora.
Dane klientów i rezerwacji; JSONB pod warstwę adapterową.
Silnik niezawodności: retry, timeouty, eskalacja, cache.
Integracja wg zasady „dostęp osobno, adapter osobno".
Środowiska prod + test, automatyczne wdrożenia, dane w UE.
Admin widzi najważniejsze dane operacyjne i finansowe w jednym miejscu: ile rezerwacji obsłużono, jaką mają łączną wartość, ilu klientów korzysta z systemu i które trasy są najczęstsze. W docelowej platformie ta sama logika raportowania obejmie całą firmę.
Rezerwacja nie jest wykonywana „na żywo" z założeniem, że API akurat odpowie. Trafia do kolejki, a osobny worker realizuje ją w sposób kontrolowany. Ten sam mechanizm stanowi fundament, na którym w projekcie docelowym osadzone zostają pilnowanie terminów slotów i eliminacja kar no-show.
Każda rezerwacja trafia najpierw do kolejki, nie bezpośrednio do API.
Chwilowy brak odpowiedzi API rozwiązuje się automatycznie, bez udziału pracownika.
Po wyczerpaniu prób rezerwacja nie znika — system przechodzi dalej.
Uruchamia fallback mailowy lub trafia do pracownika z alertem.
Wiele równoczesnych rezerwacji w sezonie nie obciąża systemu ponad miarę.
Pracownik widzi, co się dzieje z każdą rezerwacją: która przeszła przez API, która jest ponawiana, która poszła ścieżką mailową, a która wymaga jego decyzji. Nic nie dzieje się po cichu.
Dla przejrzystości wprost wskazujemy elementy pełnej platformy, których wycinek świadomie nie obejmuje. Zakres wyłączeń jest jednocześnie argumentem pokazującym skalę projektu docelowego względem PoC.
Panel i logowanie dla klientów końcowych (samoobsługa) pozostają poza zakresem PoC.
Faktury, salda i rozliczenia nie wchodzą w zakres tego etapu.
Agent AI oraz kanały WhatsApp i SMS są częścią platformy docelowej, nie PoC.
Integracja ograniczona do Scandlines przez API oraz ścieżki mailowej — bez pozostałych armatorów.