Otel ek hizmet satışı hangi problemi çözer?
Ek hizmet satışı, konaklayan misafirin tercihine uygun hizmeti önceden görmesini, satın almasını ve ne zaman teslim edileceğini bilmesini sağlar. Teklifin görüntülenmesi henüz satış değildir; ürünün fiyatı, kapsamı, ödeme ve teslim sorumluluğu netleştirilmelidir.
İşletme önce hangi hizmetlerin konaklama paketine dahil olduğunu, hangilerinin ayrıca ücretlendirildiğini ve hangi tarihlerde sunulabileceğini belirlemelidir. Hizmet, onu sunacak ekip ve kaynak olmadan satılırsa ödeme başarılı olsa bile deneyim olumsuz sonuçlanabilir.
Örnek satış akışıyla kararları netleştirin
Örneğin 2.400 TL tutarında bir hizmetin %30'u ön ödeme olarak alınacaksa 720 TL hemen tahsil edilir; kalan 1.680 TL ise işletmede ödenir. Tutarlar yalnız açıklayıcı örnektir. Misafir toplam tutarı, hizmet tarihini, kalan ödemeyi ve iptal koşullarını satın alma öncesinde görmelidir.
Uygulama sırası ürün bağımsızdır: uygun teklif → ürün ve fiyatın netleştirilmesi → siparişin açılması → bankanın kesin tahsilat sonucu → hizmetin teslimi → gerekirse iptal/iade. Ardından bu aşamaların hangi yazılımda yönetileceğine karar verilir.
1. Satışa başlamadan önce ürünün sorumlusunu belirleyin
Otelde ek hizmet satarken önce “Bu hizmeti kim sağlayacak, misafir neyi satın alıyor ve hangi kayıt satışın kanıtı olacak?” sorularını cevaplayın. Misafirin Stay içinde gördüğü bir seçenek ile otelin ona vereceği hizmet arasında operasyonel bir sözleşme vardır. Yalnız kampanya kartı tasarlamak bunun yerini tutmaz.
Bir transfer için güzergâh ve rezervasyon saati, bir spa hizmeti için seans ve uzman uygunluğu, bir oda yükseltmesi için gerçek oda kapasitesi ayrı kontrol ister. İlk pilotta farklı riskte iki ürün seçin: önceden hazırlanabilen bir paket ve müsaitliğe bağlı bir hizmet. Hangi ürünün otomatik onaylanacağına değil, hangi koşullar altında onaylanabileceğine karar verin.
2. Kataloğu Experience’da tanımlayın
Rezervem Experience’da önce kategori, sonra ürün, ardından satılabilir varyant tanımlanır. Örneğin bir transfer hizmetinin tek yön ve çift yön seçeneklerini ayrı fiyatlandırabilirsiniz. Tek seçeneği olan üründe de arka planda bir varyant bulunur. Kategori ve ürün açıklamasını misafir dilinde anlaşılır yazın; satılacak hizmetlerin adlarını ve kapsamını işletmenizin gerçek koşullarıyla yazın.
Ürün için kullanım koşulları, iptal metni, dahil/hariç bilgisi, adet ve kişi sınırları, ilgili restoran/şube ataması, aktiflik, satış kanalı, vergi ve fiyat bilgisi kontrol edilir. Uygun ürünün seçildiği tesiste satılabilir olması gerekir. Bazı kanallardaki satış için geçerli tarih/öğün kuralları bulunur; ancak bu kuralları bir spa takvimi veya oda kapasitesi motoru olarak göstermeyin.
Satılan nesne ürünün seçeneği yani varyanttır. Siparişe satış anındaki fiyat ve açıklama kopyalanır; sonraki katalog değişikliği önceki tahsilat kaydını değiştirmemelidir. Çok şubeli otelde fiyat override, misafir dili ve şube eşleşmesini ayrı test edin. Experience katalog kurulum rehberi bu adımların ayrıntılarını içerir.
- Kategori ve ürün metni anlaşılır, doğru dilde ve tesisin gerçek hizmetine uygun mu?
- En az bir aktif varyant, geçerli fiyat, KDV ve satıcı şube tanımlı mı?
- Ürünün gösterileceği/satılacağı kanal etkin mi? Katalogda bulunması tek başına satış izni değildir.
- Müsaitliğe veya tarihe bağlı hizmet için ayrıca gerçek onay süreci var mı?
3. Stay’de misafirin karar anını tasarlayın
Pre-check-in sırasında veya konaklama boyunca ek hizmet göstermek aynı işlem değildir. Varıştan önce misafirin ulaşım ihtiyacı, konaklamanın ortasında restoran veya spa tercihi, çıkışa yaklaşırken uygunluk koşullu geç çıkış gibi seçenekler anlamlı olabilir. Ancak aynı ürünü her aşamada tekrarlamak yerine misafirin görmeye yetkili olduğu hizmetleri seçin.
Stay misafir deneyimi tarafında ürünün adını, kapsamını, fiyatını, varsa peşin/kalan tutarını ve iptal şartını anlaşılır göstermelidir. Siparişin doğru konaklamayla eşleşmesi gerekir. Oda numarası tek başına değişmez misafir kimliği değildir; konaklama tarihleri ve tesisin doğrulama koşulları korunmalıdır.
Stay ekranında katalogdan seçim ve ödeme akışının ilgili otel için etkin olduğu ayrıca doğrulanmalıdır. Mevcut kodda Experience kataloğu ve sipariş çekirdeği bulunması, Stay’in her kurulumunda otomatik mağaza açıldığı anlamına gelmez.
4. Experience siparişi ile Pay tahsilatını ayırın
Satın alma akışında önce hangi ürünün hangi miktarda seçildiği belirlenir, ardından sipariş kaydı oluşturulur. Ödeme başarılı olduğunda siparişin finansal durumu ilerler. Rezervem Experience sipariş modeli (`ExperienceOrder`) ödeme durumunu, satırlarını ve gerekiyorsa kullanım kodlarını izler; para hareketi ayrı ödeme kaydından takip edilir.
Rezervem Pay iki şekilde ilişkilendirilebilir: İşletme Experience ürününü içeren bir ödeme talebi oluşturabilir veya etkinleştirilmiş misafir satın alma akışı doğrudan entegre ödeme alabilir. Her deneyim satışı için ayrıca ödeme linki üretildiği varsayımı yanlıştır. Ödeme talebinin gönderilmesi, Pay ödeme ekranının açılması ve bankadan başarılı tahsilat dönmesi de birbirinden farklı durumlardır.
Ön ödeme oranı kullanılan ürün ve satış senaryosuna göre değişebilir. Örneğin temsili 2.000 TL’lik bir hizmette %40 ön ödeme koşulu tanımlandıysa 800 TL şimdi alınır, 1.200 TL mekânda ödenir. Sipariş “Paid” durumunda olsa bile bütün hizmet bedeli tahsil edildi denemez. Kalan kısmın hangi sistemde takip edileceği ve misafire nasıl gösterileceği operasyon kararına yazılmalıdır.
Ürünlü Pay talebinin ayrıntısını Experience ödeme linki rehberinde, genel ödeme ve tahsilatı Rezervem Pay ürün sayfasında inceleyin.
5. Sipariş kesinleştikten sonra teslimi planlayın
Ödeme onaylandıktan sonra bile hizmetin kim tarafından teslim edileceği belirsiz olmamalıdır. İşletme, hazırlık için departmanı ve hizmet zamanını belirler; gerekiyorsa çalışma görevi veya operasyon notu açar. Rezervem Hospitality görev takibiyle ilişkili bir çözüm olabilir fakat Experience siparişinden Hospitality görevi otomatik açıldığı ilgili kurulumda ayrıca kanıtlanmalıdır.
Kodlu teslim kullanılan satışlarla rezervasyona bağlı hizmetler birbirinden farklıdır. Rezervasyona bağlı satışta her zaman kullanım kodu oluşturulduğu söylenemez. Misafir ürünü satın aldığında hem müşteri ekranındaki mesajın hem sipariş ekranındaki durumun hem de personelin teslim bilgisinin aynı işlemi işaret ettiğini doğrulayın.
6. Beş hata senaryosunu pilotta deneyin
Yalnız başarılı bir satış testi yeterli değildir. Ödeme tamamlanmadan misafire “satın aldınız” denmesi, iki kez tıklamayla mükerrer sipariş açılması veya iptal edilen konaklamaya bağlı ürünün hizmet ekibinde açık kalması gerçek risklerdir. Farklı para birimi, ödeme sağlayıcısı zaman aşımı ve eksik PMS yanıtı da işletmenin karşılaşabileceği durumlardır.
Test raporunda her senaryo için misafir mesajı, Experience sipariş durumu, Pay tahsilat sonucu, PMS etkisi ve varsa Hospitality görevi ayrı kolonlarda gösterilsin. Her adımda aynı güvenli işlem referansı kullanılmalı; kart veya kimlik bilgileri loglara taşınmamalıdır.
- Misafir ürün seçti, ödeme başarısız oldu: sipariş hizmete hazır olarak işaretleniyor mu?
- Misafir yeniden denedi: tek hizmet için iki tahsilat veya iki teslim kaydı oluşuyor mu?
- Konaklama iptal edildi veya oda değişti: ürün doğru konaklamaya bağlı kalıyor mu?
- Hizmet o anda uygun değil: onay bekleyen teklif ile kesin satış ayrılıyor mu?
- İade gerekti: Experience siparişi, Pay para kaydı ve hizmet ekibi durumu tutarlı mı?
7. Canlıya çıkmadan önce ürün yeteneklerini doğrulayın
Rezervem Experience katalog/sipariş altyapısı ile Pay tahsilat akışının kodda bulunması, her müşteri tesisinde bütün satın alma yollarının açık olduğu anlamına gelmez. Experience hesap modülü, ürünün satılacağı kanal, şube, ödeme sağlayıcısı, Stay satın alma ekranı ve personel operasyonu ayrı etkinleştirme/kabul adımlarıdır.
Özellikle PMS tarafında “ödeme alındıysa oda folyosuna işlendi” iddiasını genel geçer kullanmayın. İncelenen Rezervem PMS ve OHIP adaptörlerinde `Upsell` yazma portu uygulanmış değil. Bu nedenle otomatik folyo veya oda yükseltme vaadi ancak ilgili akış gerçek otel ortamında test edilirse kullanılabilir.
Yurt dışı tesiste ayrıca para birimi ve ödeme sağlayıcısı kontrolü yapılmalıdır. Experience sipariş modelinin mevcut karar dokümanı TRY üzerinden kurulmuştur; Mısır gibi farklı para birimi kullanan bir otelde EGP/USD/EUR ile checkout çalıştığı, canlı yetenek testi yapılmadan iddia edilmemelidir.
Bu akışın ticari ve teknik sorumluluk haritası: Stay misafir kanalı, Experience katalog/sipariş, Pay tahsilat, PMS oda-konaklama, Hospitality ekip operasyonudur.
