Branża nieruchomości tonie w ręcznej robocie: oferty wpisywane wielokrotnie, podstrony budowane jedna po drugiej, CRM rozjechany z portalem, raportowanie cen na ostatnią chwilę. Każda z tych czynności z osobna wygląda niegroźnie. Razem tworzą system, w którym jedna zmiana ceny mieszkania wymaga edycji w trzech miejscach, a połowa z nich zostanie zapomniana.
Wtyczki łatają objawy#
Typowy portal ofert rośnie przez doklejanie wtyczek: jedna do importu z CRM, druga do generowania podstron, trzecia do mapy, czwarta do raportu cen. Każda rozwiązuje jeden problem i dokłada dwa. Po roku portal to kruchy zlepek, którego nikt nie chce dotykać. Konkretne tryby awarii, które widzimy najczęściej:
- Konflikty wersji wtyczek. Aktualizacja CMS (np. WordPress) albo jednej wtyczki psuje drugą; import ofert pada cicho, a nikt tego nie zauważa do reklamacji klienta.
- Podwójna publikacja. Webhook z CRM ponawia próbę po timeoucie i ta sama oferta tworzy dwie podstrony. Bez klucza idempotencji portal ma duplikaty, które kanibalizują się w wyszukiwarce.
- Nieaktualne strony. CRM ma nową cenę, ale cache podstrony nie został unieważniony. Klient widzi cenę sprzed tygodnia, agent dostaje telefon „przecież na stronie jest taniej”.
- Dryf schematu. Wtyczka oczekuje pola
powierzchnia, portal eksportujemetraz, a nowy system CRM nazywa toarea_m2. Mapowanie żyje w głowie jednej osoby i znika razem z nią.
Żaden z tych problemów nie jest błędem konkretnej wtyczki. To efekt braku jednej warstwy, która pilnuje danych.
Produktowe podejście: jeden przepływ danych#
Zamiast łatać objawy, projektuje się przyczynę. Sednem jest kanoniczny kontrakt oferty: jeden kształt danych, do którego sprowadza się wszystko, co przychodzi z CRM, i z którego renderuje się każda podstrona. Przepływ wygląda tak:
- Wejście z CRM. Webhook (push) lub okresowy poll (pull) pobiera surową ofertę. Dla CRM-ów bez webhooków poll co kilka–kilkanaście minut jest wystarczający dla rynku nieruchomości, gdzie oferta nie zmienia się co sekundę.
- Normalizacja do kanonicznego schematu. Surowe pola CRM mapuje się na jeden, stały kontrakt danych — to miejsce, gdzie „jedno źródło prawdy” przestaje być hasłem, a staje się kodem.
- Deduplikacja. Klucz dopasowania (np.
crm_offer_idplus adres i powierzchnia) wykrywa, czy to nowa oferta, czy aktualizacja istniejącej. Idempotencja na tym etapie eliminuje podwójną publikację przy ponowieniach webhooka. - Render z szablonu. Kanoniczna oferta plus szablon dają podstronę. Setki ofert = setki spójnych, szybkich stron z tym samym kodem, bez ręcznego składania.
- Kolejka publikacji i unieważnienie cache. Zmiana trafia do kolejki, która publikuje stronę i unieważnia cache (w stacku Next.js: rewalidacja na żądanie / ISR), żeby klient nigdy nie widział nieaktualnej ceny.
Na każdym etapie, który dotyka ceny, statusu prawnego oferty lub danych do raportu regulacyjnego, zostaje miejsce na zatwierdzenie przez człowieka. Automatyzujemy żmudną pracę, nie odpowiedzialność.
Kontrakt danych: jak wymusić „jedno źródło prawdy”#
Mapowanie pól to nie szczegół implementacyjny, tylko serce systemu. Spisuje się je jawnie, w jednym miejscu, zamiast trzymać w głowie. Przykładowy fragment mapowania (pola ilustracyjne — w realnym wdrożeniu wynikają ze schematu konkretnego CRM):
| Pole w CRM | Pole kanoniczne | Pole na podstronie | Uwaga |
|---|---|---|---|
cena_brutto / price | price_pln | Cena | walidacja: liczba ≥ 0, waluta PLN |
metraz / area | area_m2 | Powierzchnia | jednostka wymuszona na m² |
status_oferty | status | Badge statusu | enum: aktywna / rezerwacja / sprzedana |
zdjecia[] | photos[] | Galeria | deduplikacja URL, limit rozmiaru |
lat / lng | geo | Mapa | walidacja zakresu współrzędnych |
id_oferty | crm_offer_id | (klucz) | klucz idempotencji i deduplikacji |
Gdy pojawia się nowy CRM albo wtyczka zmienia nazwę pola, zmienia się tylko warstwa mapowania — reszta systemu nie wie i nie musi wiedzieć, skąd dane przyszły. To jest różnica między „integracją CRM” jako hasłem a jako kontraktem.
Efekt: czas zamiast tarcia#
W jednej z realizacji (Estate OS) 450 ofert publikuje się automatycznie z CRM — czas publikacji spadł z godzin do minut, a błędy ręcznego przepisywania zniknęły, bo nikt już niczego nie przepisuje. To realna liczba z jednego wdrożenia, nie obietnica wyniku dla każdego.
Czego uczciwie nie obiecujemy: konkretnego procentu wzrostu ruchu ani sztywnego ROI — te zależą od rynku, jakości ofert i SEO, których nie kontroluje sam pipeline. To, co produktowe podejście realnie zmienia i co da się zaobserwować po wdrożeniu, to:
- Czas od zmiany w CRM do publikacji — z godzin (ręczny obieg) do minut (kolejka). Mierzalne w logach kolejki.
- Liczba pól wpisywanych ręcznie — z pełnego formularza na ofertę do zera, bo dane idą z jednego źródła.
- Liczba duplikatów i rozjazdów CRM–portal — dążenie do zera dzięki kluczowi idempotencji i jednemu kontraktowi danych.
Property-tech zbudowany jak produkt skaluje się od kilkudziesięciu do tysięcy ofert, bo architektura (monorepo, kolejki, czyste kontrakty danych) była założeniem, nie refleksją. Ten sam pipeline, który publikuje 450 ofert, publikuje 5 000 bez zmiany kodu — zmienia się tylko liczba zadań w kolejce.
Zgodność i raportowanie bez pożaru#
Część obowiązków w nieruchomościach jest cykliczna i nieubłagana — np. raportowanie cen (dane.gov.pl dla deweloperów). W modelu „zlepek wtyczek” to comiesięczny pożar: ktoś ręcznie zbiera dane i wysyła na ostatnią chwilę. W modelu produktowym raport powstaje z tego samego kanonicznego źródła co podstrony, z weryfikacją integralności i logiem, kto i kiedy zatwierdził wysyłkę.
Tam, gdzie portal przetwarza dane osobowe (np. zapytania klientów, kontakty), obowiązuje RODO: minimalizacja danych, jasna podstawa prawna i retencja. To kolejny powód, by mieć jedną warstwę danych — łatwiej w niej wskazać i usunąć dane konkretnej osoby niż w czterech wtyczkach, z których każda trzyma własną kopię.
Spróbuj: zaprojektuj pipeline ofert dla swojego CRM#
Powiązane ścieżki#
Zobacz, jak ten wzorzec działa w praktyce w Estate OS, integracji strony deweloperskiej z dane.gov.pl, synchronizacji CRM z zespołem sprzedaży oraz usługach PropTech i synchronizacji CRM.
FAQ#
Co znaczy „PropTech jak produkt”?#
To budowa systemu dla nieruchomości jak spójnego produktu — monorepo, jeden kanoniczny kontrakt danych, synchronizacja CRM, automatyczna publikacja ofert i podstron — zamiast zlepka wtyczek, który trzeba pilnować ręcznie. Przyczyną jest jedno źródło prawdy, a nie kolejna wtyczka łatająca objaw.
Czy oferty można publikować automatycznie?#
Tak. Oferta wpada raz do CRM, a setki podstron generują się i publikują same przez kolejkę zadań — czas publikacji spada z godzin do minut, a błędy ręcznego przepisywania znikają, bo nikt już niczego nie przepisuje. Zmiany cen i statusów prawnych zostawiamy do zatwierdzenia przez człowieka.
Jak uniknąć duplikatów i nieaktualnych stron?#
Przez idempotencję i unieważnianie cache. Każda oferta ma klucz (np. crm_offer_id plus adres i powierzchnia), więc ponowienie webhooka aktualizuje istniejącą podstronę zamiast tworzyć drugą. Zmiana w CRM trafia do kolejki, która publikuje stronę i unieważnia jej cache (rewalidacja na żądanie / ISR), więc klient nie widzi ceny sprzed tygodnia.
Co psują typowe wtyczki w portalu ofert?#
Najczęściej cztery rzeczy: konflikty wersji przy aktualizacjach, podwójną publikację przy ponowieniach webhooka, nieaktualne strony przy braku unieważnienia cache i dryf schematu, gdy pole w CRM zmienia nazwę. Wszystkie znikają, gdy istnieje jedna warstwa mapująca dane CRM na kanoniczny kontrakt oferty.
Czy system jest zgodny z wymogami (np. dane.gov.pl)?#
Raportowanie cen i obowiązki cykliczne automatyzujemy w pipeline danych, z weryfikacją integralności i logiem zatwierdzeń — raport powstaje z tego samego źródła co podstrony. Zgodność z RODO wspiera jedna warstwa danych, w której łatwiej odnaleźć i usunąć dane konkretnej osoby. Ostateczną odpowiedzialność za zatwierdzenie wysyłki regulacyjnej zostawiamy człowiekowi.