Restoranlarda Masa Doluluğunu ve No-Show'u Önceden Tahmin Eden Sistem Nasıl Çalışır?

Cuma akşamı saat 20.30, kapıda sıra var, salon tıklım tıklım — ama POS ekranında hâlâ üç masa 'rezerve' yazıyor ve kimse gelmedi; üstelik o üç masa boşuna bekletildiği için kapıdaki sıradan en az bir grup çekip gitti. Aynı haftanın salı akşamı ise tam tersi: salon yarı boş, mutfakta bir kişi fazladan duruyor, çünkü geçen yıl salı hep sakin geçmiş diye tahmin edilmiş. Restoran ve kafe işletmeciliğinde en pahalı hatalardan biri tam da bu: masa doluluğu ve no-show tahmini hâlâ deneyim ve içgüdüyle yapılıyor, oysa elde zaten aylarca, hatta yıllarca birikmiş rezervasyon ve satış verisi duruyor.

##Masa Doluluğu ve No-Show Tahmini Restoranlar İçin Ne Anlama Geliyor?

Elindeki rezervasyon ve POS verisini — tarih, saat, kişi sayısı, geçmişte kaç kez rezervasyon yapıp gelmediği, ne kadar önceden rezervasyon yapıldığı, hatta hava durumu ve yakın çevredeki konser/maç gibi etkinlikler — tek yerde toplayıp basit bir tahmin modeliyle işleyen bir sistem kurulabilir. Bu sistem her gün, her vardiya için bir doluluk tahmini ve her rezervasyon için bir no-show olasılığı üretir. Riski yüksek görünen rezervasyonlar (örneğin bir hafta önceden alınmış, daha önce hiç gelmemiş bir müşteriden gelen 8 kişilik masa) otomatik olarak işaretlenir; sisteme bağlı bir SMS/WhatsApp hattı o rezervasyonu gün öncesinden nazikçe teyit eder ve teyit gelmeyen masalar için kapıdaki bekleme listesine ya da fazla rezervasyon (overbooking) stratejisine yer açar. Aynı risk skoru, belirli bir eşiğin üzerindeki büyük grup rezervasyonlarında küçük bir depozito istemek gibi basit kurallar için de kullanılabilir — havayı okumak yerine geçmiş veriye dayanan bir eşik koymuş olursunuz.

Bunun için büyük bir zincir olmaya gerek yok. Tek şubeli bir restoranın rezervasyon defteri veya kullandığı QR/rezervasyon uygulaması zaten bu verinin çoğunu tutuyor; eksik olan, bu veriyi bir araya getirip anlamlı bir tahmine çeviren küçük bir katman. Yatırım, sıfırdan yazılım kurmaktan çok, mevcut sistemlere takılan orta ölçekli bir otomasyon projesi büyüklüğünde kalıyor. Dürüst olmak gerekirse bu bir kehanet değil, olasılık aracı: yeni açılan bir şubede ya da bayram gibi emsali olmayan bir günde tahmin daha zayıf kalır, o yüzden sistem her zaman son kararı yöneticiye bırakan bir öneri katmanı olarak kurulmalı, otomatik pilot olarak değil.

##Gerçek Bir Senaryo: Sahil Kafe

Sahil Kafe, sahil şeridinde 40 masalık, tek şubeli, kurgusal ama gerçekçi bir işletme olsun. Şu ana kadar personel planlaması müdürün hafızasına ve 'geçen yıl bu hafta nasıldı' sorusuna dayanıyor; bazı akşamlar salon dolup taşarken bir garson eksik kalıyor, bazı akşamlar da salon yarı boşken tam kadro çalışıyor. No-show'lar da ayrı bir dert: özellikle hafta içi akşamları alınan büyük grup rezervasyonlarının önemli bir kısmı hiç gelmiyor, o masalar da kapıdan dönen müşterilere kapalı kalıyor.

Kurulan sistemde rezervasyon uygulaması, POS ve basit bir hava durumu API'si her gece verilerini ortak bir tabloya aktarıyor; bir tahmin modeli her sabah saat 07.00'de o günün öğle ve akşam vardiyası için beklenen doluluğu ve risk taşıyan rezervasyonların listesini üretiyor. Müdür sabah bu listeye bakıyor: 'Bugün akşam yüksek doluluk bekleniyor, üç rezervasyonun teyit edilmesi öneriliyor.' Riskli üç rezervasyona otomatik teyit mesajı gidiyor; ikisi onaylıyor, biri iptal ediyor ve o masaya kapıdan gelen bir gruba yer açılıyor. Haftalık personel çizelgesi de artık geçen haftanın kopyası değil, o haftanın tahminine göre bir gün önce hazırlanıyor — sakin geçmesi beklenen bir akşama bir kişi eksik, yoğun beklenen bir hafta sonuna bir garson fazladan planlanıyor.

##Nasıl Kurulur (Kısaca)

Teknik tarafı abartmaya gerek yok; sistemin omurgası şu birkaç parçadan oluşuyor:

• ▸Rezervasyon uygulaması, POS ve varsa hava durumu/etkinlik verisini tek bir veri tabanında birleştirmek
• ▸Geçmiş 6-12 aylık veriyle günlük/vardiyalık doluluk ve no-show olasılığını hesaplayan basit bir istatistiksel model (baştan büyük bir yapay zeka modeli şart değil)
• ▸Riskli rezervasyonlar için otomatik SMS/WhatsApp teyit hatırlatması
• ▸Yöneticiye sabah özeti gösteren, tek sayfalık bir panel: bugünkü tahmini doluluk, riskli rezervasyonlar, önerilen personel sayısı
• ▸Teyit gelmeyen riskli rezervasyonlar için basit bir fazla rezervasyon (overbooking) kuralı
• ▸Gerçekleşen sonuçlarla modelin ay ay kalibre edilmesi, böylece tahminler zamanla iyileşir

Bunu da eklemek gerekir: her rezervasyon/POS sistemi aynı seviyede veri erişimi sunmuyor, bazılarında API varken bazılarında sadece dışa aktarılabilir bir rapor bulunuyor, bu da entegrasyon süresini biraz uzatabiliyor. Ayrıca ilk birkaç ay model henüz yeterince veriyle beslenmediği için tahminler kaba kalabilir; bu bir kurulup unutulan sistem değil, gerçek sonuçlarla haftalık kendini düzelten bir araç. Overbooking kuralı da temkinli başlamalı: örneğin sadece no-show olasılığı %50'nin üzerindeki rezervasyonlarda ve toplamda vardiya kapasitesinin en fazla %10'u kadar fazladan masa açmak gibi dar bir sınırla başlayıp, gerçek sonuçlar biriktikçe bu sınırı gevşetmek ya da sıkmak makul bir yaklaşım.

##Sık Sorulan Sorular

>Bu sistem tek şubeli küçük bir restoran için de mantıklı mı?

Evet, hatta asıl fark küçük işletmelerde daha çok hissediliyor çünkü tampon kapasitesi yok — bir no-show ya da yanlış personel planı doğrudan o günün cirosunu ve moralini etkiliyor. Sistem zincir değil veri geçmişi ister; 6 ayı geçmiş rezervasyon kaydı olan hemen her yer başlayabilir.

>Tahmin için ne kadar geçmiş veri gerekir?

Anlamlı bir başlangıç için 6-12 aylık rezervasyon ve satış verisi yeterli. Daha kısa geçmişle de kurulabilir ama ilk birkaç ay tahminler kaba kalır; sistem her hafta gerçekleşen sonuçla kendini düzeltir, yani zamanla iyileşen bir araçtan bahsediyoruz, ilk günden kusursuz bir kristal küreden değil.

>Hava durumu veya yerel etkinlikler gerçekten fark yaratıyor mu?

Sahil ve bahçe alanı olan yerlerde evet, belirgin şekilde — yağmurlu bir akşam rezervasyonların önemli bir kısmı hiç gelmeyebiliyor. Kapalı mekan ve merkezi lokasyonlarda etkisi daha küçük ama yine de sıfır değil, özellikle maç günleri ve konser gibi büyük yerel etkinliklerde.

>Mevcut rezervasyon veya POS sistemimle entegre olur mu?

Çoğu yaygın rezervasyon ve POS sistemi bir API veya en azından dışa aktarılabilir rapor sunuyor; entegrasyon genelde bu veriyi düzenli çekip ortak tabloya yazan orta ölçekli bir otomasyon işi. Sıfırdan bir rezervasyon sistemi yazmaya gerek kalmıyor, mevcut araçların üzerine ince bir katman ekleniyor.

>Sistem fiyatlandırma veya depozito kararlarında da kullanılabilir mi?

Evet, ama temkinli bir ek olarak. Aynı risk skoru, belirli bir eşiğin üzerindeki büyük grup rezervasyonlarında küçük bir depozito talep etmek ya da yoğun beklenen akşamlarda erken/geç saat rezervasyonlarını teşvik edecek küçük bir fiyat farkı sunmak için de kullanılabilir. Ama bunu sistemin ana amacı değil, doluluk tahmini oturduktan sonra eklenecek ikinci bir katman olarak düşünmek gerekir; ikisini aynı anda kurmaya çalışmak ilk aşamada işi gereksiz karmaşıklaştırır.

Kendi restoran ya da kafen için doluluk ve no-show tahminini nasıl kurabileceğimizi konuşmak istersen, birkaç soruyla başlayabiliriz — hangi verinin elinde olduğuna bakıp ondan yola çıkarız.