2026 Etkinlikleri için Otel Bloğu: rooming list

Otel bloğu için pratik bir kılavuz: odaları nasıl tahmin edersiniz, rooming list nasıl oluşturulur, giriş işlemleri nasıl yapılır ve fatura nasıl kontrol edilir.

Bir etkinlik için otel bloğu, bütçede basit bir satır gibi görünür: şu tarihlerde şu kadar oda. Pratikte bu satırın arkasında farklı giriş dalgaları, tek kişilik ve çift kişilik yerleşimler, isim değişiklikleri, geç gelenler, misafirlerin kişisel harcamaları ve otelle yapılan son mutabakat vardır.

Biz Aventura olarak konaklamayı kayıt, transfer ve etkinlik programıyla ilişkilendiriyoruz. Böylece rooming list, ekibin giriş bankosunda düzeltmeye başladığı bir Excel dosyası yerine işleyen bir kayıt defteri haline gelir.

Katılımcıların konaklamaya ihtiyacı varsa, otel bloğunu görüşün ve bir teklif alın. İlk görüşme için şehir, tarihler, yaklaşık misafir sayısı, etkinlik formatı ve tahmini varış dalgalarını belirtmeniz yeterlidir.

Otel bloğu ve rooming list nedir?

Otel bloğu, otelin belirli tarihlerde bir gruba ayırdığı üzerinde anlaşılmış oda hacmidir. Rooming list ise blok içinde isimli rezervasyonların oluşturulduğu veri listesidir. Bu kavramlar birbiriyle bağlantılıdır ancak farklı düzeyleri tanımlar: blok oda müsaitliğinden, liste ise belirli misafirlerden ve onların konaklama koşullarından sorumludur.

Oracle OPERA dokümantasyonunda blok, belirli bir dönem için birkaç tipte odanın allocation'ı olarak tanımlanır. İsimli rezervasyonlar blok içinde daha sonra, manuel olarak veya rooming list içe aktarıldıktan sonra oluşur. Seçilen otel başka bir sistemle çalışsa bile bu ayrım doğru soruları sormaya yardımcı olur.

Müşteri için basit bir zincir faydalıdır:

misafir tahmini -> sözleşmeli blok -> isimli rezervasyonlar -> fiili giriş -> nihai fatura

Ekip yalnızca davetli sayısına göre rezervasyon yaparsa geceler ve konaklama tipleri arasındaki farklar kaybolur. İsimli kısım olmadan misafirin rezervasyonla eşleştirilmesinde gecikme riski artar. Fiili konaklamanın olmaması da nihai fatura mutabakatını zorlaştırır.

Otel listesi etkinlik katılımcı kaydının yerini almaz. Kayıt, verileri toplar ve etkinliğe giriş iznini yönetir. Rooming list otele yalnızca konaklama ve ödeme için gereken bilgi kısmını iletir.

Blok, pickup ve günlük tahmin

Otel bloğunu yönetmek için dört gösterge gerekir: tutulan hacmin büyüklüğü, oluşturulan isimli rezervasyon sayısı (pickup), güncel tahmin ve fiili konaklama. Son gösterge girişleri, gelmeyenleri ve erken çıkışları kaydeder, bu nedenle başlangıç listesiyle değiştirilemez. Dört değerin tümü tek bir nihai satır olarak değil, her gece için tutulur.

İki günlük bir etkinlik düşünelim. Konuşmacılar bir gün önce gelir, ana grup açılış sabahı gelir, ekibin bir kısmı finalden sonra kalır. Toplam misafir sayısı otele gecelere göre yük hakkında hiçbir şey söylemez. Günlük bir tablo gerekir.

Tablo bilinçli olarak örnek yüzdeler içermiyor. Evrensel bir pickup veya no-show normu yoktur. Geçmiş seyahat geçmişi, şirket benzer şehirleri, sezonları, kitleleri ve ödeme kurallarını karşılaştırıyorsa yardımcı olur. Başkasının katsayısı güzel bir formül ve yanlış bir blok verebilir.

Oracle ayrıca konaklayan kişi sayısına göre dağılımı (occupancy split) gösterir. Müşteri için bu, oda sayısı ile misafir sayısının tek bir alanda saklanamayacağı anlamına gelir. İki kişilik oda tipi ve iki kişinin yerleştirilmesi farklı parametreleri tanımlar; çalışma kaydında bunlar ayrı ayrı yazılmalıdır.

Gerekli oda sayısı nasıl hesaplanır?

Hesaplama, toplam katılımcı sayısından değil, konaklama takviminden başlar. Önce ekip misafirleri tarihlere ve rollere göre ayırır, ardından konaklama tipini belirler ve ancak bundan sonra blok oluşturur. Son adım, tahmini sözleşme koşullarıyla karşılaştırmak ve hacmin değiştirilebileceği noktaları işaretlemektir.

Hesaplama adım adım ilerler:

1. Katılımcıları rollere göre ayırın: ekip; konuşmacılar; yönetim; yükleniciler; misafirler; refakatçiler.
2. Her rol için beklenen varış ve ayrılış tarih ve saatlerini belirleyin.
3. Tek kişilik ve paylaşımlı konaklamayı belirtin. Müşterinin onaylaması gereken çiftleri ayrıca işaretleyin.
4. Hareket kısıtlılığı olan misafirler; aileler; refakatçiler ve diğer işlevsel ihtiyaçlar için odaları işaretleyin.
5. Ana programın öncesi ve sonrasındaki geceleri, blok kapsıyorsa ekleyin.
6. Tahmini, hâlihazırda oluşturulmuş rezervasyonlarla karşılaştırın.
7. Bir sonraki gözden geçirme tarihini ve blok değişikliği kararının sahibini kaydedin.

Müşterinin onayladığı bir kural olmadan misafirleri çift olarak eşleştirmiyoruz. Katılımcı, tek kişilik mi yoksa iki kişilik mi konaklama öngörüldüğünü, oda arkadaşını kimin seçtiğini ve çiftin değişmesi durumunda ne olacağını bilmelidir.

Büyük bir organizasyon için konaklama, ulaşımla birlikte hesaplanmalıdır. Otelin belirlediği giriş saati öğleden sonraysa, erken varış ayrı bir hizmet görevi yaratır. Bazen onaylı erken giriş gerekir, diğer durumlarda ise bagaj odası, kahvaltı, çalışma alanı veya oda teslimine kadar bir program yardımcı olur. Otel ve güzergâh bağlantısını MICE ve kurumsal turizm ile iş etkinlikleri organizasyonunda bir araya getiriyoruz.

Program, konaklama ve ulaşım hâlâ farklı tablolarda toplanmışsa, tek bir organizasyon planı için talep bırakın. Varış dalgalarını, otel bloğunu, transferleri ve etkinlik programını karşılaştırır, açık sözleşme konularını ayrı bir listeye taşırız.

Rooming list alanları ve tek bir ana sürüm

Çalışan bir rooming list; ad, konaklama tarihleri, oda tipi, misafir sayısı ve rezervasyon ile hesaplaşma için gerekliyse ödeme yöntemini içerir. Ek alanlar yalnızca belirli bir amaç için eklenir. Liste, uygulayıcı için kısa, rezervasyon oluşturmak, değişiklikleri takip etmek ve ödemeyi mutabık kılmak için ise yeterli olmalıdır.

Liste toplanıp iletilmeden önce veri işlemenin hukuki dayanağı, müşterinin, organizatörün ve otelin rolleri, alıcılar, saklama süreleri ve silme prosedürü belirlenir. Bu kararlar, çalışma tablosuna erişim açılmadan önce kayıt altına alınır.

Sözleşmede, işleme talimatında ve yerel belgelerde amaçlar, veri kapsamı, alıcılar, erişim, süreler ve silme kayıt altına alınır; bu model uygulanabilirse. Belgeler, listenin fiili aktarım akışıyla örtüşmelidir.

Katılımcıya hangi bilgilerin, kime ve neden iletildiği bildirilir. Belirli şemanın, Federal Law No. 152-FZ dikkate alınarak müşterinin avukatı veya kişisel verilerden sorumlu kişisi tarafından kontrol edilmesi gerekir.

Listenin tek bir ana sürümü ve müşteri tarafından atanmış bir sahibi olmalıdır. Paralel kopyalar düzenlemeye kapatılır. Her dışa aktarım tarih ve saat alır, değişiklikler ise bir günlükte saklanır.

Kullanışlı bir değişiklik kaydı; satır ID'sini, eski değeri, yeni değeri, yazarı, gönderim zamanını ve otelin yanıtını içerir. Tekil bir değişiklikte tam listeyi her zaman yeniden göndermek gerekmez. Tam dosya, daha güncel verilerin üzerine yazma veya bilgileri ihtiyacı olmayan kişilere açıklama riskini artırır.

Pasaport kopyaları, tam kart bilgileri ve tıbbi teşhisler normal genel rooming list kapsamına girmez. İşlevsel talepler sağlıkla ilgili bilgileri dolaylı olarak açıklayabilir; bu nedenle yalnızca gerekli hacimde toplanır ve sınırlı sayıda çalışana açılır. Her birim yalnızca kendisine gereken kısmı alır. Tesisin ihtiyaç duyması halinde belgeler ve ödeme verileri ayrıca mutabık kalınan güvenli bir kanaldan iletilir.

NIST ve ICO minimizasyon ilkeleri metodolojik bir kılavuz olarak kullanılabilir, ancak Rus hukukunun yerini tutmaz. Rusya'daki bir proje için amaçlar, dayanaklar, işleme talimatı ve organizasyonel önlemler Federal Law No. 152-FZ, sözleşmeler ve operatörlerin belgeleriyle mutabık kalınmalıdır.

Değişiklikler ve geç girişler nasıl yönetilir?

Bir değişiklik, otel yeni kaydı onayladığında ve ana sürüm güncellendiğinde tamamlanmış sayılır. "İvanov'u Petrov ile değiştirdik" şeklindeki bir e-posta tek başına rezervasyonun yeniden yapılandırıldığını kanıtlamaz. Çalışma grubu, talebin durumunu, tesisin yanıtını ve güncel onay numarasını saklar; misafire yalnızca otelin kabul ettiği seçeneği bildirir.

Değişiklikler için şu sıralamayı belirlemek uygundur:

1. Misafir veya koordinatör değişikliği liste sahibine bildirir.
2. Sahip, talebin tarihleri, tarifeyi, oda tipini, ödemeyi ve transferi etkileyip etkilemediğini kontrol eder.
3. Değişiklik, misafir kopyası oluşturulmadan satır ID'sine göre kaydedilir.
4. Otele üzerinde anlaşılmış güncelleme formatı gönderilir.
5. Otelin yanıtı ana sürüme işlenir.
6. Misafire yalnızca onaylanmış sonuç bildirilir.

Freeze tarihinden sonra listeyi değiştirebilecek kişi sayısının azaltılması daha iyidir. Bu, değişiklikleri yasaklamaz. Böyle bir sınır, otelin ve ekibin masrafları kimin aktarabileceğini, konaklamayı kimin uzatabileceğini veya ücretli bir hizmeti kimin onaylayabileceğini anlamasına yardımcı olur.

Geç giriş ayrıca belirtilir. Katılımcıya otelin rezervasyonu ne zamana kadar tutacağı ve belirli bir saatten sonra varış bildirimi gerekip gerekmediği açıklanır. Transfer veya otel bu bilgileri gerçekten kullanıyorsa, listeye beklenen varış saati ile uçuş veya tren bilgileri eklenebilir.

Erken giriş ve geç çıkış, yazılı onay alınana kadar talep olarak kalır. Oda teslim ve tahliye saatleri ilgili tesisin koşullarından alınmalıdır: bunlar oteller ve tarifeler arasında farklılık gösterir. Çalışma grubu, katılımcı erken geldi diye sabah hazır bir oda vaat etmez.

Uluslararası veya statülü bir grup için otel planının iş heyeti karşılama güzergâhıyla karşılaştırılması faydalıdır. Karşılama, bagaj, yemek, tercüme ve programa erişim, gerçek oda teslim saatini dikkate almalıdır.

Cut-off, attrition ve no-show: farklı koşullar

Cut-off, seçilmeyen kontenjanın satışa dönüş tarihini; attrition ise hacmin altında kalınması durumundaki sözleşmesel sorumluluğu tanımlar. Bloğun iptali cancellation koşullarıyla düzenlenir. No-show, belirli bir rezervasyona gelinmemesini ifade eder. Bu kavramlar birbirinin yerine kullanılamaz, çünkü finansal bağlantıları ve hesaplama yöntemleri sözleşmeye bağlıdır.

Oracle dokümantasyonu cut-off'u kullanılmayan allotment'ın serbest bırakılması olarak tanımlar. Bu bir müsaitlik yönetimi işlevidir. Sözleşmesel sorumluluk ise otelle yapılan anlaşmada yer alır. Cut-off, tüm yükümlülüklerin otomatik olarak sıfırlanması şeklinde yorumlanmamalıdır.

Evrensel bir attrition yüzdesi yoktur. Colorado State University ile Hilton Fort Collins arasındaki güncel ana sözleşmede room attrition bölümü kasten çıkarılmıştır. Bu örnek, başka bir projedeki rakamın kendi projenize norm olarak taşınamayacağını iyi gösterir.

Sözleşmeyi imzalamadan önce otele doğrudan sorular sorun:

• Picked up room night olarak ne kabul edilir?
• Hacim hangi tarihte ve hangi rapora göre ölçülür?
• Fazla satılan odalar dikkate alınır mı?
• Vergiler ve servis ücretleri nasıl hesaplanır?
• Cut-off sonrası iptal edilen rezervasyon ve no-show durumunda ne olur?
• Tarife değişmeden isim değişikliği yapılabilir mi?
• Sözleşme veya ek değişikliği nasıl düzenlenir?

Yanıtları yazılı olarak kaydedin. Bu makale operasyonel mantığı açıklar, ancak belirli bir otel sözleşmesinin avukat veya müşterinin satın alma birimi tarafından incelenmesinin yerini tutmaz.

Oda ve ek masrafları kim öder?

Ödemeyi isimler gönderilmeden önce bölmek daha iyidir. Ödeme matrisi, hangi kategorilerin şirketin ortak hesabına (master account) gittiğini ve hangilerini misafirin kendisinin karşıladığını gösterir. Ayrıca, ek masraf veya ücret aktarımı için onay verme yetkisine sahip kişileri ve bunların mali yetki sınırlarını da belirtir.

Colorado State University ile Hilton Fort Collins arasındaki örnek sözleşmede iki model öngörülmüştür: şirket tüm masrafları öder veya yalnızca seçilen kategorileri öder. Sınırlı ortak hesap durumunda otel, ek hizmetler için misafirin kartını talep edebilir. Bu belirli bir sözleşme örneğidir, bu nedenle depozito, tutarın önceden rezerve edilmesi ve iade prosedürü seçilen tesisten ayrıca teyit edilmeli ve katılımcıya varıştan önce bildirilmelidir.

Yetkili kişileri atayın. Resepsiyondaki personel, misafirin talebi üzerine mini barı, uzatmayı veya kategori yükseltmesini şirket hesabına aktarmamalıdır. Gerekçeyi kontrol edecek ve mutabık kalınan limit dahilinde karar verecek bir kişinin iletişim bilgisi onda olmalıdır.

Bir konferans için otel masraflarını genel bütçe ve misafir güzergâhıyla ilişkilendirmek daha iyidir. Konferans organizasyonu sırasında, aynı hizmetin hem otel hem de başka bir yüklenicinin faturasında yer almaması için konaklama, mekân, yemek ve ulaşımı ayrı ayrı bir araya getiririz.

Giriş işlemleri: yardım masası ve eskalasyon

Büyük bir giriş için otel ve müşteri temsilcileriyle birlikte belirlenmiş bir yardım noktası faydalıdır. Yeri, saatleri, ekip yapısı, listeye erişim ve olası maliyeti otelle önceden görüşülmelidir. Tam rooming list misafirlere kapalıdır. İhtilaflı konular belirlenen eskalasyon zinciri üzerinden iletilir.

Asgari şema şunları içerir:

• bir otel sorumlusu;
• bir müşteri veya organizatör koordinatörü;
• durum bilgilerini içeren güncel ana sürüm;
• transfer ve kayıt iletişim bilgileri;
• sorun ve çözüm günlüğü;
• koordinatörün onaylayabileceği harcama limiti;
• kuyruk veya sistem arızası durumunda yedek iletişim kanalı.

Tipik durumların önceden ele alınması daha iyidir. Rezervasyon bulunamazsa koordinatör satır kimliğini, isim yazımını ve onayı kontrol eder. Tarihlerde uyuşmazlık olması durumunda değişiklik günlüğünü açar.

Talep edilen oda tipi hazır olmadığında çalışma grubu onaylanmış kategoriyi ve mevcut seçenekleri netleştirir. Otel depozito isterse koordinatör ödeme matrisini ve katılımcının seyahatten önce aldığı mesajı kontrol eder.

Yardım masası boş vaatlerde bulunmamalıdır. Ücretsiz kategori yükseltme, geç çıkış, masrafların aktarılması ve yan oda otel ve müşterinin yetkili temsilcisi tarafından onaylanır. Koordinatör akşam kontrolü için kararı kaydeder.

Otel ve mekân farklı yerlerdeyse giriş programı otobüs kalkışlarıyla ilişkilendirilmelidir. Etkinlik planının ayrıntılı planını kurumsal bir etkinlik nasıl organize edilir makalesiyle karşılaştırabilirsiniz. Mekân aramak için mekânlar ve şehir dışı oteller kataloğumuz de faydalı olacaktır.

Konaklama nasıl mutabakata alınır ve hesap nasıl kapatılır?

Mutabakat, nihai fatura alındıktan sonra değil, konaklamanın ilk gününde başlar. Sorumlu kişi her gün çalışma listesini fiili durumla karşılaştırır. Girişleri ve gelmeyenleri, erken çıkışları ve şirketin genel hesabına yansıtılan tutarları kontrol eder. Bu düzen, otel çalışanları, değişiklik onayları ve birincil belgeler erişilebilirken ihtilaflı kalemin yerinde çözülmesini sağlar.

Mutabakat süreci dört adıma ayrılabilir:

1. Girişten önce. Ödeme matrisini ve yetkili kişiler listesini onaylayın. Garantileri, depozitoları, vergileri ve gelmeme kurallarını kontrol edin.
2. Her gün. Onaylanmış rezervasyonları fiili girişlerle karşılaştırın. Gelmeyenleri ve erken çıkışları, genel otel hesabını ve ek harcamaları kontrol edin.
3. Toplu çıkıştan önce. Kişisel tutarları ayırın ve misafirin bireysel hesabı ile şirket hesabı arasındaki aktarımları kontrol edin.
4. Çıkıştan sonra. Nihai rooming list'i konaklama raporu ve iptal ile gelmeme bilgileriyle karşılaştırın. Genel ve bireysel hesapları, depozitoları, iadeleri ve sözleşme kalemlerini ayrıca kontrol edin.

Mews, grup faturalandırmasını misafir tutarlarının konsolidasyonu ve kalemlerin misafir, rezervasyonu yapan kişi ve şirket arasında aktarılması olarak tanımlar. Ürün işlevi, kimin ödemesi gerektiğine kendiliğinden karar vermez. Dayanak, ödeme matrisi ve sözleşmedir.

Her fark için bir durum gereklidir: onaylandı, reddedildi, belge gerekli, düzeltme belgesi bekleniyor veya düzeltilmiş fatura. Kapanış yazılı olarak kaydedilir. Listelerin ve finansal dökümlerin yerel kopyaları, mutabakat ve talep çalışması tamamlandıktan sonra belirlenen süre içinde silinir.

Otele teslim öncesi kontrol listesi

Rooming list; tarihler, isimler ve ödeme kontrol edildikten sonra teslim edilmeye hazırdır. Ekip ayrıca değişiklikleri ve erişim yetkilerini de gözden geçirir. Dosyanın bir sahibi, sürümü ve otelin anlaşılır bir yanıt formatı vardır. Kapatılmamış talepler onaylanmış koşullardan ayrı tutulur; böylece katılımcıya henüz mevcut olmayan bir hizmet vaat edilmez.

Göndermeden önce kontrol edin:

1. Blok her gece ve oda tipine göre ayrıştırılmıştır.
2. Pickup, tahminden ve fiili konaklamadan ayrılmıştır.
3. Oda sayısı, konaklayan kişi sayısından ayrılmıştır.
4. Her satırın kalıcı bir ID'si vardır.
5. Tarihler ve isimlerin yazımı kontrol edilmiştir.
6. Ödeme yöntemi billing matrix ile uyuşmaktadır.
7. Erken giriş ve geç çıkış, onay öncesi talep olarak işaretlenmiştir. Yan yana konaklama da öyle.
8. Geç varışlar ve ulaşım bilgileri yalnızca ilgili birimler için girilmiştir.
9. Erişilebilirlik, gereksiz tanı olmadan işlevsel ihtiyaç üzerinden tanımlanmıştır.
10. Pasaport ve ödeme bilgileri ortak tabloda yer almamaktadır.
11. Amaç ve hukuki dayanak belirlenmiştir. Tarafların rolleri, alıcılar, erişim, saklama süreleri ve kişisel verilerin silinme usulü kayıt altına alınmıştır.
12. Master sürümün sahibi ve değişiklik yetkisi olanlar atanmıştır.
13. Cut-off ve attrition sözleşmeyle karşılaştırılmıştır. Aynısı cancellation ve no-show için de yapılmıştır.
14. Otel, güncelleme formatını ve eskalasyon iletişimini onaylamıştır.
15. Girişte bir sorun günlüğü ve finansal karar limiti vardır.
16. Günlük ve nihai mutabakat ekibin planında yer almaktadır.

Otel bölümüne konaklama takvimi ve sorumluluk matrisiyle başlıyoruz. Ardından rooming list'i transferler, kayıt, program ve bütçeyle ilişkilendiriyoruz. Bu sıralama, misafirler gelmeden önce bir çatışmayı görmeye yardımcı olur; henüz resepsiyon kuyruğunda değil, bir e-postayla çözülebilecekken.

Konaklama, ulaşım ve programı tek bir planda toplamanız gerekiyorsa, etkinlik organizasyonu için teklif isteyin. Otel bloğunun yapısını, ekip rollerini, kontrol noktalarını ve tesise sorulacak soruların listesini hazırlarız.

Kaynaklar

• Oracle OPERA Cloud: Blocks
• Oracle OPERA Cloud: Group Rooming Lists
• Oracle OPERA Cloud: Forecast Reports
• Oracle OPERA Cloud: Blocks Controls
• Colorado State University ve Hilton Fort Collins: master contract
• Hilton: Express Agreement Additional Terms
• Mews Help: Group Billing
• Federal Law No. 152-FZ “On Personal Data”: Article 5
• NIST: Minimization
• ICO: Data minimisation