Booking Engine: mis see on, milleks ta on vaja ja kuidas teda valida

Külaline on Teie juba välja valinud: ta on lugenud hommikusöögist, vaatanud tubade fotosid ja on maksmiseks valmis. Teie veebisaidil ootavad teda telefon, e-post ja lubadus vastata ühe tööpäeva jooksul. Edasi juhtub tavaline: inimene avab kanali, leiab Teid sealt samast nimekirjast ja broneerib kolme minutiga. Tuba on müüdud, aga komisjonitasu selle broneeringult saab keegi teine.

Booking Engine on loodud täpselt selleks hetkeks: ta muudab hotelli veebisaidi kohaks, kus broneeritakse, mitte kohaks, kus jäetakse päring. Allpool vaatame, kuidas mootor on üles ehitatud, mida ta annab 9–30 toaga objektile ja kuidas teda valida — kriteeriumidega, mida saab kontrollida enne tellimust, mitte pärast.

Mis on Booking Engine

Booking Engine on hotelli tarkvara osa, mis võtab Teie veebisaidil vastu otsebroneeringuid: külaline valib kuupäevad ja toatüübi, näeb Teie hindu, maksab kaardiga ja saab kinnituse. Vahendajateta ja kanali komisjonitasuta.

Töötab see paaris haldussüsteemiga: vidin näitab reaalajas seda, mis asub PMS-i Planneris. Muutsite hinna — saidil on uus. Müüsite toa — vabu on vähem. Külaline lõpetas broneeringu — see sattus samasse kalendrisse, kus elavad kanalite ja telefonide broneeringud. Käsitsi seda üle kanda ei tule: vastuvõtt näeb broneeringut juba nime, kuupäevade ja summaga.

Sellest järeldub lihtne mootori „pärisuse“ test. Küsige, kust ta saadavust ja hindu võtab. PMS-ist — see on müügikanal. Oma tabelist, mida keegi peab pidevalt uuendama, — see on päringute kogumise vorm, kuidas iganes seda esitluses nimetatakse.

Kas Booking Engine ja veebibroneerimissüsteem on üks ja sama?

Jah — ühe süsteemi eri nimed. „Booking Engine“ on rahvusvaheline nimi, mille all moodulit turgudel müüakse; „veebibroneerimissüsteem“ on pikem sünonüüm samadest tekstidest. Nime valik ei muuda midagi; muudab see, mis mootori kõrval seisab. Naabreid on kaks: PMS, kus elavad broneeringud, hinnad, külalised ja raha, ning Channel Manager, mis kannab Teie hinnad ja saadavuse müügikanalitesse. Süsteeme aetakse segi sagedamini kui termineid — seepärast on neile allpool eraldi osa.

Broneeringu tee: neli sammu

Külalise sammud on kõigil mootoritel sarnased.

Esmalt kuupäevad ja seltskond: kaks kuupäeva, täiskasvanud, lapsed. Seejärel toatüübid ja hinnad nendele kuupäevadele — külaline näeb Teie tegelikke hindu, mitte „alates“. Siis kaardimakse maksepakkuja lehel, kuhu kaardiandmed hotellini ei jõua. Ja lõpuks kinnitus: kiri külalisele ja broneering Planneris.

Kõik see võtab paar minutit. Võrdluseks: päring vormist on kiri, vastuse ootamine, saadavuse täpsustamine, arve, veel üks vastus. Osa külalistest langeb igal sammul välja — ja see ei ole hooletus, vaid normaalne käitumine: inimene broneerib seal, kus on lihtsam.

Kuhu mootori paigaldada — küsimus lühikese vastusega: veebisaidile. Nupp „Broneeri“ päises ja kuupäevade valikuga vidin avalehel katavad enamiku stsenaariumidest, ja ühendamine taandub tavaliselt kahele koodireale — veebisaiti ümber teha pole vaja. Ühe lehega asi siiski ei piirdu: link mootorile töötab kõikjal, kus Teie külaline viibib — sotsiaalvõrgustiku profiilis, vastuses sõnumirakenduses, e-kirja allkirjas. Ja Google’i metaotsingus: tasuta broneerimislingid näitavad Teie hinda ja viivad otse broneerimislehele, ilma klõpsutasuta.

Aeg töötab siin Teie kasuks — kui veebisait kiiresti vastab. Sektori aruande kohaselt on ettebroneerimise aeg kasvanud 38 päevalt 2023. aastal 40 päevani 2025. aastal: külaline broneerib keskmiselt nelikümmend päeva enne saabumist. Need nelikümmend päeva ta võrdleb — hindu, toatüüpe, tühistamistingimusi. Kui võrdluse hetkel on Teil pakkuda ainult telefon ja e-post, langetatakse otsus võõraste reeglite järgi.

Mida Booking Engine annab

Kuus põhjust, miks väike objekt mootori paigaldab. Alustame rahast.

1. Kanali komisjonitasu selle broneeringu eest jääb maksmata

Kanali keskmine komisjonitasu on broneeringult 15–30% ja enam, kümme aastat tagasi püsis see umbes 10% juures (sektori aruande andmed). See arvestatakse kogu summast, mille külaline maksis, ja see kasvab hindadest kiiremini: nähtavus- ja edendusprogrammid tõstavad tegeliku määra baasmäärast kõrgemale.

Lihtne arvutus objektile, mis müüb aastas 250 broneeringut ühe kanali kaudu keskmise 312-dollarise broneeringuga (sektori aruanne). 15% komisjonitasu tähendab 11 700 $ aastas — voost, mis Teil juba olemas on. Summa kasvab võrdeliselt käibega: rohkem broneeringuid — suurem komisjonitasu, ja ükski kanali hinnaplaan seda ei tühista.

Aus mööndus: otsekanal ei ole tasuta. Veebisait, liiklus ja maksete vastuvõtmine maksavad raha — HospitalityNet’i hinnangul maksab otsebroneeringu värbamine 4–5% broneeringu summast, turundusega koos 8–12%. Vahe kanali komisjonitasuga jääb umbes kahekordseks — ja see on vahe marginaalis, mitte mahus. Otsekanal ei asenda kanaleid: ta lisab veel ühe kanali, mille külalise eest Teie komisjonitasu ei maksa. Millega kanali komisjonitasu kokku tuleb ja kus ta peidus on — artiklis OTA-dest ja müügikanalitest.

2. Hinnad ja saadavus saidil ei valeta

Broneering saidilt tuleb ühest kohast — Plannerist. Seepärast ei ilmu saidile seda, mis on müügist juba väljas, ja hind kattub täpselt Teie määratuga. Eraldi tabelit „saidi jaoks“ ei eksisteeri ja seda ei saagi keegi unustada uuendada.

Sellel on teine poolgi — usaldusväärsus. Sektori aruande andmetel (üle 90 miljoni iseseisva objekti broneeringu 2025. aastal) tühistatakse kanalitest tulnud broneeringutest 21,8%, otsebroneeringutest 10,6%. Vahe on kahekordne. Mehaanika on lihtne: külaline, kes Teie saidini jõudis, valis teadlikult — mitte foto järgi pikas sarnaste kaartide nimekirjas.

3. Külaline võtab kallimalt — kui Teil on talle mida pakkuda

Sektori aruande andmetel (üle 135 miljoni broneeringu aastas, 20 turgu) toob hotelli veebisaidilt tehtud broneering keskmiselt 516 $, kanalist tehtud 312 $. Põhjus ei ole „otsemüügi“ maagias: saidil näeb külaline kõiki toatüüpe, mitte ainult neid, mille Teie kanalisse välja panite, ja kõiki lisateenuseid — hommikusööki, transfeeri, hilinenud väljaregistreerimist. Kui mootor oskab müüa lisateenuseid koos ajaga — transfeer konkreetse lennu jaoks, hommikusöök määratud tunnil —, müüakse neid toa kõrval eraldi ridadena. Paketid ja perioodisoodustused lülitatakse sisse, kui madal hooaeg tuleb täita, ja välja, kui hõivatus on niigi hea.

9–30 toaga objektil töötab see ka vastupidi: kui müüa ainult „tuba ööks“, pole kanaliga vahet. Mootor on koht, kus müüakse kogu Teie valikut — mitte ainult kõige odavamat toatüüpi.

4. Saidi konversioonimäär lakkab olemast loterii

Hotelli veebisaidi keskmine konversioonimäär on 1,5–2,5%, kombinatsioonil „sait pluss mootor“ 2–5%. Need on suurusjärgud valdkonna ülevaadetest, mitte norm: nende numbrite tagant avalikke metoodikaid ei leita. Rääkivam on teine vahe — mootorite vaheline. Triptease’i 2022. aasta võrdluses (üle 10 000 hotelli veebilehe) tõi mobiiline vidin peaaegu kõikidel pakkujatel vähem kui poole lauarvuti broneeringutest, ja parima ja halvima mootori konversioonimäär erines rohkem kui kolmekordselt. Mootorid ei ole võrdsed — seepärast on allpool ka valimise kriteeriumid.

Nüüd mobiilidest. Umbes 61% võrgus tehtud majutuse broneeringutest tuleb telefoniga (Mordor Intelligence, 2025), ja just mobiilis jäetakse broneering kõige sagedamini pooleli. Valdkonna andmetel ei jõua makseni umbes 80% algatatud broneeringutest; põhjuste seas on varjatud lisatasud viimasel sammul, hõõrdumine vormis ja ebaselged tühistamistingimused. Hea mootor näitab lõppsummat juba ette ära ega peida tühistamisreegleid viimase ekraanini.

5. Külaline ja tema andmed jäävad Teile

Broneering kanali kaudu tähendab, et külaline kuulub kanalile: tema kontakt, ajalugu ja nõusolek uudiskirjade saamiseks jäävad platvormile. Otsebroneering jätab Teile alles e-posti, telefoni, ööbimise ajaloo ja võimaluse talle hiljem uuesti kirjutada. Valdkonna andmetel on otsebroneeringud alates 2019. aastast kasvanud 55% võrra — see pole plahvatus, aga suund.

Siit tuleb praktiline küsimus, mille tasub esitada enne tellimust: kus külaliste andmed asuvad. Säilitamise riik, kellel on juurdepääs, mis juhtub lepingu lõpetamisel. Euroopa külaliste jaoks pole see formaliteet: HotelsCalendar hoiab andmeid ELis ja juurdepääs on piiritletud.

6. Vähem käsitsitööd — ja makse üllatuseta

Külaline broneerib öösel kell kaks, vastuvõtt näeb hommikul broneeringut — mitte vastamata jäänud kõnet ja sedelit „helistage tagasi“. Kinnitus saadetakse välja ise, tühistamistingimused kinnitatakse broneeringus ja summa arvutab süsteem, mitte keegi peas.

Makse käib maksepakkuja poolel: hotell ei puuduta kaardiandmeid ega vastuta nende hoidmise eest. Rahakotid — Apple Pay, Google Pay — võtavad kaardi sisestamise ära seal, kus konversioonimäär on niigi kõige madalam: telefonis. Stripe’i andmetel muude valdkondade ostudes lisas Apple Pay konversioonimäärale +22,3%: need on kogu turu, mitte hotelli näitajad, aga suunda näitavad õigesti. Millistest makseviisidest külaline kasutada saab, millega eelautoriseerimine ettemaksest erineb ja kuidas maksevaidlust vältida — artiklis veebimaksete kohta.

Kuidas Booking Engine erineb PMS-ist ja Channel Managerist

Kolm süsteemi vastavad kolmele erinevale küsimusele ja nende segiajamine maksab kallilt.

Süsteem	Küsimus, millele vastab	Kes seda näeb
PMS	kus elavad broneeringud, hinnad, külalised ja raha	Teie töötajad
Booking Engine	kuidas külaline Teie saidil broneerib	külaline
Channel Manager	kuidas Teie hinnad ja saadavus kanalitesse jõuavad	kanali külaline

PMS on tuum: Planner, hinnad, külaliste profiilid, kassa. Ilma selleta pole teistel moodulitel millega töötada. Channel Manager kannab hinnad ja saadavuse Booking.com-i, Airbnbisse ja kümnetesse teistesse kanalitesse ning toob sealt broneeringud tagasi — arenenud süsteemides on see eraldi moodul oma edastuslogiga.

Praktiline järeldus. Kanalite sünkroonimist teeb Channel Manager, mitte Booking Engine: mootor vastutab otsebroneeringute, haldur kanalite eest. Kui mootori kirjelduses lubatakse „sünkroonimine Booking.com-iga ja Airbnbiga“, küsige järele, millega täpselt see tagatud on — nii saate süsteemist teada rohkem kui ühestki esitlusest.

Ja teine järeldus — ost. Neid mooduleid müüakse nii eraldi kui ka ühe tellimusena; teine mudel on arvepidamises lihtsam. HotelsCalendar puhul lähevad PMS, Booking Engine, Channel Manager ja Guest Portal ühe tellimuse sees — komisjonitasu broneeringutelt ja tasu moodulite eest arvel puuduvad.

Kuidas valida Booking Engine’i: neli kriteeriumi

9–30 toaga objektil on valik lihtsam kui ketil: vähem integratsioone ja formaalseid nõudeid. Aga just siin on kõige lihtsam eksida — seepärast tasub alljärgnevad kriteeriumid ise läbi kontrollida, mitte esitluse põhjal.

Kriteerium 1. Mobiilne, mitte „responsiivne“

Enamik majutuse broneeringutest tehakse telefoniga ja telefon konverteerib halvemini. Selline on turg, sellega vaielda pole mõtet. Avage mootor oma nutitelefonis ja minge külalise tee lõpuni: mitu ekraani kuupäevadest makseni, kas kaart tuleb sõrmedega sisestada, kas lõppsumma on loetav. Kiirus ei ole kosmeetika: 2020. aasta Deloitte’i ja Google’i uuringus andis 0,1 sekundit kiirem laadimine reisilehtedel +10,1% konversioonimäärale. Andmed on aegunud, aga suund pole sellest ajast saati muutunud.

Sama käik — analüütikaga. Kui mootor elab lehel eraldi iframe’is, kaob osa külalise sammudest statistikast: analüütika ei näe, mis seal sees toimub. Küsige, kuidas mootor täpselt ühendatakse ja millised tema sündmused Teie analüütikasse jõuavad. Muidu teate poole aasta pärast, et broneeringud on olemas, aga ei tea, kust nad tulevad.

Ja viimane mobiilitest — pooleli jäetud broneering. Alustage broneerimist ja sulgege leht poolel teel, enne makset. Kui külalise kontakt salvestub juba esimesel sammul, saab hotell sellele inimesele veel kirjutada; valdkonna andmetel konverteerivad sellised kirjad hotellides kordades paremini kui tavalised uudiskirjad. Kui kontakt ilmub alles koos maksega, kaob broneering koos külalisega — ja see on samuti mootori valiku küsimus.

Kriteerium 2. Teie bränd, Teie keeled

Vidin on saidi osa ja külaline ei tohiks üleminekut märgata: värvid, font, logo, tekstide toon. Kontrollige, kas kujundust saab muuta ilma arendajata: nupuvärvi muutmine toe poole pöördumisega ei ole kohandamine, vaid kirjavahetus.

Teiseks — keeled, millega Teie külalised tegelikult räägivad, ja valuutad, milles hindu vaadatakse. Rahvusvaheline külaline tahab teada, kui palju see tema rahas maksab — kuigi tasumine läheb ikkagi hotelli valuutas.

Kriteerium 3. Ühendus PMS-i ja Channel Manageriga

Küsimus on üks: kust mootor võtab saadavuse ja hinnad. Haldussüsteemist — broneering on kohe kalendris ja teist tabelit ei teki. Omast andmebaasist — Teil on juurde tekkinud veel üks nimekiri, mida tuleb käsitsi sünkroonida.

Kontrollige kolme asja: kui kiiresti broneering Plannerisse jõuab, mis juhtub külalise tühistamisel ja kuidas saadavus käitub, kui tuba on kanalis müüdud. Viimane kuulub Channel Managerile, aga küsige seda kohe: need kaks süsteemi töötavad paaris ja nende ost erinevatelt pakkujatelt on eraldi lugu eraldi integratsiooniga.

Õige ühenduse märke näeb esimesest päevast. Kui see on olemas, muudate hinna ja näete minuti pärast saidil uut, ning saidi broneeringut ei pea kalendrisse üle kandma. Kui pole, kordab keegi pärast iga parandust selle teises aknas käsitsi — ja varem või hiljem valetab kumbki koht.

Kui objekte on mitu — teine apartemendihotell või väike kett —, pikeneb küsimuste nimekiri ühe võrra: kuidas mootor mitme objektiga töötab. Küsige enne tellimust, kas kõik objektid elavad ühes kontos või läheb igale oma tellimus — muidu teate seda alles esimesest arvest.

Kriteerium 4. Turvalisus: neli küsimust lubaduste asemel

Esimene — HTTPS kõigil mootori lehtedel, maksesamm kaasa arvatud. Liikluse krüptimine on täna hügieeniline miinimum, mitte eelis; kui vähemalt üks leht avaneb ilma selleta, on jutt läbi.

Teine — PCI DSS, maksekaartide andmete turvalisuse standard. Väike hotell ei pea ja ei saagi teda enda õlgadele võtma. Kui makse käib maksepakkuja lehel — eraldi aknas või iframe’is —, lasub suurem osa nõuetest pakkuja õlgadel; hotellile jääb kõige kergem enesehindamise vorm, SAQ A. Alates 31. märtsist 2025 on standard makselehtede suhtes rangem: kohustuslikud on nõuded 6.4.3 ja 11.6.1 — skriptide kontroll ja lehe terviklikkus —, ja just need võtab maksepakkuja poolel tehtav makse Teie õlgadelt. Praktiline järeldus: küsige maksepakkuja sertifikaati, mitte loosungit „me oleme turvalised“.

Kolmas — makse kinnitus. Euroopas kehtib tugeva kliendi autentimise (SCA) nõue: pank kinnitab makse teise teguriga, külalise jaoks näeb see välja täiendava 3-D Secure’i sammuna. ELi maksevaldkonna reegleid uuendatakse praegu (PSD3 ja PSR; Nõukogu ja Parlamendi esialgne kokkulepe 2025. aasta lõpus), seepärast pole tähtis lühend esitluses, vaid vastus küsimusele, kuidas kinnitus täpselt käib ja mida külaline näeb.

Neljas — külaliste andmed: säilitamise riik, juurdepääs, kord lepingu lõpetamisel. Sama küsimus nagu viiendas hüves, ja esitada tuleb seda enne tellimust, mitte siis, kui külaline esimest korda küsib.

Kontrollnimekiri: kümme küsimust enne ühendamist

Nimekiri kirjaks pakkujale — või enda kontrollimiseks:

1. Kust mootor võtab saadavuse ja hinnad — PMS-ist või omast tabelist?
2. Kui kiiresti jõuab broneering Plannerisse ja milliste väljadega?
3. Mitu ekraani on kuupäevadest makseni — telefonis, mitte monitoril?
4. Mis jõuab Teie analüütikasse: külalise sammud, broneeringute allikad, pooleli jäetud broneeringud?
5. Kuidas mootor saidiga ühendatakse: skriptiga lehele või eraldi aknaga?
6. Milliseid keeli ja valuutasid külaline näeb ja kuidas need sisse lülitatakse?
7. Kui kaugele kujundus Teie brändile kohandub — ja ilma toe poole pöördumiseta?
8. Kes on maksepakkuja, kellel on PCI DSS sertifikaat, kuidas makse kinnitamine käib?
9. Kus külaliste andmeid säilitatakse ja kellel on juurdepääs?
10. Kuidas hind arvutatakse: tellimus, protsent broneeringult või mõlemad?

Ja küsimus, mis kõige sagedamini ununeb: kas mootor oskab hindu Google’i metaotsingusse anda. Google’i tasuta broneerimislingid näitavad Teie hinda ja viivad Teie broneerimislehele ilma klõpsutasuta. Mootor, mis seda ei oska, annab need näitamised kanalitele — koos komisjonitasuga.

Mida Booking Engine ei tee

Piire on kasulik tunda enne ostu, mitte pärast esimest pettumist.

Mootor ei loo nõudlust. See on koht, kus ostetakse, mitte reklaam. Ilma liikluseta — otsing, sotsiaalmeedia, metaotsing, kanalid — jääb vidin tühjaks ja see ei ole mootori süü. 2025. aasta sektori aruande järgi tõid kanalid iseseisvatele objektidele 63,4% broneeringutest: otsekanalit ehitatakse nende kõrvale, mitte nende asemele.

Mootor ei sünkrooni kanaleid. See on Channel Manageri ülesanne: tuba müüdi kanalis — saadavust saidil vähendab tema, mitte vidin.

Mootor ei halda hindu. Hinnad elavad hinnaplaanides, mitte kalendris: Planneris on broneeringud; hinnad koos tühistamisreeglite ja müügipiirangutega on eraldi seadistus. Mootor näitab täpselt seda, mida Teie seadistanud olete, ilma oma aritmeetikata. Kuidas selliseid plaane kokku panna — artiklis toa hinna kohta.

Mootor ei asenda veebisaiti. Külaline, kes satub otselingiga kirjast otse kolmele broneerimisekraanile, tuleb saidile niikuinii tagasi — fotode, kirjelduse ja reeglite pärast. Tühjad lehed vidinaga esireas konversioonimäära ei tõsta.

Kokkuvõte

• Booking Engine on müügikanal Teie veebisaidil: külaline broneerib ise, broneering jõuab ühisesse Plannerisse ja kiri läheb välja ilma Teie sekkumiseta.
• Kasum ei ole „tasuta broneeringud“, vaid marginaal ja andmed: kanali komisjonitasu selle broneeringu eest Teie ei maksa ja külalise kontakt jääb Teile.
• Ühendus PMS-iga on peamine kriteerium: ilma selleta kogub mootor päringuid, mitte broneeringuid.
• Valikut kontrollitakse telefoniga ja küsimustega: külalise mobiilitee, Teie bränd ja keeled, integratsioon, turvalisus ja andmete asukoht.

Kui Te panete objektile süsteemide komplekti kokku ja ei ole veel otsustanud, mida esimesena võtta, alustage artiklist väikese hotelli tarkvarast: seal on juttu juurutamise järjekorrast ja sellest, milleta saab alustada.

Kuidas Booking Engine HotelsCalendar tootes töötab, saab vaadata Booking Engine’i lehelt: ühendamine kahe koodireaga, kaardimakse Stripe’i kaudu koos eelautoriseerimisega, ajakavaga lisateenused ja lojaalsusprogramm — kõik ühes tellimuses koos PMS-i ja Channel Manageriga.

Korduma kippuvad küsimused

Kas Booking Engine ja veebibroneerimissüsteem on üks ja sama?

Jah. Rahvusvahelisel turul kannab moodul nime booking engine, eestikeelsetes tekstides öeldakse sageli ka „veebibroneerimissüsteem“ — kõik need on üks ja sama otsemüügisüsteem hotelli veebisaidil. Vahe ilmneb alles naabrite kõrval: PMS haldab objekti, Channel Manager sünkroonib kanaleid, Booking Engine võtab saidil vastu otsebroneeringuid. Kuidas mootor HotelsCalendar tootes töötab — Booking Engine’i lehel.

Kas Booking Engine’it on vaja, kui hotell müüb juba Booking.com-is ja Airbnbis?

On — mitte kanalite asemel, vaid nende kõrval. 2025. aasta sektori aruande järgi tõid kanalid iseseisvatele objektidele 63,4% broneeringutest: sellisest voost pole põhjust loobuda. Tasub arvutada, kui palju iga kanal maksab: komisjonitasu, tühistused, keskmine broneeringu summa. Kanalid annavad nõudluse mahu, mida objekt ise kokku ei vea; otsekanal annab marginaali ja külaliste andmed. Kuidas kanaleid arvutatakse ja millest nende komisjonitasu koosneb — artiklis OTA-dest.

Kuidas Booking Engine erineb PMS-ist ja Channel Managerist?

Need on kolm erinevat süsteemi. PMS haldab objekti: Planner, hinnad, külalised, kassa. Channel Manager kannab hinnad ja saadavuse kanalitesse ning toob broneeringud tagasi. Booking Engine võtab saidil vastu otsebroneeringuid. Eraldi ostma ei pea: HotelsCalendar pakub kõiki mooduleid ühe tellimusena koos PMS-iga.

Mis peab mootoris kindlasti olema 9–30 toaga hotelli jaoks?

Miinimum on neli asja: ühendus PMS-iga (muidu on see päringute vorm, mitte broneeringute süsteem), kaardimakse koos kinnitusega, külalise teekonna mobiiliversioon ja keeled, millega Teie külalised räägivad. Kõige muu järele vastavalt vajadusele: lisateenused, lojaalsusprogramm, aruanne broneeringute allikate kohta. Täielik juurutamise järjekord — artiklis väikse hotelli tarkvarast.

Kas on turvaline võtta makseid Booking Engine’i kaudu vastu?

Jah, kui makse käib maksepakkuja poolel: kaardiandmed sisestatakse tema lehel ja hotell ei hoia neid enda juures. Jälgige kolme asja: HTTPS kõigil mootori lehtedel, PCI DSS sertifikaat pakkujal (sellise skeemi puhul jääb hotellile kõige kergem enesehindamise vorm, SAQ A) ning makse kinnitamine teise teguriga — 3-D Secure, mida Euroopas nõuab tugev kliendi autentimine. Lubadus „me oleme turvalised“ esitluses ei asenda mitte ühtegi neist kolmest punktist.

Miks ühed mootorid müüakse tellimusena ja teised küsivad broneeringult protsenti?

Turg elab mõlema mudeliga. Protsent broneeringult nihutab riski pakkujale: pole broneeringuid — pole tasu, aga iga broneering muutub käibe kasvades kallimaks. Tellimus on arvepidamises etteaimatav ega kasva hõivatusega kaasa, kuid eeldab, et mootor toob broneeringuid ka tegelikult. Mida küsida mõlemal puhul: mis kuulub hinda ja kas moodulite eest ei teki eraldi tasu. HotelsCalendar arvel on ainult tellimus — komisjonitasu broneeringutelt ja tasu moodulite eest puuduvad; tellimuse sisu on mootori lehel.