Apartma Matevž • Journal
CM Community — kaj če bi se neodvisni Channel Managerji lahko povezali?
CM Community — kaj če bi se neodvisni Channel Managerji lahko povezali?

CM Community — kaj če bi se neodvisni Channel Managerji lahko povezali?

Ustvarjeno 10.08.2026Posodobljeno 13.08.2026

Nekatere ideje nastanejo zato, ker jih načrtuješ. Druge odkriješ med reševanjem povsem drugega problema.

Pred nekaj dnevi smo iskali precej konkretno rešitev. CM Plus in CM PRO potrebujeta pravo dvosmerno povezavo z Booking.com, Airbnb in drugimi rezervacijskimi kanali. Ker neposredna pot do njihovih API-jev ni vedno odprta, smo začeli raziskovati certificirane connectivity ponudnike.

Tako smo prišli do Channexa.

OTA API povezave med gostitelji in Platformami

- In nato do ideje CM Relay.

Prvotni namen je bil preprost: CM → CM Relay → Connectivity Provider → Booking.com / Airbnb

To bi CM Free/Plus/PRO omogočilo, da bi preko enega ponudnika API povezav(takojšnje posodobitve zasedenosti), dobili možnost povezovanja več kanalov za več enot, in ne nazadnje za več Free/Plus/PRO instalacij.

Relay bi omogočil, da številne neodvisne CM instalacije uporabljajo skupno certificirano povezovalno infrastrukturo, medtem ko vsaka lokalna namestitev še vedno ostane gospodar svojih rezervacij, cen, razpoložljivosti in pravil.

Toda ko smo začeli postavljati njegovo osnovno arhitekturo, se je pojavilo precej bolj zanimivo vprašanje.

Zakaj bi Relay znal samo posredovati podatke do Booking.com?

Relay, ki zna več kot samo posredovati

CM Free, CM Plus in CM PRO so zasnovani kot samostojne namestitve. To želimo ohraniti.

CM Free mora še vedno delovati brez centralnega računa, brez naročnine in brez obveznega priklopa na naš strežnik.

Toda v Free lahko dodamo nekaj drugega:

  • Connector.
  • Ne avtomatske telemetrije.
  • Ne skritega »phone home«.

Ampak možnost, da se uporabnik zavestno odloči:

Želim svojo namestitev priključiti v CM ekosistem. Takrat Relay nenadoma ni več samo tehnični most do OTA platform.

Postane lahko priklopna točka med neodvisnimi CM sistemi.

## CM Community

Predstavljajmo si,da ima nekdo

  • CM Free v Sloveniji.
  • Drug ponudnik uporablja CM Plus v Avstriji.
  • Tretji CM PRO na Hrvaškem.

Vsaka namestitev ostaja neodvisna.

Vsak ponudnik še vedno upravlja svoje podatke.

Toda vsi trije so se prostovoljno odločili deliti določene javne informacije:

  • lokacijo
  • kapaciteto
  • osnovne lastnosti nastanitve
  • javno razpoložljivost
  • morda javno ceno
  • povezavo za neposredno rezervacijo

Relay lahko iz tega ustvari nekaj, česar nobena posamezna CM instalacija ne more ustvariti sama.

##MREŽO

In tu se ideja Channel Managerja začne nekoliko spreminjati.

Ne samo:

  • Upravljaj moje kanale.

Ampak tudi:

  • Poišči drugega ponudnika, kadar jaz nimam prostora.

Kaj če sem poln?

To je eden najbolj naravnih primerov.

Gost povpraša za štiri noči.

Moja nastanitev je zasedena.

Danes lahko odgovorim:

Žal nimamo prostega termina.

CM Community pa bi lahko omogočil drugačen odgovor:

Mi smo zasedeni, vendar so v bližini trenutno proste tri nastanitve iz CM Community.

To ni Booking.com.

Ni centralni PMS.

Ni nova OTA platforma.

Je referral med neodvisnimi ponudniki.

CM Comunity
Povezava različnih CM platform v skupnost
## In potem pride AI
**Tu postane stvar še bolj zanimiva.**

Gost oziroma uporabnik ne bi nujno moral izpolnjevati klasičnega iskalnega obrazca.

Lahko bi vprašal:

Iščem apartma za štiri osebe v okolici Bleda naslednji vikend. Potrebujem parkirišče in možnost polnjenja električnega avtomobila. Do približno 180 EUR na noč.
AI ima pri tem zelo natančno omejeno nalogo.

- Ne določa, kaj je prosto.
- Ne izmišljuje cen.
- Ne odloča namesto Channel Managerja.

 Prevede vprašanje:
naravni jezik
      ↓
strukturirana poizvedba
      ↓
CM Community
      ↓
dejanska availability

CM ostane source of truth.
### AI je samo bolj naraven vhod v podatke.
To je pomembna meja.
AI ima pri tem zelo natančno omejeno nalogo.
Ne določa, kaj je prosto.
Ne izmišljuje cen.
Ne odloča namesto Channel Managerja.
Prevede vprašanje:
naravni jezik
      ↓
strukturirana poizvedba
      ↓
CM Community
      ↓
dejanska availability
CM ostane source of truth.
AI je samo bolj naraven vhod v podatke.
To je pomembna meja.

                  Booking.com
                       │
Airbnb ──────────── CM Relay ─────────── AI
                       │
       ┌───────────────┼───────────────┐
       │               │               │
    CM Free         CM Plus          CM PRO
       │
       ├──────── regional tourism portal
       ├──────── another PMS
       ├──────── discovery service
       └──────── something we do not know yet
In ravno zadnja vrstica je morda najpomembnejša.
Something we do not know yet.
Dobra infrastruktura omogoča stvari, ki jih njen avtor ob nastanku ni mogel predvideti.

Mednarodna vesoljska postaja

Med razmišljanjem o tej arhitekturi se je pojavila nekoliko nenavadna primerjava.

Mednarodna vesoljska postaja.

Njena vrednost ni samo v tem, kaj je bilo nanjo priključeno prvi dan.

Pomembno je, da ima priklopna mesta.

CM Relay bi lahko imel podobno vlogo.

Ali mora drugi sistem sploh uporabljati CM?

Morda ne.

Če bo nekega dne obstajal dovolj jasen CM Community protocol, bi lahko nek drug mali PMS implementiral svoj Connector.

Ne bi mu bilo treba namestiti CM.

Moral bi samo razumeti dogovorjeni način komunikacije.

Na primer:

  • property discovery
  • availability query
  • capability discovery
  • referral
  • booking handoff

CM Free bi bil lahko prva javna referenčna implementacija. Toda Community bi lahko nekoč postal večji od samega CM. To je za zdaj samo smer razvoja. In ravno zato ta dokument objavljamo zdaj.

Zakaj objaviti idejo, preden je končana?

Običajno se programske projekte predstavi, ko so dokončani.

Pri CM smo večkrat delali drugače.

Najprej smo opisali problem. Nato arhitekturo. Potem smo jo preizkusili v resnični uporabi.

CM Community ima dodatno posebnost:

Community ideja nima veliko smisla, če je skrita .

Če želimo nekoč omogočiti priklop drugim sistemom, morajo vedeti, da priklopna točka obstaja.

Zato ta članek ni predstavitev končanega izdelka.

Je RFC — Request for Comments.

Povabilo k razmišljanju.

Toda ena stvar mora ostati lokalna.

Ko smo začeli govoriti o API povezljivosti, je eden naših resnih beta uporabnikov izpostavil zelo praktičen strah.

  • Kaj se zgodi, če API odpove?
  • Kaj če connectivity provider ne deluje?
  • Kaj če račun po pomoti ni plačan?
  • Kaj če naš Relay ni dosegljiv?
  • Ali Channel Manager takrat preneha upravljati kanale?

Odgovor mora biti:

Ne.

Zato smo sprejeli eno precej trdno arhitekturno odločitev.

ICS ostane. 
V CM Free.
V CM Plus.
V CM PRO.
Tudi če je API omogočen.
API deluje
     ↓
API je primarna povezava

API odpove
     ↓
CM ostane lokalen
     ↓
ICS ostane varnostna pot
Ta stran je v delu malo dalj časa, ker se med delom spreminja in dograjuje tudi Journal-editor ki sedaj omogoča bolj bogato vsebino.

ICS seveda ne ponuja vseh zmožnosti pravega API-ja.

Ne zna vsega, kar lahko naredijo ARI, restrictions, messaging ali druge napredne funkcije.

Toda osnovna kontinuiteta koledarja ne sme biti odvisna od enega plačljivega servisa.

API mora izboljšati Channel Manager, ne pa ga držati za talca To je morda najbolj pomembno načelo današnje arhitekture. API connectivity should improve a Channel Manager, not become the single point that can kill it.

Če Channex izgine, CM ostane.

Če se pozneje odločimo za Beds24, Relay ostane.

Če Booking.com nekoč ponovno odpre neposredni connectivity onboarding:

ChannexAdapter lahko postane:BookingNativeAdapter

Če centralni servis ni plačan:lokalni CM še vedno deluje.

Če uporabnik nikoli ne želi Community:CM Free še vedno deluje. Če uporabnik ne želi nobenega centralnega servisa:CM ostane njegov.

Kaj trenutno dejansko obstaja?

Pomembno je ločiti idejo od produkta.

CM Community danes še ni izdelan.

CM Relay ima šele začetno barebone strukturo.

Trenutno postavljamo arhitekturne temelje:

• installation identity, • Connector, • capability model, • consent, • provider-neutral events, • connectivity health, • pripravo na OTA adapterje.

Community, Sharing in AI Discovery so naslednje možne plasti. Zato se bodo podrobnosti skoraj zagotovo spremenile. Tudi to je razlog, da temu dokumentu pravimo:

CM Community RFC 001.

Community ni izdelek, ki ga lahko zgradiš sam To je nekoliko nenavadna ugotovitev za projekt, ki je doslej večinoma rasel iz lastne potrebe.

  • Channel Manager lahko narediš sam.
  • Guestbook lahko narediš sam.
  • Financing lahko narediš sam.
  • Tudi Relay lahko tehnično narediš sam.

Toda Community obstaja šele, ko se priključi nekdo drug. Zato je naslednja razvojna faza nekoliko drugačna. Ne gradimo samo funkcije.

Gradimo vrata.

In za zdaj še ne vemo, kdo bo nekoč potrkal nanje. Toda vrata bodo tam.

Status projekta

  • CM Community / Relay
  • Concept + architecture in development
  • CM Relay barebone
  • Development started
  • OTA Connectivity
  • Provider evaluation / adapter architecture
  • CM Community
  • RFC / design stage
  • AI Discovery
  • Concept
  • ICS fallback
  • Permanent CM core requirement

Ne predstavljamo končanega CM Community. Dokumentiramo trenutek, ko je ideja postala dovolj konkretna, da smo jo začeli graditi.

##Relay je dobil prvo okostje.

Kaj bo nekoč priključeno nanj, pa bo — tako kot pri večini CM-ja doslej — pokazala resnična uporaba.

Morda gradimo samo most do Booking.com.

Morda pa smo pravkar naredili prvi priklop na precej večjo postajo.

CM Community — What If Independent Channel Managers Could Form a Network?