Apartma Matevž • Journal
CM Free - Journal serija #2
CM Free - Journal serija #2

CM Free - Journal serija #2

Ustvarjeno 10.06.2026Čas branja 2 minPosodobljeno 16.06.2026
CM FreeJournal serijaBookingApartmentsApartmaji

Pri oddajanju apartmaja hitro prideš do točke, ko podatki prihajajo z več strani.

Nekaj vpišeš ročno. Nekaj pride iz spletne strani. Nekaj pride iz Booking ali Airbnb koledarja. Nekaj nastane, ko gost potrdi povpraševanje. Nekaj dodaš zato, ker potrebuješ čas za čiščenje ali ker želiš termin zapreti.

Na papirju je vse to samo “zasedenost”. V resnici pa ni. Največja nevarnost pri takem sistemu ni to, da nimaš dovolj podatkov. Nevarnost je, da imaš več podatkov, pa ne veš, kateri je pravi. Če en koledar pravi, da je termin prost, drugi pa pravi, da je zaseden, komu sistem verjame?

Če gost odda povpraševanje ravno v trenutku, ko zunanji kanal še ni osvežen, ali je termin res prost?

Če zunanja platforma pošlje blokiran termin, ali to pomeni rezervacijo, lastno uporabo ali samo zaprt datum?

Zato sem v sistemu začel razmišljati o eni notranji resnici. Ne o tem, da bi en zunanji kanal postal glavni. Ne o tem, da bi bil ročni koledar vedno nad vsem. Ampak o tem, da se vsi signali najprej zberejo, razumejo, združijo in šele potem sistem odloči, kaj je operativna resnica.

V tehničnem delu temu pravim "merged occupancy" oziroma združena zasedenost.

V praksi pa to pomeni nekaj zelo preprostega: Preden sistem karkoli obljubi gostu ali pošlje zunanjemu kanalu, mora najprej vedeti, kakšno je trenutno združeno stanje. To je razlika med aplikacijo, ki samo prikazuje koledarje, in sistemom, ki zna sprejemati varne odločitve. Zame je to postalo eno temeljnih pravil:

Najprej povleci podatke, potem jih združi, potem preveri, šele nato pošiljaj naprej.

V praksi bi to lahko zapisali kot: pull → merge → validate → push

To ni samo tehnično pravilo. To je način razmišljanja. Če sistem najprej pošilja podatke navzven, šele potem pa preverja, kaj se je vmes zgodilo, je tveganje veliko. Če pa najprej osveži vhodne podatke, jih združi z lokalnimi odločitvami in šele nato naredi spremembo, postane veliko bolj zanesljiv.

Majhen ponudnik si težko privošči napako. Nima ekipe za podporo, nima oddelka za reklamacije in nima časa razlagati gostu, zakaj je prišlo do prekrivanja. Zato mora biti sistem narejen tako, da napako poskuša preprečiti prej, ne pa popravljati kasneje.

En vir resnice ni filozofija zaradi lepšega. Je varnostni pas.