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.
GTM Architect & Growth Operator · Insights · 8 grudnia 2025
TL;DR · Najważniejsze wnioski
- Niszowe rynki rezerwacyjne są niedoinwestowane, bo uniwersalne platformy przerabiają nie te rzeczy
- Kluczowy insight: operatorzy kempingów potrzebują kalendarza, cennika i potwierdzenia SMS. Reszta nie ma znaczenia na start
- Mobile-first, bo 80%+ wyszukiwań kempingów dzieje się na telefonie, często przy samej bramie
- Model przychodowy to prowizja od transakcji, nie subskrypcja SaaS: wyrównuje motywacje z operatorami
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
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
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.
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.
Related: GTM Tools: Build vs Buy Decision Framework for Operators · How to Build Micro-SaaS with AI Tools: product lessons from 10+ shipped apps
