Sekizinci tedarikçiyi bağladığınız gün envanteriniz sekiz katına çıkmadı. Arama sonucu uzadı, sayfa yavaşladı, aynı otel listede üç kez belirdi ve rezervasyon personeli hangisini satacağını sormaya başladı. Bu, entegrasyonun kötü yapıldığı anlamına gelmez. Çok tedarikçili envanterin doğal davranışı budur: her tedarikçi aynı fiziksel tesisi kendi kodu, kendi isim yazımı ve kendi içerik kalitesiyle gönderir.
Kazanç bağlantı sayısında değildir. Kazanç, bu çakışan görünümleri tek bir doğru kayda indirgeyen üç kararda saklıdır: hangi kayıtların aynı otel olduğuna nasıl karar verdiğiniz, aynı otelin iki teklifi geldiğinde hangisinin satışa çıkacağı ve iki kaydı birleştirirken hangi alanları harmanlayıp hangilerine asla dokunmayacağınız. Üçüncüsü en az bilineni ve en pahalısıdır; çünkü yanlış birleştirilmiş bir iptal politikası müşteriye yanlış koşul okutur ve farkı acente öder.
Bu yazı, kontrat ve ürün tarafında çalışan bir yöneticinin bu üç kararı verirken kullanabileceği eşikleri, karar sıralarını ve kontrol rutinlerini topluyor. Kendi kontrat otellerinizi de aynı listeye soktuğunuzda devreye giren allotment, stop-sale ve release üçgeni de dâhil. Hiçbir yazılım kullanmasanız bile buradaki kuralların çoğu bir Excel dosyasında ve bir haftalık toplantı gündeminde uygulanabilir.
Problem ikinci tedarikçide başlar, sekizincide yönetilemez hâle gelir
Tek tedarikçiyle çalışırken mükerrer kayıt diye bir sorununuz yoktur. İkinci tedarikçiyi bağladığınız anda aynı tesis iki kez görünmeye başlar. Buradan sonrası doğrusal değil, çarpımsal büyür: her yeni kaynak, mevcut tüm kaynaklarla ayrı ayrı çakışır.
Çakışmanın büyüklüğü sanıldığından yüksek. Vervotech'in 2026 tarihli otel eşleştirme rehberine göre Dubai, Bangkok veya Londra gibi büyük bir pazarda herhangi iki tedarikçi arasındaki envanter çakışması rutin olarak %60'ı aşıyor. Aynı kaynak, orta ölçekli bir çevrimiçi seyahat acentesinin er ya da geç 15 tedarikçiye bağlandığını belirtiyor. Yani 15 temiz liste değil, aynı tesislerin büyük ölçüde üst üste binen 15 görünümü yönetilir.
İşin bir de hareketli tarafı var. AltexSoft'un GIATA verisine dayandırdığı analize göre, GIATA'nın yirmi yıllık istatistiği otellerin yaklaşık %2'sinin her yıl köklü bir değişiklik geçirdiğini gösteriyor: isim değişikliği, zincir bağlantısının değişmesi veya iletişim bilgisinin güncellenmesi. 3.000 otellik bir kataloğunuz varsa yılda yaklaşık 60 tesisin kimlik bilgisi kayar. Eşleştirme bir kez yapılıp bitirilen bir iş değil, bakımı olan bir varlıktır.
| Bağlı tedarikçi | Pratikte ne olur | Ne yapılmalı |
|---|---|---|
| 1 | Mükerrer yok, karşılaştırma da yok | Eşleştirmeye gerek yok |
| 2-3 | Mükerrer görünür hâle gelir, elle ayıklanabilir | Kanonik kimlik tanımı başlatılır |
| 4-7 | Personel hangisinin ucuz olduğunu göremez | Eşleştirme kaynağı ve kazanan teklif kuralı şart |
| 8+ | Eşleştirmesiz liste satılamaz durumdadır | Oda seviyesi eşleştirme ve keşif kaydı rutini gerekir |
Bu tablodaki eşik şudur: dördüncü tedarikçiden itibaren eşleştirme bir iyileştirme değil, ön koşuldur. Bu noktadan sonra elle ayıklama insan gücüyle yetişilebilir bir iş olmaktan çıkar.
Kanonik otel kimliği: "tek doğru kayıt" fikri
Tedarikçi otel kodu bir kimlik değildir; o tedarikçinin kendi kataloğundaki sıra numarasıdır. Aynı tesis dört kaynakta dört farklı kod taşır. Kanonik otel kimliği, bu kodların hepsini tek bir fiziksel tesise bağlayan üst kayıttır. Bu kayıt kurulduktan sonra "aynı otel mi?" sorusu bir daha personelin önüne gelmez.
Aynı tesis dört kaynakta dört farklı kod ve dört farklı isim yazımıyla gelir. Kanonik kimlik bunları tek karta indirger; en düşük teklif satışa çıkar, diğerleri karşılaştırma için arkada tutulur.
Eşleştirme kararı tek bir alana bakarak verilemez. İsim yazımı tedarikçiden tedarikçiye değişir ("GRAND MARINA RESORT SPA" ile "Hotel Grand Marina Resort and Spa" aynı tesistir), koordinat bazen tesisin girişini bazen otoparkını gösterir, adres formatı ülkeye göre farklıdır. Bu yüzden karar, normalize edilmiş isim, koordinat yakınlığı, adres/posta kodu ve yıldız-tesis tipi alanlarının birlikte değerlendirilmesiyle verilir.
Doğruluk oranı bir pazarlama cümlesi değil, bir bütçe kalemidir
Eşleştirme sağlayıcıları doğruluk oranı yayımlar ve bu oranlar birbirine çok yakın görünür. AltexSoft'un derlemesine göre GIATA %99,998, Vervotech ise otel seviyesinde %99,999 doğruluk bildiriyor. Aynı derleme, GIATA'nın veri tabanında yaklaşık 1,2 milyon tesis ve 124 milyon rezervasyon kodu, Gimmonix'te 1,9 milyon tesis bulunduğunu aktarıyor.
Asıl ayrım oranın kendisinde değil, ona nasıl ulaşıldığında. Vervotech'in rehberi, yalnızca kural tabanlı sistemlerin iyi kapsanan pazarlarda %90-95 bandında platoya oturduğunu, %99,9 üzerinin ancak kural, makine öğrenmesi ve insan denetiminin birlikte kullanıldığı hibrit yaklaşımlarla ölçeklendiğini söylüyor. Bir kaynak değerlendirirken sorulacak soru "yüzde kaç?" değil, "bu yüzdeye nasıl ulaşıyorsunuz ve hangi pazarda ölçtünüz?" olmalı.
Hatanın maliyeti de somut. AltexSoft'un GIATA'nın pazarlama yöneticisine dayandırdığı rakama göre Almanya'da ortalama bir otel eşleştirme hatası bir OTA'ya yaklaşık 1.500 EUR ek gider çıkarıyor. Bu, hatalı eşleşen tek bir kaydı düzeltmenin ve doğurduğu sonuçları kapatmanın maliyetidir; rezervasyon başına bir maliyet değildir.
Rezervasyon tarafındaki karşılığını Vervotech ayrıca veriyor: %4'lük bir eşleştirme hata oranı, her 1.000 rezervasyonda 40 yanlış oda onayı anlamına geliyor; ayda 50.000 rezervasyon işleyen orta ölçekli bir OTA'da bu ayda yaklaşık 2.000 yanlış oda onayı demek.
Bu iki rakamı çarpmayın — farklı birimlerdir. Ama kendi hacminize uyarlayın: ayda 800 rezervasyon yapan bir acentede %4 hata oranı, ayda yaklaşık 32 yanlış oda onayı üretir. Her biri bir müşteri şikâyeti, bir yeniden rezervasyon veya bir fiyat farkı demektir. Bu sayıyı bir kez hesaplayın; eşleştirme yatırımının geri dönüşü tartışması orada biter.
Eşleştirme kaynağı seçerken sorulacak 5 soru
- Kapsama: Benim sattığım destinasyonlarda kapsama oranı nedir? Global ortalama değil, Antalya-Bodrum-Kapadokya için rakam isteyin.
- Oda seviyesi: Yalnızca otel seviyesinde mi eşleştiriyorsunuz, oda seviyesinde de var mı? İkisinin doğruluk oranını ayrı ayrı verin.
- Güncelleme sıklığı: Otellerin %2'si yılda değişiyor; katalog ne sıklıkla yenileniyor ve değişiklik bana nasıl bildiriliyor?
- Çakışma çözümü: İki kayıt aynı kimliğe düşerse hangisi kazanır, kararı kim verir, geri alınabilir mi?
- Eşleşmeyen kayıt raporu: Eşleştirilemeyen kodları bir liste olarak alabiliyor muyum? Alamıyorsanız kör noktanız ne kadar büyük bilemezsiniz.
Beşincisi en çok atlanan ve en kritik olanıdır. Eşleşmeyen kayıtların keşif kaydına düşüp haftalık gözden geçirilmesi, eşleştirme kalitesinin zamanla bozulmasını engelleyen tek pratiktir.
Kazanan teklif kuralı: aynı otel iki fiyatla geldiğinde
Tekilleştirme yaptınız; şimdi aynı otelin iki teklifinden hangisinin satışa çıkacağına karar vermelisiniz. Yaygın sadeleştirme "en düşük fiyat kazanır" şeklindedir. Bu, çoğu durumda doğru ve savunulabilir bir varsayılandır — ama her zaman değil.
"En ucuz" ifadesi ancak iki teklif aynı şeyi satıyorsa anlamlıdır. Aşağıdaki durumlarda en düşük fiyat yanlış karardır:
- İki teklif farklı pansiyona sahiptir. Sadece oda ile oda-kahvaltı arasındaki fark fiyat farkından büyük olabilir.
- İki teklif farklı iptal politikası taşır. İade edilemez bir teklif, esnek bir tekliften doğal olarak ucuzdur; ikisini yan yana koyup "ucuz olan kazandı" demek karşılaştırma değil, karıştırmadır.
- Fiyatlardan biri vergi ve harç hariç gelir. Toplamda pahalı olan teklif listede ucuz görünür.
- Teklif sor-sat kaynaklıdır; onay gelene kadar gerçekte satılabilir değildir.
Bu yüzden karar tek kriterli değil, sıralı olmalıdır.
| Sıra | Kriter | Kural |
|---|---|---|
| 1 | Karşılaştırılabilirlik | Pansiyon ve oda tipi eşleşmiyorsa yan yana koyma |
| 2 | Gerçekten satılabilirlik | Sor-sat teklif, anında onaylı teklife eşit sayılmaz |
| 3 | Toplam maliyet | Vergi ve harç dâhil tutar karşılaştırılır |
| 4 | İptal esnekliği | Eşit fiyatta esnek politika kazanır |
Dördüncü satır bir tercih değil, bir risk kararıdır: aynı fiyata iki teklif geldiğinde iptal esnekliği yüksek olanı satmak, iptal geldiğinde acentenin üzerinde kalacak tutarı düşürür. Bu kuralı yazılı bir politikaya çevirin; personelin inisiyatifine bırakılırsa satış anında hep en düşük rakam seçilir.
İçerik çapraz tamamlama: hangi alan birleşir, hangisi asla
Kazanan teklif belirlendikten sonra ikinci bir fırsat doğar. Fiyatı ucuz olan tedarikçi genellikle içerik tarafında fakirdir: otel açıklaması kısadır, görsel azdır, olanak listesi eksiktir. Kaybeden tedarikçinin zengin içeriğini kazanan teklifin boş alanlarına taşımak, satılabilirliği doğrudan artırır.
Ama bu birleştirmenin sınırı çok nettir ve çoğu ekip bu sınırı ilk kez bir şikâyetle öğrenir.
Solda tesise ait sabit bilgiler: bunlar kaybeden tedarikçiden tamamlanabilir. Sağda satan teklifin sözleşme koşulları: bunlar asla harmanlanmaz.
Ayrım tek bir soruya indirgenebilir: bu alan tesise mi aittir, yoksa satan teklife mi?
- Tesise aittir, birleştirilebilir: otel adı, adres ve koordinat, görseller, tesis olanakları, açıklama metni, yıldız sayısı, tema etiketleri, misafir puanı. Bu bilgiler hangi tedarikçiden gelirse gelsin aynı gerçeği anlatır.
- Teklife aittir, asla birleştirilmez: fiyat, iptal politikası ve son iptal tarihi, pansiyon kodu, oda tipi ve kapasitesi, müsaitlik, fiyata dâhil vergi ve harçlar, rate plan koşulları, tesiste ödenecek kalemler.
Kural tek cümleyle şudur: fiyatı A tedarikçisinden, iptal politikasını B tedarikçisinden okuyan bir kart müşteriye yanlış koşul söyler. Müşteri "iade edilebilir yazıyordu" dediğinde elinizde savunulacak bir şey kalmaz; farkı acente kapatır. Birleştirme mantığınızı kuran kişiye verilecek tek talimat budur.
Oda eşleştirme: otelden bir kademe zor olan iş
Otel seviyesinde eşleştirmeyi çözdüğünüzü varsayalım. Asıl para kaybı bir kademe aşağıda, oda seviyesinde gerçekleşir. GIATA'nın kendi yayınında da geçtiği gibi, birçok şirket önce otel eşleştirmesine yönelir çünkü mükerrer tesisler gözle görülür; ancak otel eşleştirmesi problemin yalnızca bir kısmını çözer.
Bu farkın büyüklüğünü en iyi tek bir sağlayıcının kendi rakamları gösteriyor. AltexSoft'un derlemesine göre Vervotech otel seviyesinde %99,999, oda seviyesinde ise %95 doğruluk bildiriyor. Aynı şirket, aynı veri, iki kat.
Bunun operasyonel karşılığı çarpıcı: otel seviyesinde hata payı yüz binde bir iken, oda seviyesinde yirmide birdir. Yani oda seviyesindeki hata payı otel seviyesinin yaklaşık 5.000 katıdır. Her 20 odadan biri yanlış eşleşiyorsa, oda bazlı fiyat karşılaştırmanız istatistiksel olarak güvenilir değildir.
Aynı otelde dört farklı oda adı: "King Room With Park View", "Twin Room With Partial Bosphorus View". Her oda tipinin altında iki fiyat satırı var — aynı oda, farklı rate plan. Sağdaki panelde iptal politikası ve pansiyon ayrı ayrı seçiliyor. Eşleştirme yapılırken karşılaştırılması gereken şey oda adı değil, bu üçlünün tamamıdır.
Sorunun kaynağı basit: aynı oda tedarikçiden tedarikçiye "Standart Oda Deniz Manzaralı", "Sea View Double", "Superior Double Sea View" olarak gelir. Eşleştirme için yatak tipi, manzara, banyo düzeni ve olanakların ayrı ayrı normalize edilmesi gerekir — bu, tesis seviyesindeki eşleştirmeden çok daha ince taneli bir iştir.
Uygulanabilir kural
Oda seviyesinde eşleşme kurulamıyorsa yapılacak şey tahmin etmek değil, karşılaştırmayı geri çekmektir:
Aynı otelin iki teklifi oda seviyesinde eşleşmiyorsa yan yana fiyat karşılaştırması gösterilmez. İki ayrı kart olarak gösterilir ve hangi tedarikçiden geldiği görünür kalır.
Bu kural, yanlış bir "daha ucuz" iddiasını engeller. Personel iki kartı görüp kendi kararını verir; sistem olmayan bir kesinliği taklit etmez. Kısa vadede liste daha az derli toplu görünür, uzun vadede şikâyet sayısı düşer.
Pansiyon kodları: RO, BB, HB, FB, AI, UAI
Pansiyon, otel satışında fiyattan sonra en çok yanlış anlaşılan alandır ve tedarikçiler bunu standart bir kodla göndermez. Serbest metin gelir: "Bed and Breakfast", "Kahvaltılı", "Breakfast Included", "B/B" — dördü de aynı şeydir.
Sektörde yerleşmiş kanonik set altı koddan oluşur.
Altı kanonik kod ve tedarikçilerin sık kullandığı serbest metin karşılıkları. Gelen metni bu altı koda indirgeyemiyorsanız pansiyon filtresi de fiyat karşılaştırması da yanıltır.
Uygulanacak süreç üç adımdır:
- İndirgeme sözlüğü kurun. Her tedarikçiden gelen serbest metni altı koddan birine eşleyen bir sözlük tutun. Sözlük tedarikçi bazında olmalıdır; aynı metin iki tedarikçide farklı şey anlatabilir.
- Eşleşmeyeni sessizce atmayın. Sözlükte karşılığı bulunmayan değerler keşif kaydına düşmeli ve haftalık gözden geçirilmelidir. Varsayılan bir kod atayıp geçmek, ay sonunda "kahvaltı dâhil sanıyordum" şikâyeti olarak geri döner.
- Kodu eşitlemenin kapsamı eşitlemediğini kabul edin. Özellikle UAI için.
"Ultra her şey dâhil" bir standart değil, bir sözleşme maddesidir
UAI'nin sektörde bağlayıcı bir tanımı yoktur. Kapsamı tesisle yapılan sözleşmeyle belirlenir: bir tesiste ithal içecekler dâhilken, diğerinde yalnızca yerli üretim dâhil olabilir; à la carte restoran hakkı bir tesiste sınırsız, diğerinde konaklama başına bir kez olabilir.
Pratik sonuç: UAI satarken kodu değil, o tesisin kapsam listesini iletin. Kendi kontrat otelleriniz için bu listeyi sözleşmeden çıkarıp ürün açıklamasına yazın. Tedarikçi otellerinde kapsam listesi gelmiyorsa, satış ekranında "kapsam tesise göre değişir" uyarısını görünür tutun.
Kendi kontratınız listeye girdiğinde: allotment, stop-sale, release
Kendi kontrat otellerinizi de aynı arama listesine soktuğunuzda yeni bir yönetim yükü doğar. Tedarikçi envanterinde müsaitlik başkasının sorunuydu; kendi kontratınızda sizin.
Üç kavram sürekli birbirine karıştırılır çünkü üçü de kontenjanı etkiler. Ama üçü farklı soruya cevap verir.
Üstte girişe geri sayan eksende allotment bloğu, release penceresi ve tesise geri dönen odalar. Altta günlük kontenjan şeridi: satışa açık günler, stop-sale ile kapatılan günler ve fiyatı girilmediği için sessizce satılamaz kalan günler.
- Allotment: satış hakkınız olan oda bloğu. Sorusu: ne kadar satabilirim?
- Stop-sale: gün bazında satışı kapatma. Sorusu: hangi gün kapalı?
- Release: satılmayan odanın tesise geri döndüğü an. Sorusu: ne zamana kadar?
Release penceresi: sektör aralığı ve müzakere hedefi
DMC Quote'un otel allotment sözleşmeleri üzerine 2026 tarihli rehberine göre standart müzakere aralığı girişten 14-21 gün önce, müzakere hedefi ise 21-30 gün. Xotels'in tanımına göre bu süre "release period" ya da "cut off date" olarak adlandırılır ve blok odaların tutulduğu sürenin sonunu işaretler.
Buradaki denge basit: release süresi uzadıkça satılmayan oda riski tesise kayar, kısaldıkça sizin üzerinizde kalır. Sezon başında uzun release isteyin; sattığınızı kanıtladıktan sonra fiyat müzakeresinde bunu koz olarak kullanın.
Soft, hard ve free sale: aynı otel, üç farklı risk
Aynı rehberin verdiği aralıklar üç modeli net biçimde ayırıyor.
| Model | Rack altı indirim | Satılmazsa | Ne zaman seçilir |
|---|---|---|---|
| Free sale | %5-15 | Yükümlülük yok | Talebin belirsiz olduğu yeni destinasyon |
| Soft allotment | %10-25 | Release'te geri döner | Talebi bilinen, sezonluk ana ürün |
| Hard allotment | %20-35 | Satılsa da satılmasa da ödenir | Doluluğu kanıtlanmış, yüksek hacimli tesis |
Aynı kaynağa göre hard allotment'ta tipik peşinat onayda %25-50, müzakere hedefi %25 peşinat ve 30 gün ödeme vadesi. Bakiye standart olarak girişten 14 gün önce istenir, müzakere hedefi 7 gündür. Hacim kademesi olarak da yıllık oda gecesine göre 50-100 gecede %15, 101-250'de %20, 251-500'de %25, 500 üzerinde %30 indirim aralıkları veriliyor. Yüksek sezon farkı standartta %30-50, müzakere hedefi ise %25 tavan ya da sabit sezon fiyatı.
Karar kuralı: Hard allotment'a ancak geçen sezon aynı tesiste gerçekleşmiş doluluğunuz varsa girin. Geçmiş veriniz yoksa soft allotment'ın %10-25 bandıyla başlayın; ek %10-20 indirim uğruna satılmayan odanın tamamını üstlenmek, ilk zayıf sezonda o indirimin çok üstünde zarar yazar.
Fiyatı veya kontenjanı eksik kalan günler: sessiz gelir kaybı
Kendi envanterinizde en pahalı hata stop-sale değil, hiç fark edilmeyen boşluktur. Stop-sale bilinçli bir karardır; fiyatı girilmemiş bir gün ise kimsenin karar vermediği bir gündür. İkisi de satılamaz, ama yalnızca biri kasıtlıdır.
Bu günler raporsuz fark edilmez, çünkü arama sonucunda hata vermezler — sadece o tarih için sonuç dönmez. Müşteri başka otele gider, siz bir şey olmadığını sanırsınız.
Uygulanabilir rutin: Sezon açılmadan önce ve sezon boyunca haftada bir, "fiyatı veya kontenjanı eksik gün" raporunu çalıştırın. Bu raporların pratik bir sınırı vardır: çalıştığımız kurulumda tarama penceresi 92 gün ile sınırlıdır. Sezonunuz üç ayı aşıyorsa rapor tek seferde değil, dilimlenerek çalıştırılmalıdır — aksi halde sezonun son ayı hiç taranmaz ve tam da en yüksek fiyatlı günleriniz kör noktada kalır.
Kaybın büyüklüğünü bir kez hesaplayın. Varsayımsal ama gerçekçi bir örnek: 6 odalık bir blokta 2 gün fiyatsız kalmışsa 12 oda gecesi sessizce satılamaz durumdadır. Gecelik 4.500 TL'lik bir ortalama fiyatla bu 54.000 TL'lik bir satış hakkının hiç vitrine çıkmaması demektir. Rakamı kendi oda sayınız ve ortalama fiyatınızla yeniden kurun; haftalık rapor alışkanlığının maliyeti bu sayının yanında görünmez kalır.
Bir tedarikçi cevap vermezse aramanız durmamalı
Sekiz kaynağa aynı anda sorulan bir aramada en yavaş kaynak, tüm aramanın hızını belirlemek zorunda değildir. İki tasarım kararı bunu engeller.
Aşamalı sonuç akışı: Sonuçlar hepsi geldiğinde değil, geldikçe listelenir. Yavaş kaynağın cevabı geldiğinde listeye eklenir. Personel ilk sonuçları saniyeler içinde görür.
Devre kesici: Sürekli hata veren veya zaman aşımına uğrayan bir kaynak geçici olarak devre dışı bırakılır ve belirli aralıklarla yeniden denenir. Böylece arızalı bir tedarikçi her aramada aynı gecikmeyi tekrar tekrar ürettirmez.
Durum senkronizasyonu tarafında da benzer bir kadans gerekir. Çalıştığımız kurulumda rezervasyon durum senkronizasyonu 2 dakikalık bir döngüyle ve sağlayıcı başına devre kesiciyle yürütülür. Burada bilinmesi gereken kısıt şu: durum sorgulama tüm tedarikçilerde mevcut değildir. Yalnızca durum sorgulamayı destekleyen kaynaklarda otomatik takip çalışır; diğerlerinde rezervasyon durumu süre aşımı süpürmesiyle yönetilir.
Operasyon kuralınız buradan çıkar: hangi tedarikçilerinizde otomatik durum takibi olmadığını bir liste hâlinde yazın ve o kaynaklardaki rezervasyonlar için manuel kontrol noktası tanımlayın. Bu listeyi kurulum başında çıkarmazsanız, ilk fark ettiğiniz an bir müşterinin tesise gidip "rezervasyon yok" cevabı aldığı an olur.
Sor-sat oteller: listede var, satılmış değil
Sor-sat (talep üzerine onay) oteller, kontenjanı garanti olmayan ama satılabilir görünen tekliflerdir. Onay tesisten gelene kadar rezervasyon kesinleşmez. Bu, operasyonel olarak sorun değildir — müşteriye yanlış anlatılırsa sorun olur.
Riski kapatan şey yazılım değil, standart bir metindir. Satış anında müşteriye iletilecek şablon şu üç bilgiyi içermelidir:
"Bu tesis talep üzerine onaylanmaktadır. Rezervasyonunuz şu an ön talep durumundadır ve tesisin onayıyla kesinleşecektir. Onay süresi genellikle [X saat]'tir. Onay gelmezse ücret tahsil edilmez ve size alternatif seçenekler iletilir."
Buna eşlik eden operasyon kuralı: sor-sat teklifi satarken aynı tarih için anında onaylı bir alternatifi belirleyip kenarda tutun. Onay olumsuz döndüğünde müşteriye "bulamadık" değil, "şu seçenek var" denmelidir. Bu tek alışkanlık, sor-sat kaynaklı iptallerin önemli kısmını satışa çevirir.
Sezon açılışı kontrol listesi
Sezon açmadan önce, tek oturumda tamamlanabilecek kontroller:
- ☐ Bağlı her tedarikçi için eşleşmeyen otel kodu raporu alındı, keşif kaydı boşaltıldı.
- ☐ Sattığım ilk 20 destinasyonda mükerrer otel taraması yapıldı, kalan mükerrerler elle birleştirildi.
- ☐ Oda seviyesinde eşleşmeyen teklifler için yan yana karşılaştırma kapatıldı.
- ☐ Pansiyon indirgeme sözlüğü her tedarikçi için gözden geçirildi; eşleşmeyen serbest metinler kodlandı.
- ☐ UAI satılan tesislerin kapsam listeleri sözleşmeden çıkarılıp ürün açıklamasına işlendi.
- ☐ Kendi kontrat otellerinde "fiyatı/kontenjanı eksik gün" raporu, sezon 92 günü aşıyorsa dilimlenerek çalıştırıldı.
- ☐ Her kontratta release süresi yazılı olarak teyit edildi; 14 günün altındakiler müzakereye alındı.
- ☐ Hard allotment'a girilen tesisler için geçen sezon doluluk verisi dosyaya eklendi.
- ☐ Stop-sale günleri tesisle karşılıklı teyit edildi (tesisin kapattığı günler ile sizin kapattıklarınız ayrı listelendi).
- ☐ Otomatik durum takibi olmayan tedarikçiler listelendi; manuel kontrol noktası ve sorumlusu atandı.
- ☐ Sor-sat tesisler için müşteri bilgilendirme şablonu ve alternatif tutma kuralı ekibe tebliğ edildi.
- ☐ Kazanan teklif karar sırası yazılı politikaya dönüştürüldü ve satış ekranında görünür hâle getirildi.
Yazılım seçerken kalem kalem sorulacaklar
Çok tedarikçili envanter yöneten hiçbir sistem her şeyi yapmaz. Aşağıdaki yetenekler sık varsayılır ama çoğu kurulumda bulunmaz; teklif alırken her birini ayrı ayrı sorun ve "var" cevabını ekranda görün:
- Kanal yöneticisi (channel manager) entegrasyonu var mı? Kendi envanterinizin kontenjan ve fiyatını dışarıdaki bir kanal yöneticisine itebiliyor musunuz?
- Envanteri dışa verme var mı? Kendi kontrat envanterinizi XML/API olarak başka bir alıcıya sunabiliyor musunuz?
- Toplu içe aktarma var mı? Oda, fiyat ve kontenjan verisini dosyadan (Excel/CSV) yükleyebiliyor musunuz, yoksa hepsi ekrandan mı giriliyor?
- Sözleşme dosyası saklanıyor mu? Kontrat PDF'ini otel kaydına ekleyip sonradan bulabiliyor musunuz?
- Otel tarafında grup/blok rezervasyon modülü var mı? Uçuş tarafındaki blok mantığının otel karşılığı çoğu sistemde yoktur.
- Rezervasyona ek hizmet satışı var mı? Transfer, tur, ekstra gibi kalemler otel rezervasyonuna eklenebiliyor mu?
- Kısmi tahsilat / depozito akışı var mı? Konaklamada peşinat alıp bakiyeyi girişten önce tahsil edebiliyor musunuz?
- Otomatik durum takibi hangi tedarikçilerde çalışıyor? "Hepsinde" cevabını kabul etmeyin; listeyi isteyin.
Bu sekiz sorunun cevabı "hayır" olabilir ve sistem yine de sizin için doğru sistem olabilir — yeter ki cevabı satın almadan önce bilin ve o işi manuel süreç olarak planınıza yazın. Sorulmadığında ortaya çıkan boşluk, sezon ortasında kapatılması en pahalı boşluktur.
Kaynaklar
- Vervotech — What is Hotel Mapping? The 2026 Guide for OTAs, Bedbanks, and Metasearch: https://vervotech.com/blog/what-is-hotel-mapping-guide/
- AltexSoft — Hotel Mapping Tools: How GIATA, Gimmonix, Vervotech, and Other Solutions Work: https://www.altexsoft.com/blog/hotel-mapping-tools-how-giata-gimmonix-databindr-and-other-solutions-work/
- GIATA — Hotel Mapping and Room Mapping: https://www.giata.com/hotel-mapping-room-mapping-travel-bookings/
- DMC Quote — Hotel Allotment Contracts: Negotiating Terms: https://dmcquote.com/blog/post/hotel-allotment-contracts-negotiating-terms
- Xotels Glossary — Allotment: https://www.xotels.com/en/glossary/allotment
Sıkça Sorulan Sorular
Aynı otel neden birden fazla tedarikçiden farklı isimle geliyor?
Her tedarikçi kendi kataloğunu kendi kurallarıyla tutar; otel adını büyük harfle, kısaltmayla veya başına "Hotel" ekleyerek yazabilir. Adres formatı ülkeye ve kaynağa göre değişir, koordinat bazen tesisin girişini bazen otoparkını işaret eder. Bu yüzden aynı fiziksel tesis dört kaynakta dört farklı kayıt gibi görünür. Çözüm, bu kodların hepsini tek bir kanonik otel kimliğine bağlamaktır.
Otel eşleştirme ile oda eşleştirme arasındaki fark nedir?
Otel eşleştirme, farklı tedarikçilerin kodlarının aynı fiziksel tesise ait olduğunu belirler. Oda eşleştirme ise o tesisin içindeki oda tiplerini eşler: "Sea View Double" ile "Standart Oda Deniz Manzaralı" aynı oda mı? İkincisi belirgin biçimde daha zordur; AltexSoft'un derlediği rakamlara göre bir sağlayıcı otel seviyesinde %99,999, oda seviyesinde %95 doğruluk bildirir. Oda eşleşmesi tutmuyorsa fiyat karşılaştırması anlamını yitirir.
Allotment ile free sale arasındaki fark nedir?
Allotment, tesisin size ayırdığı ve satış hakkınızda olan bir oda bloğudur. Free sale'de ayrılmış kontenjan yoktur; sözleşmeli fiyattan satarsınız ama müsaitlik her rezervasyon talebinde tesisten teyit edilir. DMC Quote'un 2026 rehberine göre free sale rack fiyatın %5-15 altında, soft allotment %10-25, hard allotment %20-35 altında fiyatlanır — indirim büyüdükçe üstlendiğiniz risk de büyür.
Release süresi ne kadar olmalı?
DMC Quote'un aynı rehberine göre sektör pratiği girişten 14-21 gün önce, müzakere hedefi 21-30 gündür. Kural şudur: release süresi uzadıkça satılmayan oda riski tesise kayar, kısaldıkça size kalır. Sezon başında uzun release isteyin; satış performansınızı kanıtladıktan sonra bunu fiyat müzakeresinde kullanın. 14 günün altındaki her kontratı ayrıca gözden geçirin.
Stop-sale ile kontenjanı sıfırlamak aynı şey mi?
Operasyonel sonuçları benzer, kayıtları farklıdır. Stop-sale o günü açıkça satışa kapatır ve neden kapandığı izlenebilir kalır. Kontenjanı sıfıra çekmek ise "hepsi satıldı" ile "kapattım" arasındaki farkı siler. Raporlamada ve tesisle mutabakatta bu ayrım önemlidir; kasıtlı kapatmalar için stop-sale kullanın, satış sonucu tükenen kontenjanı kendi haline bırakın.
RO, BB, HB, FB, AI, UAI ne demek?
Sırasıyla sadece oda, oda ve kahvaltı, yarım pansiyon (kahvaltı + bir ana öğün), tam pansiyon (üç öğün, içecek genelde hariç), her şey dâhil (öğünler ve sözleşmede belirlenen içecekler) ve ultra her şey dâhil (genişletilmiş içecek/hizmet kapsamı). UAI'nin sektörde bağlayıcı bir tanımı yoktur; kapsamı tesis sözleşmesiyle belirlenir, bu yüzden iki tesis aynı kodla farklı şey satabilir.
Bir tedarikçi cevap vermezse arama sonucum eksik mi kalır?
Aşamalı sonuç akışı kurulmuşsa kalmaz: sonuçlar geldikçe listeye eklenir, yavaş kaynağın cevabı sonradan görünür. Sürekli hata veren kaynaklar için devre kesici uygulanır ve o kaynak geçici olarak devre dışı bırakılıp belirli aralıklarla yeniden denenir. Kalıcı çözüm izlemedir: hangi tedarikçinin hangi sıklıkta zaman aşımına uğradığını haftalık takip edin, çünkü bu sessizce daralan bir envanterdir.
Eşleştirme sağlayıcısının doğruluk oranına güvenebilir miyim?
Oranın kendisinden çok nasıl elde edildiğine bakın. Vervotech'in 2026 rehberine göre yalnızca kural tabanlı sistemler iyi kapsanan pazarlarda %90-95 bandında platoya oturur; %99,9 üzeri ancak kural, makine öğrenmesi ve insan denetiminin birlikte çalıştığı yaklaşımlarla ölçeklenir. Global ortalama yerine kendi sattığınız destinasyonlar için rakam isteyin ve eşleşmeyen kayıt raporunun size verilip verilmediğini mutlaka sorun.
Yarın sabah yapabileceğiniz beş şey
- Mükerrer sayın. En çok sattığınız üç destinasyonda arama yapın ve aynı otelin kaç kez listelendiğini elle sayın. Bu sayı, eşleştirme yatırımı tartışmasını başlatacak tek rakamdır.
- Kendi hata maliyetinizi hesaplayın. Aylık rezervasyon sayınızı %4 ile çarpın. Çıkan sayı, eşleştirme kalitesi düzelmezse her ay yaşayacağınız yanlış oda onayı adedinin gerçekçi bir tahminidir.
- Birleştirme kuralını yazın. Tek sayfalık bir not: hangi alanlar çapraz tamamlanır, hangileri asla. Fiyat, iptal politikası, pansiyon ve oda kapasitesi "asla" listesinde olmalı. Bu notu içerik birleştirmeyi kuran kişiye verin.
- Eksik gün raporunu çalıştırın. Kendi kontrat otellerinizde fiyatı veya kontenjanı girilmemiş günleri listeleyin. Sezonunuz 92 günü aşıyorsa raporu dilimleyerek alın; en yüksek fiyatlı haftalarınızın kör noktada kalmadığını doğrulayın.
- Release sürelerini tek tabloya dökün. Her kontrat için tesis adı, release günü ve peşinat oranını yan yana yazın. 14 günün altındaki ve %50 peşinatlı olanları işaretleyin; gelecek sezon müzakere gündeminiz o işaretli satırlardır.