Tarkvara, mida väikehotell vajab: PMS, Booking Engine, Channel Manager ja aruanded

Ühel reedel kaheksa sisseregistreerimist, tabel, postkast ja märkmik vastuvõtulaual — tavaliselt just sel hetkel hakkab 12-toalise hotelli omanik tarkvara otsima. Seni sai kõik käega tehtud: broneering tuli kirjaga — kirjutasite üles, külaline helistas — nihutasite, külaline saabus — registreerisite sisse.

Edasi on kaks teed. Esimene — osta see „hotelliprogramm“, mille keegi vestlusringis soovitas. Teine — trükkida päring otsingumootorisse ja upuda „top 20“ nimekirjadesse, kus iga müüja nimetab just oma süsteemi hädavajalikuks. Mõlemad teed lõppevad ühtmoodi: ostetakse midagi mittevajalikku ja jääb puudu millestki vajalikust.

Tegelik nimekiri on lühem. Väikehotell vajab ühte tuuma — PMS (property management system), majutusasutuse haldussüsteem — ja kolme moodulit ümber: Booking Engine, Channel Manager ja Guest Portal. Aruandeid ei pea eraldi ostma: need kasvavad välja samast PMS-ist. Kõik ülejäänu — tulujuhtimissüsteem, restorani kassa, nutikad lukud — ühendatakse siis, kui selleks on põhjus olemas.

Vaatame järjekorras läbi: mida iga süsteem teeb, millest saab ilma olla ja millises järjekorras seda kõike ühendada.

Kaart: üks tuum, neli moodulit ümber

Lühiversioon, mida peas hoida:

Süsteem	Mida katab	Mis juhtub ilma temata
PMS	broneeringud, Planner, hinnad, külalised, kassa	iga loend elab oma elu
Booking Engine	otsebroneeringud Teie veebilehelt	kanali komisjonitasu igalt broneeringult
Channel Manager	saadavus ja hinnad kõigis kanalites	käsitsi ülekanne ja topeltbroneeringud
Guest Portal	registreerimisvorm, dokumendid, küsimused, teenused	kõned, kirjad ja pabervormid
Aruanded	päeva pilt ja raha	otsused mälust

Edasi — üks süsteem korraga.

PMS: tuum, millest alustatakse

PMS on koht, kus elavad broneeringud, hinnad, toad, külalised ja raha. Sees Planner, kuhu koonduvad broneeringud kõigist allikatest; hinnad tühistamistingimuste ja müügipiirangutega; külaliste profiilid ajalooga; kassa vahetustega. Hinnad elavad hinnaplaanides, Planneris — broneeringud: kui neid kahte ei hoia lahus, muutub reede hind ühel päeval kogemata.

Niikaua, kui ühtset süsteemi pole, on igal neist asjadel oma koht: broneeringud postkastis ja tabelis, tubade staatused sõnumirakenduses, raha pangakontol. Töötab. Täpselt päevani, mil kaks inimest vaatavad ühe ja sama õhtu kahte erinevat versiooni.

Hotel Tech Reporti küsitluse (450 hotellipidajat, 2026) järgi peab 86% PMS-i hotelli kõige tähtsamaks süsteemiks ja 91% ütleb, et see mõjutab tulu otse. Need on müüja enda numbrid: Hotel Tech Report müüb tarkvara reitinguid. Kuid suurusjärku näitab ta õigesti — kõik muu ehitatakse PMS-i ümber, mitte vastupidi. Samast küsitlusest: 89% haldajatest säästab 2–10+ tundi nädalas, 17% — üle 500 tunni aastas.

Mida see praktikas tähendab 12-toalisele objektile? Reedel hommikul on Teil üks ekraan: saabujate järjekord, igal broneeringul külaline, tuba ja makse. Sisseregistreerimine ühe-kahe klõpsuga, broneeringu nihutamine lohistades, hinna muutmine kuupäeval — parandusega hinnaplaanis. Päeva hoiatused meenutavad tasumata sisseregistreerimist ja tuba, mis pole veel valmis.

Eraldi küsimus — pilv või töölauaversioon. 2025. aastal moodustasid pilvelahendused umbes 65% PMS-i turust (Mordor Intelligence; turutulemuste absoluutmahu osas erinevad uurijate hinnangud kordades, seega usaldage osakaalu, mitte summat). 9–30 toaga objektile tähendab see lihtsat asja: serverit ja paigaldust pole, töö käib brauserist — vastuvõtulaual, kodust, telefonist. Rohkem tuumast — PMS-i lehel.

Viimane, mida tuumi kohta tasub mõista: tema peab olema täpselt üks. Kaks süsteemi, kummalgi oma Planner, ei ole varuvariant — need on kaks tõe versiooni. Kui Teile pakutakse eraldi „süsteemi kanalitele“ ja eraldi „süsteemi vastuvõtule“, küsige, kus nende andmed kokku tulevad. Heal väikehotelli PMS-il kohtub kõik ühes aknas: Planneris on broneeringud mis tahes allikast, hinnad — hinnaplaanides, ja kui vaja on vaadet „hinnad kuupäevade kaupa“, näidatakse neid otse võrgu lahtrites.

Inimestegi peale tasub ette mõelda. 12-toalises objektis on tavaliselt kaks-kolm inimest erineva ligipääsuga: omanik vaatab raha, administraator tegeleb broneeringute ja sisseregistreerimisega, koristajale piisab päeva toaloendist. Rollid ja õigused on igav teema — kuni esimese juhuseni, mil külaline helistab ja selgub, et vajaliku paranduse oskab teha „see, kes oskab“, ning tema on puhkusel.

Booking Engine: Teie veebileht kui müügikanal

Booking Engine on müügivorm Teie veebilehel. Külaline valib kuupäevad ja toatüübi, näeb Teie hindu, maksab kaardiga — ja broneering jõuab Plannerisse iseseisvalt, ilma kirjavahetuse ja käsitsi ülekandmiseta. Töötab see ainult koos PMS-iga: mootor näitab reaalset saadavust ja reaalseid hindu, mitte eelmise kuu pilti.

Miks see on raha, mitte „veel üks funktsioon“. Sektori aruande järgi (135 miljonit broneeringut aastas, 20 riiki) toob broneering hotelli enda saidilt keskmiselt 516 $ ja broneering kanalist 312 $. Otsekanal kuulub tulu poolest top 3 hulka 90% turgudel. Miks nii — see on eraldi uurimuse teema, kuid kahekolmandikuline vahe on põhjus, miks enda müügikanal välja ehitada.

Kanali komisjonitasu seejuures kuhugi ei kao: valdkonna müüjate hinnangul moodustab see 15–30%+ igalt broneeringult. Nende numbrite taga metoodikat ei avaldata, seega on aus sõnastus selline: kanali komisjonitasu on märgatav ja püsiv protsent tulust, mida Te maksate igalt broneeringult, mis ei tulnud Teie enda saidilt. Kui palju kanal maksab ja millest komisjon moodustub — OTA ülevaates.

Ja vastupidine hoiatus: otsekanal ei ole tasuta. Kaardimaksed, saidi ülalpidamine, liiklus — samade müüjate hinnangul veel 4–5% kulusid. Mootor ei asenda kanaleid, vaid lisab ühe, mille eest Te külalise toomise eest komisjoni ei maksa. Täpsemalt — Booking Engine’i lehel.

Mida mootori valimisel vaadata. Vidin peab mahtuma olemasolevale saidile — vaid paari koodireaga, ümberehituseta; külaliselehed mitmes keeles, kui Teie külalised tulevad välismaalt; makse kaardiga, valikuga ettemakse või eelautoriseerimine. Väikesed asjad, mis saavad kiiresti kohustuslikuks: sooduskoodid, lisateenuste müük ajaga (transfeer konkreetse lennu jaoks), kahe-kolme toa broneerimine ühe korraga perele. Kõik see on mooduli osa, mitte kallim tellimustase. Kuidas vitriin külalisele välja näeb ja millised hinnaplaanid sinna panna — Booking Engine’i juhendis.

Channel Manager: et kanalid ei valetaks

Kanalid on endiselt seal, kus nõudlus elab. Sektori aruande järgi (üle 90 miljoni broneeringu sõltumatutel objektidel, 2025) moodustasid kanalid 63,4% broneeringutest ja otsekanalid 36,6%. Aasta varem oli kanalite osakaal 61%. Trend ei soosi otsemüüki ja sellega vaidlemine ei aita: kanalid toovad külalisi, keda objekt ise kätte ei saa.

Probleem ei ole kanalites, vaid nende arvus. Kolm kanalit on kolm vahekaarti, kolm käsitsi parandust ja kolm võimalust müüa sama tuba kaks korda. Topeltbroneering ei tähenda ainult seda, et „külalisel pole kus magada“: valdkonna müüjate hinnangul maksab külalise ümberpaigutamine teise hotelli 300–450 $ juhtumi kohta, rääkimata rikutud arvustusest ja suhetest kanaliga.

Channel Manager sulgeb just selle lünga. Ta hoiab saadavuse ja hinnad kõigis kanalites ühesugused: müüsite toa ühes — arv teistes kahaneb, tõstsite hinna PMS-is — muudatus läks kõigisse kanalitesse. Broneering kanalist jõuab Plannerisse iseseisvalt, koos märkega, kust ta tuli.

Tehniliselt on see nii: tubade arv kuupäeva kohta arvutatakse PMS-i ühisest kalendrist, mitte ei hoia seda eraldi iga kanali jaoks. Seepärast on kuupäeva müügi sulgemine üks tegevus, mitte kolm. Kanali ühendamine on valik kataloogist (küpsetel süsteemidel üle saja: Booking.com, Airbnb, Expedia ja kümneid teisi), Teie toatüüpide vastendamine kanali omadega ja esimene väljastus, mille järel lähevad saadavus ja hinnad kanalisse iseseisvalt.

Kanalid ei pea ka kõik võrdselt maksma. Channel Manager kui klass võimaldab pidada kanalikohta hinda: lisada peale komisjoni või vastupidi — hoida otsehinda madalamana — ilma et teised seaded segi läheksid. Keegi juhib nii oma positsiooni otsingutulemustes, keegi turgude erinevust; tähtis on see, et otsus langetatakse ühes kohas, mitte kolme parandusega kolmes kabinetis. Millest kanali positsioon otsingutulemustes üldse sõltub — artiklis OTA rankimisalgoritmist.

Tähtis aus hoiatus: sünkroonimine ei tühista kanalite võidujooksu sama toa pärast. Topeltbroneeringuid juhtub ka Channel Manageriga — neid on lihtsalt suurusjärk vähem ja nad on kohe näha.

Millal Channel Managerit pole vaja? Kui Te müüte läbi ühe kanali ja broneeringuid on vähe, töötab käsitsi sünkroonimine. Küsimus on ainult selles, kui palju aega olete valmis ülekandmiseks kulutama ja mis hinda Te maksate ühe unustatud õhtu eest.

Guest Portal: mida külaline enne ja pärast broneeringut teeb

Seda kategooriat polnud „seitse hotelliprogrammi“ nimekirjades hiljaaegu veel olemas — ja just seepärast jäetakse ta sageli unarusse. Guest Portal on külalise isiklik leht: veebipõhine registreerimisvorm ja dokumendid enne saabumist, broneering tervikuna hindadega päevade kaupa, teenuste tellimine, küsimused hotellile. Külaline tuleb sisse isikliku lingiga e-kirjast — ilma registreerumise ja paroolita, mida keegi ei mäleta.

Vastuvõtule tähendab see vähem kõnesid „mis kell on sisseregistreerimine“ ja „kas saab hilja“. Külaline täidab registreerimisvormi ette, dokumendid laadib üles ise, ja küsimus jõuab hotelli ühisesse järjekorda — mitte administraatori isiklikku vestlusrakendusse, kellel täna vabapäev. See pole sõnumirakendus: formaat „küsimus — vastus“, ja selles formaadis katab ta suurema osa kirjavahetusest enne saabumist.

Külalise ootus on siin tähtsam, kui paistab. Inimene, kes ostab lennupileti ja tellib söögi rakendusest, ei mõista, miks sisseregistreerimiseks tuleb helistada ja passiandmeid telefoni teel ette ütelda.

On ka vastupidine pool, ja see on hea: osa palveid, mis varem kõnesid tulid, vormistab külaline nüüd ise. Tellida transfeer või hommikusöök kindlal kellaajal — taotlus jõuab samasse järjekorda ja vastus läheb külalisele sinna, kust ta kirjutas.

Rohkem moodulist — Guest Portali lehel.

Aruanded: mida iga päev vaadata

Aruanded ei ole eraldi programm, vaid kiht samade andmete peal. Päevapilt mahub ühele armatuurlauale: tänased sisse- ja väljaregistreerimised, kes majas on, hõivatus lähematel kuupäevadel, broneeringute tasumata jäägid. Pluss kassa: vahetused ja rahaliikumise päevik, et õhtu lõpeks vastavuskontrolliga, mitte administraatori mäluga.

Väikehotellide planeerimishorisont on pikenenud. Valdkonna andmetel kasvas ettebroneerimise aeg 38 päevani aastal 2023 ja 40 päevani aastal 2025 — külaline broneerib keskmiselt nelikümmend päeva enne saabumist. See tähendab, et kuu ettevaade on Teil alati olemas, ja ühe kuuga jõuab nädalavahetuse hinda üles tõsta, kui hõivatus on juba hea. Kuidas jälgida, kuidas tulevased kuupäevad täituvad — artiklis OTB kohta.

Ausalt piiridest: ketite tasemel juhtimisanalüütikat — ADR, RevPAR, nõudluse prognoos — ei maksa väikehotellide PMS-ilt oodata. Neid näitajaid arvutatakse andmete peal, tabelis. Tähtis on muu: et algsed numbrid (hinnad päevade kaupa, broneeringud, hõivatus, maksed) asuksid ühes kohas ega tuleks kokku neljast allikast. Kuidas neid vigadeta arvutada — artiklis ADR kohta.

Praktiline kontroll on lihtne. Küsige õhtul endalt: kui palju tube on vaba järgmisel nädalavahetusel, kui palju külalisi saabub homme, kas on broneeringuid, mille eest pole veel makstud. Kui kolme vastuse jaoks tuleb avada kolm erinevat kohta — pole Teil aruandeid, on ainult loendid, mida keegi käsitsi peab. Kui vastused on ühel ekraanil — täiustage edasi nii palju, kui tahate.

Mida ühendada hiljem — ja millal seda tõesti vaja on

RMS: tulujuhtimissüsteem

RMS (revenue management system) prognoosib nõudlust ja liigutab hindu ise: broneerimise tempo, hõivatuse, konkurentide hindade ja hooaja järgi. See on eraldi programm PMS-i peal ja maksab märgatavat raha.

9–30 toaga objektile on täielik RMS tavaliselt liiast: broneeringute ajalugu on prognoosi õppimiseks liiga vähe ja inimest, kes sellega iga päev tegeleks, pole. Alustada saab hinnareeglitest — „7 päeva enne kuupäeva, kui hõivatus on 80%, tõsta hinda 10% võrra“ — ja juba see annab tulemust. Distsipliin „vaatasin hõivatust — kohandasin hinda“ katab suurema osa sellest, mida tuluhaldus väikesele objektile tähendab. Kuidas selle samm-sammult üles ehitada — artiklis tuluhaldusest.

Turg liigub sellegipoolest hinnakujunduse automatiseerimise suunas: tuluhaldusmoodulid on PMS-i turu kõige kiiremini kasvav lõik (umbes 14% aastas Mordor Intelligence’i hinnangul) ja 65% reisijatest aktsepteerib juba, et hind liigub koos nõudlusega (valdkonna küsitlus 12 000 reisija seas 14 riigis). Dünaamiline hinnakujundus saab normiks. RMS eraldi ostuna — veel mitte.

Aeg sellest mõelda on siis, kui kokku tulevad kolm asja: vähemalt aasta broneeringute ajalugu, hooajalisus, mida hõivatuses näha on, ja inimene, kes on valmis hindu regulaarselt vaatama. Seni annavad samasuguse tõusu hinnareeglid väiksema rahaga.

Housekeeping, restoran, nutikad lukud ja CRS

Housekeeping. On seotud väljaregistreerimistega: külaline lahkus — tuba tuleb järgmiseks sisseregistreerimiseks korda. Eraldi koristusprogramm on siis, kui brigaadi juhitakse kaugelt ja vahetusgraafiku järgi. Enamikus väikehotellides teeb koristust püsiv koristaja ja eraldi programm pole vaja.

Restoran. Kui objekti juures on baar või restoran, seotakse tema kassa PMS-iga integratsiooniga: külalise tellimus jõuab toa arvele, ilma käsitsi kanneteta. Kasulik. Aga restoranitarkvara paigutamine hotelli kohustuslike programmide nimekirja, kus restorani pole — ilmne viga.

Nutikad lukud. Apartementidele on isesseregistreerimine juba standard: külaline saab isikliku koodi oma broneeringu kuupäevadeks. Kui Te sellised lukud valite, kontrollige, et nad Teie PMS-iga ühilduksid — muidu saate veel ühe akna, kuhu koode käsitsi sisestada.

CRS. CRS (central reservation system) on keskne broneerimissüsteem: ühine majutusvõimsuse ladu paljude objektide jaoks. See on ketite ja haldusfirmade tase. Väikeobjektile katab need funktsioonid ära PMS, Channel Manager ja Booking Engine.

Millal mida ei pea ostma

Kaardi teine pool: mitte iga süsteem ei ole iga objekti jaoks vajalik, ja see on normaalne.

Teie olukord	Mida saab edasi lükata	Mis katab praegu
Üks kanal, broneeringuid vähe	Channel Manager	Käsitsi ülekanne, kuni seda pole hakatud unustama
Nõudlus tuleb peaaegu kõik kanalitest	Booking Engine (üheks-kaheks kuuks)	Kanalid peamise allikana, otsekanal — plaanina
Külalised registreeruvad Teie juuresolekul, võtmed käsitsi	Guest Portal	Sisseregistreerimine vastuvõtulaual, registreerimisvorm paberil
5–10 tuba, üks töötaja	RMS, eraldi housekeeping-tarkvara	Reeglid hindades; koristusstatused uuenevad ise

Ainus, mida ei maksa edasi lükata, on tuum. Ilma temata lahendab iga järgmine ost ühe ülesande ja lisab ühe koha rohkem, kus andmed elavad.

Juurutamise järjekord: majutusvõimsus → hinnad → kanalid → veebileht

Järjekord on ostunimekirjast tähtsam. Segamini aetud järjekord on kõige levinum põhjus, miks tarkvara ostetakse ära, aga ta ei juurdu.

Majutusvõimsus. Esmalt toatüübid ja toad: ilma nendeta pole kuhugi broneeringuid panna, ja toatüüpide fotod ning kirjeldused lähevad vaja niikuinii nii kanalitele kui saidile.

Hinnad. Seejärel hinnad reeglitega: müügipiirangud, minimaalne ööbimine, tühistamistingimused. Siin otsustate ka, milliseid toatüüpe ja hindu üldse müüte. Kuidas tugiväärtused ja hinnakomplekt kokku panna — artiklis toahinna kohta.

Kanalid. Alles nüüd ühendate kanalid: toatüüpide ja hindade vastendamine, esimene väljastus, kontroll, et saadavus klapib.

Veebileht. Viimaseks Booking Engine: kui majutusvõimsus ja hinnad elavad juba süsteemis, piisab saidile vidina lisamisest.

Kalendris ei ole see kuid. Registreerimine võtab minuteid ja majutusvõimsuse, hindade ning kanalite seadistamine 1–2 päeva ühist tööd. Toe abi pole selleks kohustuslik: tee on lihtne ja seda saab ise läbi käia.

Üle kolida saab nii teisest süsteemist kui tabelist: objekti profiil, toatüübid fotode, hinnad ja kehtivad broneeringud kolivad koos Teiega. Kui objekt elab veel Excelis, kolige ära enne, kui tabel esimest korda valetab.

Kui palju see maksab

Täpseid numbreid kõigiks juhtudeks pole olemas: pilvesüsteemides sõltub tellimus objekti suurusest. Tavaliselt arvestatakse mahutavust — tubade, voodikohtade või korterite arvu, mida Te müüte. Hostel neljakümne voodikohaga ja külalistemaja kaheteistkümne toaga võivad sama hõivatuse juures maksta erinevalt.

Erineb ka see, mis hinnaga kaasas on. Üks mudel: PMS-i baashind, ja Booking Engine, Channel Manager ning Guest Portal makstakse eraldi. Teine: üks tellimus, mille sees on kõik — PMS, Booking Engine, Channel Manager ja Guest Portal. Teist on lihtsam arvestada: Te teate kohe ette, mida tarkvara maksma läheb, ja komisjonitasu broneeringutelt arvele ei lisandu.

Töölauasüsteemidel on eraldi kulutulp — juurutamine: paigaldus, seadistus, koolitus, uuendused. Pilves need read eelarvest kaovad ja alles jääb vaid Teie aeg majutusvõimsuse ja hindade seadistamiseks.

Praktiline reegel on lihtne: võtke süsteem, mille prooviperiood annab täieliku ligipääsu, mitte demorežiimi. Kahe nädalaga jõuate sisestada majutusvõimsuse, hinnad, ühendada ühe kanali ja näha, kui palju aega töö tegelikult võtab. HotelsCalendar puhul tähendab see 14 päeva täielikku ligipääsu — sel perioodil ei võeta midagi tasu.

Kuus küsimust müüjale enne ostmist

Programmide nimekiri on pool tööd. Teine pool — valida süsteem, mis Teiega aasta pärast ei lähe lahku.

1. Pilv või paigaldus? Umbes 65% PMS-i turust oli 2025. aastal pilves. Väikeobjektidele on see peaaegu alati õige vastus: uuendused tulevad ise, ligipääs töötab mis tahes seadmelt.
2. Mis on karbis ja mis on integratsioon? Täpsustage, millised kanalid ühendatakse otse, kas on olemas avatud API ja integratsioonide turg. Suletud süsteem täna tähendab käsitsi ülekannet homme.
3. Kus külaline maksab? Hotel Tech Reporti küsitluse järgi nimetab 67% hotellipidajatest sisseehitatud makseid soovitumaks funktsiooniks nr 1. Küsige, kuidas makse saidil töötab ja mis muudab broneeringu garanteerituks. Kuidas erinevad ettemakse, eelautoriseerimine ja kaart telefoni teel — artiklis veebimaksete kohta.
4. Mida süsteem teeb ise? 49% hotellipidajatest tahab PMS-ilt ennekõike automatiseerimist ja 82% hotellidest laiendab tehisintellekti kasutamist 2026. aastal (Canary Technologies). Eraldage turundus mehaanikast: automaatkiri vaucheriga on automatiseerimine, „tehisintellekt“ esitluses ei tähenda seda alati.
5. Kui pikk on start ja kes viib andmed üle? Keegi peab sisestama majutusvõimsuse, hinnad ja kehtivad broneeringud. Selguge ette: kas see on Teie töö nädalavahetusel või toe töö.
6. Kus andmed elavad? Riik, kus andmeid hoitakse, kellel on ligipääs ja mis juhtub lepingu lõppemisel.

Kokkuvõte: minimaalne komplekt

• PMS — vajalik: Planner, hinnad, külalised, kassa ja aruanded ühes aknas.
• Booking Engine — võtke kasutusele siis, kui on olemas veebileht või vähemalt objekti leht.
• Channel Manager — vajalik alates teisest kanalist, enne seda piisab käsitsi ülekandmisest.
• Guest Portal — säästab kõnesid ja pabervorme, kui külalised saabuvad ise.
• RMS, restoran, nutikad lukud — kui põhjus tekib, mitte sellepärast, et nad nimekirjas seisavad.

Korduma kippuvad küsimused

Kuidas erineb PMS Channel Managerist ja Booking Engine’ist?

Need on kolm erinevat süsteemi erinevate ülesannetega. PMS haldab objekti: broneeringud, Planner, hinnad, külalised, raha. Channel Manager sünkroonib saadavust ja hindu PMS-i ning müügikanalite vahel. Booking Engine müüb Teie veebilehel: külaline broneerib otse ja broneering jõuab samasse Plannerisse. Neid ükshaaval ostma ei pea: HotelsCalendar puhul tulevad moodulid koos PMS-iga ühes tellimuses.

Kust alustada 10–20 toaga hotelli automatiseerimisega?

Ühest arvestussüsteemist — PMS-ist —, mitte kanalitest ega saidist. Kõigepealt viige üle majutusvõimsus (toatüübid ja toad), seejärel hinnad reeglitega, seejärel ühendage kanalid — ja alles siis pange saidile broneerimisvidin. See järjekord annab süsteemile andmed, ilma milleta moodulid töötavad tühjalt.

Kas Channel Managerit on vaja, kui müüa ainult ühe või kahe kanali kaudu?

Ühe kanali ja mõõduka broneeringute hulgaga — ei: käsitsi sünkroonimine töötab. Pöördepunkt on teine kanal: sellest hetkest tuleb saadavust muuta kahes kohas ja varem või hiljem unustatakse üks neist ära. Channel Manager võtab käsitsi ülekandmise ära, aga tema kokkuhoidu ei mõõdeta tundides — vaid topeltbroneeringutes, mida ei juhtunud.

Kas väikehotelli saab Excelis pidada ja millal see lakkab töötamast?

Saab, ja paljud teevad seda. Tabel lakkab töötamast, kui broneeringud tulevad rohkem kui ühest allikast, kui andmeid kasutab teine inimene ja kui toa staatust tuleb peas hoida.

Kas broneeringud saidilt ja kanalitest jõuavad Plannerisse ise?

Jah, kui süsteemid on ühendatud. Saidi broneering jõuab Plannerisse kohe pärast makset, kanali broneering tuleb Channel Manageri kaudu — koos allika märkega. Käsitsi ei pea midagi üle kandma; käsitsi sisestatakse ainult telefonibroneeringud ja broneeringuta saabunud külalised. Topeltbroneeringud ei kao siiski päriselt — miks, on lahti seletatud Channel Manageri jaotises.

Kas süsteeme saab ühendada järk-järgult või peab kõik korraga sisse lülitama?

Järk-järgult — ja just nii on õige. Tuum (PMS) kohe, sest ilma temata ei ole ülejäänutel millega töötada. Moodulid lisanduvad vajaduse järgi: kanalid, kui neid on rohkem kui üks, veebileht, kui leht on olemas, Guest Portal, kui enne saabumist kuhjub küsimusi. Moodulid kuuluvad ühte tellimusse, seega sõltub järjekord ainult Teist; vaadake, kuidas Booking Engine on üles ehitatud.