Kanalų tvarkyklė: kas tai, kaip veikia ir kaip pasirinkti

Sekmadienis, vienuolikta vakaro. Dvylikos numerių viešbučio administratorius uždaro pamainą ir Planner kalendoriuje mato tą patį dvivietį numerį antradieniui – dukart. Viena rezervacija atėjo iš Booking.com, kita – iš Airbnb. Abi patvirtintos, abi su svečio kortele. Naktį miegos vienas svečias, o antrajam ryte teks aiškinti, kad numerio nėra.

Perkėlimas į viešbutį už kampo objekto sąskaita, taksi, kompensacija, atsiprašymai kanalui – vakaras virto klaidų narpliojimu. O ryte iškilo klausimas, kurį reikėjo užduoti anksčiau: kodėl du kalendoriai apskritai galėjo parodyti skirtingai.

Atsakymas nuobodus: todėl, kad jų du. Kol kanalas vienas, prieinamumas gyvena vienoje vietoje ir suklysti nėra kur. Nuo antro kanalo kiekviena data turi du vaizdus apie tai, kiek numerių laisva, – ir jie suderinami rankomis, tarp reikalų, geriausiu atveju vakare. Kanalų tvarkyklė (Channel Manager) – programinis sluoksnis, kuris atlieka būtent šį darbą: kainos, prieinamumas ir pardavimo taisyklės visuose kanaluose vienodi, o parduotos rezervacijos pačios grįžta į objekto kalendorių. Išnagrinėsime, kas tiksliai sinchronizuojama, kuo gresia rankinis režimas, kaip sinchronizavimas įrengtas ir pagal kokius kriterijus jį rinktis.

Kanalų tvarkyklė paprastais žodžiais

Apibrėžimas telpa į du sakinius, ir jis sutampa visuose srities šaltiniuose. Kanalų tvarkyklė – tarpinis sluoksnis tarp objekto valdymo sistemos ir pardavimų kanalų: laukan ji perduoda tai, ką parduodate (kainas, prieinamumą, sąlygas), atgal – tai, kas parduota: rezervacijas, jų pakeitimus ir atšaukimus. Viskas kita šiame straipsnyje – šių dviejų sakinių padariniai.

Iškart apie ribas, nes jos maišomos dažniausiai. Kanalų tvarkyklė neparduoda ir nereklamuoja. Objekto kortelė, nuotraukos, atsakymai į atsiliepimus, mokamos matomumo programos – visa tai lieka kanalo ekstranete. Pozicijos paieškos rezultatuose ši programinė įranga irgi nepakelia: ji sinchronizuoja duomenis, o tikslūs duomenys – tik viena iš rodymo sąlygų. Kaip iš tikrųjų statoma pozicija Booking.com ir Airbnb – atskirame straipsnyje.

Vieta sistemų rinkinyje – sluoksnis tarp branduolio ir vitrinų. PMS (property management system) – objekto valdymo sistema: Planner, tarifai, svečiai, pinigai. Kanalai – vitrinos, kuriose objektas pristatomas kortele ir parduoda savo datas. Kanalų tvarkyklė būna atskira programa, o būna ir PMS modulis – nepriklausomam 9–30 numerių objektui antrasis variantas tipinis: vienas kalendorius, vienas tiekėjas, nėra bereikalingos jungties, kurioje pranyksta duomenys.

Ir tai ne egzotiškas pirkimas, o rinkos norma. Pagal sektoriaus ataskaitą apie daugiau nei 90 mln. nepriklausomų objektų rezervacijų per 2025 m. 63,4 % jų atėjo per kanalus – prieš metus buvo 61 %. Kanalai – pagrindinė paklausa; klausimas ne tas, ar jų reikia, o kas laikys jų duomenis tvarkoje. Kas yra OTA (internetinė kelionių agentūra) ir iš ko susideda kanalo komisinis mokestis – straipsnyje apie OTA.

Kas tiksliai sinchronizuojama

Laukan, iš PMS į kanalus, keliauja trys srautai.

Prieinamumas – kiek numerio tipo numerių galima parduoti tai datai kanale. Tarifai – kainos pagal datas ir kainų planus. Apribojimai – datos pardavimo taisyklės: minimali ir maksimali viešnagės trukmė, atskirų datų uždarymas atvykimui ar išvykimui, pilnas datų uždarymas pardavimui. Kartu šie trys srautai ir yra „aktualūs duomenys“: kanalas, kurio kaina šviežia, o prieinamumas vakarykštis, parduoda vakarykštį viešbutį.

Atgal, iš kanalų į PMS, grįžta tai, kas jau parduota: naujos rezervacijos, jų pakeitimai, atšaukimai. Atšaukimas – irgi sinchronizavimo įvykis: atlaisvėjusi data turi grįžti į pardavimą visuose kanaluose, kitaip numeris stovės tuščias.

Principas, ant kurio visa laikosi: kvotos datai skaičiuojamos iš vieno PMS kalendoriaus, o nelaikomos atskiru skaitikliu kiekvienam kanalui. Parduotas paskutinis numerio tipo numeris – visuose kanaluose šiai datai atsiranda nulis. Uždarytas pardavimas datai – kvotos nulinės visur. Pakelta kaina penktadieniui – nauja kaina iškeliauja į visus kanalus, kuriuose parduodamas šis kainų planas. Vienas tiesos šaltinis, daug vitrinų.

Objekto įvykiai – atskiras ir neįvertintas atvejis. Artimųjų vestuvės, korporatyvinis atvykimas, numerio tipo remontas: datas reikia jums, o ne svečiams. Pilnas pardavimo uždarymas stabdo datą – ir kanalai gauna jai nulinį prieinamumą ta pačia sinchronizacija, be apeigos po ekstranetus. Esamos rezervacijos niekur nedingsta: uždarymas veikia tik naujus pardavimus.

Grįžtamasis srautas aiškiausiai matomas Planner kalendoriuje: rezervacija iš kanalo atsiranda kalendoriuje pati, su žyma, iš kur atėjo. Planner – rezervacijos, kainos gyvena kainų planuose; kol šie du pasauliai nesimaišo, atsitiktinis kainos pataisymas pats „neišvažiuos“ į kanalus. Kaip susidėti pačius tarifus ir apribojimus, kurie keliaus į kanalus, – straipsnyje apie kambario kainą.

Kaip būna be jos: rankinio perkėlimo kaina

Rankinis režimas atrodo taip: kiekvienam kanalui – savo ekstranetas ir savo kalendorius. Ateina rezervacija – reikia užeiti į likusius ekstranetus ir uždaryti datą. Pakeitėte kainą – pakartokite pataisymą visur. Atšaukta rezervacija – atverkite datą atgal. Kiekviena operacija triviali. Problema – jų skaičius ir pauzės tarp jų.

Laiko sąnaudų rankinei sinchronizacijai vertinimai tiekėjų bloguose skiriasi: apklausti savininkai nurodo maždaug dešimt valandų per savaitę penkiems kanalams. Tai praktikų apžvalgos, o ne matavimas, statistika jos nėra – todėl jų necituosime. Klaidos mechanikai statistikos nereikia: tarp rezervacijos kanale A ir datos uždarymo kanale B praeina laiko, ir šiame tarpelyje antras svečias mato laisvą numerį. Dviguba rezervacija – srities žargonu overbooking – gimsta būtent ten. Tai ne tas pat, kas strateginis overbooking, sąmoningas perteklinis pardavimas laukiant numatytų neatvykimų: čia kalba eina apie nesuplanuotą sinchronizavimo klaidą.

Kuo tai kainuoja. Pagal srities apžvalgų vertinimus – 200–500 $ ir daugiau tiesioginių išlaidų vienam atvejui: perkėlimas į kitą viešbutį objekto sąskaita, transportas, kompensacija svečiui. Cornell mokomasis pavyzdys skaičiuoja taip: perkeltas svečias kainuoja apie 300 $, tuščias numeris – apie 100 $; srities kompensacijos norma – nakvynės naktis plius kelionė. Plius tai, kas nėra skaičiuojama pinigais: neigiamas atsiliepimas, darbuotojų valandos, sugadinti santykiai su kanalu.

Dabar aritmetika prieš prenumeratą. Vienas overbooking atvejis – tie patys 200–500 $ tiesioginių išlaidų. Atskira kanalų tvarkyklė objektui iki 50 numerių kainuoja 50–200 $ per mėnesį (tiekėjų apžvalgos 2026 m.). Vienas išvengtas atvejis atperka nuo vieno iki dešimties mėnesių sistemos darbo – dar iki tol, nei kalba pakils apie atsiliepimą, kurio neįmanoma pašalinti.

Atšaukimai rankinį režimą daro dar blogesnį. Pagal tos pačios ataskaitos duomenis atšaukiama 21,8 % kanalų rezervacijų prieš 10,6 % tiesioginių. Atšaukta rezervacija grąžina datą į pardavimą – dažnai paskutinę akimirką, – ir ją reikia suspėti atverti visuose ekstranetuose. Rankinis sinchronizavimas klysta abiem kryptimis: parduoda užimtą ir slepia laisvą.

Yra ir foninė ekonomika, kurios verta nepamiršti. Kanalo komisinis mokestis – vidutiniškai 15–30 % ir daugiau nuo visos rezervacijos sumos (sektoriaus ataskaitos vertinimas), o rezervacija iš viešbučio svetainės vidutiniškai atneša 516 $ prieš 312 $ iš kanalo (sektoriaus ataskaita, 135 mln. rezervacijų 20 rinkų; pats šaltinis pardavinėja kanalų tvarkykles, todėl sąžiningiau skaityti tai kaip dydžių tvarką). Kanalai duoda apimtį, tiesioginis kanalas – maržą ir svečio duomenis. Kanalų tvarkyklė šios pusiausvyros už jūsų nesprendžia – ji pasiima rutiną, kuriai iš pusiausvyros nebelieka laiko. Kaip statyti tiesioginį kanalą – Booking Engine gide.

Kaip veikia sinchronizavimas

Dvipusė sinchronizacija – du srautai per vieną ryšį su kiekvienu kanalu. Laukan automatiškai keliauja tarifai, prieinamumas ir apribojimai – be įėjimo į kanalų ekstranetus. Atgal, į bendrą PMS kalendorių, grįžta rezervacijos, pakeitimai ir atšaukimai.

Kaip tai atrodo pardavimo minutę. Svečias rezervuoja paskutinį numerio tipo numerį penktadieniui Booking.com. Rezervacija keliauja į PMS, numerio tipo prieinamumas šiai datai sumažėja – ir Expedia su Agoda mato penktadieniui nulį, tuo pačiu mechanizmu kaip bet kuris kitas pataisymas. Atšaukimas veikia veidrodžiškai: data grįžo į pardavimą, ir kanalai vėl mato numerį. Laikas tarp rezervacijos ir atnaujinimo pas kitus – tas pats pristatymo laikas, apie kurį žemiau.

Pats ryšys – ne savadarbė istorija, o susiklosčiusi srities praktika. Dideli kanalai turi formalias prisijungimo programas. Booking.com sertifikuoja partnerius, per kuriuos objektai veda sinchronizavimą, – platformos pagalbos puslapyje jie vadinami sinchronizacijos paslaugų teikėjais (connectivity provider). Sinchronizacijos paslaugų teikėjas – tarpininkas, per kurį objektas veda kalendorių, tarifus ir apribojimus. Tipinis atvejis – kanalų tvarkyklė. Reikalavimai partneriams – raštu: palaikyti visas API funkcijas, iškrauti tarifus ir prieinamumą bent metams į priekį, sekti API pokyčius. Airbnb turi viešą palaikomų kanalų tvarkyklių sąrašą.

Ryšiai būna skirtingi, o žodis „sinchronizacija“ jų neskiria. Lėtas variantas – kalendorių apsikeitimas pagal tvarkaraštį: paprasta, pigu, bet atnaujinimai ateina su vėlavimu, o rezervacijos – laišku. Visavertis dvipusis prisijungimas viskam laiko vieną ryšio kanalą: rezervacija grįžta į sistemą pati, apribojimai keliauja kartu su kainomis. Atskirti juos renkantis paprasta: paklauskite, kas tiksliai keliauja į kanalą ir kas grįžta, – ir paprašykite parodyti siuntimų žurnalą.

OTA akimis

Parodomiausia tai, kad kanalai sinchronizavimo netoleruoja – jie jį skatina. Booking.com pagalbos puslapis apie Ekstraneto ir kanalų tvarkyklės sinchronizavimą tikslą formuluoja tiesiai: sinchronizavimas reikalingas „kad būtų išvengta dvigubų rezervacijų“. Ten pat – oficialus patarimas: jei dirbate per sinchronizacijos paslaugų teikėją, kalendorių ir tarifus veskite per jį, o ne per Ekstranetą, – tuomet pakeitimai garantuotai išsaugomi. Airbnb oficialiame puslapyje apie kanalų tvarkykles išvardija naudas: mažiau neatitikimų kainose ir laisvose datose, daugiau pasitikėjimo iš svečių ir agentų, daugiau rezervacijų dėl tikslių duomenų.

Platformų logika paprasta. Kai duomenys sutampa, objektas drąsiau atveria visą fondą – be baimės dvigubų rezervacijų nereikia slėpti pusės numerių „dėl viso pikto“. Svečias mato sąžiningą prieinamumą, platforma parduoda, objektas gauna rezervacijų. Laimi visi trys.

Apie „pusės slėpimą“ – tai ne kalbos figūra. Objektai be sinchronizavimo dažnai apsidraudžia: į kanalus iškrauna ne visą fondą, o „saugią“ dalį – staiga datos uždaryti nespės. Fondas, paslėptas spintoje, – tai per pusę parduoti savaitgaliai. Vienas kalendorius pats savaime baimės nepašalina – jis padaro ją nereikalinga.

Kodėl sinchronizavimas nėra akimirksniu

Garbinga detalė, kurios nepasako pardavimo puslapiai: sinchronizavimas turi pristatymo laiką, ir jis ne visada priklauso nuo jūsų programinės įrangos. Booking.com rašo tiesiai: pakeitimai tarp Ekstraneto ir kanalų tvarkyklės „gali būti apdorojami iki penkių minučių“. Tai pačios platformos laikas, o ne jūsų pasirinktos sistemos charakteristika. Praktinė išvada: jei du svečiai viename trumpame tarpelyje rezervuoja paskutinį numerį dviejuose kanaluose, praeiti gali abi rezervacijos. Konfliktinė rezervacija patenka į apdorojimą – ir ją patogiau nagrinėti Planner kalendoriuje, o ne telefone su svečiu. Booking.com turi ir buitiškesnį tos pačios taisyklės padarinį: pakeitimai, atlikti vienu metu Ekstranete ir kanalų tvarkyklėje, gali išsiskirti – todėl platforma ir pataria rinktis vieną tiesos šaltinį.

Todėl garbinga formulė skamba ne „nulis dvigubų rezervacijų“, o „konfliktas tampa pavieniu atveju, o ne kasdiene loterija“. Tarpelis susispaudžia nuo valandų iki minučių, kiekvienas išsiuntimas matomas žurnale, o kiekvieno prisijungimo būsena – aktyvus, pauzė, klaida – ne spėlionė, o eilutė ekrane.

Kodėl sinchronizavimas griūva: penkios tipinės priežastys

Net automatinis sinchronizavimas kartais stringa. Srities apžvalgos sutaria dėl penkių pasikartojančių scenarijų.

1. Atnaujinimai pagal tvarkaraštį, o ne pagal įvykį. Sistema apklausia kanalus kartą per valandą – tarp apklausų kanalai rodo pasenusį prieinamumą.
2. Susiejimo klaida. Klasika po numerių pervadinimo ar talpos keitimo: kanalas gauna duomenis ne tam numerio tipui.
3. Rankiniai pataisymai kanalo ekstranete. Kaina, pakeista apeinant sistemą, konfliktuoja su tuo, ką sistema išsiųs kitą kartą.
4. Vienpusis srautas. Kainos iškeliavo, o rezervacijos grįžta laišku į paštą: pusė sinchronizavimo yra, pusės nėra.
5. Vėlinimas kanalo pusėje. Platforma pati apdoroja pakeitimą ilgiau nei įprasta; nuo objekto čia niekas nepriklauso – tik tai, kaip greitai jis tai pamatys.

Padariniai tie patys: perkėlimai, darbuotojų valandos, atsiliepimai. Ir dar vienas, apie kurį pamirštama: sinchronizavimo triktys muša per skelbimo poziciją – kanalas žemina objektą, rodantį netikslius duomenis. Kaip skaičiuojama pozicija – straipsnyje apie OTA rūšiavimo algoritmą.

Praktika iš tų pačių apžvalgų. Netaisyti kainų kanalo ekstranete, jei dirbate per sistemą, – trečia sąrašo priežastis pati nuspėjamiausia. Po tipų pervadinimo patikrinti susiejimą. Ir prie bet kokio keisto kanalo elgesio pirmiausia žiūrėti į siuntimų žurnalą, o tik paskui rašyti į pagalbą: pusę trikčių galima išspręsti pakartotiniu išsiuntimu, o ne laukimu.

Iš čia pagrindinis klausimas renkamai sistemai: „Ką aš pamatysiu, kai sinchronizavimas sugriuvo?“ Jei atsakymas – „parašysite į pagalbą“, tai blogas atsakymas. Gera sistema rodo siuntimų žurnalą – koks kanalas, koks periodas, kokia būsena, – ir prisijungimų būsenas, ir turi mygtuką visų kanalų sinchronizavimui vienu veiksmu.

Kaip pasirinkti Kanalų tvarkyklę: penki kriterijai

Paieška pagal užklausą „kaip pasirinkti kanalų tvarkyklę“ grąžina „top 10“ reitingus, kuriuose kiekviena eilutė parduodama. Tokio sąrašo nepermuši kitu pavadinimų sąrašu, todėl – kriterijai. Jie tie patys bet kuriam tiekėjui, įskaitant mus.

1. Kanalų padengimas. Ne skaičius iš pardavimo puslapio, o jūsų kanalų buvimas: katalogas su paieška pagal pavadinimą, kuriame Booking.com, Airbnb ir Expedia randami per kelias sekundes. Didžiausių žaidėjų prisijungimai skaičiuojami šimtais – didieji tiekėjai skelbia 450+, – bet jums reikia savų trijų-penkių, o ne svetimos sumos. Prieš pirkimą atidarykite katalogą ir raskite jame savo kanalą: minutė, kuri iškart atskiria realų padengimą nuo skaičiaus baneryje.

2. Ryšys su PMS. Kvotos turi būti skaičiuojamos iš vieno kalendoriaus, o ne dubliuojamos skaitikliu kiekvienam kanalui – kitaip dvigubos rezervacijos grįš iš sistemos vidaus. Jei kanalų tvarkyklė atskira, pasiteiraukite, kaip ji jungiasi su jūsų PMS ir kas atsako už jungtį.

3. Būsenos matomumas. Prisijungimų būsenos, siuntimų žurnalas su periodais ir būsenomis, rankinė sinchronizacija vienu veiksmu. Demonstracijoje prašykite parodyti klaidų ekraną, o ne laimingą kelią. Geras ženklas – kai tiekėjas rodo jį pats, nelaukdamas klausimo.

4. Integracijų palaikymas. Kanalų API keičiasi nuolat – tai oficialus prisijungimo programų reikalavimas, o ne pardavėjo gąsdinimas. Paklauskite, kas ir kaip greitai pasiveja konkretaus kanalo pokyčius. Atsakymas „turime tiesioginius santykius su kanalais“ be konkretikos – ne atsakymas.

5. Mokėjimo modelis. 2026 m. rinkos orientyrai pagal tiekėjų apžvalgas: atskira kanalų tvarkyklė objektui iki 50 numerių – 50–200 $ per mėnesį; rinkinys PMS + kanalų tvarkyklė + Booking Engine – 250–500 $. Komisinis modelis – apie 2 % nuo rezervacijų – augant apyvartai kainuos brangiau nei fiksuota prenumerata. Skaičiuokite pagal savo apyvartą, o ne pagal vidutinę.

Mokėjimo modelis	Kaip mokate	Kada brangiau
Fiksuota prenumerata	kartą per mėnesį, nepriklausomai nuo rezervacijų	beveik niekada – lengviausia skaičiuoti
Už numerį	proporcingai objekto dydžiui	piko sezonu, kai pardavimų daug
Už rezervaciją ar procentą	nuo kiekvienos rezervacijos per sistemą	augant apyvartai – kartu su sėkme

Antras išsišakojimas – imti kanalų tvarkyklę PMS moduliu ar atskira programa. Nepriklausomam objektui tipinis atsakymas – modulis: vienas tiekėjas, vienas kalendorius, mažiau jungčių. Atskira tvarkyklė pateisinama, kai reikia kanalo, kurio jūsų PMS neturi, arba kai distribucija svarbesnė už operacinį branduolį. O CRS – centrinė rezervavimo sistema tinklams – mažam objektui apskritai nereikalinga: tai valdymo bendrovių lygis; jos funkcijas uždaro PMS ir kanalų tvarkyklė.

Kada Kanalų tvarkyklės dar nereikia

Garbingas atsakymas: kol kanalas vienas – nereikia. Vienas ekstranetas, vienas kalendorius, rezervacijos perkeliamos rankomis. Bet ir šis režimas turi savo kainą – drausmę: uždaryti datą po kiekvienos rezervacijos, atverti po kiekvieno atšaukimo, nepraleisti. Rankinis režimas nemokamas tik iki pirmo pražiopsojimo. Liga, atostogos, įtemptas atvykimas – ir tarpelis dvigubai rezervacijai atsivėrė pats.

Ribos aiškios. Vienas kanalas – ekstraneto ir atidumo užtenka. Du-trys kanalai su rankiniu perkėlimu – jau metas: pataisymų per daug, ir visi skubūs. Ne todėl, kad žmonės blogi, o todėl, kad rankinis sinchronizavimas nesiplečia.

Jei objekto sistemų rinkinį tik renkatės, pradėkite nuo straipsnio apie mažo viešbučio programinę įrangą: ten kanalų tvarkyklė stovi savo vietoje sekoje „fondas → tarifai → kanalai → svetainė“, ir ši seka svarbesnė už pirkinių sąrašą.

Ir dar vienas garbingumas. Kanalų tvarkyklė neatsiperka „sutaupytomis valandomis“ – argumentas tikras, bet vangus. Stiprus – aritmetika iš skyriaus apie klaidos kainą: vienas išvengtas atvejis atperka mėnesius prenumeratos, o išvengtas atsiliepimas neatsiperka niekuo.

Kaip tai įrengta HotelsCalendar

Trumpai apie tai, kaip šie kriterijai atrodo pas mus.

Prisijungimas – daugiau nei 100 kanalų katalogas su paieška pagal pavadinimą, išorinis objekto ID iš kanalo ekstraneto, numerio tipų ir kainų planų susiejimas. Po susiejimo prieinamumas, tarifai ir apribojimai į kanalą iškraunami automatiškai – dvejiems metams į priekį. Apribojimai keliauja pakete su kainomis ir prieinamumu: minimali ir maksimali viešnagės trukmė, atvykimo ir išvykimo datų uždarymai, nulinės kvotos uždarytoms datoms. Kvotos skaičiuojamos iš vieno PMS kalendoriaus: pardavimo uždarymas datai nuliuoja kvotas visuose kanaluose vienu pataisymu, o ne ekstranetų apeiga.

Skaidrumas. Kiekvienam kanalui – būsena: aktyvus, pauzė, klaida. Siuntimų žurnalas rodo kanalą, periodą ir kiekvienos iškrovos būseną. Visų kanalų sinchronizavimą galima paleisti rankomis vienu veiksmu. Naujos rezervacijos pačios patenka į Planner – su kanalo vardu. O rezervacijos, parduotos iki prisijungimo, įkeliamos rankomis už periodą – istorija pati nesikels, ir mes verčiau sakome tai tiesiai, o ne po prisijungimo.

Pažiūrėti, kaip tai veikia, galima Kanalų tvarkyklės puslapyje.

Išvados

• Kanalų tvarkyklė – sluoksnis tarp PMS ir kanalų: laukan kainos, prieinamumas ir apribojimai, atgal – rezervacijos, pakeitimai ir atšaukimai.
• Rankinis režimas klysta abiem kryptimis: parduoda užimtą ir slepia laisvą; dviguba rezervacija – brangiausia klaida, 200–500 $ ir atsiliepimas.
• Sinchronizavimas nėra absoliutus: kanalų lenktynės retos, bet galimos – konfliktinė rezervacija patenka į apdorojimą ir išsprendžiama Planner.
• Kanalai patys skatina sinchronizavimą: Booking.com pataria kalendorių ir tarifus vesti per sinchronizacijos paslaugų teikėją.
• Rinktis reikia pagal katalogą, ryšį su PMS, siuntimų žurnalą, integracijų palaikymą ir mokėjimo modelį. Kol kanalas vienas – galima rankomis.

Dažniausiai užduodami klausimai

Kas yra kanalų tvarkyklė paprastais žodžiais?

Tai jungtis tarp objekto valdymo sistemos ir pardavimų kanalų. Kainą ar prieinamumą pakeičiate vieną kartą – pakeitimas keliauja į visus prijungtus kanalus; svečias rezervuoja kanale – rezervacija grįžta į objekto kalendorių. Duomenimis valdo PMS, kanalų tvarkyklė juos sinchronizuoja.

Kuo kanalų tvarkyklė skiriasi nuo PMS?

PMS valdo objektą: Planner, tarifai, svečiai, kasa. Kanalų tvarkyklė tik sinchronizuoja kainas, prieinamumą ir rezervacijas tarp PMS ir kanalų. Pirkti atskirai nebūtina: kanalų tvarkyklė būna PMS modulis – HotelsCalendar ji eina vienoje prenumeratoje kartu su kitais moduliais.

Ar reikia kanalų tvarkyklės, jei kanalas vienas?

Ne. Vienas kanalas – vienas ekstranetas, pataisymai rankomis. Ribą brėžia antras kanalas: nuo to momento prieinamumą reikia laikyti dviejose vietose, ir tarpelis dvigubai rezervacijai atsiveria su kiekviena nauja rezervacija. Kaip kanalų tvarkyklė įsirauna į bendrą sistemų rinkinį – straipsnyje apie mažo viešbučio programinę įrangą.

Kodėl dvigubos rezervacijos nutinka net su kanalų tvarkykle?

Kanalai varžosi dėl to paties numerio, o sinchronizavimas turi pristatymo laiką. Jei dvi rezervacijos praeina viename trumpame tarpelyje, sistemoje gali atsidurti abi – tuomet konfliktinė rezervacija patenka į apdorojimą, o konfliktas išsprendžiamas Planner. Skirtumas ne „nulis klaidų“, o tas, kad konfliktas tampa pavieniu atveju, o ne kasdiene loterija. Kaip tai įrengta produkte.

Kas yra numerio tipų ir kainų planų susiejimas?

Kanalo prisijungimo žingsnis: jūsų numerio tipai ir kainų planai poromis susiejami su kanalo tipais ir planais, kad duomenys keliautų į reikiamas korteles. Susiejimo klaidos – viena iš tipinių sinchronizavimo trikčių priežasčių, ypač po tipų pervadinimo. Susiejimas tikrinamas Kanalų tvarkyklės ekrane.

Ar kanalų tvarkyklė pakeičia kanalų ekstranetus?

Ne. Objekto kortelė, nuotraukos, atsakymai į atsiliepimus, matomumo programos – visa tai lieka kanalo ekstranete; nuotraukų programinė įranga neiškrauna. Kanalų tvarkyklė atsako tik už duomenis: kainas, prieinamumą, apribojimus ir rezervacijas. Ką kanalai duoda objektui ir už ką už tai mokama – straipsnyje apie OTA.