Nyaralóingatlan-kezelő szoftver: kategóriakalauz üzemeltetőknek

Írd be a kategória nevét a keresőbe, és kapsz egy platformlistát, egy összehasonlító táblázatot és rengeteg magabiztos tízes skálát. Amit szinte soha nem kapsz meg, az pont az, amire először szükséged lett volna: egy egyszerű leírás arról, mit is hivatott csinálni ez a szoftver, a heted melyik részét célozza minden modul, és a heted melyik részéhez nem nyúl hozzá semmi a listán.

Ez a hiány egy nagyon konkrét olvasónak számít a legjobban, és ez a cikk neki készült. Nem a két lakást kiadó házigazdának, akinek az igényei őszintén egyszerűbbek. Hanem annak, aki mások egységeit kezeli: öt, húsz, negyven otthont, amelyek olyan tulajdonosokhoz tartoznak, akik elszámolást, választ és magyarázatot várnak. Ennek az olvasónak a szoftverkérdés két félből áll, és a teljes kategória csak az egyik köré épül.

A fél, amit mindenki árul, a foglalás: naptárak, csatornák, árak, vendégüzenetek, vendégváltások, kifizetések. A fél, amit senki nem árul, az üzlet: a tulajdonos, aki üzemeltetőváltáson gondolkodik, az érdeklődés, ami este tizenegykor érkezett WhatsAppon, az aláírásra váró kezelési szerződés, a mosodai számla, amelynek semmi köze egyetlen foglaláshoz sem. Alább mindkettő őszinte térképe következik, az ebből fakadó stack-kérdés, és az a fejezet, amit minden vásárlási útmutató kihagy: mennyibe kerül valójában a váltás és milyen sorrendben érdemes végigvinni. Ha a második fél alkalmazott változata érdekel, a nyaralóingatlan CRM oldal közvetlenül az üzleti réteget tárgyalja.

A szállítói árazási modellek leírása a közzétett adatokon vagy független elemzők általánosan idézett megállapításain alapul 2026 szeptemberi állapot szerint. Vásárlás előtt ellenőrizd az aktuális összegeket minden szállító saját ároldalán.

A három réteg, rendesen felrajzolva

Képzeld a kategóriát három egymásra épülő rétegnek, nem egyetlen terméknek. Így olvasva érthetővé válik a piaci zűrzavar java része, mert a szállítók egy rétegen belül versenyeznek, majd úgy kommunikálnak, mintha mindhármat lefednék.

A disztribúciós réteg van felül. Kifelé néz, és az a dolga, hogy egy eladott éjszaka mindenhol lezárt éjszaka legyen. Ide tartozik a channel manager, az egyesített szabad kapacitás naptár, az éjszakai árak és árszabályok, a csatornákra kitolt hirdetési tartalom, és általában egy közvetlen foglalási motor honlappal. Ha itt törik el valami, valódi vendég érkezik egy házba, ahol már lakik valaki, ezért kap ez a réteg a legtöbb fejlesztői figyelmet és a legtöbb óvatosságot migráció közben.

Az üzemeltetési réteg van középen. A csapatod és a vendégeid felé néz. Foglalások és életciklusuk, minden csatornából összefésült üzenetek, automatikus üzenetek a tartózkodás előtt, alatt és után, takarítások ütemezése a kijelentkezési naptárból, ellenőrzőlisták fotós igazolással, karbantartási és ellenőrzési jegyek, és a fizetéskezelés, ami a foglalásból pénzt csinál. Ez a réteg nő a leggyorsabban az ingatlanszámmal, mert minden újabb otthon vendégváltásokat, üzeneteket és apró hibákat ad hozzá, nem csak egy sort egy listában.

A tulajdonosi réteg van alul, és jórészt üres. Azokra néz, akik azért fizetnek, hogy létezz. A tulajdonos itt kapcsolatként szerepel, nem kifizetési sorként: a megkeresett tulajdonosok pipeline-ja, a nekik járó utánkövetés, a kezelési szerződés és annak megújítási dátuma, az új ingatlan bevezetési ellenőrzőlistája, a havi teljesítménybeszélgetés, az a számlázás, ami nem foglalási kifizetés, és az a riport, amit egy tulajdonos tényleg elolvas. A legtöbb platform ezt a réteget egy tulajdonosi portállal és egy elszámoláskészítővel képviseli, ami a kapcsolat terméke, nem maga a kapcsolat.

A gyakorlati következmény: az az üzemeltető, aki csak a felső két réteget vásárolja meg, a harmadikat egy telefonból, egy jegyzetfüzetből és a memóriájából viszi. Öt ingatlannál ez működik. Valahol tizenöt és harminc között elromlik, méghozzá csendben, mert senki nem küld riasztást, amikor egy tulajdonos halkan beszélgetni kezd a versenytársaddal.

Mire való valójában az egyes modulok

A funkciólisták modulokat írnak le. Azt ritkán magyarázzák el, melyik milyen munkát végez, pedig épp ez mondja meg, hogy szükséged van-e rá már most.

Channel manager. Szinkronizáció, semmi más. A szabad kapacitás, az árak és a foglalások mozognak a rendszered és a hirdetési oldalak között, így az egyiken leadott foglalás a többin lezárja a dátumokat. Aszerint ítéld meg, mely csatornákat támogatja natívan, milyen gyors a szinkron, és mi történik hiba esetén. Ma szinte minden platform tartalmazza, tehát ritkán külön vásárlás, de továbbra is ez az a komponens, amelynek meghibásodása a legdrágább.

Egyesített naptár. Egyetlen nézet minden egységre és minden éjszakára. A harmadik ingatlantól hasznos, a tizediknél nélkülözhetetlen, és ez az az egy dolog, ami leggyakrabban vált ki táblázatos üzemeltetőt.

Árak és árszabályok. Alapár, szezonális korrekció, minimum tartózkodás, résszabályok, utolsó pillanatos kedvezmény. Ez nem ugyanaz, mint egy dinamikus árazó eszköz, amely a platform mellé kerül és élő kereslet ellenében mozgatja az árakat. A legtöbb üzemeltetőnél végül mindkettő ott van.

Közvetlen foglalási motor és honlap. Saját csatorna, jutalék nélkül. A motor kevésbé számít, mint a forgalom: egy látogató nélküli foglalási oldal semmit nem spórol, ezért a közvetlen foglalás marketingprojekt szoftverkomponenssel, nem fordítva.

Vendégpostafiók és tartózkodási üzenetek. Minden csatorna üzenete egy szálban, plusz egy sorozat, ami foglaláskor, érkezés előtt, a tartózkodás közepén és kijelentkezés után indul. Ez az a modul, amely a legmegbízhatóbban hozza vissza az árát megspórolt órákban.

Vendégváltás és takarítás. Takarítások a kijelentkezési naptárból ütemezve, takarítóhoz rendelve, ellenőrzőlistával és fotós bizonyítékkal. Könnyű változata a legtöbb platformban ott van, a szakosodott eszközök pedig okkal léteznek, amint valódi takarítócsapatod van.

Karbantartás és ellenőrzés. Egy elromlott kazánhoz felelős kell, határidő és nyom arról, hogy megjavították. Kis szervezetekben ez egy csoportos beszélgetésben él és elvész.

Fizetések, jutalékok és kifizetések. A vendég pénzének beszedése, a jutalék leválasztása, kauciók és károk kezelése, a tulajdonos kifizetése. Ahol a helyi szabályozás letéti számlavezetést ír elő, ez megfelelőségi kérdéssé válik, nem kényelmivé.

Tulajdonosi elszámolás és portál. A havi dokumentum bruttóval, jutalékkal, költségekkel és nettóval. Minden komoly platform előállítja. Ez a tulajdonosi kapcsolat terméke, nem a kapcsolat.

Riportok. Kihasználtság, átlagos éjszakai ár, elérhető éjszakára jutó bevétel, csatornaarány, és azok a számok, amiket egy nem tervezett hívásban kérnek tőled.

Stacket építeni vagy csomagot venni

Ha a rétegek tiszták, előkerül a valódi döntés, és az nem az, melyik szállító kap magasabb pontot. Hanem az, hány terméket akarsz üzemeltetni.

A csomag melletti érv, hogy egyetlen platform disztribúcióval és üzemeltetéssel egy belépést, egy támogatási kapcsolattartót, egy adatmodellt és nulla fenntartandó szinkront jelent. Ez valódi előny és megéri megfizetni. Az ára, hogy egy csomag szélessége általában egyenetlen: az a modul, amitől a bemutató teljesnek tűnt, éles üzemben gyakran a legvékonyabb, és körülbelül hat hét múlva derül ki, melyik.

A stack melletti érv, hogy minden rétegnek van szakosodott gazdája, aki jobban csinálja, és egy komponenst le tudsz cserélni anélkül, hogy mindent cserélnél. Aki egy elterjedt platformot használ disztribúcióra, dedikált árazót árakra, takarítási szakértőt a váltásokra és üzleti réteget a tulajdonosokra, annak négy számlája és négy belépése van, viszont nincs olyan egyetlen szállító, akinek a leggyengébb modulja lesz a leggyengébb folyamata.

A gyakorlatban három kérdés dönt.

Hány ingatlan, és kié? Tíz saját egység alatt a csomag ráfordításban szinte mindig nyer. Húsz idegen egység felett a tulajdonosi réteg önálló üzleti funkcióvá válik, és megszűnik elférni egy portálfülön.

Melyik hiba fájna jobban? Ha egy elmulasztott tulajdonosi utánkövetés évi több ezret érő szerződésbe kerül, a tulajdonosi réteg megérdemli a saját eszközét. Ha a problémád a dupla foglalás, a pénzt a stack tetején költsd el.

Ki tartja karban? Minden újabb integráció olyasmi, ami csendben elromolhat. A stack csak akkor olcsóbb a csomagnál, ha valaki gazdája az illesztéseknek. Egy ötfős üzemeltető cégnél nevezd meg ezt az embert, mielőtt megveszed a negyedik eszközt.

Létezik egy valódi házon belüli út is, amit a legtöbb útmutató túl gyorsan elintéz. Táblázat, közös naptár és üzenetküldő alkalmazás kis portfólióra tényleg működik, és tovább bírja, mint a szállítók elismerik. Az a pont, ahol elromlik, konkrét és felismerhető: amikor ketten szerkesztik ugyanazt a fájlt, amikor egy utánkövetésnek nincs gazdája, amikor egy tulajdonosi elszámolást minden hónapban kézzel raknak össze, vagy amikor a táblázatban lévő szám nem egyezik a bankkal.

Hol illeszkedik a Zoye, és hol nem

Kezdd a határral, mert az dönti el, releváns-e neked a fejezet többi része. A Zoye nem PMS. Nincs benne channel manager, nincs OTA szinkron, nincs szabad kapacitás naptár, nincsenek éjszakai árak, nincs foglalási motor, nincs csatornákból érkező vendégpostafiók és nincs letéti számlakezelés. Nem váltja ki a Guestyt, a Hostawayt, a Lodgifyt, az OwnerRezt vagy a Smoobut, és nem is akarja. Tartsd meg azt, amit használsz.

A Zoye a tulajdonosi réteg. MI-alapú üzleti operátor egy üzemeltető cég azon felére, amelynek semmi köze a foglaláshoz: a tulajdonosokhoz, akiket most szerzel meg, az érdeklődésekhez, amiket követsz, a szerződésekhez és dokumentumokhoz, a belső munkához, a nem kifizetés jellegű számlázáshoz, és ahhoz a riporthoz, ami arról szól, nő-e a cég, nem arról, hogy sűrű volt-e a múlt hónap.

A riportok egy helyre hozzák a tulajdonosi, pipeline, feladat és számlaadatokat, így a havi képet nem kell kézzel újraépíteni.

Ez a gyakorlatban néhány konkrét dolgot jelent. Minden tulajdonosi érdeklődésből lead lesz rögzített forrással, akár űrlapról, ajánlásból, Facebook vagy Instagram hirdetésből, akár WhatsApp üzenetből érkezett. A pipeline szakaszait te határozod meg, így látod azt a tizenegy tulajdonost, akikkel ebben a negyedévben beszéltél, és azt a négyet, aki elhallgatott. A kezelési szerződések, biztosítási iratok és ingatlanadatok a tulajdonosi rekordon élnek, nem egy e-mail szálban. Egy új ingatlan bevezetésének feladatai ismételhető lista, nem memóriateszt. A számlák ütemezetten mennek ki és késés esetén maguktól emlékeztetnek. A riportok a cégről szólnak, nem a naptárról.

Ami a munkanapot megváltoztatja, az az asszisztens. Ugyanazokat a rekordokat kezeli WhatsAppon, ott, ahol az üzemeltető valójában van: egy félig kitakarított lakásban állva, autóban két ingatlan között, vagy vasárnap, amikor ír egy tulajdonos. Küldj hangüzenetet egy tulajdonosi találkozó után, és lesz belőle kapcsolat, jegyzet és három határidős feladat. Kérdezd meg, mi van lejárva, és élő adatból kapsz valódi számokat, nem tippet. Kérd meg, hogy fogalmazza meg az utánkövetést a tíz napja nem válaszoló tulajdonosnak, és megírja jóváhagyásra. Minden romboló vagy tömeges művelet előbb rákérdez, és minden automatikus futás naplózott és visszafordítható.

A folyamatautomatizmusok azokat a szabályokat fedik le, amiket egy üzemeltető egyébként fejben tart: perceken belül válaszolni egy új tulajdonosi érdeklődésre, megjelölni egy hete álló üzletet, elindítani a bevezetési ellenőrzőlistát szerződésaláíráskor, emlékeztetni egy lejárt számlára. Egy mondatban leírod a szabályt, a Zoye érthető nyelven visszaadja, és semmi nem indul el, amíg jóvá nem hagyod.

Árazás: az Almost Free havi 5 dollár, éves számlázással havi 4 dollár, és 1 csapattagot tartalmaz 1 GB tárhellyel. A Starter havi 29 dollár, évesen 23 dollár, 10 tagra és 5 GB-ra. A Growth havi 59 dollár, évesen 47 dollár, 20 tagra és 10 GB-ra. A Scale havi 119 dollár, évesen 95 dollár, 100 tagra és 25 GB-ra. A Customize ajánlat alapján. A teljes részletek az árak oldalon.

Kinek való: olyan üzemeltetőknek, akik mások egységeit kezelik, már van PMS-ük, és azt szeretnék, hogy a tulajdonosi oldal ne a fejükben lakjon.

A váltás költsége, amit senki nem árazik be

Minden összehasonlító cikk a vásárlásnál ér véget. A drága rész utána kezdődik, és érdemes megérteni még aláírás előtt, mert a váltás költsége az oka annak, hogy a legtöbb üzemeltető olyan szoftveren marad, amit rég kinőtt.

Négy költség jelenik meg megbízhatóan.

Adat, ami nem képződik le. A jelenlegi rendszerednek vannak mezői, amik az újban nincsenek, és fordítva. Egyedi jegyzetek, tulajdonosonként eltérő jutalékfelosztás, korábbi elszámolások és minden, amit szabadszöveges mezőbe tettél, strukturálatlan tömbként érkezik, vagy sehogy. Tervezz időt annak eldöntésére, mi az, aminek tényleg át kell jönnie. A többségének nem.

A párhuzamos időszak. Néhány hétig két rendszert viszel, mert élő naptárt nem lehet egy este alatt átkapcsolni. Két rendszer azt jelenti, hogy két helyre lehet bevinni egy változást, és egy helyen el lehet felejteni.

Újratanítás, azokat is beleértve, akik nem alkalmazottak. A takarítók, karbantartók és részmunkaidősök szokásai a jelenlegi eszközre épültek. Egy új ellenőrzőlistás alkalmazás valódi változás annak, akit takarításonként fizetnek és nem olvas e-mailt.

A bizalmi rés. Nagyjából egy hónapig nem fogsz teljesen bízni az új számokban, ezért összeveted őket a régiekkel. Ez idő, és ez az a költség, ami a legtöbbeket meglepi.

Ezek egyike sem szól a váltás ellen. Amellett szólnak, hogy olyan sorrendben válts, ami a kockázatot az olcsó helyeken hagyja.

A migráció sorrendje: tulajdonosi rekordok elsőként, channel manager utoljára

A helyes sorrend majdnem a fordítottja annak, ahogy ösztönösen csinálják. Az ösztön azt mondja, mozgasd először a legnagyobb rendszert és essünk túl rajta. A biztonságos sorrend a legkisebb kockázatú adatot mozgatja először, és az élő foglalásokhoz nyúl utoljára.

Egy. Tulajdonosi és érdeklődési rekordok. Itt kezdd. Ez az az adat, ami a legnagyobb eséllyel csak egy táblázatban, egy telefonban és valakinek a fejében létezik, tehát ezt fenyegeti leginkább a teljes elvesztés. Ez a legbiztonságosabban mozgatható is, mert a hiba a vendégek felé láthatatlan és egy délután alatt javítható. Hozz át minden tulajdonost, minden hozzá tartozó ingatlant, minden nyitott érdeklődést a forrásával, és mindegyikhez a következő lépést. Már ez a lépés is jellemzően felszínre hoz két-három tulajdonost, akit senki nem hívott vissza.

Kettő. Dokumentumok és szerződések. Kezelési szerződések, biztosítási igazolások, kulcs- és belépési információk, házikalauzok. A tulajdonoshoz vagy az ingatlanhoz csatold őket, ne egy mappafához, és a megújítási dátumokat rögzítsd feladatként, amíg a dokumentumok úgyis nyitva vannak.

Három. Számlázás és a nem kifizetés jellegű tulajdonosi pénzügy. A foglalási folyamaton kívül számlázott kezelési díj, textil és fogyóeszközök, karbantartás továbbterhelése. Az ismétlődőket tedd ütemezésre.

Négy. Belső feladatok és vendégváltások. A csapat munkáját akkor mozgasd, amikor a rekordok, amikhez kapcsolódik, már léteznek. Az első lépés előtt elvégezve olyan feladatokat kapsz, amikhez nincs mit kötni.

Öt. Vendégüzenetek. Sablonok és sorozatok. Teszteld néhány valódi tartózkodáson, mielőtt mindent átkapcsolsz, és tartsd meg a régi sorozatokat, amíg az újak a tartózkodás minden szakaszában legalább egyszer sikeresen le nem futnak.

Hat. A csatornakapcsolatok. Utoljára, szándékosan, és lehetőleg a legalacsonyabb kihasználtságú időszakban. Először egy ingatlant vigyél át, és hagyd futni egy teljes hétig, valódi bejelentkezéssel és kijelentkezéssel együtt. Csak ezután vidd a többit, és az első napokban kézzel vesd össze az egyesített naptárt minden csatornával.

Két szabály teszi az egész sorrendet biztonságosabbá. Soha ne mozgass két réteget ugyanazon a héten, mert ha valami elromlik, nem fogod tudni, melyik változás okozta. És a régi rendszert tartsd olvashatóan, ne csak lemondva, legalább egy teljes számlázási és elszámolási cikluson át a befejezés után.

Hogyan válassz pontozótáblázat nélkül

A pontozómátrixok általában a leghosszabb funkciólistás szállítót jutalmazzák, ami ritkán a jó válasz. Négy kérdés többet ér.

Melyik réteg bukik el valójában? Írd le az utolsó öt dolgot, ami félrement. Ha négy naptár vagy csatorna probléma volt, a pénzed a stack tetejére való. Ha négy egy elfelejtett utánkövetés, egy hiányzó szerződés vagy egy mellőzöttnek érzett tulajdonos volt, semennyi PMS mélység nem segít.

Mi a legkisebb változtatás, ami megoldja? A kategória jutalmazza a türelmet. Egy dinamikus árazó vagy egy üzleti réteg hozzátétele a már ismert platform mellé sokkal olcsóbb, mint lecserélni azt a platformot.

Közzétesz-e árat a szállító? 2026 szeptemberében a kategória két legnagyobb platformja bemutató után ad ajánlatot, ami a szegmensükben normális, de azt jelenti, hogy költséget csak akkor tudsz összehasonlítani, amikor már benne vagy egy értékesítési folyamatban. Mások ingatlanszámmal skálázódó csomagokat tesznek közzé. Egyik modell sem hibás, de tudni, melyikkel van dolgod, meghatározza, mennyi ideig tart a vásárlás.

Mi történik azon a napon, amikor távozol? Az adatexportról aláírás előtt kérdezz, ne utána. Az a szállító, aki világosan válaszol, hasznosat mond a kapcsolatról.

Miért választják az üzemeltetők a Zoye-t a tulajdonosi réteghez

A minta következetes azoknál, akik hozzáveszik. A foglalási oldal náluk már megoldott volt, és nem akartak hozzányúlni. Ami hiányzott, az egy rendszer az üzlet azon részére, ami növeli a céget ahelyett, hogy kiszolgálná.

A tulajdonosi pipeline megszűnik láthatatlan lenni. Minden érdeklődésnek van forrása, szakasza és következő lépése, így a negyedév megkeresései lista, nem érzés.

A back office megszűnik a memóriától függeni. Szerződések, megújítási dátumok, bevezetési ellenőrzőlisták és számlák azon a rekordon ülnek, ahová tartoznak, és amelyiknek határideje van, az magától emlékeztet.

Az asszisztens ott dolgozik, ahol az üzemeltető. A WhatsApp és a hangüzenet azt jelenti, hogy a frissítés két ingatlan között történik, nem este tizenegykor, és egyedül ezért maradnak naprakészek a rekordok.

És a PMS-ed mellé áll, nem vitatkozik vele. A disztribúció és az üzemeltetés marad, ahol van. A tulajdonosi rétegnek végre van hol laknia.

Nézd meg, hogyan viszi a Zoye egy üzemeltető cég tulajdonosi oldalát. A csomagok havi 5 dollártól indulnak.

További kontextusért nézd meg a nyaralóingatlan CRM oldalt, a legjobb nyaralóingatlan szoftverek összeállítást, a vendéglátói CRM magyarázatot és a Guesty és Hostaway összevetést.