Channel Manager: mis see on, kuidas töötab ja kuidas valida

Pühapäeva õhtu, kell üksteist. Kaheteistkümne toaga hotelli administraator sulgeb vahetuse ja näeb Planneris üht ja sama kaheinimesetuba teisipäevaks — kaks korda. Üks broneering tuli Booking.com-ist, teine Airbnbist. Mõlemad kinnitatud, mõlemad külalise kaardiga. Ööbib üks külaline, ja teisele tuleb hommikul seletada, et tuba ei ole.

Paigutamine ümber nurga asuvasse hotelli Teie kulul, takso, hüvitis, vabandused kanalile — õhtust sai intsidentide lahkamine. Hommikul aga sündis küsimus, mille oleks tulnud esitada varem: miks kaks kalendrit said üldse näidata erinevat.

Vastus on igav: sellepärast, et neid on kaks. Kuni kanal on üks, elab saadavus ühes kohas ja eksida pole kus. Teisest kanalist alates on igal kuupäeval kaks ettekujutust sellest, mitu tuba vaba on — ja neid võrreldakse käsitsi, muu töö kõrvalt, parimal juhul õhtul. Channel Manager on tarkvarakiht, mis võtab just selle töö endale: hinnad, saadavus ja müügi reeglid on kõigis kanalites ühesugused, ja müüdud broneeringud tulevad objekti kalendrisse ise. Vaatame, mida ta täpselt sünkroonib, millega käsitsirežiim ähvardab, kuidas sünkroonimine toimib ja milliste kriteeriumide järgi teda valida.

Channel Manager lihtsas keeles

Definitsioon mahub kahte lausesse ja ta kattub kõigi valdkonna allikate omaga. Channel Manager on vahendav kiht objekti haldussüsteemi ja müügikanalite vahel: välja edastab ta selle, mida Te müüte (hinnad, saadavuse, tingimused), tagasi selle, mis on müüdud — broneeringud, nende muudatused ja tühistamised. Kõik ülejäänu selles artiklis on järeldused nendest kahest lausest.

Kohe piiridest, sest neid segatakse kõige sagedamini. Channel Manager ei müü ega reklaami. Objekti leht, fotod, vastused arvustustele, tasulised nähtavusprogrammid — kõik see jääb kanali haldusliidesesse. Positsiooni otsingutulemustes see tarkvara samuti ei tõsta: ta sünkroonib andmeid, ja täpsed andmed on vaid üks näitamise tingimustest. Kuidas positsioon Booking.com-is ja Airbnbis tegelikult kujuneb — eraldi analüüsis.

Koht tarkvara arhitektuuris on kiht tuuma ja näiteakende vahel. PMS (property management system) on objekti haldussüsteem: Planner, hinnad, külalised, raha. Kanalid on näiteaknad, kus objekt on esindatud lehega ja müüb oma kuupäevi. Channel Manager tuleb nii eraldi programmina kui ka PMS-i sisseehitatud moodulina — iseseisvale 9–30 toaga objektile on tüüpiline teine variant: üks kalender, üks pakkuja, pole liigset liigest, millel andmed kaovad.

Ja see pole eksootiline ost, vaid turu norm. Sektori aruande järgi — üle 90 miljoni iseseisva objekti broneeringu 2025. aastal — tuli 63,4% neist kanalite kaudu; aasta varem oli 61%. Kanalid on põhinõudlus; küsimus pole selles, kas neid on vaja, vaid selles, kes peab nende andmed korrast. Mis on OTA (online travel agency) ja millest kanali komisjonitasu koosneb — eraldi artiklis.

Mida täpselt sünkroonitakse

Välja, PMS-ist kanalitesse, lähevad kolm voogu.

Saadavus — mitu toatüübi tuba saab selles kanalis kuupäeval veel müüa. Hinnad — hinnad kuupäevade ja hinnaplaanide kaupa. Müügipiirangud — kuupäeva müügi reeglid: minimaalne ja maksimaalne ööbimine, saabumiste ja lahkumiste sulgemised üksikutele kuupäevadele, müügi täielik sulgemine. Kokku on need kolm voogu just see, mida kutsutakse värskeks infoks: kanal, kellel hind on tänane ja saadavus eilne, müüb eilset hotelli.

Tagasi, kanalitest PMS-i, tuleb see, mis on juba müüdud: uued broneeringud, muudatused neis, tühistamised. Tühistaminegi on sünkroonimissündmus: vabanenud kuupäev peab kõigis kanalites müüki tagasi jõudma, muidu jääb tuba tühjalt seisma.

Põhimõte, millele kõik toetub: kuupäeva kvoodid arvutatakse PMS-i ühest kalendrist, mitte hoita neid eraldi loendurina iga kanali kohta. Müüdi toatüübi viimane tuba — kõigis kanalites tekkis sellele kuupäevale null. Sulgeti müük kuupäevale — kvoodid läksid kõikjal nulli. Tõstsite reedi hinda — uus hind läks kõigisse kanalitesse, kus see hinnaplaan müügil on. Üks tõeallikas, palju näiteaknaid.

Objekti enda sündmused on eraldi ja alahinnatud juht. Oma inimeste pulm, korporatiiv, toatüübi remont: kuupäevad on vajalikud Teile, mitte külalistele. Müügi täielik sulgemine peatab kuupäeva — ja kanalid saavad sellele nulli saadavuse sama sünkroonimisega, ilma haldusliideseid läbimata. Olemasolevad broneeringud ei lähe sellega kuhugi: sulgemine kehtib ainult uutele müükidele.

Tagasivoolu näeb kõige selgemalt Planneris: kanali broneering ilmub sinna ise, koos märgisega, kust ta tuli. Planneris on broneeringud, hinnad elavad hinnaplaanides; kuni neid kaht maailma ei segata, ei „sõida“ juhuslik hinnaparandus ise kanalitesse. Kuidas koostada hinnaplaanid ja müügipiirangud, mis kanalitesse lähevad — toahinna artiklis.

Mis juhtub ilma temata: käsitsi ülekandmise hind

Käsitsirežiim näeb välja nii: igal kanalil oma haldusliides ja oma kalender. Tuli broneering — tuleb minna ülejäänud haldusliidestesse ja kuupäev kinni panna. Muudeti hinda — korrata parandust kõikjal. Tühistati broneering — avada kuupäev tagasi. Iga toiming on triviaalne. Probleem on nende arvus ja pausides nende vahel.

Ajahinnangud käsitsi sünkroonimisele rändavad tarkvarapakkujate blogides: küsitletakse omanikke — tuleb umbes kümme tundi nädalas viie kanali kohta. Need on praktikaülevaated, mitte mõõtmine, statistikaks nad ei kõlba — seepärast ei viita me neile. Vea mehaanika statistikat ei vaja: kanali A broneeringu ja kanali B kuupäeva sulgemise vahel kulub aega, ja selles aknas näeb teine külaline vaba tuba. Topeltbroneering — valdkonna keeles ülebroneerimine — sündib just seal. See pole sama, mis teadlik ülebroneerimine, kavatsuslik ülemüük oodatud mitteilmumiste vastu: siin on juttu plaanivälisest sünkroonimisveast.

Mida see maksab. Sektori ülevaadete hinnangul 200–500+ $ otsekulusid ühe juhtumi kohta: paigutamine teise hotelli objekti kulul, transport, hüvitis külalisele. Cornelli õppenäide arvutab nii: ümberpaigutatud külaline maksab umbes 300 $, tühi tuba umbes 100 $; sektori hüvitise norm on ööbimine pluss teekond. Pluss see, mida rahas ei arvesta: negatiivne arvustus, personalitunnid, rikutud suhe kanaliga.

Nüüd aritmeetika tellimuse hinna vastu. Üks ülebroneerimise juhtum on need samad 200–500 $ otsekulusid. Eraldi Channel Manager kuni 50 toaga objektile maksab 50–200 $ kuus (tarkvarapakkujate ülevaated 2026. aastast). Üks välditud juhtum tasub ära süsteemi ühe kuni kümne kuu töö — juba enne, kui jutt tuleks arvustusest, mida ei saa kustutada.

Tühistamised teevad käsitsirežiimi veel hullemaks. Sama aruande andmeil tühistatakse 21,8% kanalite broneeringutest 10,6% otsebroneeringute vastu. Tühistatud broneering tagastab kuupäeva müüki — sageli viimasel hetkel — ja ta peab jõudma õigeaegselt kõigis haldusliidetes lahti teha. Käsitsi sünkroonimine eksib mõlemas suunas: müüb hõivatut ja peidab vaba.

On ka taustamajandus, mida tasub meeles pidada. Kanali komisjonitasu on keskmiselt 15–30%+ broneeringu kogusummast (sektori aruande hinnang), ja hotelli veebilehelt tehtud broneering toob keskmiselt 516 $ kanalist tulnud 312 $ vastu (sektori aruanne, 135 miljonit broneeringut 20 turul; allikas müüb ise Channel Managereid, seega oleks ausam lugeda seda suurusjärjuna). Kanalid annavad mahu, otsekanal aga marginaali ja külalise andmed. Channel Manager ei lahenda seda tasakaalu Teie eest — ta võtab ära rutiini, millele tasakaalu jaoks aega ei jää. Kuidas otsekanalit üles ehitada — Booking Engine’i juhendis.

Kuidas sünkroonimine töötab

Kahesuunaline sünkroonimine on kaks voogu ühe ühendusega iga kanaliga. Välja lähevad automaatselt hinnad, saadavus ja müügipiirangud — ilma kanalite haldusliidestesse uuesti logimata. Tagasi, PMS-i ühisesse kalendrisse, tulevad broneeringud, muudatused ja tühistamised.

Kuidas see müügi minutis välja näeb. Külaline broneerib toatüübi viimase toa reedeks Booking.com-is. Broneering läheb PMS-i, toatüübi saadavus sellel kuupäeval väheneb — ja nii Expedia kui ka Agoda näevad reedeks nulli, sama mehhanismiga, mis iga muu parandus. Tühistamine töötab peegelpildis: kuupäev naasis müüki ja kanalid näevad tuba jälle. Aeg broneeringu ja ülejäänute uuenduse vahel on just see edastusaeg, millest allpool juttu.

Ühendus ise pole käsitöö, vaid vormistatud valdkonnapraktika. Suurtel kanalitel on formaalsed ühendamisprogrammid. Booking.com sertifitseerib partnereid, kelle kaudu objektid sünkroonivad — platvormi abilehel kutsutakse neid ühenduspakkujateks. Ühenduspakkuja on vahendaja, kelle kaudu objekt peab kalendrit, hindu ja müügipiiranguid. Tüüpiline juht on Channel Manager. Nõuded partneritele on kirjalikud: toetada kõiki API funktsioone, laadida hinnad ja saadavus vähemalt aasta ette, jälgida API muudatusi. Airbnbil on toetatud Channel Managerite avalik nimekiri.

Ühendusi on samas erinevaid, ja sõna „sünkroonimine“ neid ei erista. Aeglane variant on kalendrite vahetus ajakava järgi: lihtne ja odav, aga uuendused jõuavad kohale viivitusega ja broneeringud kirjaga. Täielik kahesuunaline ühendus hoiab kõige jaoks ühe sidekanali: broneering tuleb süsteemi ise, müügipiirangud lähevad hindadega koos. Nende eristamine valimisel on lihtne: küsige, mis täpselt kanalisse läheb ja mis tagasi tuleb — ja paluge näidata edastuslogi.

OTA pilgu läbi

Kõige näitlikum: kanalid ei talu sünkroonimist vastumeelselt — nad soosivad seda. Booking.com-i abileht Extraneti ja Channel Manageri sünkroonimisest sõnastab eesmäri otse: sünkroonimine on vajalik „topeltbroneeringute vältimiseks“. Samas on ametlik soovitus: kui töötate ühenduspakkujaga, pidage kalender ja hinnad tema kaudu, mitte Extranetis — siis salvestuvad muudatused garanteeritult. Airbnb ametlikul lehel Channel Managerite kohta on kasud loetletud: vähem lahknemisi hindades ja vabades kuupäevades, rohkem usaldust külaliste ja agentide poolt, rohkem broneeringuid täpsete andmete arvel.

Platvormide loogika on lihtne. Kui andmed kattuvad, avab objekt kogu majutusvõimsuse julgemini — ilma topeltbroneeringute kartuseta ei pea poolt tuba „igaks juhuks“ varju jätma. Külaline näeb ausat saadavust, platvorm müüb, objekt saab broneeringud. Võidavad kõik kolm.

„Poolte varju jätmine“ pole kõnekäänd. Sünkroonimiseta objektid kindlustavad end tihti: laadivad kanalitesse mitte kogu majutusvõimsust, vaid „ohutu“ osa — äkki ei jõua kuupäeva sulgeda. Kappi peidetud majutusvõimsus on pooleldi müüdud nädalavahetus. Üks kalender ei võta hirmu iseenesest ära — ta teeb selle tarbetuks.

Miks sünkroonimine ei ole kohene

Aus detail, millest müügilehed vaikivad: sünkroonimisel on edastusaeg, ja ta ei sõltu alati Teie tarkvarast. Booking.com kirjutab otse: Extraneti ja Channel Manageri vahelised muudatused „võivad töötlemisele minna kuni viis minutit“. See on platvormi enda aeg, mitte süsteemi omadus, mille Te välja valite. Praktiline järeldus: kui kaks külalist ühes lühikeses aknas broneerivad viimase toa kahes kanalis, võivad läbi minna mõlemad. Konfliktne broneering satub töötlusesse — ja selle lahtiharutamine on parem Planneris kui külalisega telefonis. Booking.com-il on sellest reeglist ka argisem järeld: ühel ajal Extranetis ja Channel Manageris tehtud parandused võivad lahkneda — seepärast platvorm soovitabki valida ühe tõeallika.

Seepärast kõlab aus valem mitte „null topeltbroneeringuid“, vaid „konflikt saab üksikjuhtumiks, mitte igapäevaseks loosimiseks“. Aken tõmbub tundidest minutiteks, iga edastus on logis näha, ja iga ühenduse olek — aktiivne, pausil, viga — ei ole aimamine, vaid rida ekraanil.

Miks sünkroonimine laguneb: viis korduvat põhjust

Isegi automaatne sünkroonimine läheb mõnikord sassi. Valdkonna ülevaated koonduvad viiele korduvale stsenaariumile.

1. Uuendused ajakava järgi, mitte sündmuse järgi. Süsteem küsitleb kanaleid kord tunnis — küsitluste vahel näitavad kanalid aegunud saadavust.
2. Toatüüpide vale vastendamine. Klassika pärast tubade ümbernimetamist või mahutavuse muutmist: kanal saab andmed vale toatüübi kohta.
3. Käsitsi parandused kanali haldusliideses. Hind, parandatud süsteemist mööda, läheb konflikti sellega, mida süsteem järgmisena saadab.
4. Ühesuunaline voog. Hinnad läksid, aga broneeringud tulevad tagasi e-kirjaga: pool sünkroonimisest on olemas, poolt pole.
5. Viivitus kanali poolel. Platvorm töötleb muudatust kauem kui tavaliselt; objekt ei saa siin midagi parandada — sõltub vaid see, kui kiiresti ta seda näeb.

Tagajärjed on samad: ümberpaigutused, personalitunnid, arvustused. Ja üks, mida ununeb: sünkroonimise tõrked löövad majutuskoha positsioonile — kanal alandab objekti, mis näitab ebatäpseid andmeid. Kuidas positsiooni arvutatakse — OTA järjestamise algoritmi artiklis.

Praktika samadest ülevaadetest. Ärge parandage hindu kanali haldusliideses, kui töötate süsteemi kaudu — kolmas põhjus loendis on kõige etteaimatavam. Pärast toatüüpide ümbernimetamist kontrollige vastendamist. Ja kanali mis tahes imelise käitumise korral vaadage kõigepealt edastuslogi ja kirjutage tuge alles siis: pool „tõrgetest“ laheneb uuesti saatmisega, mitte ootamisega.

Sealt ka peamine küsimus süsteemile, mille Te valite: „Mida ma näen, kui sünkroonimine on katki?“ Kui vastus on „kirjutate tuge“, on see halb vastus. Hea süsteem näitab edastuslogi — milline kanal, milline periood, milline olek — ja ühenduste olekuid, ja tal on nupp kõigi kanalite käsitsi sünkroonimiseks ühe toiminguga.

Kuidas Channel Managerit valida: viis kriteeriumi

Päringu „kuidas valida Channel Manager“ väljund on „top 10“ reitingud, kus iga rida on müügis. Seda nimekirja ei saa üle lüüa teise nimede nimekirjaga, seega — kriteeriumid. Need on ühesugused igale pakkujale, ka meile.

1. Kanalite kate. Mitte arv sihtlehelt, vaid Teie kanalite olemasolu: kataloog nimejärgi otsinguga, kus Booking.com, Airbnb ja Expedia leiab üles sekunditega. Suurimatel mängijatel käib ühenduste loendus sadades — suured pakkujad väidavad 450+ —, aga Teile on vaja oma kolme-viit kanalit, mitte võõraste summat. Enne ostu avage kataloog ja leidke oma kanal: minut, mis eraldab tegeliku katte kohe bänneri arvust.

2. Side PMS-iga. Kvoodid tuleb arvutada ühest kalendrist, mitte dubleerida loenduriga iga kanali kohta — muidu tulevad topeltbroneeringud tagasi süsteemi seest. Kui Channel Manager on eraldi, küsige, kuidas ta Teie PMS-iga kokku käib ja kes liigendi eest vastutab.

3. Oleku nähtavus. Ühenduste olekud, edastuslogi perioodide ja olekutega, käsitsi sünkroonimine ühe toiminguga. Demol paluge näidata veaekraani, mitte õnnelikku teed. Hea märk on, kui pakkuja näitab seda ise, küsimust ootamata.

4. Integratsioonide hooldus. Kanalite API-d muutuvad pidevalt — see on ühendamisprogrammide ametlik nõue, mitte müüja hirmulugu. Küsige, kes ja kui kiiresti jõuab järgi konkreetse kanali muudatustele. Vastus „meil on kanalitega otsesuhted“ ilma sisuta ei ole vastus.

5. Maksemudel. 2026. aasta turu orientiirid tarkvarapakkujate ülevaadete järgi: eraldi Channel Manager kuni 50 toaga objektile 50–200 $ kuus; komplekt PMS + Channel Manager + Booking Engine 250–500 $. Komisjonimudel — umbes 2% broneeringutelt — maksab kasvaval tulul rohkem kui fikseeritud tellimus. Arvutage oma tuluga, mitte keskmisega.

Maksemudel	Kuidas maksate	Millal kallim
Fikseeritud tellimus	kord kuus, sõltumata broneeringutest	peaaegu iial — kõige lihtsam arvutada
Toa kohta	vastavalt objekti suurusele	tipphooajal, kui müüki on palju
Broneeringu või protsendi eest	igalt süsteemi läbinud broneeringult	kasvaval tulul — koos eduga

Teine ristmik — kas võtta Channel Manager PMS-i moodulina või eraldi programmina. Iseseisvale objektile on tüüpiline vastus moodul: üks pakkuja, üks kalender, vähem liigendeid. Eraldi Channel Manager on õigustatud, kui on vaja kanalit, mida Teie PMS-is pole, või kui distributsioon on tähtsam kui töötuuma. Ja CRS — keskne broneerimissüsteem ketidele — on väikesele objektile üldse mitte vaja: see on haldusfirmade tase, tema funktsioonid katavad PMS ja Channel Manager.

Millal Channel Managerit veel ei vaja

Aus vastus: kuni kanal on üks, pole teda vaja. Üks haldusliides, üks kalender, broneeringud kantakse üle käega. Aga ka selles režiimis on oma hind — distsipliin: sulgeda kuupäev pärast iga broneeringut, avada pärast iga tühistamist, vahele ei jätta. Käsitsirežiim on tasuta täpselt esimese vahelejäämuni. Haigus, puhkus, pingeline saabumispäev — ja topeltbroneeringu aken läks ise lahti.

Piirid ise on selged. Üks kanal — haldusliidesest ja tähelepanelikkusest piisab. Kaks-kolm kanalit käsitsi ülekandmisega — on juba aeg: parandusi on liiga palju ja kõik on kiireloomulised. Mitte sellepärast, et inimesed oleksid halvad, vaid sellepärast, et käsitsi sünkroonimine ei skaala.

Kui süsteemide komplekti objektile alles koostate, alustage väikehotelli tarkvara artiklist: seal seisab Channel Manager oma kohal järjekorras „majutusvõimsus → hinnad → kanalid → veebileht“, ja see järjekord on tähtsam kui ostunimekiri.

Ja veel üks ausus. Channel Manager ei tasu end „säästetud tundidega“ — argument on tõsi, aga leige. Tugev on vea hinna jaotise aritmeetika: üks välditud juhtum tasub ära kuude jagu tellimust, ja välditud arvustust ei hüvita miski.

Kuidas see on lahendatud HotelsCalendaris

Lühidalt, kuidas loetletud kriteeriumid meie juures välja näevad.

Ühendamine — üle 100 kanali kataloog nimejärgi otsinguga, objekti ID kanali haldusliidesest, toatüüpide ja hindade vastendamine. Pärast vastendamist laaditakse saadavus, hinnad ja müügipiirangud kanalisse automaatselt — kaks aastat ette. Müügipiirangud lähevad paketis hindade ja saadavusega: minimaalne ja maksimaalne ööbimine, saabumiste ja lahkumiste sulgemised, nullkvoodid suletud kuupäevadele. Kvoodid arvutatakse PMS-i ühest kalendrist: müügi sulgemine kuupäeval nullib kvoodid kõigis kanalites ühe parandusega, mitte haldusliidete läbimisega.

Läbipaistvus. Igal kanalil on olek: aktiivne, pausil, viga. Edastuslogi näitab kanalit, perioodi ja iga laadimise olekut. Kõigi kanalite sünkroonimise saab käivitada käsitsi ühe toiminguga. Uued broneeringud jõuavad Plannerisse ise, koos kanali nimega. Aga enne ühendamist müüdud broneeringud laaditakse käsitsi perioodi kaupa — ajalugu ei tule ise, ja meile meeldib öelda seda otse, mitte pärast ühendamist.

Vaadata, kuidas see töötab, saab Channel Manageri lehel.

Kokkuvõte

• Channel Manager on kiht PMS-i ja kanalite vahel: välja hinnad, saadavus ja müügipiirangud, tagasi broneeringud, muudatused ja tühistamised.
• Käsitsirežiim eksib mõlemas suunas: müüb hõivatut ja peidab vaba; topeltbroneering on kalleim viga — 200–500+ $ ja arvustus.
• Sünkroonimine pole absoluutne: kanalite võidujooksud on harvad, aga võimalikud — konfliktne broneering läheb töötlusesse ja laheneb Planneris.
• Kanalid soosivad sünkroonimist ise: Booking.com soovitab pidada kalendrit ja hindu ühenduspakkujaga.
• Valida tuleb kataloogi, PMS-i sideme, edastuslogi, integratsioonide hoolduse ja maksemudeli järgi. Kuni kanal on üks, saab ka käega.

Korduma kippuvad küsimused

Mis on Channel Manager lihtsalt?

See on side objekti haldussüsteemi ja müügikanalite vahel. Te muudate hinda või saadavust üks kord — muudatus läheb kõigisse ühendatud kanalitesse; külaline broneerib kanalis — broneering tuleb objekti kalendrisse tagasi. Andmeid haldab PMS, Channel Manager sünkroonib neid.

Kuidas Channel Manager PMS-ist erineb?

PMS haldab objekti: Planner, hinnad, külalised, kassa. Channel Manager ainult sünkroonib hinnad, saadavuse ja broneeringud PMS-i ning kanalite vahel. Neid eraldi ostma ei pea: Channel Manager tuleb PMS-i sisseehitatud moodulina — HotelsCalendaris läheb ta ühe tellimusena koos ülejäänud moodulitega.

Kas Channel Managerit on vaja, kui kanal on ainult üks?

Ei ole. Üks kanal — üks haldusliides, parandused käega. Piir jookseb mööda teist kanalit: sellest hetkest peab saadavust pidama kahes kohas, ja topeltbroneeringu aken avaneb iga uue broneeringuga. Kuidas Channel Manager kogu süsteemide komplekti mahtub — väikehotelli tarkvara artiklis.

Miks topeltbroneeringuid juhtub ka Channel Manageriga?

Kanalid võistlevad ühe ja sama toa pärast, ja sünkroonimisel on edastusaeg. Kui kaks broneeringut lähevad läbi ühes lühikeses aknas, võivad mõlemad süsteemi jääda — siis satub konfliktne broneering töötlusesse ja konflikt laheneb Planneris. Vahe ei ole „null viga“, vaid selles, et konflikt saab üksikjuhtumiks, mitte igapäevaseks loosimiseks. Kuidas see tootes on lahendatud.

Mis on toatüüpide ja hindade vastendamine?

Kanali ühendamise samm: Teie toatüübid ja hinnad seotakse paarikaupa kanali toatüüpide ja hindadega, et andmed läheksid õigetele lehtedele. Vastendamise vead on üks tüüppõhjustest, miks sünkroonimine tõrkeid teeb, eriti pärast toatüüpide ümbernimetamist. Vastendamist kontrollitakse Channel Manageri ekraanil.

Kas Channel Manager asendab kanalite haldusliidesed?

Ei asenda. Objekti leht, fotod, vastused arvustustele, nähtavusprogrammid — kõik see jääb kanali haldusliidesesse; fotosid tarkvara ei laadi. Channel Manager vastutab ainult andmete eest: hinnad, saadavus, müügipiirangud ja broneeringud. Mida kanalid objektile annavad ja mida selle eest makstakse — OTA artiklis.