Kako izbrati CRM za prodajo novogradenj: merila za investitorje

Zakaj generični CRM pri novogradnji hitro naleti na omejitve

Večina sistemov je zasnovana okoli kontakta in ponudbe: oseba povpraša, prodajalec jo pokliče, posel se zapre. Pri novogradnji je središče drugje. Kupec izbira med omejenim številom enot, vsaka ima svojo ceno, etažo, površino, orientacijo in pripadajoče parkirno mesto ali shrambo, vsaka pa je lahko prodana samo enkrat.

Zato je vprašanje, kako izbrati CRM, v resnici vprašanje, ali sistem razume enoto kot samostojen zapis s svojim statusom. Če je ne, se dejansko stanje projekta vodi v preglednici ob strani. To je najpogostejši vir dvojnih rezervacij in neusklajenih cen.

Investitor ima poleg tega več deležnikov: lastno prodajno ekipo, zunanje agencije, vodjo projekta in finance. Vsi potrebujejo isto sliko stanja, vsak pa z drugimi pravicami vpogleda.

Vezava na enote: osrednje merilo pri CRM za prodajo novogradenj

Pri izbiri preverite, ali lahko enoto ustvarite kot objekt z lastnimi polji in jo povežete z več interesenti. Povezava mora delovati v obe smeri: na kartici kupca vidite, katere enote ga zanimajo, na kartici enote pa, kdo vse zanjo tekmuje in kdo ima aktivno rezervacijo.

Posebej pozorni bodite na pripadajoče dele. V Sloveniji se parkirna mesta in shrambe pogosto prodajajo ločeno, v Nemčiji in Avstriji pogosteje skupaj z enoto, zato mora sistem podpirati oba modela.

• enota kot zapis s poljema etaža in številka ter površino, ceno, orientacijo in statusom
• pripadajoči deli (parkirišče, shramba, vrt) kot priloga ali samostojna enota
• več interesentov na eni enoti, a samo ena aktivna rezervacija
• zgodovina sprememb cene in statusa z datumom in uporabnikom
• uvoz in izvoz cenika iz preglednice
• več faz ali stavb v istem projektu, brez podvajanja računov

Statusi: ločite status kupca od statusa enote

Pogosta zmota je en sam niz statusov. V resnici potrebujete dva. Kupec napreduje skozi korake, kot so novo povpraševanje, kontaktiran, ogled opravljen in ponudba poslana. Enota ima svoje stanje: prosto, rezervirano, predpogodba oziroma Reservierung, prodano, začasno nerazpoložljivo.

Rezervacija mora imeti rok veljavnosti in opomnik ob izteku. Brez tega enote ostajajo rezervirane tedne po tem, ko je kupec že odnehal. Pri trgu DACH dodajte še korake, ki jih narekuje postopek: Notartermin, Beurkundung, plačilni mejniki po Bauträgervertrag. V Sloveniji ustrezajo predpogodba, varščina in kupoprodajna pogodba.

Dobro je, da sprememba statusa enote sproži naslednje dejanje: obvestilo prodajalcu, posodobitev javnega prikaza razpoložljivosti in nalogo za pripravo pogodbe.

Integracije: kaj mora CRM za nepremičnine sprejeti in oddati

CRM ni otok. Povpraševanja prihajajo s spletne strani projekta, iz oglasnih portalov, e-pošte in telefona, podatki o prodanih enotah pa morajo naprej v finance in pogodbeno dokumentacijo. Preverite, ali ima sistem odprt API ali webhooke ter delujoče vgrajene povezave, ne le obljubo o integraciji.

Največ koristi prinese skupna šifra enote. Pri projektih, kjer ARHIX poveže interaktivni model stavbe s CRM-jem, kupec izbere enoto v brskalniku, v CRM pa pride povpraševanje z natančno oznako etaže in enote. Prodajalec tako ve, o čem se pogovarja, še preden dvigne telefon.

Za trg DACH je pomembno tudi varstvo podatkov. Zahtevajte hrambo podatkov v EU, pogodbo o obdelavi osebnih podatkov in možnost izbrisa po zahtevi posameznika, saj sta GDPR in DSGVO za kupce samoumevna.

• obrazci na spletni strani, ki prenesejo enoto in vir povpraševanja
• e-pošta in koledar za ogledne termine
• digitalna prodajna platforma ali 3D prikaz z zapisom, katere enote je kupec odprl
• elektronski podpis in shramba pogodb
• računovodstvo ali ERP za plačilne mejnike
• portal za kupce, ki prikazuje status njegove enote

Poročila: kaj investitor res potrebuje

Poročilo je uporabno le, če odgovarja na odločitev. Investitor mora vedeti, kje se prodaja zaustavlja, kateri kanal prinaša resne kupce in katere enote ostajajo neprodane ter zakaj. Sistem, ki zna narisati le splošni lijak, to težko pokaže.

Preverite, ali lahko poročila filtrirate po projektu, stavbi, etaži, tipu enote in agenciji ter jih izvozite za upravo ali financerja. Pomembno je tudi, da poročila temeljijo na istih podatkih kot vsakodnevno delo, ne na ročno pripravljenih izvozih.

• razpoložljivost in zasedenost po etažah in tipih enot
• lijak od povpraševanja do pogodbe po projektu in viru
• čas med povpraševanjem, ogledom in rezervacijo
• rezervacije s pretečenim ali bližnjim rokom
• primerjava agencij in kanalov po realiziranih prodajah
• načrtovani in prejeti zneski po plačilnih mejnikih

Kdaj obstoječi CRM zadostuje

Če v podjetju že deluje CRM, ga ni treba menjati samo zato, ker se je pojavil nov projekt. Zadostuje, če omogoča lastne objekte ali tabele, v katere vnesete enote, če lahko statuse enot vodite ločeno od statusov kupcev in če ima API za povezavo s spletno stranjo.

Običajno zadostuje tudi pri manjšem projektu z eno fazo, eno prodajno ekipo in brez zunanjih agencij. Tam je večji strošek uvajanja novega sistema kot tveganje napak.

Zamenjava je smiselna, ko prodajalci enote še vedno vodijo v preglednici, ko pride do dvojnih rezervacij ali ko uprava ne dobi pregleda brez ročnega usklajevanja. Preden se odločite, naredite dvotedenski preizkus z resničnim cenikom ene stavbe.

Pogoste napake in kontrolni seznam

Največ težav nastane, ker se sistem izbere po videzu vmesnika, ne po podatkovnem modelu. Pred podpisom naročila preverite spodnje točke z demo okoljem, napolnjenim z vašimi podatki.

Če sistem pri več od teh točk odpove, bo prodaja v praksi tekla mimo njega.

• Ali lahko uvozite cenik s 40 ali več enotami v eni operaciji?
• Ali sistem prepreči dvojno rezervacijo iste enote?
• Ali ima rezervacija rok in samodejni opomnik?
• Ali agencija vidi samo svoje kupce in prosti del ponudbe?
• Ali je mogoče izvoziti vse podatke ob menjavi ponudnika?
• Kdo na vaši strani bo vzdrževal polja, statuse in pravice?

Naslednji koraki

Začnite z opisom procesa na enem listu: od prvega stika do notarja ali podpisa pogodbe, z imeni statusov in odgovornimi osebami. Nato primerjajte ta opis z obstoječim CRM-jem in označite, kje se podatki izgubijo.

Če ugotovite, da vam manjkata le enote in integracija s spletno stranjo, je prilagoditev obstoječega sistema običajno hitrejša od menjave. Če so vrzeli širše, imate zdaj merila za zahtevnik, ki ga pošljete ponudnikom.