1. Kanal yönetim grid ekranını tanımak (GridView mantığı)
GridView, çoğu channel manager’da “satır–sütun” düzeninde çalışır: satır = oda tipi veya rate plan, sütun = tarih, hücre ise o gün için fiyat ve/veya envanter bilgisini taşır. Bazı sistemler satırda RoomType, bazıları RoomType+RatePlan kombinasyonu gösterir; ama mantık değişmez: doğru satır + doğru sütun = doğru güncelleme.
Bu ekrana geçmeden önce kavramsal çerçeveyi kanal yönetimi temel mantığı üzerinden netleştirmek faydalıdır; çünkü grid, daha geniş PMS & OTA yönetimi yapısının günlük operasyon yüzüdür.
Grid ekranında “kritik alanlar” (neresi ne işe yarar?)
- •RoomType (Oda Tipi): Standard, Deluxe, Family vb.
- •RatePlan (Fiyat Planı): BAR, Non-Refundable, Early Booking, Package vb.
- •DateRange (Tarih Aralığı): Başlangıç–bitiş aralığı; çoğu hatanın kaynağı burasıdır.
- •OTAFilter (Kanal Filtresi): Booking, Expedia, Agoda vb. veya “All channels”.
- •Market/Segment filtresi (varsa): Ülke/pazar bazlı fiyat setleri (özellikle resort/çok pazar).
- •Inventory alanı: Müsait oda sayısı / allotment / stop-sell vb. kurallar.
En sık görülen iki yanlış anlama
- “All channels” güvenlidir yanılgısı: Tüm kanallara aynı fiyatı bir anda basmak doğru strateji olmayabilir.
- “Bir kere kaydettim, geri alamam” korkusu: Doğru sistemde geri alma/rollback ya da geçmişe dönük düzenleme akışı vardır; burada mesele “kayıt disiplinidir”.
Mini Check (Grid mantığı)
- • Satırın RoomType/RatePlan’ı temsil ettiğini net biliyorum
- • Sütunun tarih olduğunu ve DateRange’in riski belirlediğini anladım
- • “All channels” yerine OTAFilter ile kontrollü ilerlemeyi planlıyorum
- • Güncelleme öncesi “kontrol/test” adımı zorunlu
Ne yapmalıyım?
- • Grid ekranındaki alanları ekip için “tek sayfa sözlük” haline getirin.
- • RoomType + RatePlan listesini sadeleştirip isimleri tutarlı yapın.
- • DateRange seçiminde “yüksek riskli canlı tarih” uyarısı ekleyin.
- • Kanal filtresini önce çekirdek kanallarla sınırlandırın; sonra genişletin.
2. Oda tipi ve rate plan seçimi (RoomType + RatePlan)
Fiyat hatalarının önemli kısmı “yanlış fiyat”tan değil, yanlış rate plan’a fiyat girmekten doğar. Örneğin BAR güncellenmesi gerekirken Non-Refundable satırına fiyat girilirse, OTA’da görünürlük ve dönüşüm etkilenir. Bu yüzden grid’de ilk disiplin, RoomType ve RatePlan seçiminde standart oluşturmaktır.
Grid satırlarının neden böyle kurgulandığını daha derin okumak için kanal yönetiminde room type ve rate plan mimari içeriği iyi bir tamamlayıcıdır; çünkü günlük kullanım hatalarının çoğu veri modelinin yanlış anlaşılmasından doğar.
Rate plan’ı seçerken 3 pratik kural
- •Kural 1: “Ana fiyat” (BAR) ile “türev fiyatlar” (NRF, EB) ayrı yönetilsin.
- •Kural 2: Kampanya rate plan’ları tarih aralığıyla birlikte yönetilsin; kampanya bittiğinde kapansın.
- •Kural 3: Rate plan isimleri ekip için anlaşılır olsun (kısaltma standardı).
Mini örnek (Belek resort – erken rezervasyon): Belek’te erken rezervasyon açacaksınız. BAR fiyatını güncelledikten sonra EB rate plan’ı belirli tarihlerde daha düşük veya koşullu olabilir. Grid’de önce BAR satırını, sonra EB satırını güncellemek; kontrolü ve raporlamayı kolaylaştırır.
Mini Check (RoomType/RatePlan)
- • BAR/NRF/EB gibi ana rate plan’larım net ayrışmış
- • Kampanya rate plan’ları “tarih aralığı”yla birlikte yönetiliyor
- • Rate plan isimleri tutarlı (ekip karıştırmıyor)
- • Yanlış satıra girme riskini azaltacak kontrol adımım var
Ne yapmalıyım?
- • Rate plan envanterini sadeleştirin (gereksiz planları kapatın).
- • Rate plan isim standardı belirleyin (anlaşılır ve kısa).
- • Kampanya planları için “başlangıç–bitiş kapanış checklist’i” oluşturun.
3. Tarih aralığı, pazar ve kanal filtreleri (DateRange + OTAFilter)
Filtre seçmeden fiyat girmek, direksiyonu kilitlemeden gaza basmak gibidir. Özellikle Antalya/Side yoğun sezon öncesi toplu fiyat güncellemeleri yapılırken, DateRange yanlışsa hata çarpan etkisiyle büyür.
DateRange seçimi (yüksek risk–düşük risk mantığı)
- •Düşük riskli test aralığı: Yakın ama doluluğun düşük olduğu 1–3 günlük dönem (test amaçlı)
- •Orta risk: 1–2 haftalık dönem (kontrol zorunlu)
- •Yüksek risk: Yoğun sezon, bayram, özel etkinlik tarihleri (çok kontrollü, tercihen parça parça)
Teknik not: Toplu grid güncellemeleri öncesinde, canlı tarihler yerine test amaçlı yakın ama düşük riskli tarih aralıklarında deneme yapılmalıdır.
OTAFilter seçimi (çekirdek kanal yaklaşımı)
“All channels” yerine önce çekirdek kanallar (ör. Booking + Expedia) üzerinde test yapmak, sonra diğer kanallara yaymak daha güvenlidir. Çünkü hatayı erken yakalarsınız.
Pazar/segment filtresi (varsa) nasıl düşünülmeli?
Resort yapılarda farklı pazarlar farklı iptal/lead time davranışı gösterebilir. Bu yüzden “tek fiyat–her pazar” yaklaşımı her zaman doğru değildir; ancak önce temel akışı oturtup sonra segmentleşmeye geçmek daha sağlıklıdır.
Mini Check (Filtre disiplini)
- • DateRange’i önce test aralığında deniyorum
- • OTAFilter’ı çekirdek kanallarla başlatıyorum
- • “All channels” kullanacaksam iki kez kontrol kuralım var
- • Yüksek sezon güncellemelerini parça parça planlıyorum
Ne yapmalıyım?
- • “Test DateRange” standardı belirleyin (her güncelleme önce 1–3 günlük test).
- • Çekirdek kanalları seçip OTAFilter’ı önce onlarda kullanın.
- • Yüksek sezon toplu güncellemelerini 7–10 günlük bloklara bölün.
- • Güncelleme sonrası 2 dakikalık “OTA kontrol turu” checklist’i ekleyin.
4. Kanal yönetim grid ekranını adım adım nasıl kullanırsınız?
7 adımda toplu fiyat & envanter güncelleme
- RoomType seç: Güncelleyeceğin oda tipini belirle (Standard/Deluxe vb.).
- RatePlan seç: BAR mı, NRF mi, kampanya mı? Doğru satırı doğrula.
- DateRange belirle: Önce 1–3 günlük test aralığı seç.
- OTAFilter uygula: Önce çekirdek kanalları seç (örn. Booking + Expedia).
- Fiyat/Envanter gir: Grid hücrelerine fiyatı yaz; envanter değişecekse aynı anda uygula (sistem izin veriyorsa).
- Kontrol et: Kaydetmeden önce “önizleme/kontrol” alanından satır–tarih–kanal eşleşmesini doğrula.
- Kaydet + doğrula: Kaydet; sonra OTA tarafında 2 dakikalık kontrol turu yap. Hata görürsen geri alma/rollback adımına geç.
30 saniyelik hızlı kontrol soruları
- •Doğru RoomType mı?
- •Doğru RatePlan mı?
- •DateRange yanlışlıkla “tüm ay” mı oldu?
- •OTAFilter “All channels” mı kaldı?
- •Kaydetmeden önce önizleme kontrol edildi mi?
Mini Check (Adım adım uygulama)
- • Test aralığında denedim (1–3 gün)
- • Çekirdek kanallarda doğruladım
- • Kaydetmeden önce önizleme/kontrol yaptım
- • Hata olursa rollback planım hazır
Ne yapmalıyım?
- • Bu 7 adımı ekip SOP’si (standart operasyon prosedürü) yapın.
- • “Kaydet” yetkisini en azından sezon öncesi süreçte sınırlayın.
- • Her güncellemeyi loglayın: kim, neyi, hangi DateRange’de değiştirdi?
5. Fiyat ve envanter giriş yöntemleri (pratik kullanım)
Grid ekranı genellikle iki tür girişe izin verir: (1) tek hücreye değer girme, (2) seçili tarih aralığına toplu değer girme. Toplu giriş, zaman kazandırır ama riski artırır; bu yüzden kontrol ve geri alma ile birlikte düşünülmelidir.
Burada yapılan fiyat girişini yalnız operasyon gibi değil, fiyat stratejisi ile kanal yönetimini senkronize etmek yaklaşımının sahadaki uygulaması gibi okumak gerekir. Çünkü grid’e girilen her değer, daha büyük gelir stratejisinin canlı yansımasıdır.
3 yaygın giriş senaryosu
- •Senaryo A (tek gün): Özel gün fiyatı (tek güncelleme)
- •Senaryo B (hafta bloğu): 7 günlük fiyat revizyonu
- •Senaryo C (sezon bloğu): 30–60 günlük büyük güncelleme (yüksek risk)
Örnek “tarih–oda–fiyat” tablo (ekip içi kontrol için)
Key Statistics / Data Point (sheet): Toplu grid güncellemelerini doğru kullanan otellerde, fiyat hatalarının ve manuel işlem sürelerinin belirgin şekilde azaldığı gözlemlenir; test süreçleri atlandığında canlıda yanlış fiyatlar görülebilir.
| RoomType | RatePlan | DateRange | OTAFilter | Fiyat Aksiyonu | Envanter Aksiyonu | Not |
|---|---|---|---|---|---|---|
| Standard | BAR | 01–03 May | Booking+Expedia | Güncelle | Değişme | Test aralığı |
| Standard | BAR | 04–10 May | Booking+Expedia | Güncelle | 5 oda aç | Kontrol sonrası |
| Deluxe | NRF | 01–10 May | Booking | Güncelle | Değişme | Kanal özel |
| Family | BAR | 15–30 Tem | All channels | Yüksek risk | Değişme | Parça parça yap |
Mini Check (Giriş yöntemi)
- • Sezon bloğu güncellemelerini parçalara bölüyorum
- • Tabloyla değişikliği kayıt altına alıyorum
- • Yüksek riskli “All channels” işlemlerini iki aşamalı yapıyorum
- • Kontrol turunu SOP’ye bağladım
Ne yapmalıyım?
- • “Değişiklik tablosu”nu standart hale getirin (kim/ne/nerede/niçin).
- • Sezon güncellemelerini 7–10 günlük bloklar halinde planlayın.
- • All channels işlemlerinde iki kişi kontrolü uygulayın.
6. Belirli OTA’ları açma/kapama (kanal kontrolü)
Grid ekranında sadece fiyat değil, kanal bazlı aç/kapat (stop-sell, closed) gibi aksiyonlar da yönetilebilir. Burada kritik kural şudur: Kanal aç/kapat kararı “strateji + operasyon” birleşimidir. Sadece fiyatı değiştirmek yetmez; kanalın açık kalması doğru mu?
Bu değişikliklerin gerçek hayatta değer üretmesi için güncellemenin OTA entegrasyonu üzerinden kanallara doğru yansıması gerekir. Yani grid ekranındaki satır değişikliği, yalnız panel içinde değil, satış yüzeylerinde de doğru görünmelidir.
Ne zaman OTA kapatılır?
- •Yüksek talepte direkt satışa alan açmak için
- •Overbooking riski yükseldiğinde
- •Kanal performansı düşükken (net gelir/iptal oranı)
- •Operasyon kapasitesi kısıtlıyken
Mini örnek (Antalya resort – yüksek sezon öncesi): Antalya’da yüksek sezona girerken, belirli tarihlerde talep çok yükselir. Bu dönemde bazı kanalları kısıtlayıp çekirdek kanallarda kontrollü ilerlemek, “yanlış fiyat + yanlış envanter” riskini azaltır.
Mini Check (Kanal kontrolü)
- • Kanal aç/kapat kararının kriterleri var (net gelir, iptal, risk)
- • Stop-sell/closed aksiyonlarını kim yapar belli
- • Aç/kapat sonrası OTA görünürlüğünü kontrol ediyorum
- • Kural çakışmalarını (PMS/CM/OTA) önlüyorum
Ne yapmalıyım?
- • Kanalları “çekirdek / ikincil” sınıflandırın.
- • Stop-sell kararını KPI temelli verin (özellikle iptal/lead time).
- • Kural yönetimini tek merkezde tutun; çift yerden kural yazmayın.
7. Kontrol, test ve geri alma (rollback) süreçleri
İlk kez grid kullananlar için 5 ipucu
- Her güncellemeyi önce test DateRange’de dene.
- “All channels” yerine önce çekirdek OTAFilter ile ilerle.
- Kaydetmeden önce satır–tarih–kanal eşleşmesini önizlemede doğrula.
- Büyük değişiklikleri parça parça yap; blokları logla.
- Rollback senaryosunu önceden bil: “Hata olursa neyi geri alacağım?”
Rollback mantığı (geri alma nasıl düşünülür?)
- •En iyi rollback: Hata yayınlanmadan yakalanır (önizleme/kontrol).
- •İkinci en iyi: Hata yayınlandıysa, aynı filtrelerle geri dönüp doğru değerle düzeltme + OTA doğrulaması yapılır.
- •Operasyonel disiplin: Değişiklik kaydı yoksa rollback uzar; bu yüzden log şarttır.
Mini Check (Kontrol & rollback)
- • Test → kontrol → kaydet sırası bende refleks oldu
- • Değişiklik kaydı (log) tutuyorum
- • Hata olursa geri alma adımlarım net
- • Güncelleme sonrası OTA kontrol turum var
Ne yapmalıyım?
- • Her toplu güncellemeyi “test DateRange → çekirdek kanal → genişletme” olarak 3 aşamaya bölün.
- • Değişiklik log’unu zorunlu kılın (kim, ne, hangi tarihler).
- • Rollback playbook’u yazın (1 sayfa yeter).
8. Kanal Yönetimi Fiyat & Envanter Grid Checklist (v1.0)
Kanal Yönetimi Fiyat & Envanter Grid Checklist’ini İndir — PMS & OTA Yönetimi (v1.0)
Bu checklist, kanal yönetim grid ekranında toplu fiyat ve envanter güncellemelerini hatasız yapmak için test–kontrol–rollback adımlarını standartlaştırır. Özellikle yoğun sezon öncesi (Antalya/Belek/Side gibi destinasyonlarda) yapılan büyük güncellemelerde, yanlış fiyatın canlıya çıkma riskini azaltmayı hedefler.
Kim Kullanır?
Resepsiyon, revenue/satış ekipleri ve kanal operasyonunu yöneten ajans ekipleri.
Nasıl Kullanılır?
- Her güncellemeyi önce test DateRange’de uygula.
- Çekirdek kanallarda doğrula, sonra kanalları genişlet.
- Değişiklik log’u + rollback adımıyla canlı riski kontrol et.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ RoomType + RatePlan isimleri tutarlı ve sade
- ▢ ✅ Güncelleme önce test DateRange’de denendi
- ▢ ✅ OTAFilter çekirdek kanallarla başladı
- ▢ ✅ Kaydetmeden önce önizleme/kontrol yapıldı
- ▢ ✅ Değişiklik log’u girildi (kim / ne / hangi tarih)
- ▢ ✅ Kaydet sonrası OTA kontrol turu tamamlandı
- ▢ ✅ Hata halinde rollback adımı biliniyor
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
9. Özet: Grid ekranıyla toplu güncellemede hedef “hız” değil “kontrol”
Grid ekranı size hız verir; ama hedef hız değil kontrol olmalı. Doğru filtreleme, küçük test aralığı, kontrol ve rollback; canlıda yanlış fiyat görünmesini engelleyen “dört emniyet kemeri”dir. Bu yaklaşımı SOP’ye dönüştürdüğünüzde, fiyat hataları ve manuel işlem süreleri belirgin şekilde azalır; ekibin güveni artar ve sezon yönetimi daha sakin ilerler.
Bu ekran başı disiplin, doğru kurulduğunda yalnız fiyat hücresini değil tüm rezervasyon yönetimi akışını ve daha geniş otel OTA yönetimi performansını etkiler. Detaylı adımlar için kanal yönetimi hizmeti akışına, sık sorular için de kanal yönetimi hakkında sık sorulan sorular sayfasına geçebilirsiniz.
Bir Sonraki Adım
Yoğun sezon öncesi ekibinizi standartlaştırıp hatasız güncelleme rutini kuralım.
Sık Sorulan Sorular
Kanal yönetim ekranı nasıl kullanılır?▾
Fiyat ve envanter grid ekranından nasıl güncellenir?▾
Belirli tarihlerde belirli OTA’lar nasıl kapatılır/açılır?▾
Hatalı fiyat girişi yaptığımda nasıl düzeltebilirim?▾
Toplu güncelleme yaparken en büyük risk nedir?▾
İlgili İçerikler