Jedním z probíhajících "trendů" v cenotvorbě krátkodobých pronájmů jsou "dynamické ceny".
Princip dynamických cen je v tom, že cenu nestanovuje provozovatel ubytovacího zařízení, ale vypočítává ji algoritmus komerční firmy na základě aktuální poptávky, konkurenčních cen v oblasti a dalších faktorů.
Software takto přeceňuje cenovou nabídku každý den.
Systém dynamických cen vznikl pravděpodobně v maloobchodě a v eshopech prodávajících zaměnitelné zboží.
Pokud jako nakupující volíte eshop, ve kterém nakoupíte nějaký standardní model standardní značky stejného zboží, které nabízí 500 eshopů, pak vedle důvěryhodnosti, hodnocení eshopu a rychlosti dodání pro vás bude cena velmi důležitým faktorem a strategií některých eshopů se stávají "cenové války o haléře".
V oblasti ubytování je ale princip výběru úplně jiný. Jako host ubytovacího zařízení volíte kromě referencí hlavně lokalitu, kapacitu, dispozice a rozložení ubytovací jednotky a lůžek, potřebné vybavení pokojů, kuchyně, koupelen, blízkost atraktivních bodů vašich zájmů, možnosti nakupování, dopravní možnosti v okolí, design interiéru. Cena je pro mnoho hostů také důležitým faktorem, ale její výkyvy v řádu procent mají minimální vliv na rozhodování. Těžko přimějí rybáře, který hledá blízkost přehrady, k pronájmu luxusního penthouse u nákupního centra, i kdyby snížil cenu o 20%.
Zaměnitelnost ubytovacího zařízení může hrát roli v případě, že existují na stejné ulici 2 vedle sebe stojící konkureční hotely se stejným konceptem, stejnou nabídkou pokojů a stejnou kvalitou služeb. V takovém případě ale nepotřebujete software pro výpočet ceny, ale stačí se občas kouknout na ceník konkurenčního hotelu.
Koncept dynamických cen eshopů je také mimořádně špatně použitelný pro ubytovací zařízení.
Proč?
1 zboží má 1 cenu. Pokud denně změníme 1 cenu, tak to technicky není zásadní problém.
Ale 1 ubytovací jednotka má běžně i několik tisíc různých cen zároveň.
Pokud stanovujeme cenu na 18 měsíců předem, je to 540 různých denních záznamů cenového kalendáře pro 1 jednotku.
Pak můžeme mít ceny pro odlišný počet hostů na pokoji, slevy pro delší pobyty, ceny pro nevratnou sazbu a podobně.
V případě dynamické cenotvorby musíte tedy denně změnit tisíce různých cen (celý budoucí cenový kalendář) pro 1 ubytovacích jednotku. A tyto změny musíte denně odesílat do všech propojených systémů.
Zvýší se vám tržby?
Těžko říct. Kolísání vašich cen bude znamenat, že občas prodáte stejný pokoj o něco dráž, občas o něco levněji. Ve výsledku budou vaše tržby tedy pravděpodobně víceméně obdobé, jako kdybyste dynamické ceny nepoužívali. Buďme ale optimisté a věřme, že tržby budou o pár procent vyšší.
Zvýší se vám náklady?
V každém případě. Za použití software pro dynamickou cenotvorbu zaplatíte nemalé poplatky, řekněme například 150 USD měsíčně za penzion. To ale nebude váš největší náklad.
Pokud budete chtít takový nástroj integrovat, tak vám vzniknou náklady na integraci. A už z bodu 3 víme, že budou extrémně vysoké kvůli povahy cenotvorby ubytovacích zařízení.
Srovnejme náklady se standardním Channel managerem
Standardní Channel manager provádí kompletní přecenění ubytovacího zařízení na počátku při založení systému a pak dejme tomu průměrně 1-2× ročně.
Channel manager pro software pro dynamické ceny bude pro každou ubytovací jednotku, např. pokoj, provádět denní import ze software dynamických cen, tedy interní změnu 540 budoucích záznamů ceníku a denní exporty cen do všech připojených katalogů (tedy 365× ročně kompletní přecenění cenového kalendáře).
Náklady na provoz takového systému tedy budou cca 180× větší a to celé ještě krát počet připojených katalogů Channel managerem.
Váš PMS systém bude muset denně aktualizovat pro 1 pokoj minimálně 540 záznamů interních a provést denně minimálně 540 API exportů pro změny cen krát počet propojených systémů Channel managerem (tzn. pro 3 katalogy = 1620 API exportů jednoho pokoje denně). Pro zjednodušení nebereme vůbec v potaz možnost více cenových kategorií - v takových případech by to byly násobky tohoto čísla.
Pokud tedy náklady na provoz 1 jednotky v klasickém Channel manageru budou např. 37 Kč měsíčně, při napojení 3 katalogů pak celkem 111 Kč měsíčně.
Srovnatelné náklady pro software dynamických cen pak budou bude 180× vyšší × počet katalogů, tedy 180 × 37 Kč × 3 katalogy = 19.980 Kč měsíčně za 1 jednotku (např. pokoj).
Ve výsledku tak:
Jedná se tedy dle našeho názoru o ukázkový příklad extrémně neefektivního systému s minimálním přínosem a astronomickými provozními náklady.
Katalogy z přetěžování svých API systémů denním přeceňováním celého ceníku určitě mít radost nebudou.
API systémy katalogů nejsou vytvořeny za účelem denního přeceňování miliony nadbytečných requestů.
A použitím software pro dynamické ceny dochází k nárůstu zátěže pro všechny zúčastněné servery na minimálně tisícinásobky standardní zátěže.
Pokud by systémy dynamických cen používal jen zlomek procenta provozovatelů v katalozích jako Booking, způsobilo by to zhroucení jejich serverů.
Katalogy mají plnou kontrolu nad četností využívání API requestů každým partnerem a mají nastavené limity jejich používání.
Při překročení limitů dochází k automatickému dočasnému odpojování partnera a při opakovaném porušování mají smluvní možnost permanentního uzavření účtu partnera, který zneužívá jejich API.
Budoucnost samozřejmě věštit neumíme.
Ale můžeme si tipnout.
Jedna z možností je, že katalogy zařadí své interní nástroje pro dynamické ceny.
Provozovatelé, kteří buď chtějí mít pocit, že jejich ceník je "high-tech" nebo mají chuť vyzkoušet "gambling" se svým ceníkem ubytování, si budou moct stanovit limity minimální a maximální ceny a ponechat na katalogu, aby podle aktuální poptávky zkoušel dynamicky snižovat a zvyšovat cenu v povoleném limitu.
Provovozovatel také pravděpodobně nezíská významně větší tržby, ale ani se mu nezvýší náklady.
Jen odpadne celý byznys s přeposíláním milionů zbytečných API requestů denně mezi servery tam a zpět.
Příkladem takového vývoje je nový nástroj Smart Pricing od Airbnb
https://www.airbnb.cz/help/article/1168?_set_bev_on_new_domain=1714496740_MjkwMWVkMDUwYmE3
en
es
cz
sk
pl