Lendly.pl — platforma P2P do wynajmu samochodów

Lendly.pl to jeden z tych projektów, w których poczułem, że marketplace to coś więcej niż tylko lista ogłoszeń z formularzem kontaktowym. To była platforma P2P do wynajmu samochodów — taki rodzimy, polski pomysł w stylu „Airbnb dla aut”. Z jednej strony użytkownicy prywatni, którzy chcą dorobić na swoim aucie stojącym pod blokiem, z drugiej klasyczne wypożyczalnie samochodów szukające nowego kanału sprzedaży. Moim zadaniem było połączyć te dwa światy w jedną spójną aplikację webową na stosie .NET.

Problem — marketplace P2P plus gracze instytucjonalni

Klasyczne porównywarki wynajmu aut agregują oferty z kilku dużych wypożyczalni. Lendly miał pójść o krok dalej i dopuścić do platformy również osoby prywatne. To brzmi prosto, dopóki nie zacznie się projektować modelu danych i procesu rezerwacji.

Dwa typy właścicieli to dwa różne światy. Osoba prywatna ma jedno, góra dwa auta i prosty kalendarz. Wypożyczalnia ma flotę, własny system rezerwacji poza platformą i potrzebuje narzędzia, które nie będzie jej przeszkadzać, tylko realnie pomagać sprzedawać. To od początku wymuszało kilka decyzji architektonicznych — jeden model oferty dla obu grup, ale panel administracyjny przygotowany pod tego bardziej wymagającego użytkownika.

Marketplace zaczyna działać dopiero wtedy, kiedy zarówno gość z jednym autem, jak i wypożyczalnia z flotą czują, że aplikacja została zaprojektowana pod nich.

Drugim problemem było zaufanie i UX strony publicznej. Użytkownik wchodzący z Google’a musi w pięć sekund zrozumieć, o co chodzi, wpisać miasto, zobaczyć sensowne wyniki i móc zarezerwować auto bez zbędnych kroków.

Wyszukiwarka z dostępnością w czasie

Kluczowy element Lendly — i moim zdaniem najciekawszy technicznie — to wyszukiwarka, która od razu uwzględnia dostępność w danym terminie. Nie chciałem platformy, na której klikasz ofertę, wypełniasz formularz, a potem dostajesz maila „niestety to auto jest już zajęte”. To anty-UX.

Wyszukiwarka działa następująco — użytkownik wpisuje lokalizację, na przykład Radzisz, i wybiera przedział dat. Silnik zwraca tylko te auta, które w tym oknie czasowym nie mają kolidującej rezerwacji. Do tego dochodzi wielopoziomowa filtracja:

kategoria pojazdu (osobowy, SUV, luksusowy, sportowy),
przedział cenowy za dobę,
kaucja,
limit kilometrów,
rok produkcji, skrzynia biegów, rodzaj paliwa.

Każda oferta ma pełną kartę produktu — galerię zdjęć, specyfikację techniczną, cennik, listę wyposażenia i mapę z lokalizacją odbioru. Dodałem też kalkulator, który na bieżąco, podczas wybierania dat, liczy całkowity koszt wynajmu. Cena za dobę razy liczba dni, plus pakiety opcjonalne — wszystko widoczne od razu, bez przechodzenia do koszyka. Przy dwóch dobach po 179 złotych użytkownik od razu widzi 358 złotych — żadnych niespodzianek na końcu lejka.

Rezerwacje, kalendarz, płatności

Rezerwacja zewnętrzna, czyli ta inicjowana przez użytkownika z poziomu oferty publicznej, to tylko jedna ścieżka. W panelu wypożyczalni obsługiwane są też rezerwacje wewnętrzne — takie, które klient załatwił telefonicznie, mailem albo przychodząc do biura. Oba typy lądują w jednym kalendarzu, ale w różnych kolorach — zielony dla zewnętrznych, fioletowy dla wewnętrznych. Dzięki temu wypożyczalnia widzi jeden spójny obraz dostępności floty, niezależnie od kanału sprzedaży.

W panelu administracyjnym każda wypożyczalnia widzi swój własny pulpit z najważniejszymi metrykami — liczba wyświetleń ogłoszeń, liczba rezerwacji, przychód. Szczegóły rezerwacji pokazują wartość zamówienia, naliczoną prowizję platformy oraz pełne dane klienta.

Osobny wątek to warunki wynajmu. Każda wypożyczalnia może zdefiniować globalne warunki obowiązujące w całej jej flocie — na przykład wymagany minimalny wiek kierowcy, kaucja, limit kilometrów. Ale może też nadpisać je na poziomie pojedynczego ogłoszenia. Jeśli Audi S3 ma być dostępne tylko dla kierowców 25+, to warunek z ogłoszenia wygrywa z warunkiem wypożyczalni. To wymagało przemyślanego modelu dziedziczenia konfiguracji.

Zaprojektowałem też prosty status lifecycle ogłoszenia — aktywne, nieaktywne, oczekujące na akceptację zespołu, niedokończone. Ten ostatni status pojawia się, kiedy użytkownik doda ofertę bez zdjęć — wtedy ląduje w zakładce „do uzupełnienia” i nie pokazuje się publicznie.

Stos i architektura

Lendly zbudowałem na stosie .NET — od backendu, przez warstwę dostępu do danych, po panel administracyjny. Aplikacja webowa działa jako jeden spójny system — publiczna wyszukiwarka dla końcowego użytkownika plus panel dla wypożyczalni i osób prywatnych.

Dodawanie oferty to trzyetapowy kreator, który dzieli formularz na strawne kawałki:

Dane techniczne auta — kategoria, rocznik, liczba miejsc, moc, pojemność, skrzynia biegów, paliwo, adres odbioru.
Cena i wymagania — obowiązkowa stawka wynajmu, opcjonalny opis, ograniczenie wieku kierowcy, wyposażenie.
Galeria zdjęć — można dodać od razu albo uzupełnić później.

Kreator zapisuje stan po każdym kroku, dzięki czemu użytkownik nie traci danych, nawet jeśli zamknie kartę. To była świadoma decyzja UX — w aplikacjach z długimi formularzami nic tak nie frustruje, jak utrata danych przy pierwszym błędzie walidacji.

W planach zostawiłem też miejsce na automatyczne fakturowanie zleceń. Obecnie zlecenia dla wypożyczalni są widoczne w panelu i gotowe do rozliczenia — kolejnym krokiem byłoby podpięcie zewnętrznego systemu fakturowego i generowanie dokumentów jednym kliknięciem.

Czego się nauczyłem

Lendly nauczyło mnie, że w marketplace’ach diabeł tkwi w kalendarzu. Wyszukiwarka, która nie filtruje po dostępności, jest tak naprawdę tylko katalogiem — a katalog to nie jest produkt, za który klient zapłaci prowizję. Dopiero połączenie oferty z realną dostępnością w czasie zamienia stronę w działający mechanizm rezerwacyjny.

Marketplace bez wyszukiwarki uwzględniającej dostępność to katalog. Marketplace z nią — to produkt.

Druga lekcja to projektowanie pod dwóch bardzo różnych użytkowników jednocześnie. Osoba prywatna chce dodać auto w dwie minuty, wypożyczalnia chce pełnoprawny panel zarządzania flotą z kalendarzem, statystykami i rezerwacjami wewnętrznymi. Pokusa, żeby zrobić „coś pośrodku”, kończy się zwykle tym, że żadna z grup nie jest zadowolona. W Lendly postawiłem na jeden formularz dodawania oferty, ale rozbudowany panel dla tych, którzy go realnie potrzebują — i ta asymetria okazała się słuszna.

Trzeci wniosek — kalkulator ceny na żywo i trzyetapowy kreator dodawania oferty to drobne decyzje UX, które nie kosztują dużo w implementacji, a radykalnie zmieniają odbiór aplikacji. Użytkownik widzi koszt zanim kliknie „Zarezerwuj”, a dodanie oferty przestaje być przerażającą ścianą pól.

Projekt można zobaczyć pod adresem lendly.pl.