Son odaya aynı anda iki talep gelirse: rezervasyon yazılımı ne yapar?

Rezervasyon yazılımı son odayı, satılabilir oda-gecelerin tek bir ortak sayacını tutarak ve kontrolü düşürmeyi tek adımda yaparak korur: bir talep kazanır, diğeri reddedilir. Misafir ödeme yaparken oda kısa süreli bir askıyla ayrılır. Koruma, bir kanalın, elle yapılan bir kaydın ya da bir allotmanın bu sayacın dışında kalmasıyla biter.

İki misafir, iki kanal, tek oda. Her iki talep de aynı saniye içinde geliyor ve her iki ekranda da oda boş görünüyor. Bundan sonra ne olacağına, çoğu otelin hiç görmediği birkaç satırlık mantık karar veriyor. Bu yazının sonunda o satırların ne yapması gerektiğini, bir yazılım tedarikçisine bunu nasıl soracağınızı ve her sistemin korumasının nerede bittiğini bileceksiniz.

Aynı anda son odaya iki talep gelirse ne olur?#

Her iki talep de aynı sayaca bakıyorsa, biri odayı alır ve diğeri reddedilir. Bakmıyorsa ikisi de başarılı olabilir ve otel aynı odayı iki kez satmış olur.

Önce satılan birimden başlayalım: oda değil, oda-gece. Üç gecelik bir konaklama üç birim harcar, her gece için bir tane, ve her gece ayrı ayrı kontrol edilir. Bir otelde cuma gecesi son standart oda boş, cumartesi gecesi tamamen dolu olabilir; cumartesiye sarkan bir talep, cumartesi kontrolünde başarısız olmak zorundadır.

Her rezervasyon talebi sırayla üç iş yapar: sayacı oku, karar ver, yeni sayacı yaz. Tehlike, okuma ile yazma arasındaki boşlukta yaşar. Her iki okuma da herhangi bir yazmadan önce gerçekleşirse, iki talep de bir oda boş görür ve ikisi de ilerler. Bu klasik yarıştır ve yazılımın hızıyla ilgisi yoktur. Kontrolü düşürmeden ayıran her sistemde, son odaya aynı anda gelen iki talep çarpışır.

Kaybeden talebin sessizce kaybolması değil, net bir yanıt alması gerekir: bir ret, bekleme listesi kaydı ya da resepsiyonun sunabileceği alternatif bir tarih. Ödemeden önceki ret bir özürle atlatılır; ödemeden sonraki ret bir misafir, bir iade ve bir yorum demektir. Onay bir sözdür ve sistem yalnızca tutabileceği sözü vermeli.

Hız hâlâ önemlidir ama belirleyici değildir: bir saniyede yanıt veren ve ara sıra aynı odayı iki kez satan bir sistem, yavaş ama bunu hiç yapmayan bir sistemden pahalıdır.

Tek sayaç, tek kontrol: ortak oda sayacı çift rezervasyonu nasıl önler?#

Ortak sayaç, hâlâ satışta olan oda-gecelerin sayısını tutan tek bir kayıttır ve otelin kontrol ettiği her talep bu kaydın içinden geçmek zorundadır. Koruma, kontrolü düşürmeyi bölünmez tek bir adım haline getirmekten gelir.

Düz bir dille: sayıyı oku, karar ver, yeni sayıyı yaz. Bu üçü tek adımda olursa, aralarına başka hiçbir talep giremez. Veritabanları bunu yapabilir. Koşullu yazma denen yöntemde, yazma işlemi yalnızca değerin az önce okunan değer olması durumunda başarılı olur; başka bir talep değeri çoktan değiştirdiyse yazma başarısız olur ve talep reddedilir. Bu özel bir özellik değil, standart bir veritabanı yeteneğidir; bunu bu terimlerle anlatamayan bir tedarikçiye tekrar sormak gerekir.

Sayaç, resepsiyon, otelin kendi web sitesi, acenteler ve otel adına rezervasyon yapan herhangi bir yapay zekâ asistanı için aynı olmak zorundadır. İki sayaç, aynı odayı iki kez satmanın iki şansıdır. Müsaitlik ayrıca oda tipi ve tarih bazında olmalı, tek bir manşet sayı olmamalıdır: tek bir "kalan oda" sayısı, gerçekte hangi gecenin gittiğini gizler.

İkinci talep, neden başarısız olduğunu öğrenmelidir; böylece resepsiyon başka bir oda tipi ya da tarih önerirken tahmin yürütmek zorunda kalmaz. Nedeni olan ret bir hizmet telafisidir; nedeni olmayan ret bir omuz silkmedir.

Örneğin: 12 Eylül gecesi için bir standart oda kalmış. İki talep birlikte geliyor. İlki sayacı sıfıra düşürüyor ve onaylıyor; ikincisi sıfır buluyor ve nedeni ekranda görünen bir ret alıyor.

Üç adım, yan yana#

Her iki okuma da sayaç 1 iken yapıldı, bu yüzden iki talep de odanın kendisine ait olduğuna inandı. Şimdi aynı diziyi, kontrol ve yazma birleşik tek adımla izleyelim:

Talep B'nin kontrolü artık sıfır döndürüyor, çünkü A'nın kontrolü ve yazması tek adımdı. Aynı mekanizma otel gruplarını da kapsar: tek giriş, çok sayıda tesis, yine de tesis başına ve gece başına tek sayaç. AI Otel'in rezervasyon sistemi bu ilke üzerine geliştirildi; kanal başına ayrı sayaçlar yerine, web sitesini, rezervasyon sitelerini, acenteleri ve yapay zekâ asistanlarını besleyen tek bir oda envanteri için geliştirildi.

Rezervasyon askısı nedir, ne zaman biter?#

Askı, misafir ödemeyi tamamlarken odayı kısa süreliğine kenara ayırır ve bu süre boyunca satılmış sayılmalıdır. Ödeme yapılmadan süresi dolarsa, oda otomatik olarak sayaca geri döner.

Askılar, ödemenin zaman aldığı için vardır: kart yetkilendirmesi, banka yönlendirmesi, yavaş bir bağlantı. Askı olmadan, bir misafir yazı yazdığı sırada satılmış bir odaya ödeme yapabilir. Askı, sistemin parayı beklemeden envanteri harcama biçimidir.

Yalnızca rezervasyon ekranında yaşayan bir askı hiçbir şeyi korumaz. Odanın sayaçtan düşmesi, ödeme tahsil edildiğinde değil, askı oluşturulduğu anda olmalıdır. Süre sonu otomatik ve otelin belirlediği biçimde olmalıdır: ancak biri hatırlayıp serbest bıraktığında geri dönen oda, bütün hafta sonu kapalı kalan odadır. Askının süresinin dolması kadar terk edilmesi de önemlidir; tarayıcıyı kapatan bir misafir, odayı bir saat boyunca tutmamalıdır.

En sıkıntılı durum, ödemenin süre bitiminden hemen sonra başarılı olmasıdır. Kuralı önceden belirleyin: ödemeyi reddedin ya da başka bir oda bulun ve misafire varışından önce haber verin. İkisi de savunulabilir; bu durumu gece saat 11'de ilk kez keşfetmek savunulabilir değildir.

Ödünleşme gerçektir. Uzun askı ödeme yapan misafiri korur ve envanteri tıkar. Kısa askı envanteri serbest bırakır ve yavaş bir ödemenin başarısız olma olasılığını artırır. Askılar, otelin elle onayladığı acente talepleri için de geçerlidir; orada talep kartı değil bir kişiyi bekler.

Bu koruma nerede bitiyor?#

Otelin kendi sayacının sınırında biter. Bir acente ya da rezervasyon sitesi müsaitliğin kendi kopyasını tutar ve orada yapılan rezervasyon, otelin sistemi haber almadan önce gerçektir.

Kanal gecikmesi ilk boşluktur. Müsaitlik dışarı gider, rezervasyonlar geri gelir; bu pencere içinde satılan her şey, otel boşluğu yönetmedikçe iki kez satılır. Yönetim genellikle pencereyi kısa ve dışa güncellemeleri sık tutarak yapılır. Bir kanal yöneticisi bu pencereyi kısaltır, kapatmaz; bu konuya SSS'de ve çift rezervasyon neden olur, kanallar arasında nasıl önlenir? yazısında geri döneceğiz.

Elle yapılan kayıtlar ikinci boşluktur. Kâğıt üzerinde bloke edilen bir oda, sistem güncellenmeden resepsiyonda uzatılan bir konaklama, bakım için satıştan çıkarılıp geri hiç konulmayan bir oda: her biri sayacı sessizce bozar. Kapıdan gelen misafirler ve aynı gün satışları, sayacın en çok bayatladığı yerdir, çünkü insanların en hızlı çalışıp en az kontrol yaptığı an odur.

Allotmanlar üçüncü boşluktur. Bir acenteye bağlı tutulan odalar serbest satışın dışındadır ve sayaç, neyin bağlandığını, ne kadarının bloktan kullanıldığını (pick-up) ve neyin hangi tarihte geri döndüğünü göstermek zorundadır. Başlangıçta ne kadar bağlamanız gerektiği ayrı bir karardır; allotment mı, free sale mi? Acentelere ne kadar kontenjan verilmeli? yazısında ele alıyoruz.

Çalışma kuralı şu: aynı müsaitlik iki yerde varsa, biri yanlıştır ve hangisi olduğunu mutabakat yapana kadar bilemezsiniz. Mutabakat bir olağanüstü durum değil, rutindir. Sistemi her kanalla sabit bir takvimde karşılaştırın ve her farkı, nedeniyle birlikte yazın.

Peki oda ataması ve gruplar?#

Bir oda-gece satmak ile belirli bir odayı atamak iki ayrı karardır ve bu ikisini karıştırmak, resepsiyondaki kafa karışıklığının çoğuna neden olur.

Sayaç, oda-geceleri tipe göre satar. Atama ise fiziksel bir oda numarası seçer; ya önceden ya da giriş (check-in) sırasında, yani satış sırasında değil sonrasında yapılır. Aynı oda tipi için iki misafirin rezervasyonu tamamen geçerli olabilir ve yine de aynı oda numarasına yönlendirilebilirler. Bu bir envanter hatası değil, atama hatasıdır ve farklı bir kontrol gerektirir.

Gruplar üçüncü katmanı ekler. Bir blok, belirli bir dönem için bir dizi odayı ayırır. Bloktan kullanılan oda sayısı (pick-up), grubun gerçekte aldığıdır. Serbest bırakılmayan odalar belirtilen bir tarihte satışa dönmeli, yoksa blok otelin en iyi gecelerini sessizce yutar.

Aşırı rezervasyon bilinçli bir tercih olabilir: bir otel, iptalleri göze alarak elindekinden fazla oda-gece satmayı seçebilir. Bu, bir maliyeti olan ticari bir karardır ve olduğu gibi kayda geçirilmelidir. Herhangi bir sistemde doğrulanacak nokta şudur: sistem aynı odaya aynı gece için iki etkin rezervasyon atanmasını reddetmeli ve bloğu, bloktan kullanılan oda sayısını ve odaların satışa dönüş tarihini tek bir görünümde göstermelidir.

AI Otel'in rezervasyon sistemi bu konuda ne yapıyor?#

AI Otel'in otel işletim sistemi, rezervasyon, grup ve oda atamasını aynı odanın iki kez satılmasına karşı korunaklı biçimde tek sistemde tutar. Durumu geliştirildi: çalışan yazılım, lansman öncesi.

Bu cümleyi yazıldığı gibi okumak gerekir. Sıfır çift rezervasyon vaat etmez ve hiçbir sistem edemez. Sayaç, içinden geçeni korur; yukarıda anlatılan boşluklar otelin kanallarına ve alışkanlıklarına aittir. Aynı envanter, otelin kendi web sitesini, rezervasyon sitelerini, seyahat acentelerini ve yapay zekâ asistanlarını tek yerden besleyecek şekilde geliştirildi. Rezervasyon siteleri Channex entegrasyonumuzla canlıya geçiş öncesi test aşamasında; dağıtım merkezine henüz bağlı bir acente yok. Nelerin geliştirildiği ve nelerin olmadığı dahil geniş tablo, bir satış iddiasında değil platform sayfalarında ve AI Otel otel işletim sistemi: neler geliştirildi, neyi kapsıyor? yazısında durur.

Şimdi ne yapmalı#

Gelecek haftadan tek bir oda-gece seçin ve müsaitliğinin yazıldığı her yeri izleyin: resepsiyon ekranı, web siteniz, her rezervasyon sitesi, her acente allotmanı. Kopyaları sayın. Bu sayı, mevcut kurulumunuzun gerçekte ne kadar koruma verebildiğini söyler; yukarıdaki bölümler ise bulduğunuz her kopya için ne yapmanız gerektiğini anlatır. Tek bir sayacın aynı anda gelen iki talep altında nasıl davrandığını görmek isterseniz, görüşme talep edin.