ProductsProductBookingWeb appB2C

Budowa silnika rezerwacji dla rynku, którego nikt nie chciał

Operatorzy niszowych kempingów potrzebowali kalendarza, cennika i SMS. Uniwersalne platformy przerabiały wszystko inne. Więc zbudowałem to, czego faktycznie potrzebowali.

Wojciech Łuszczyński

GTM Architect & Growth Operator · Insights · 8 grudnia 2025 · 4 min czytania

W tym artykule

Polski rynek kempingów i miejsc dla kamperów miał problem: większość rezerwacji odbywa się telefonicznie albo przez listing na booking.com, który kosztuje operatora 15-18% od rezerwacji. Żadna z tych opcji nie jest dobra.

Rezerwacje telefoniczne to utracony przychód (brak zapytań późnym wieczorem, brak wyszukiwalności, brak upsella). Booking.com działa dla hoteli; dla 40-stanowiskowego kempingu ze stołem piknikowym i kompostowym toaletą to kosztowna przesada.

Więc zbudowałem pionowy silnik rezerwacji konkretnie pod tę lukę.

Ograniczenia produktowe, które ukształtowały build

Operatorzy nie są techniczni. Interfejs admina musiał działać na Samsungu Galaxy z Chrome’em w zasięgu kempingowego wifi. Bez onboardingu telefonicznego, bez helpdocsów, bez budżetu na szkolenie. UI musiał być oczywisty sam w sobie.

Goście rezerwują z telefonu. Analityka ze starej strony pierwszego operatora pokazywała 82% mobile. Flow rezerwacji musiał być obsługiwalny jednym kciukiem: wybierz daty, wybierz stanowisko, zapłać, gotowe. Bez konieczności zakładania konta.

Cenniki są nieregularne. Kempingi mają ceny weekendowe, ceny w szczycie sezonu, rabaty early-bird, ceny last-minute i cenniki per stanowisko lub per osoba w zależności od operatora. Każdy uniwersalny silnik rezerwacji albo to upraszcza, albo przerabia. Zbudowałem elastyczną macierz cenową, która obsługuje 80% przypadków bez potrzeby doktoratu do konfiguracji.

Decyzje techniczne

Postgres z prostym modelem dostępności: inwentarz stanowisk, blokady dat, rezerwacje. Główne sprawdzenie dostępności to proste zapytanie o nakładające się przedziały: celowo proste, bo musi być szybkie i poprawne, nie sprytne.

Stripe, nie Przelewy24 ani PayU. Developer experience jest lepszy, a międzynarodowa obsługa kart ma znaczenie dla ruchu turystycznego. Polska akceptacja kart przez Stripe jest kompletna.

SMS przez Twilio. W testach potwierdzenie e-mailem miało 34% open rate w ciągu 10 minut. SMS miał 94% open rate w ciągu 2 minut. Przy potwierdzeniu rezerwacji z kodem do bramy i numerem stanowiska ta różnica ma znaczenie operacyjne.

Prosty interfejs CRUD z wizualnym kalendarzem dostępności. Najczęściej używane widoki: dzisiejsze przyjazdy, kalendarz tygodniowy i edytor cennika. Wszystko inne jest drugorzędne.

Co bym zmienił

Adopcja płatności online była niższa niż zakładałem w pierwszej kohorcie operatorów. Polscy goście kempingowi są przyzwyczajeni do płacenia na miejscu. Konwersja na pełną przedpłatę była akceptowalna; konwersja na “zarezerwuj teraz, zapłać na miejscu” była znacznie wyższa, ale generowała problemy z anulacjami.

Lepszy model: mały depozyt online, reszta na miejscu: to byłaby właściwa decyzja produktowa od pierwszego dnia. Dodałem to w trzecim miesiącu.

Lekcja z niszowego rynku

Ewolucja modelu płatności

Pełna przedpłata

Wyższy sygnał zaufania, niższa konwersja. Goście polskich kempingów są przyzwyczajeni do płacenia na miejscu. Obsługa anulowań była czysta, ale wolumen słaby.

Zaliczka + reszta przy przyjeździe

Mała zaliczka online, reszta na miejscu. Wyższa konwersja, lekkie ryzyko anulowań, ale operacyjnie lepiej dla obu stron. Powinienem był wdrożyć to od pierwszego dnia.