Kiedy zrozumiałem, kto jest moim klientem: ekonomia WolnyParking

Koszty pojawiły się natychmiast

Zanim aplikacja miała nawet pięciu realnych użytkowników, już generowała rachunki. Serwer już wcześniej miałem. Działało na nim kilka moich wcześniejszych projektów, więc za niego i tak płaciłem. Ale dalej lista zaczęła narastać: domena, certyfikaty, dodatkowe usługi bezpieczeństwa, serwis SMS, licencje na oprogramowanie, usługi AI potrzebne do asystenta, profesjonalny polski głos do syntezy odpowiedzi głosowych. Niepoliczony został koszt własnego czasu, bo praktycznie każdy weekend i każda wolna chwila wieczorem przez wiele miesięcy szły w projekt. Niedawno doszły jeszcze koszty SEO i GEO oraz migracja na profesjonalną chmurę, bo serwer, na którym startowałem, przestał być adekwatny do tego, co aplikacja musiała robić.

Na początku można było sobie wmawiać, że to hobby i że każdy weekend dzielony między aplikację a kodowanie jest jakąś formą rekreacji. Ale rachunki za SMS-y, certyfikaty, domeny i usługi zewnętrzne przychodziły co miesiąc i były jak najbardziej realne. Dość szybko zrozumiałem, że jeśli nie ruszę z tym poważnie, projekt mnie przerośnie. Albo zostanie amatorskim eksperymentem, albo stracę do niego zapał, albo po prostu przestanie działać, bo nie będzie komu płacić rachunków.

Pierwsza myśl: niech zapłacą mieszkańcy

Oczywistą pierwszą myślą były mikro-abonamenty. Jeden, dwa złote miesięcznie od mieszkańca. Liczyłem, że przy kilkuset aktywnych użytkownikach to w zupełności pokryje bieżące koszty i jeszcze coś zostanie na rozwój.

Pomysł upadł w kilka dni.

Kłócił się z podstawowym założeniem aplikacji, że dla mieszkańców jest i będzie bezpłatna. Każda inna zasada wymagałaby zbudowania drugiej, płatnej ścieżki, przekonywania użytkowników do wyjmowania portfela, obsługiwania reklamacji za dwa złote, a przede wszystkim psuła sąsiedzki ton, na którym zbudowałem cały projekt. Nie chciałem aplikacji, w której jednym z pytań na ekranie jest „chcesz zapłacić, żeby kontynuować”. To zmieniłoby wszystko, co do tej pory napisałem o wizji przełamywania anonimowości i o tym, że aplikacja ma obniżać koszt drobnej interakcji sąsiedzkiej. Płatna ścieżka ten koszt podnosi, nie obniża.

Odrzuciłem ten pomysł i zacząłem myśleć inaczej.

Kto może zapłacić naprawdę

Skoro mieszkaniec nie zapłaci, a koszty muszą się z czegoś pokrywać, to zapłaci ten, dla kogo aplikacja ma wartość wystarczająco dużą, żeby przełożyć ją na fakturę. Kogoś takiego miałem dokładnie jednego: zarządcę osiedla albo wspólnotę mieszkaniową. Ale żeby zarządca faktycznie chciał zapłacić, musiałem mu dać coś, co rozwiązuje jego realne problemy, nie moje, nie mieszkańców, tylko jego.

To było nowe zadanie. Do tej pory projektowałem aplikację jako sąsiad dla sąsiadów. Teraz musiałem zrozumieć, co w codziennej pracy zarządcy osiedla jest uciążliwe, kosztowne, pracochłonne i nieefektywne, i czy którakolwiek z tych rzeczy da się załatwić w aplikacji, w której już są mieszkańcy.

I wtedy wydarzyło się coś, co przyspieszyło cały ten kierunek o kilka miesięcy.

Scena, która wszystko zmieniła

Na jednym z corocznych zebrań mieszkańców pojawiła się garstka osób. Jak to zwykle bywa, papierowa frekwencja na takich zebraniach jest niska: ludzie pracują, wyjechali, są zmęczeni, nie mają czasu, albo po prostu zakładają, że pojedyncze głosowanie ich nie dotyczy. Przedstawiono do głosowania szereg uchwał, od bieżących spraw finansowych po decyzje remontowe. Na koniec wieczoru okazało się, że dziewięćdziesiąt dziewięć procent z nich nie uzyskało wymaganej liczby głosów.

Wszystkie te uchwały trafiły do tak zwanego dogłosowywania. To jest ręczny proces zbierania podpisów od drzwi do drzwi przez kolejne tygodnie: ktoś chodzi po mieszkaniach z papierową listą i prosi właścicieli o podpis. W praktyce taki proces potrafi trwać pół roku. Zarządca jest w tym czasie zablokowany, wspólnota nie może podjąć decyzji, a każda kolejna sprawa czeka. Koszt logistyczny i psychiczny tej procedury jest trudny do wytrzymania.

Rozmowa z zarządcą

Zaproponowałem zarządcy spotkanie. Pokazałem, co już działa w aplikacji na moim osiedlu: jak mieszkańcy wymieniają się miejscami parkingowymi, jak działa moduł pomocy sąsiedzkiej, jak wyglądają zgłoszenia awarii w jednym centralnym miejscu zamiast w kilku telefonach do biura. Potem opowiedziałem o tym, jak wyglądałoby głosowanie elektroniczne: z weryfikacją tożsamości przez SMS, z natychmiastowymi wynikami, z frekwencją liczoną na żywo, z pełnym protokołem generowanym automatycznie na koniec.

Nie musiałem go długo przekonywać. Historia z dogłosowywaniem sprzed chwili była dla niego świeża i bolesna. Widział, ile kosztuje go tydzień, miesiąc, pół roku opóźnienia w każdej decyzji wspólnoty. Od tamtej chwili zaczęliśmy rozmawiać o pełnym wdrożeniu, a ja wróciłem do domu z przekonaniem, że mam pierwszego realnego klienta, który chce zapłacić. Nie za moje hobby, tylko za rozwiązanie konkretnego problemu, który kosztował go miesiące pracy każdego roku.

Model rozliczeniowy

Model płatności, który wybrałem, jest prosty: miesięczna subskrypcja, jedna faktura dla zarządcy lub wspólnoty, abonament uzależniony od wielkości osiedla i liczby mieszkań. W cenie abonamentu jest zaszyty pakiet SMS-ów, wystarczający dla typowego osiedla. To ważne, bo SMS-y są jednym z głównych bieżących kosztów operacyjnych (weryfikacja przy głosowaniach, powiadomienia o pilnych sprawach) i nie chciałem, żeby zarządca dostawał osobne rachunki za każdy przekroczony limit. Asystent AI jest oferowany osobno, jako dodatkowa funkcja, którą zarządca może dobrać opcjonalnie albo wynegocjować w pakiecie.

Wysokość abonamentu starałem się tak skroić, żeby większość wspólnot i firm zarządzających mogła sobie na niego pozwolić bez długich dyskusji na zarządzie. Chodzi o to, żeby aplikacja była postrzegana jako normalna pozycja w ogólnych kosztach operacyjnych wspólnoty, a nie jako nowy, trudny do uzasadnienia wydatek. Konkretnych kwot nie podaję publicznie, bo zależą od wielkości osiedla, liczby mieszkań i zakresu zamawianych funkcji. Ustalam je indywidualnie z każdym zarządcą, który się zgłosi.

Lekcja

To jest pivot, jeśli można go tak nazwać, choć od wewnątrz nie czuł się jak żaden ostry skręt. Czuł się raczej jak proces uświadomienia: najpierw zrozumienie, że jest problem (koszty), potem próba rozwiązania go w najbardziej oczywisty sposób (mikro-abonamenty), potem świadoma rezygnacja (bo psuje filozofię), potem nowe pytanie (kto więc zapłaci), potem nowa odpowiedź (zarządca), potem nowe zadanie (zrozumieć jego problemy) i dopiero wtedy zbieg okoliczności, który trafił w punkt (zebranie z dogłosowywaniem).

Lekcja, którą stąd wyciągnąłem, nie jest o modelach biznesowych w abstrakcji. Jest o czymś bardzo konkretnym: jeśli budujesz narzędzie „dla społeczności”, możesz długo nie widzieć, kto w tej społeczności ma pieniądze i realne powody, żeby ci zapłacić. Musisz to aktywnie znaleźć, a nie zakładać, że wszyscy użytkownicy są równi pod względem ekonomicznym. Mieszkaniec korzysta z aplikacji dla własnej wygody, ale nie ma z tego bezpośredniej oszczędności. Zarządca korzysta z tej samej aplikacji i oszczędza kilka miesięcy pracy na każdym cyklu głosowań. Oszczędność jest konkretna, mierzalna, da się ją przełożyć na fakturę. To jest różnica, której nie widać, dopóki się na nią nie popatrzy z bliska.

Co było dalej

Po tym pivocie zacząłem dużo celowej pracy nad pakietem funkcji specjalnie dla zarządców. W piątym, ostatnim tekście z tej serii opisuję dokładnie, co znajduje się w aktualnym pakiecie dla zarządcy wspólnoty: jakie moduły są gotowe, jak działają w praktyce, jak zabezpieczone są dane, jak wygląda głosowanie elektroniczne w trzech trybach włącznie z obsługą osób wykluczonych cyfrowo, i co jest w planach na kolejne miesiące. To jest tekst napisany stricte dla tej jednej osoby, dla zarządcy, który siedzi z rachunkami wspólnoty, z protokołami zebrań, z telefonami od mieszkańców o pękniętej rurze w piwnicy, i który zastanawia się, czy ten cały „WolnyParking” to rzeczywiście coś, co warto zobaczyć.