Turizmde Kanal Yöneticisi Entegrasyonu: Müsaitlik, Fiyat ve Rezervasyon Akışı Nasıl Kurgulanır?

Bir otelin aynı odası aynı gece hem kendi web sitesinden hem de birkaç OTA kanalından satılabilir. Kanal yöneticisi entegrasyonu iyi kurgulanmadığında sonuç bilinen sorunlardır: çifte rezervasyon, yanlış fiyatla satılan odalar ve resepsiyonda elle yapılan düzeltmeler. Bu hatalar misafir deneyimini bozar, ekibin zamanını alır ve kanal puanlarını etkileyebilir.

Bu yazıda rezervasyon motoru, otel yönetim sistemi ve OTA arasındaki veri akışını sade bir çerçevede ele alıyoruz. Müsaitlik, fiyat ve rezervasyon akışının nasıl düzenleneceğini ve KBS kimlik bildirimi ile KVKK açısından hangi noktalara dikkat edileceğini somut adımlarla anlatıyoruz.

01Üç sistem, dört veri akışı: büyük resim

Konaklama işletmelerinde genellikle üç katman birlikte çalışır:

• Rezervasyon motoru: Web sitenizden doğrudan satışı alır.
• Otel yönetim sistemi: Oda envanterini, check-in/check-out işlemlerini ve misafir kaydını yönetir.
• Kanal yöneticisi ya da doğrudan OTA bağlantısı: Booking, Expedia gibi kanallara envanter ve fiyat dağıtır, oradan gelen rezervasyonları geri alır.

Bu üç sistem arasında dört temel akış vardır:

1. Müsaitlik: Hangi oda tipinden, hangi gece kaç adet satılabilir?
2. Fiyat ve kısıtlar: Gecelik fiyat, pansiyon tipi, minimum konaklama, giriş/çıkış kısıtı.
3. Rezervasyon: Yeni kayıt, değişiklik, iptal ve gelmeme durumu.
4. Misafir ve kimlik verisi: Check-in sırasında toplanan, KBS bildirimine ve kayıtlara konu olan bilgi.

Tasarımın ilk kuralı şudur: her veri türü için tek bir doğruluk kaynağı belirleyin. Envanter ve rezervasyon durumu için bu kaynak çoğunlukla otel yönetim sistemidir. Diğer sistemler bu kaynağı besler ya da ondan beslenir, ancak birbirleriyle yarışmaz.

02Kanal yöneticisi entegrasyonu öncesinde netleştirilecek noktalar

Kod yazmadan önce aşağıdaki başlıkları yazılı hâle getirmek, sonradan çıkacak sorunların büyük kısmını önler:

• Oda tipi eşleştirme: OTA’daki “Deluxe Deniz Manzaralı” odası otel yönetim sisteminde hangi kodla izleniyor? Bire bir eşleşmeyen tipler için kural belirleyin.
• Fiyat planı eşleştirme: Oda + kahvaltı, yarım pansiyon, iptal edilebilir ve edilemez tarifeler ayrı kodlanmalıdır.
• Bağlantı yöntemi: Kanal yöneticisi üzerinden mi, doğrudan OTA API’leri üzerinden mi bağlanacaksınız? Kanal sayınız ve ekibinizin işletme kapasitesi bu kararı etkiler.
• Hata sahipliği: Bir mesaj iletilemediğinde kim uyarılır, kim müdahale eder?
• Test ortamı: OTA ve kanal yöneticisi tarafındaki test erişimleri ile onay adımları sağlayıcıya göre değişir; bunları projenin takvimine baştan yazın.
• Para birimi ve vergi: Fiyatlar vergi dahil mi, hariç mi aktarılacak? Kur dönüşümü nerede yapılacak?

Bu liste keşif toplantısının gündemi olarak da kullanılabilir. Eşleştirme tabloları çoğu projede en çok emek isteyen, ama en çok hata önleyen çalışmadır.

03Müsaitlik ve fiyat akışı: envanter tek yerde düşer

Çifte rezervasyonun temel nedeni, aynı envanterin iki yerden aynı anda satılmasıdır. Örnek bir senaryo ile düşünelim: Otelinizde beş deluxe oda var. Web sitesinden bir rezervasyon geldi ve envanter dörde indi. Bu bilginin kanal yöneticisi aracılığıyla OTA’lara gitmesi için geçen kısa sürede başka bir OTA rezervasyonu da düşebilir. Riski azaltmak için şu yöntemler birlikte kullanılır:

• Sıralı işleme: Envanter değişiklikleri bir kuyruğa alınır ve sırayla işlenir. İki rezervasyon aynı anda gelse bile envanter tutarlı kalır.
• Yeniden deneme: İletilemeyen güncelleme kaybolmaz, tekrar denenir ve başarısızlıkta uyarı üretir.
• Periyodik mutabakat: Otel yönetim sistemindeki envanter ile kanallardaki envanter belirli aralıklarla karşılaştırılır, fark varsa raporlanır.
• Emniyet payı: Yoğun dönemlerde kanallara gerçek envanterin bir miktar altını açmak, işletme politikanıza bağlı bir tasarım seçeneğidir.

Fiyat akışında ise kuralların nerede tanımlandığı önemlidir. Baz fiyatı ve kampanya kurallarını tek yerde tutup kanallara türetilmiş fiyat göndermek, her kanalda elle fiyat girmekten daha az hata üretir. Minimum konaklama ve giriş/çıkış kısıtlarını da fiyatla birlikte aynı pakette taşıyın; aksi hâlde doğru fiyat yanlış kısıtla yayınlanabilir.

04Rezervasyon akışı: yeni, değişiklik, iptal

OTA’dan gelen bir rezervasyonun otel yönetim sistemine ulaşma yolunu adım adım şöyle düşünebilirsiniz:

1. Kanaldan rezervasyon mesajı alınır.
2. Oda tipi, tarih, fiyat planı ve misafir sayısı doğrulanır.
3. Otel yönetim sisteminde kayıt oluşturulur ve OTA rezervasyon numarası saklanır.
4. Envanter güncellenir ve kanallara yeni müsaitlik gönderilir.
5. Kanala onay döndürülür; hata varsa kayıt kuyrukta bekletilir ve ekip uyarılır.

Değişiklik ve iptal mesajları da aynı hat üzerinden, aynı doğrulama kurallarıyla işlenmelidir. Burada iki teknik ilke öne çıkar:

• Tekrar güvenliği (idempotency): Aynı rezervasyon mesajı iki kez gelirse sistemde iki kayıt oluşmamalı, mesaj OTA rezervasyon numarasıyla eşleştirilip tek kayıt güncellenmelidir.
• İzlenebilirlik: Her mesajın ne zaman alındığı, nasıl işlendiği ve sonucunun ne olduğu kayıt altında tutulmalıdır. Misafir “iptal etmiştim” dediğinde cevap bu kayıtlarda bulunur.

Ödeme tarafında kart verisini kendi sistemlerinizde tutmamak en güvenli yoldur. Barındırılan ödeme sayfası ya da tokenizasyon kullanıldığında PCI DSS kapsamı daralır. Bu konuyu rezervasyon motoru tasarlanırken değil, projenin başında karara bağlayın.

05KBS bildirimi ve KVKK: ayrı ayrı ele alınmalı

Konaklama sektöründe kişisel veri iki farklı yükümlülükle karşınıza çıkar ve bunları karıştırmamak gerekir.

KBS kimlik bildirimi: Konaklama kaydı için yapılan bildirim, check-in anında toplanan kimlik bilgilerine dayanır. OTA’dan gelen rezervasyon mesajı bu bildirim için çoğu zaman yeterli veri taşımayabilir. Bu nedenle akışı şöyle kurgulayın:

• Kimlik bilgisi check-in sırasında otel yönetim sisteminde toplanır.
• KBS’ye aktarım otel yönetim sisteminden yapılır; rezervasyon motoru ve kanal yöneticisi bu akışın dışında kalır.
• Bildirimin süre ve biçim şartlarını ilgili mevzuattan ve KBS sağlayıcısının güncel yönergelerinden teyit edin; entegrasyonu bu şartlara göre sınayın.

KVKK: Misafir verisinin pazarlama amacıyla kullanılması konaklama kaydından ayrı bir süreçtir. Aydınlatma metni, açık rıza ve İYS kaydı pazarlama iletişimi için ayrıca ele alınmalıdır. Teknik tarafta şunlara dikkat edin:

• Rol bazlı erişim: Resepsiyon, rezervasyon ve pazarlama ekiplerinin gördüğü alanlar farklı olsun.
• Erişim kaydı: Kimlik bilgilerine kimin ne zaman eriştiği izlenebilsin.
• Log hijyeni: Entegrasyon logları kimlik ya da pasaport numarası gibi alanları açık metin olarak içermesin; maskeleme uygulayın.
• Saklama süresi: Rezervasyon ve kimlik verisi için süreler tanımlanıp süresi dolan veri silinsin ya da anonimleştirilsin.

06Sık sorulan sorular

Kanal yöneticisi mi kullanmalıyız, doğrudan OTA API’leri mi?

İşletmenizin kanal sayısına, ekibin işletme kapasitesine ve mevcut sistemlerinize bağlıdır. Kanal yöneticisi tek noktadan birçok kanala dağıtım sağlar. Doğrudan API bağlantısı ise daha fazla kontrol verir, ancak her OTA için ayrı bakım gerektirir. Karar, keşif aşamasında bu kriterlerle birlikte verilmelidir.

Çifte rezervasyon riski tamamen ortadan kalkar mı?

Dağıtık sistemlerde sıfır risk vaadi gerçekçi değildir. Sıralı işleme, yeniden deneme, periyodik mutabakat ve gerekirse emniyet payı birlikte uygulandığında risk belirgin biçimde azalır ve oluşan farklar hızlı fark edilir.

OTA’dan gelen misafir verisini kampanyada kullanabilir miyiz?

Kullanılabilir; ancak pazarlama iletişimi için açık rıza ve İYS kaydı gerekir. Konaklama kaydı için KBS bildirim yükümlülüğü ise bundan bağımsızdır. İkisini ayrı süreçler olarak yönetmek ve kampanya listelerini yalnızca izinli misafirlerle oluşturmak doğru yaklaşımdır.

07Sonuç

Sağlam bir kanal akışı; tek doğruluk kaynağı, net eşleştirme tabloları, kuyruklu ve izlenebilir mesajlaşma ile KBS ve KVKK süreçlerinin baştan tasarlanmasına dayanır. Rezervasyon motoru, otel yönetim sistemi ve OTA arasındaki akışı bu çerçevede ele almak isterseniz, OPEIS Teknoloji’nin sektöre yönelik yaklaşımını Turizm ve Konaklama Çözümleri sayfasında inceleyebilirsiniz.