Booking Engine: kas tai, kam reikia ir kaip pasirinkti

Svečias jau pasirinko jus: perskaitė apie pusryčius, peržiūrėjo numerių nuotraukas ir pasirengęs mokėti. Jūsų svetainėje jo laukia telefonas, el. paštas ir pažadas atsakyti per darbo dieną. Toliau vyksta įprasta: žmogus atsidaro kanalą, randa jus tame pačiame sąraše ir rezervuoja per tris minutes. Numeris parduotas, o komisiniai nuo šios rezervacijos atiteks ne jums.

Booking Engine – rezervacijų sistema, sukurta būtent šiai akimirkai: ji paverčia viešbučio svetainę vieta, kurioje rezervuojama, o ne paliekama užklausa. Panagrinėsime, kaip modulis veikia, ką jis duoda 9–30 numerių objektui ir pagal kokius kriterijus jį rinktis – tokius, kuriuos galima patikrinti iki prenumeratos, o ne po jos.

Kas yra Booking Engine

Booking Engine – viešbučio programinės įrangos dalis, priimanti tiesiogines rezervacijas jūsų svetainėje: svečias pasirenka datas ir numerio tipą, mato jūsų kainas, sumoka kortele ir gauna patvirtinimą. Be tarpininkų ir be kanalo komisinio.

Visa tai veikia poroje su objekto valdymo sistema (PMS): valdiklis realiuoju laiku rodo tai, kas guli PMS Planner kalendoriuje. Pakeitėte kainą – svetainėje nauja. Pardavėte numerį – laisvų mažiau. Svečias pabaigė rezervaciją – ji atsidūrė tame pačiame kalendoriuje, kuriame gyvena kanalų ir skambučių rezervacijos. Rankomis jos perkelti nereikia: recepcija mato rezervaciją jau su vardu, datomis ir suma.

Iš to seka paprastas modulio „tikrumo“ testas. Paklauskite, iš kur jis ima prieinamumą ir kainas. Iš PMS – tai pardavimų kanalas. Iš atskiros lentelės, kurią kas nors privalo nuolat atnaujinti, – tai užklausų rinkimo forma, kaip ji besivadintų pristatyme.

Booking Engine ir internetinė rezervavimo sistema – ar tai tas pat?

Taip – vienos sistemos pavadinimai. „Booking Engine“ – vardas, kuriuo modulis parduodamas tarptautinėje rinkoje; „internetinė rezervavimo sistema“ – išsamesnis sinonimas iš tų pačių tekstų. Žodžio pasirinkimas nieko nekeičia; keičia tai, kas stovi šalia. Modulis turi du kaimynus: PMS, kuriame gyvena rezervacijos, kainos, svečiai ir pinigai, bei Kanalų tvarkyklę (Channel Manager), kuri išnešioja jūsų kainas ir prieinamumą pardavimų kanalais. Šias sistemas maišo dažniau nei pačius terminus – todėl žemiau joms skirtas atskiras skyrius.

Rezervacijos kelias: keturi žingsniai

Svečio žingsniai visuose moduliuose panašūs.

Pirmiausia datos ir sudėtis: dvi datos, suaugę, vaikai. Toliau numerių tipai ir kainos tomis datomis – svečias mato jūsų realias kainas, o ne „nuo“. Po to mokėjimas kortele mokėjimų paslaugų teikėjo puslapyje – kortelės duomenys iki paties viešbučio nepatenka. Ir paskutinis žingsnis – patvirtinimas: laiškas svečiui ir rezervacija Planner.

Tai užima porą minučių. Palyginimui: užklausa iš formos – tai laiškas, laukimas atsakymo, prieinamumo tikslinimas, sąskaita, dar vienas atsakymas. Dalis svečių atkrenta kiekviename žingsnyje, ir tai ne neatidumas, o normalus elgesys: žmogus rezervuoja ten, kur paprasčiau.

Kur įdiegti modulį – klausimas su trumpu atsakymu: į svetainę. Mygtukas „Rezervuoti“ antraštėje ir valdiklis su datų pasirinkimu pagrindiniame puslapyje apima daugumą scenarijų, o prijungimas dažniausiai susiveda į dvi kodo eilutes – svetainės perdarinėti nereikia. Bet vienu puslapiu reikalas nesibaigia: nuoroda į modulį veikia visur, kur yra jūsų svečias – socialinio tinklo profilyje, atsakyme žinute, el. laiško paraše. Ir Google metapaieškoje: nemokamos rezervacijų nuorodos rodo jūsų kainą ir veda tiesiai į rezervacijos puslapį, be mokėjimo už paspaudimą.

Laikas čia dirba jūsų naudai – jei svetainė atsako. Pagal sektoriaus ataskaitą rezervacijos langas išaugo nuo 38 dienų 2023 m. iki 40 dienų 2025 m.: svečias rezervuoja vidutiniškai keturiasdešimt dienų iki atvykimo. Per tas keturiasdešimt dienų jis lygina – kainas, numerių tipus, atšaukimo sąlygas. Jei lyginimo akimirką jūs siūlote tik telefoną ir el. paštą, sprendimas priimamas pagal svetimas taisykles.

Ką duoda Booking Engine

Šešios priežastys, kodėl mažas viešbutis jį įdiegia. Pradėsime nuo pinigų.

1. Kanalo komisinio už šią rezervaciją nemokate

Vidutinis kanalo komisinis mokestis – 15–30 % ir daugiau nuo rezervacijos, o prieš dešimt metų jis laikėsi apie 10 % (sektoriaus ataskaitos duomenys). Jis skaičiuojamas nuo visos sumos, kurią sumokėjo svečias, ir auga greičiau nei kainos: matomumo ir reklamos programos pakelia realų komisinį aukščiau bazinio.

Paprastas skaičiavimas objektui, kuris per metus parduoda 250 rezervacijų kanale su vidutine rezervacijos suma 312 $ (sektoriaus ataskaita). Esant 15 % komisiniui tai 11 700 $ per metus – iš srauto, kuris ir taip yra. Suma auga proporcingai apyvartai: daugiau rezervacijų – didesnis komisinis, ir joks kanalo kainų planas jo neatšaukia.

Sąžininga pastaba: tiesioginis kanalas nėra nemokamas. Svetainė, srautas ir mokėjimų priėmimas kainuoja – pagal HospitalityNet vertinimą tiesioginės rezervacijos pritraukimas kainuoja 4–5 % rezervacijos sumos, o su rinkodara – 8–12 %. Skirtumas su kanalo komisiniu lieka dvigubas, ir tai skirtumas maržoje, o ne apimtyse. Tiesioginis kanalas nepakeičia kanalų – jis prideda kanalą, už kurio atvestą svečią nemokate jūs. Iš ko susideda komisinis ir kur jis slepiasi – straipsnyje apie OTA ir pardavimų kanalus.

2. Kainos ir prieinamumas svetainėje nemeluoja

Rezervacija iš svetainės eina iš vienos vietos – iš Planner. Todėl svetainėje nepasirodo tai, ko jau nėra pardavime, o kaina sutampa su jūsų nustatyta. Atskiros lentelės „svetainei“ neegzistuoja, ir nėra ko pamiršti atnaujinti.

Tai turi ir antrą pusę – patikimumą. Pagal sektoriaus ataskaitos duomenis (daugiau nei 90 mln. nepriklausomų objektų rezervacijų 2025 m.) atšaukiama 21,8 % rezervacijų, atėjusių iš kanalų, prieš 10,6 % tiesioginių. Skirtumas dvigubas. Mechanika paprasta: svečias, kuris pasiekė jūsų svetainę, rinkosi sąmoningai, o ne pagal nuotrauką ilgame panašių kortelių sąraše.

3. Svečias ima brangiau – jei turite ką pasiūlyti

Pagal sektoriaus ataskaitos duomenis (daugiau nei 135 mln. rezervacijų per metus, 20 rinkų) rezervacija iš viešbučio svetainės vidutiniškai atneša 516 $, rezervacija iš kanalo – 312 $. Priežastis ne „tiesioginių pardavimų“ magijoje: svetainėje svečias mato visus numerių tipus, o ne tuos, kuriuos išstatėte kanale, ir visas papildomas paslaugas – pusryčius, pervežimą, vėlyvą išsiregistravimą. Jei modulis moka parduoti paslaugas su laiku – pervežimą prie konkretaus skrydžio, pusryčius nustatytą valandą – jos eina atskiromis eilutėmis šalia numerio. Paketai ir laikotarpio nuolaidos įjungiami, kai reikia užpildyti žemąjį sezoną, ir išjungiami, kai užimtumas ir taip geras.

9–30 numerių objektui tai veikia ir atvirkščiai: jei parduodate tik „numerį už naktį“, skirtumo su kanalu nebus. Modulis – vieta, kur parduodamas visas jūsų asortimentas, o ne tik pigiausia kategorija.

4. Svetainės konversija nustoja būti loterija

Vidutinė viešbučio svetainės konversija – 1,5–2,5 %, poros „svetainė plus modulis“ – 2–5 %. Tai dydžių tvarka iš srities apžvalgų, o ne norma: viešų metodikų už šių skaičių nėra. Iškalbingesnis kitas skirtumas – tarp pačių sistemų. Pagal 2022 m. Triptease duomenis (daugiau nei 10 000 viešbučių svetainių) mobilusis valdiklis beveik visiems tiekėjams atnešdavo mažiau nei pusę rezervacijų, palyginti su kompiuteriu, o geriausios ir blogiausios sistemos konversija skyrėsi daugiau nei tris kartus. Ne kiekviena sistema yra lygi – todėl žemiau ir pateikiami pasirinkimo kriterijai.

Dabar apie telefonus. Maždaug 61 % internetinių būsto rezervacijų tenka telefonui (Mordor Intelligence, 2025 m.), ir būtent telefone svečiai dažniausiai meta rezervaciją. Pagal srities duomenis apmokėjimo nepasiekia maždaug 80 % pradėtų rezervacijų; tarp priežasčių – paslėpti priedai paskutiniame žingsnyje, trintis formoje ir neaiškios atšaukimo sąlygos. Geras modulis galutinę sumą rodo iš anksto ir neslepia atšaukimo taisyklių iki pat paskutinio ekrano.

5. Svečias ir jo duomenys lieka pas jus

Rezervacija per kanalą reiškia, kad svečias priklauso kanalui: jo kontaktai, istorija ir sutikimas gauti naujienlaiškius lieka platformoje. Tiesioginė rezervacija jums palieka el. paštą ir telefoną, apsistojimo istoriją ir pagrindą parašyti dar kartą. Pagal srities duomenis tiesioginės rezervacijos nuo 2019 m. išaugo 55 % – ne sprogimas, bet kryptis.

Iš čia praktinis klausimas, kurį verta užduoti iki prenumeratos: kur gulės svečių duomenys. Saugojimo šalis, kas turi prieigą, kas vyksta nutraukus sutartį. Europos svečiams tai ne formalumas: HotelsCalendar duomenis saugo ES, o prieiga yra apibrėžta ir apribota.

6. Mažiau rankinio darbo – ir apmokėjimas be staigmenų

Svečias rezervuoja antrą valandą nakties, o recepcija ryte mato rezervaciją – ne praleistą skambutį ir raštelį „perskambinkite“. Patvirtinimas išsiunčiamas pats, atšaukimo sąlygos įrašomos į rezervaciją, o sumą skaičiuoja sistema, ne galva.

Apmokėjimas vyksta mokėjimų paslaugų teikėjo pusėje: viešbutis nepaliečia kortelės duomenų ir neatsako už jų saugojimą. Skaitmeninės piniginės – Apple Pay, Google Pay – pašalina kortelės vedimą ten, kur konversija ir taip žemiausia, telefone. Pagal Stripe duomenis iš kitų sričių atsiskaitymų Apple Pay pridėdavo +22,3 % prie konversijos: tai visos rinkos, o ne viešbučių atvejis, bet kryptį rodo teisingai. Kokius mokėjimo būdus priima svečiai, kuo lėšų sulaikymas kortelėje skiriasi nuo išankstinio apmokėjimo ir kaip nepatekti į ginčą dėl mokėjimo – straipsnyje apie internetinius mokėjimus.

Kuo Booking Engine skiriasi nuo PMS ir Kanalų tvarkyklės

Trys sistemos atsako į tris skirtingus klausimus, o jų supainiojimas brangiai kainuoja.

Sistema	Į kokį klausimą atsako	Kas ją mato
PMS	kur gyvena rezervacijos, kainos, svečiai ir pinigai	jūsų darbuotojai
Booking Engine	kaip svečias rezervuoja jūsų svetainėje	svečias
Kanalų tvarkyklė	kaip jūsų kainos ir prieinamumas patenka į kanalus	kanalo svečias

PMS – branduolys: Planner, kainos, svečių profiliai, kasa. Be jo moduliams nėra su kuo dirbti. Kanalų tvarkyklė perduoda kainas ir prieinamumą į Booking.com, Airbnb ir dešimtis kitų kanalų bei grąžina iš ten rezervacijas – subrendusiose sistemose tai atskiras modulis su savo siuntimų žurnalu.

Praktinė išvada. Sinchronizavimą su kanalais atlieka Kanalų tvarkyklė, o ne Booking Engine: modulis – apie tiesiogines rezervacijas, tvarkyklė – apie kanalus. Jei sistemos aprašyme žadama „sinchronizacija su Booking.com ir Airbnb“, pasitikslinkite, kuo ji užtikrinama – taip apie sistemą sužinosite daugiau nei iš bet kokios prezentacijos.

Ir antroji išvada – pirkimas. Šie moduliai parduodami ir atskirai, ir viena prenumerata; antrasis modelis paprastesnis apskaitoje. HotelsCalendar PMS, Booking Engine, Kanalų tvarkyklė ir Guest Portal eina vienoje prenumeratoje – komisinių nuo rezervacijų ir mokesčių už modulius sąskaitoje nėra.

Kaip pasirinkti Booking Engine: keturi kriterijai

9–30 numerių objektas renkasi paprasčiau nei tinklas: mažiau integracijų ir formalų reikalavimų. Bet čia lengviausia ir suklysti – todėl žemiau esančius kriterijus verta tikrinti rankomis, o ne pagal prezentaciją.

Kriterijus 1. Mobilus, o ne „pritaikomas“

Dauguma būsto rezervacijų vyksta telefone, o telefonas konvertuoja prasčiau. Tokia rinka, su ja ginčytis beprasmiška. Atsidarykite modulį savo išmaniajame telefone ir nueikite svečio kelią iki galo: kiek ekranų nuo datų iki apmokėjimo, ar kortelė renkama pirštais, ar skaitoma galutinė suma. Greitis – ne kosmetika: pagal 2020 m. Deloitte ir Google tyrimą 0,1 sekundės greitesnis įkėlimas keliaudavo +10,1 % konversijų kelionių svetainėse. Duomenys senoki, bet kryptis nuo tada nesikeitė.

Tas pats ėjimas – su analitika. Jei modulis gyvena puslapyje atskirame iframe lange, dalis svečio žingsnių statistikoje pranyksta: analitikos sistema nemato, kas vyksta viduje. Paklauskite, kaip tiksliai modulis prijungiamas ir kas iš jo įvykių patenka į jūsų analitiką. Kitu atveju po pusės metų žinosite, kad rezervacijų yra, bet nežinosite, iš kur jos.

Ir paskutinis mobilusis testas – nebaigta rezervacija. Pradėkite rezervuoti ir uždarykite puslapį pusiaukelėje, iki apmokėjimo. Jei svečio kontaktas išsaugomas jau pirmame žingsnyje, viešbutis dar gali grįžti prie šio žmogaus laišku; pagal srities duomenis tokie laiškai viešbučiuose konvertuoja dešimt kartų geriau nei įprasti naujienlaiškiai. Jei kontaktas atsiranda tik kartu su apmokėjimu, rezervacija prapuolė kartu su svečiu – ir tai irgi klausimas modulio pasirinkimui.

Kriterijus 2. Jūsų prekės ženklas, jūsų kalbos

Valdiklis – svetainės dalis, ir svečias neturi pastebėti perėjimo: spalvos, šriftas, logotipas, tekstų tonas. Tikrinkite, ar apipavidalinimas keičiamas be programuotojo: mygtuko spalvos keitimas per kreipimąsi į pagalbą – tai ne pritaikymas, o susirašinėjimas.

Antra – kalbos, kuriomis iš tikrųjų kalba jūsų svečiai, ir valiutos kainų peržiūrai. Tarptautiniam svečiui reikia suprasti, kiek tai kainuoja jo pinigais, nors nuskaitymas vis tiek eis viešbučio valiuta.

Kriterijus 3. Ryšys su PMS ir Kanalų tvarkykle

Klausimas vienas: iš kur modulis ima prieinamumą ir kainas. Iš valdymo sistemos – rezervacija iš karto kalendoriuje ir antros lentelės neatsiranda. Iš savos bazės – vadinasi, atsirado dar vienas sąrašas, kurį reikia sinchronizuoti rankomis.

Tikrinami trys dalykai: kaip greitai rezervacija atsiduria Planner, kas vyksta svečiui atšaukus ir kaip elgiasi prieinamumas, kai numeris parduotas kanale. Paskutinysis – klausimas Kanalų tvarkyklei, bet klausti verta iš karto: šios dvi sistemos dirba poroje, ir pirkti jas iš skirtingų tiekėjų – atskira istorija su atskira integracija.

Ryšio ženklus matyti nuo pirmos dienos. Yra ryšys – pakeičiate kainą ir po minutės matote naują svetainėje, o rezervacijos iš svetainės nereikia perkelti į kalendorių. Nėra ryšio – po kiekvieno pakeitimo kas nors rankomis jį pakartoja antrame lange, ir anksčiau ar vėliau viena iš dviejų vietų sumeluos.

Jei objektų turite kelis – antrasis apartamentų viešbutis, mažas tinklas, – klausimų sąrašas pailgėja vienu punktu: kaip sistema dirba su keliais objektais. Pasitikslinkite iki prenumeratos, ar visi objektai gyvena vienoje paskyroje, ar kiekvienam reikia atskiros prenumeratos – kitaip sužinosite tai iš pirmosios sąskaitos.

Kriterijus 4. Saugumas: keturi klausimai vietoj pažadų

Pirmas – HTTPS visuose modulio puslapiuose, įskaitant mokėjimo etapą. Srauto šifravimas šiandien higienos minimumas, o ne pranašumas; jei bent vienas puslapis atsidaro be jo, pokalbis baigtas.

Antras – PCI DSS, mokėjimo kortelių duomenų saugos standartas. Mažam viešbučiui jo savo pečiais vilkti nereikia ir neįmanoma. Jei apmokėjimas vyksta paslaugų teikėjo puslapyje – atskirame lange arba iframe, – pagrindinė reikalavimų dalis gula ant jo; viešbučiui tai lengviausia savęs įvertinimo forma, SAQ A. Nuo 2025 m. kovo 31 d. standartas mokėjimo puslapiams tapo griežtesnis: privalomi reikalavimai 6.4.3 ir 11.6.1 – scenarijų ir puslapio vientisumo kontrolė, – ir būtent juos nuima apmokėjimas paslaugų teikėjo pusėje. Praktinė išvada: klauskite mokėjimų paslaugų teikėjo sertifikato, o ne lozungo „mes saugūs“.

Trečias – mokėjimo patvirtinimas. Europoje galioja stipraus kliento autentifikavimo (SCA) reikalavimas: bankas patvirtina mokėjimą antruoju faktoriumi, svečiui tai atrodo kaip papildomas 3-D Secure žingsnis. ES mokėjimų taisyklės dabar peržiūrimos – PSD3 ir PSR, Tarybos ir Parlamento pirminis susitarimas 2025 m. pabaigoje, – todėl svarbiau ne santrumpa prezentacijoje, o atsakymas, kaip tiksliai vyksta patvirtinimas ir ką mato svečias.

Ketvirtas – svečių duomenys: saugojimo šalis, prieiga, tvarka nutraukus sutartį. Tas pats klausimas kaip penktajame pranašume, ir užduoti jį reikia iki prenumeratos, o ne sulaukus pirmojo svečio klausimo.

Kontrolinis sąrašas: dešimt klausimų prieš prijungimą

Sąrašas laiškui tiekėjui – arba savikontrolei:

1. Iš kur modulis ima prieinamumą ir kainas – iš PMS ar iš savo lentelės?
2. Kaip greitai rezervacija atsiduria Planner ir su kuriais laukais?
3. Kiek ekranų nuo datų pasirinkimo iki apmokėjimo – telefone, ne monitoriuje?
4. Kas patenka į jūsų analitiką: svečio žingsniai, rezervacijų šaltiniai, nebaigtos rezervacijos?
5. Kokiu būdu modulis prijungiamas prie svetainės: scenarijumi į puslapį ar atskiru langu?
6. Kokias kalbas ir valiutas mato svečias ir kaip jos įjungiamos?
7. Kiek giliai apipavidalinimas prisitaiko prie jūsų prekės ženklo – ir be kreipimosi į pagalbą?
8. Kas yra mokėjimų paslaugų teikėjas, kas turi PCI DSS sertifikatą, kaip vyksta mokėjimo patvirtinimas?
9. Kur saugomi svečių duomenys ir kas turi prieigą prie jų?
10. Kaip skaičiuojama kaina: prenumerata, procentas nuo rezervacijos ar abu?

Ir klausimas, apie kurį dažniausiai pamirštama: ar modulis moka pateikti kainas į Google metapaiešką. Nemokamos nuorodos Google rodo jūsų kainą ir veda į jūsų rezervacijų puslapį be mokėjimo už paspaudimą. Modulis, kuris to nemoka, atiduoda šiuos rodymus kanalams – kartu su komisiniu.

Ko Booking Engine nedaro

Apribojimus naudinga pažinoti iki pirkimo, o ne po pirmojo nusivylimo.

Modulis nepriveda paklausos. Tai vieta, kur perka, o ne reklama. Be srauto – paieška, socialiniai tinklai, metapaieška, kanalai – valdiklis bus tuščias, ir dėl to kaltas ne modulis. Pagal 2025 m. sektoriaus ataskaitą kanalai nepriklausomiems objektams atnešė 63,4 % rezervacijų: tiesioginis kanalas statomas šalia jų, o ne vietoj jų.

Modulis nesinchronizuoja kanalų. Tai Kanalų tvarkyklės užduotis: pardavėte numerį kanale – prieinamumą svetainėje sumažina ji, o ne valdiklis.

Modulis nevaldo kainų. Kainos gyvena kainų planuose, o ne kalendoriuje: Planner – rezervacijos, o kainos su atšaukimo taisyklėmis ir pardavimo apribojimais – atskiras nustatymas. Modulis rodo būtent tai, ką nustatėte jūs, tiksliai ir be savos aritmetikos. Kaip tokius planus susidėti – straipsnyje apie kambario kainą.

Modulis nepakeičia svetainės. Svečias, patekęs į tris rezervavimo ekranus per tiesioginę nuorodą iš laiško, vis tiek grįžta į svetainę – dėl nuotraukų, aprašymo, taisyklių. Tušti puslapiai su valdikliu pirmoje linijoje konversijos nepakels.

Išvados

• Booking Engine – pardavimų kanalas jūsų svetainėje: svečias rezervuoja pats, rezervacija patenka į bendrą Planner, laiškas išsiunčiamas be jūsų dalyvavimo.
• Nauda – ne „nemokamos rezervacijos“, o marža ir duomenys: kanalo komisinio už šią rezervaciją jūs nemokate, o svečio kontaktas lieka pas jus.
• Ryšys su PMS – pagrindinis kriterijus: be jo modulis renka užklausas, o ne rezervacijas.
• Pasirinkimą patikrina telefonas ir klausimai: mobilusis svečio kelias, jūsų prekės ženklas ir kalbos, integracija, saugumas ir duomenų saugojimo vieta.

Jei renkate objektui sistemų rinkinį ir nesprendėte, ką imti pirmiausia, pradėkite nuo straipsnio apie mažo viešbučio programinę įrangą: ten apie įvedimo tvarką ir apie tai, be ko galima pradėti.

Pažiūrėti, kaip Booking Engine įrengtas HotelsCalendar, galima Booking Engine puslapyje: prijungimas dviem kodo eilutėmis, mokėjimas kortele per Stripe su lėšų sulaikymu kortelėje, papildomos paslaugos su laiku ir lojalumo programa – vienoje prenumeratoje kartu su PMS ir Kanalų tvarkykle.

Dažniausiai užduodami klausimai

Booking Engine ir internetinė rezervavimo sistema – ar tai tas pat?

Taip. Lietuviškuose tekstuose vartojama „internetinė rezervavimo sistema“, angliškuose – booking engine: tai ta pati tiesioginių pardavimų viešbučio svetainėje sistema. Skirtumas atsiranda tik šalia kaimynų: PMS valdo objektą, Kanalų tvarkyklė sinchronizuoja kanalus, Booking Engine priima tiesiogines rezervacijas svetainėje. Kaip modulis įrengtas HotelsCalendar – Booking Engine puslapyje.

Ar reikia Booking Engine, jei viešbutis jau parduoda per Booking.com ir Airbnb?

Reikia – ne vietoj kanalų, o kartu su jais. Pagal 2025 m. sektoriaus ataskaitą kanalai nepriklausomiems objektams atnešė 63,4 % rezervacijų: nėra priežasčių atsisakyti tokio srauto. Yra prasmė skaičiuoti, kiek kainuoja kiekvienas kanalas: komisinis, atšaukimai, vidutinė rezervacijos suma. Kanalai duoda paklausos apimtį, kurios objektas pats nesurinks; tiesioginis kanalas – maržą ir svečių duomenis. Kaip kanalai skaičiuojami ir iš ko susideda jų komisinis – straipsnyje apie OTA.

Kuo Booking Engine skiriasi nuo PMS ir Kanalų tvarkyklės?

Tai trys skirtingos sistemos. PMS valdo objektą: Planner, kainos, svečiai, kasa. Kanalų tvarkyklė perduoda kainas ir prieinamumą į kanalus bei grąžina iš ten rezervacijas. Booking Engine priima tiesiogines rezervacijas svetainėje. Pirkti juos atskirai nebūtina: HotelsCalendar moduliai eina viena prenumerata kartu su PMS.

Kas privalo būti modulyje 9–30 numerių viešbučiui?

Minimumas iš keturių dalykų: ryšys su PMS (kitaip tai užklausų forma, o ne rezervacijos), mokėjimas kortele su patvirtinimu, mobilioji svečio kelio versija ir kalbos, kuriomis kalba jūsų svečiai. Toliau pagal poreikį: papildomos paslaugos, lojalumo programa, rezervacijų šaltinių ataskaita. Visa įvedimo tvarka – straipsnyje apie mažo viešbučio programinę įrangą.

Ar saugu priimti apmokėjimą per Booking Engine?

Taip, jei apmokėjimas vyksta mokėjimų paslaugų teikėjo pusėje: kortelės duomenys įvedami jo puslapyje, o viešbutis jų nesaugo pas save. Atkreipkite dėmesį į tris dalykus: HTTPS visuose modulio puslapiuose, PCI DSS sertifikatą paslaugų teikėjo pusėje (viešbučiui tokioje schemoje – lengviausia savęs įvertinimo forma, SAQ A) ir mokėjimo patvirtinimą antruoju faktoriumi – 3-D Secure, kurio Europoje reikalauja stiprus kliento autentifikavimas. Pažadas „mes saugūs“ prezentacijoje nepakeičia nė vieno iš šių trijų punktų.

Kodėl vieni moduliai parduodami prenumerata, o kiti ima procentą nuo rezervacijos?

Rinka gyvena abiem modeliais. Procentas nuo rezervacijos perkelia riziką tiekėjui: nėra rezervacijų – nėra mokesčio, bet kiekviena rezervacija brangsta augant apyvartai. Prenumerata nuspėjama apskaitoje ir neauga kartu su užimtumu, tačiau reikalauja, kad modulis realiai atvestų rezervacijų. Ko klausti abiem atvejais: kas įeina į kainą ir ar neatsiranda atskiras mokestis už modulius. HotelsCalendar sąskaitoje tik prenumerata – komisinių nuo rezervacijų ir mokesčių už modulius nėra; prenumeratos sudėtis – modulio puslapyje.