Na DREEM je pro mě důležitá jedna věc, která zvenku skoro není vidět. Nestavíme jen web nebo interní CRM pro realitku. Stavíme firmu, která je uvnitř řízená vlastním softwarem.
Že je to dnes vůbec reálné, o tom jsem psal už dřív v článku Software se změnil. K nepoznání. Tady chci jít o krok dál, ke konkrétnímu typu systému. A pro mě osobně je to ještě silnější. Celý život mě nejvíc baví stavba systémů, system thinking a návrh systémových aplikací. Možnost stavět v DREEM systém od produktu přes technickou architekturu až po business logiku je vlastně moje snová práce.
Právě proto v DREEM používáme Temporal.
O co jde
V klasické realitce bývá proces rozpadlý mezi lidi, inboxy, WhatsAppy, tabulky a osobní disciplínu jednotlivců. To funguje do chvíle, než se něco ztratí. Neozve se klientovi někdo včas. Zapadne follow-up. Není jasné, kdo je teď na tahu. Nebo se sice něco stane, ale není z toho spolehlivě vidět stav celého případu.
A přesně tohle nechceme. DREEM nestavíme jako business, kde proces drží pohromadě hlavně paměť a disciplína lidí. Chceme, aby klíčové workflow držel pohromadě systém.
To zároveň navazuje i na text Nejsme další realitní kancelář, kde ten směr popisujeme z druhé strany. Nejde podle nás hlavně o problém jednotlivých lidí. Jde o problém systému. A právě proto DREEM nechceme stavět jako další digitální realitku s pár nástroji navíc, ale jako nový typ realitní infrastruktury, kde se technologie nepřilepí na starý proces, ale pomáhají ten proces přepsat.
Proč vůbec stavíme DREEM jako software-first službu jsem popsal už v článku Nestavět tool. Stavět službu. Tohle je navazující technický pohled dovnitř.
Proč zrovna Temporal
Temporal je pro tenhle typ problému silný tím, že workflow nebere jako sérii izolovaných requestů, cronů a webhooků, ale jako dlouho žijící procesy se stavem, historií a jasným dalším krokem. A to je přesně to, co v takovém službovém businessu potřebuješ.
Prodej nemovitosti není jedna synchronní akce. Je to dlouhý proces složený z mnoha kroků:
- onboarding případu,
- příprava podkladů,
- práce s poptávkou,
- koordinace prohlídek,
- zpětná vazba,
- vyjednávání,
- administrativa,
- follow-upy.
Tohle všechno se děje v čase, s čekáním na lidi, dokumenty, reakce a externí události. Právě na to je workflow engine dobrý.
A pro nás to není abstraktní úvaha do budoucna. V DREEM už dnes stavíme a používáme první konkrétní workflow, hlavně lead flow. Nečekáme tři měsíce, až bude celý interní systém hotový. Stavíme ho po vrstvách tak, aby byl použitelný hned od začátku a mohl se rozšiřovat spolu s reálným provozem. Není to jen nějaký diagram v dokumentaci. Každý lead má vlastní workflow se svým stavem, historií, počtem pokusů o kontakt a jasně určeným dalším krokem. Systém řeší přiřazení, předkvalifikaci, záznam kontakt pokusů i převod do další fáze, hlídá další akci podle SLA, u urgentních leadů míří na první kontakt do 30 minut, u běžných třeba do 4 hodin, zarovnává follow-upy do pracovních hodin a při posunu dál umí navázat další workflow i související komunikační vrstvu.
Proč nestačí cron, queue a pár webhooků
Jasně, i tohle by šlo nějak slepit přes cron, queue, webhooky a vlastní stavovou logiku okolo. Jenže pak si ten workflow engine ve výsledku stavíš sám, akorát hůř. Přibývá ruční orchestrace, retry logika, čekání na události, dohledávání stavu a větší prostor pro chyby.
Temporal nám dává lepší základ pro durable workflow, které má jasnou historii, návaznost a spolehlivější provoz.
Co tím ve skutečnosti říkáme
Použití Temporal v DREEM není jen technická volba. Je to i jasný statement o tom, jak ten business chceme stavět. Nechceme firmu, kde software jen eviduje, co už lidi udělali. Chceme firmu, kde software pomáhá aktivně řídit, co se má stát dál.
To je velký rozdíl. Klasický interní systém často funguje jako zpětné zrcátko. Workflow engine je blíž operačnímu řízení. Pomáhá držet tempo, návaznost a spolehlivost procesu. A přesně tak to děláme i v DREEM. Nejdřív postavíš první funkční workflow, začneš ho opravdu používat a pak na něj vrstvíš další části procesu. Systém nevzniká bokem od reality. Roste přímo uvnitř ní.
Proč je to na realitku neobvyklé
Na realitní službu je to dost neobvyklý setup. Spousta podobných firem by si na tenhle problém vzala hotový SaaS stack, CRM a pár automatizací. To není nutně špatně. Pro spoustu firem je to rozumná volba.
My ale nestavíme software jako podpůrnou vrstvu kolem běžného procesu. Stavíme proces tak, aby byl od začátku software-native. Jinými slovy, nesnažíme se jen digitalizovat starý model fungování. Snažíme se navrhnout jiný operační model služby, kde jsou transparentnost, koordinace a další krok v procesu součástí systému, ne vedlejším efektem toho, že si to někdo uhlídá.
Temporal tady pro mě není technická hračka. Je to součást rozhodnutí, že ten business myslíme vážně jako systém.
Proč to dává smysl i ekonomicky
Bez dnešní AI páky by tohle podle mě pořád ekonomicky nevycházelo. Trvalo by to roky a stálo by to miliony. Dnes to ve dvou vývojářích, já a Udaya, umíme stavět v řádu jednotek měsíců a za řádově desetinové náklady.
Co je na tom pro mě nejdůležitější
Nejdůležitější pro mě není samotný Temporal. Nejdůležitější je ten posun v uvažování. Software už nemusí být jen produkt, který prodáváš dál, nebo podpůrný tool pro tým. Může to být přímo operační motor firmy.
V DREEM přesně tohle děláme. Nestavíme jen realitní službu s nějakým softwarem okolo. Stavíme software-first firmu, kde klíčové workflow chceme mít řízené systémově. A upřímně, i lidsky je to pro mě strašně silné. Vždycky jsem chtěl stavět systémy od A do Z. Tady to můžu dělat naplno, a ještě na problému, kde se produkt, technologie a business skládají do jednoho řešení.
Proto v DREEM používáme Temporal.
A příště to vezmu ještě víc technicky. Na konkrétním řešení a ukázkách, jak se s Temporalem reálně staví workflow, které pak opravdu běží v provozu.
