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.
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.
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.
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?
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.
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