Otel Booking Engine Nasıl Seçilir? Doğrudan Rezervasyon, Ödeme ve Dönüşüm Rehberi

Bir otelin çok iyi bir web sitesi olabilir. Profesyonel fotoğrafları olabilir. Markası güçlü olabilir. Google'dan trafik gelebilir. Instagram'dan ziyaretçiler gelebilir. Misafir odaları inceleyebilir. Ve tam rezervasyon yapmaya karar verdiği anda Booking Engine — Rezervasyon Motoru devreye girer.

Bu nokta kritik bir eşiktir. Çünkü web sitesinin görevi misafiri ikna etmekse, booking engine'in görevi:

bu satın alma niyetini mümkün olan en az sürtünmeyle gerçek rezervasyona dönüştürmektir.

Booking engine yavaşsa, mobilde kötü çalışıyorsa, fiyatlar anlaşılmıyorsa, ödeme güven vermiyorsa, oda seçenekleri karmaşıksa, kullanıcı farklı bir görsel dünyaya geçiyorsa veya rezervasyon için gereksiz sayıda adım gerekiyorsa; web sitesinin daha önce yaptığı bütün iyi iş boşa gidebilir. Bu nedenle booking engine web sitesine eklenen teknik bir modül değildir. Otelin Direct Booking Infrastructure sisteminin merkezidir. Doğru zincir:

Traffic → Website → Intent → Availability Search → Room Selection → Rate Selection → Guest Details → Payment → Confirmation → PMS → Guest Journey

şeklindedir. Ve booking engine bu zincirin en ticari bölümünü yönetir.

1. Booking Engine Nedir?

Booking engine misafirin otelin kendi dijital kanalı üzerinden şunları yapmasını sağlayan sistemdir:

• tarih seçmesini,
• müsaitlik görmesini,
• oda seçmesini,
• fiyat seçmesini,
• paket seçmesini,
• bilgilerini girmesini,
• ödeme veya garanti işlemini yapmasını,
• rezervasyonu tamamlamasını

Türkçede Online Rezervasyon Motoru veya Rezervasyon Motoru olarak kullanılabilir.

2. Booking Engine ile Web Sitesi Aynı Şey Değildir

Web sitesi oteli anlatır, gösterir, ikna eder. Booking engine işlemi tamamlar. Basitleştirirsek: Website = Persuasion, Booking Engine = Transaction. Ama iyi sistemde misafir bu iki yapı arasında keskin bir geçiş hissetmemelidir.

3. Booking Engine'in Ticari Görevi

Booking engine'in amacı yalnızca “rezervasyon almak” değildir. Daha doğru hedef:

Mümkün olan en yüksek nitelikli talebi, sağlıklı fiyat ve mümkün olan en düşük gereksiz sürtünmeyle doğrudan rezervasyona çevirmektir.

Dolayısıyla booking engine aynı zamanda conversion, pricing, merchandising, upselling, payment, guest data ve attribution sistemidir.

4. Booking Engine Neden Stratejik Bir Karardır?

Çünkü yanlış sistem doğrudan geliri etkileyebilir. Örneğin 100 kişi rezervasyon motoruna giriyor. Bir sistem 3 rezervasyon üretiyor. Başka sistem 5 rezervasyon üretiyor. Aynı website. Aynı trafik. Aynı otel. Aynı fiyat. Ama conversion farklı. Bu nedenle booking engine yalnızca yazılım maliyeti üzerinden seçilmemelidir.

5. En Ucuz Booking Engine En Ucuz Seçenek Olmayabilir

Örneğin A sistemi aylık daha ucuz. Ama conversion düşük. B sistemi daha pahalı. Ama daha fazla direct booking üretiyor. Bu durumda A'nın yazılım fiyatı daha düşük olmasına rağmen; otel için ekonomik maliyeti daha yüksek olabilir. Doğru soru “Booking engine kaç para?” değildir. Daha doğru soru:

“Bu sistemin net direct booking ekonomisine etkisi nedir?”

olmalıdır.

6. Booking Engine Seçiminde İlk Soru

İlk soru özellik listesi olmamalıdır. Önce otel kendi ihtiyacını tanımlamalıdır. Örneğin:

Kaç oda var?

Kaç oda tipi var?

Kaç rate plan var?

Kaç dil gerekiyor?

Hangi para birimleri kullanılacak?

Hangi pazarlardan rezervasyon geliyor?

Hangi PMS kullanılıyor?

Hangi channel manager kullanılıyor?

Online ödeme alınacak mı?

Paket satılacak mı?

Upsell yapılacak mı?

Promo code kullanılacak mı?

Corporate rate gerekiyor mu?

Bu cevaplar teknoloji seçimini değiştirir.

7. Küçük Otel ile Büyük Otelin İhtiyacı Aynı Değildir

Altı odalı bir butik otel ile 300 odalı resort aynı booking altyapısına ihtiyaç duymayabilir. Küçük otelde öncelik şunlar olabilir:

• kolay kullanım,
• düşük operasyon yükü,
• mobile conversion,
• PMS entegrasyonu,
• ödeme,
• çok dil,
• analytics.

Büyük otelde bunlara ek olarak şunlar gerekebilir:

• loyalty,
• dynamic packaging,
• advanced upsell,
• multiple properties,
• member rates,
• sophisticated merchandising

En gelişmiş sistem değil, otelin ihtiyacına en uygun sistem seçilmelidir.

8. Booking Engine Ekosistemin Neresinde?

Modern otel teknoloji mimarisinde booking engine tek başına çalışmaz. Basitleştirilmiş yapı şöyle olabilir:

Website ↔ Booking Engine ↔ PMS ↔ Channel Manager ↔ OTA

Buna ayrıca şunlar eklenebilir:

Payment Gateway

CRM

Revenue Management System

Analytics

Marketing Platform

Guest Messaging

9. PMS Entegrasyonu

En kritik entegrasyonlardan biri PMS'tir. Booking engine'den gelen rezervasyon mümkünse otomatik olarak PMS'e düşmelidir. Böylece manuel rezervasyon girişi azalır. Bu hem iş yükünü hem hata riskini azaltabilir.

10. Manuel Rezervasyon Aktarımı Neden Risklidir?

Booking engine rezervasyonu e-mail olarak gönderiyor; resepsiyon PMS'e elle giriyorsa şu riskler oluşabilir:

Tarih hatası

İsim hatası

Fiyat hatası

Oda tipi hatası

Ödeme bilgisi hatası

Rezervasyonun unutulması

Inventory'nin geç güncellenmesi

Overbooking

Bu nedenle entegrasyon operasyonel değer yaratır.

11. Channel Manager Entegrasyonu

Booking engine doğrudan satış kanalıdır. Ama OTA kanallarıyla aynı inventory havuzunda çalışabilir. Channel manager müsaitlik ve fiyatların kanallar arasında yönetilmesine yardımcı olur. İdeal yapı:

PMS / Inventory → Channel Manager → OTA + Booking Engine

veya teknoloji mimarisine göre benzer senkronizasyon modelidir.

12. Real-Time Availability

Misafir website'de oda gördüğünde gerçek müsaitliği görebilmelidir. Booking engine inventory ile gecikmeli senkronize oluyorsa satılmayan oda görünebilir veya satılabilir oda kapalı görünebilir. İki durum da gelir kaybı yaratabilir.

13. Overbooking Riski

Entegrasyon zayıfsa aynı son oda hem OTA'dan hem direct kanaldan satılabilir. Bu özellikle küçük butik otellerde ciddi problemdir. Çünkü 6 odalı bir otelde bir overbooking toplam kapasitenin önemli bölümünü etkileyebilir.

14. Inventory Mantığı Test Edilmelidir

Demo sırasında sadece arayüz gösterilmemelidir. Şunlar test edilmelidir:

Son oda satıldığında ne oluyor?

Cancellation olduğunda inventory açılıyor mu?

Oda değişikliğinde ne oluyor?

Stop-sell nasıl çalışıyor?

Minimum stay nasıl uygulanıyor?

Closed to arrival destekleniyor mu?

Closed to departure destekleniyor mu?

Rate restriction nasıl çalışıyor?

Teknik demo gerçek operasyon senaryolarıyla yapılmalıdır.

15. Booking Engine UX

Misafir booking engine'i öğrenmek zorunda kalmamalıdır. İdeal akış sezgisel olmalıdır. Örneğin:

Dates → Guests → Rooms → Rate → Details → Payment → Confirmation

Kullanıcı her aşamada nerede olduğunu anlamalıdır.

16. Rezervasyon Adımı Ne Kadar Az Olmalı?

Genel prensip gereksiz adımları azaltmaktır. Ama “tek sayfa” her zaman otomatik olarak daha iyi değildir. Çok uzun tek form da kullanıcıyı yorabilir. Önemli olan Cognitive Load ve Friction azaltmaktır.

17. Mobile Booking Flow

Booking engine seçerken ilk testlerden biri telefondan yapılmalıdır. Çünkü masaüstünde iyi görünen sistem mobilde çok kötü olabilir. Şunlar kontrol edilmelidir:

Date picker

Guest selector

Room cards

Rate selection

Form fields

Payment

Confirmation

18. Mobile Date Picker

Takvim mobil rezervasyon akışının kritik noktalarından biridir. Kullanıcı check-in ve check-out tarihlerini kolay seçebilmelidir. Aylar arasında geçiş kolay olmalıdır. Seçilen gece sayısı net görünmelidir.

19. Flexible Dates

Bazı misafirlerin tarihi esnek olabilir. Sistem uygunsa alternatif tarih veya yakın gün fiyatlarını gösterebilir. Örneğin:

“Bu tarihte müsaitlik yok, 1 gün sonra oda mevcut.”

Bu no availability durumunda satışı kurtarabilir.

20. No Availability Bir Çıkmaz Sokak Olmamalı

En kötü ekran şudur:

No Rooms Available

ve başka hiçbir seçenek yok. Daha iyi sistem uygunsa şunları sunabilir:

Yakın tarihler

Alternatif oda

Minimum stay bilgisi

Tarih değiştirme

Contact Hotel

Waitlist

Amaç satın alma niyetini hemen kaybetmemektir.

21. Room Merchandising

Booking engine yalnızca oda ismi ve fiyat göstermemelidir. Odayı satmalıdır. Örneğin birlikte gösterilebilir:

Güçlü fotoğraf

Room size

Capacity

Bed

View

Key amenities

Cancellation

Meal inclusion

Price

22. Oda Fotoğrafı Booking Engine'de de Güçlü Olmalı

Website oda sayfasında harika fotoğraflar olup; booking engine'de tek küçük fotoğraf olması conversion kaybı yaratabilir. Misafir satın alma kararına yaklaştıkça ürün kanıtı azalmamalıdır.

23. Room Description

Booking engine oda açıklaması roman olmamalıdır. Karar vermek için gereken bilgi hızlı okunmalıdır. Örneğin 28 m² · King Bed · 2 Guests · Balcony · Courtyard View gibi bir özet çok etkili olabilir.

24. Rate Plan Nedir?

Aynı oda farklı fiyat ve koşullarla satılabilir. Örneğin:

Flexible Rate

Non-Refundable Rate

Bed & Breakfast

Room Only

Early Booking

Long Stay

Package

Bunların her biri bir Rate Plan olarak yönetilebilir.

25. Rate Plan İsimleri Misafirin Diliyle Yazılmalı

İç operasyonda şöyle kod kullanılıyor olabilir: BAR_BB_FLEX_24. Ama misafir bunu görmemelidir. Misafir için örneğin Flexible Rate — Breakfast Included daha anlaşılırdır. Internal code ile customer-facing name ayrılmalıdır.

26. Fiyat Farkı Anlaşılır Olmalı

Örneğin Flexible €220. Non-refundable €198. Misafir neden €22 daha az ödediğini anlamalıdır. Yanında açık şekilde Non-refundable yazmalıdır. Ucuz fiyat gösterip kritik koşulu küçük yazıyla saklamak güven yaratmaz.

27. Cancellation Policy

Cancellation şartı rezervasyon öncesinde açık olmalıdır. Örneğin:

Ne zamana kadar ücretsiz?

Sonrasında ne kadar ücret?

No-show durumunda ne olur?

Ön ödeme var mı?

İade ne zaman yapılır?

Belirsiz policy conversion ve misafir memnuniyeti problemi yaratabilir.

28. Vergi ve Ek Ücretler

Gösterilen fiyatın hangi vergileri ve ücretleri içerdiği açık olmalıdır. Checkout sonunda beklenmedik ücret çıkması güven kaybı yaratabilir. Temel prensip:

Price transparency reduces unpleasant surprises.

29. Total Stay Price

Misafir yalnızca gecelik fiyatı değil; toplam konaklama maliyetini de kolay görebilmelidir. Örneğin 3 Nights × €200 = €600 ve varsa ek ücretler açık gösterilmelidir.

30. Currency

Uluslararası otel için booking engine çoklu currency gösterebilir. Ama şu ayrım net olmalıdır:

Display Currency

Charge Currency

Misafir hangi para biriminde ödeme yapacağını bilmelidir.

31. Dil Desteği

Booking engine web sitesinin dillerini desteklemelidir. Website İngilizce ama Book Now sonrası Türkçe ekrana geçiyorsa; uluslararası misafir için büyük friction oluşabilir. Dil booking journey boyunca korunmalıdır.

32. Çeviri Kalitesi

Booking engine standart arayüz çevirileri sağlıyor olabilir. Ama otel tarafından girilen şunlar da kontrol edilmelidir:

• room names,
• descriptions,
• rate plans,
• cancellation policies,
• packages,
• extras.

Yarı Türkçe, yarı İngilizce checkout profesyonel görünmez.

33. Brand Continuity

Misafir web sitesinden booking engine'e geçtiğinde aynı markada olduğunu hissetmelidir. Mümkünse şunlar uyarlanabilmelidir:

Logo

Colors

Typography

Photography

Button style

Domain / subdomain

Language

Brand continuity güven oluşturur.

34. White Label

Bazı booking engine sağlayıcıları kendi markalarını gösterebilir. Bazıları daha white-label deneyim sunabilir. Premium markalarda misafir deneyiminin ne kadar otel markası altında kalacağı değerlendirilmelidir.

35. Custom Domain

Örneğin book.hotelname.com gibi bir subdomain kullanımı mümkün olabilir. Bu kullanıcıya marka devamlılığı hissi verebilir. Ama teknik kurulum, SSL, tracking ve provider gereksinimleri kontrol edilmelidir.

36. Payment Gateway Nedir?

Payment gateway online ödemenin teknik olarak işlenmesini sağlayan altyapıdır. Booking engine ile ödeme altyapısının uyumu kritiktir. Çünkü rezervasyon tamamlanmak üzereyken ödeme başarısız olursa; conversion kaybedilir.

37. Ödeme Modeli Önceden Tanımlanmalı

Her rate aynı ödeme modeline sahip olmak zorunda değildir. Örneğin şunlar kullanılabilir:

Pay at Hotel

Card Guarantee

Partial Prepayment

Full Prepayment

Non-Refundable Prepayment

Booking engine otel stratejisini desteklemelidir.

38. Kart Garantisi ile Ödeme Aynı Şey Değildir

Kart bilgisinin alınması her zaman kartın çekildiği anlamına gelmez. Misafir şunu net anlamalıdır:

“Şimdi ödeme mi yapıyorum?”

yoksa:

“Kartımı yalnızca rezervasyon garantisi için mi giriyorum?”

Belirsizlik chargeback, şikâyet ve güven problemi yaratabilir.

39. Payment Failure

Ödeme başarısız olduğunda sistem kullanıcıya anlaşılır yönlendirme sunmalıdır. Örneğin:

Kartı tekrar deneyin.

Başka kart kullanın.

Bankanızla görüşün.

Otelle iletişime geçin.

Ama teknik hata kodları misafire ham şekilde gösterilmemelidir.

40. Failed Payment Reservation Oluşturuyor mu?

Bu operasyonel olarak çok önemli sorudur. Örneğin payment başarısız oldu. Ama PMS'te rezervasyon oluştu mu? Inventory düştü mü? Misafire confirmation gitti mi? Bu senaryo canlıya geçmeden test edilmelidir.

41. 3D Secure ve Ödeme Akışı

Ödeme güvenliği mekanizmaları conversion flow ile uyumlu çalışmalıdır. Kullanıcı bankanın doğrulama ekranından döndüğünde rezervasyonun tamamlanıp tamamlanmadığını net görmelidir. “Ödeme yaptım ama rezervasyon oldu mu?” sorusu oluşmamalıdır.

42. Payment Security

Otel kart verisini gereksiz şekilde kendi sisteminde saklamamalıdır. Ödeme altyapısının uygun güvenlik standartlarına sahip olması kritiktir. Booking engine tedarikçisi seçilirken payment security yalnızca IT ekibinin sorusu olarak görülmemelidir. Bu ticari risk konusudur.

43. Fraud Management

Özellikle yüksek ADR ve uluslararası rezervasyonlarda fraud riskleri de düşünülmelidir. Ödeme altyapısının risk kontrolleri otel stratejisiyle uyumlu olmalıdır. Ama aşırı sert kontroller gerçek misafirlerin ödemelerini reddederek conversion kaybı yaratabilir.

44. Deposit Management

Booking engine depozito kurallarını desteklemelidir. Örneğin:

İlk gece

%30

%50

Tam ödeme

Belirli tarihte otomatik tahsilat

gibi modeller otel politikasına göre gerekebilir.

45. Cancellation ve Refund Workflow

Rezervasyon iptal edildiğinde şunlar net olmalıdır:

PMS güncelleniyor mu?

Inventory geri açılıyor mu?

Payment refund süreci nasıl?

Misafire e-mail gidiyor mu?

Accounting kaydı nasıl?

Cancellation fee nasıl işleniyor?

Booking sistemi rezervasyon almak kadar iptali de iyi yönetmelidir.

46. Self-Service Cancellation

Misafirin uygun koşullarda rezervasyonunu kendi linkinden iptal veya değiştirebilmesi operasyon yükünü azaltabilir. Ama policy kontrolleri doğru çalışmalıdır.

47. Modify Reservation

Misafir tarih, kişi sayısı veya oda değiştirmek istediğinde sistem bunu destekliyorsa resepsiyon iş yükü azalabilir. Ancak rate difference ve availability mantığı doğru çalışmalıdır.

48. Promo Code

Booking engine promo code destekleyebilir. Örneğin:

RETURN10

WEDDING

CORPORATE

DIRECT

Ama promo code kutusu misafirde şu hissi yaratabilir:

“Ben bilmediğim bir indirim kodunu mu kaçırıyorum?”

Bu nedenle UX yerleşimi düşünülmelidir.

49. Corporate Rates

Kurumsal müşteriler için özel kod veya login üzerinden fiyat sunulabilir. Bu özellikle şehir otellerinde önemli olabilir. Sistem public rate ile negotiated rate yönetimini desteklemelidir.

50. Member Rate

Otel sadakat veya üyelik sistemi kuruyorsa member rate sunulabilir. Ama küçük butik otel için karmaşık loyalty altyapısı zorunlu değildir. Basit e-mail capture ve returning guest benefit daha uygulanabilir olabilir.

51. Package Satışı

Booking engine yalnızca oda satmak zorunda değildir. Örneğin şunlar satılabilir:

Room + Breakfast

Room + Transfer

Romantic Package

Spa Package

Dinner Package

Experience Package

Bu Average Booking Value artışına katkı sağlayabilir.

52. Upsell Nedir?

Misafir ana ürünü seçtikten sonra ek ürün sunmaktır. Örneğin:

Airport Transfer

Breakfast

Late Check-Out

Early Check-In

Bottle of Wine

Room Upgrade

Extra Bed

Experience

Booking engine upsell yapabiliyorsa yalnızca conversion değil; booking value da artabilir.

53. Upsell'in Zamanlaması

Her ek ürünü rezervasyon öncesinde göstermek zorunlu değildir. Çok fazla seçenek checkout friction yaratabilir. Upsell şuralarda yapılabilir:

Booking sırasında

Confirmation sonrasında

Pre-arrival e-mail'de

Check-in öncesinde

Doğru ürün doğru zamanda sunulmalıdır.

54. Cross-Sell

Upsell daha üst ürüne geçiş anlamında kullanılabilirken; cross-sell tamamlayıcı ürün satışı olarak düşünülebilir. Örneğin oda alan misafire transfer satmak. Her iki model booking ekonomisini iyileştirebilir.

55. Room Upgrade

Örneğin misafir Standard oda seçti. Booking engine şunu gösterebilir:

€25 more per night — Upgrade to Deluxe with Balcony

Bu çok etkili bir merchandising alanı olabilir. Ama fiyat farkı ve elde edilen değer çok net olmalıdır.

56. Urgency Mesajları

Bazı booking sistemleri şunları gösterebilir:

“Only 1 room left.”

“High demand.”

Bu mesajlar yalnızca gerçek veriye dayanıyorsa kullanılmalıdır. Sahte urgency kısa vadede conversion yaratsa bile marka güvenine zarar verebilir.

57. Scarcity Gerçek Olmalı

Özellikle küçük otellerde “Only 1 room left” gerçekten doğru olabilir. Ama bu bilgi hangi oda tipi ve hangi inventory için geçerliyse sistem onu doğru yansıtmalıdır.

58. Direct Booking Benefit Booking Engine'de Görünmeli

Website “Book Direct” diyor. Ama booking engine direct avantajı göstermiyorsa; mesaj yarım kalır. Örneğin rate card üzerinde şunlar görülebilir:

Free cancellation

Welcome drink

Flexible check-in

Best available direct offer

uygunsa.

59. Rate Comparison

Bazı sistemler direct fiyatın diğer kanallarla karşılaştırılmasını destekleyebilir. Bu misafirin OTA'ya geri dönmesini azaltabilir. Ancak karşılaştırma verisinin doğru ve güncel olması şarttır. Yanlış karşılaştırma güven kaybı yaratır.

60. Cart Abandonment

Misafir rezervasyon akışına girdi. Oda seçti. Ama tamamlamadı. Bu Booking Abandonment olarak incelenebilir. Soru şudur:

Nerede vazgeçti?

61. Abandonment Funnel

Örneğin:

1,000 Booking Engine Sessions → 700 Room Views → 400 Rate Selections → 250 Checkout Starts → 150 Payments → 130 Reservations

Burada her adım incelenebilir. En büyük kayıp nerede? Bu soru optimization başlangıcıdır.

62. Abandonment Recovery

Uygun izin ve privacy çerçevesinde bazı sistemler abandoned booking recovery özellikleri sunabilir. Örneğin misafir e-mail bıraktıysa hatırlatma gönderilebilir. Ama agresif remarketing marka deneyimini bozmamalıdır.

63. Conversion Rate

Booking engine performansının temel KPI'larından biri conversion rate'tir. Basit formül:

Booking Engine Conversion Rate = Completed Reservations / Booking Engine Sessions × 100

Örneğin 2.000 session ve 100 rezervasyon varsa conversion %5 olur. Ama bu oran tek başına yorumlanmamalıdır.

64. Conversion Rate Neden Tek Başına Yeterli Değildir?

Örneğin çok yüksek fiyat ve düşük kaliteli traffic conversion'ı düşürebilir. Booking engine kötü olduğu için değil. Veya çok agresif indirim conversion'ı yükseltebilir; ama ADR ve kârlılığı düşürebilir. Bu nedenle conversion şunlarla birlikte okunmalıdır: Traffic Quality + ADR + Revenue + Acquisition Cost + Cancellation + Net Revenue

65. Booking Engine Revenue

Temel KPI'lar şunlar olabilir:

Reservations

Room Nights

Revenue

ADR

Average Length of Stay

Average Booking Value

Conversion Rate

Cancellation Rate

Lead Time

Mobile Conversion

Market / Country

66. Average Booking Value

Formül:

Average Booking Value = Total Booking Revenue / Number of Bookings

Upsell, paket ve oda upgrade stratejisinin etkisini okumaya yardımcı olabilir.

67. Revenue per Booking Engine Session

Önemli bir ticari ölçü şudur:

Revenue per Booking Engine Session = Booking Engine Revenue / Booking Engine Sessions

Bu conversion ve booking value etkisini tek ölçüde birleştirmeye yardımcı olabilir.

68. Mobile vs Desktop Conversion

Toplam conversion oranı sorunu gizleyebilir. Örneğin Desktop %6. Mobile %2. Bu durumda genel ortalama fena görünmeyebilir. Ama trafik çoğunlukla mobile ise büyük gelir fırsatı kaybediliyor olabilir. Bu nedenle device bazında analiz önemlidir.

69. Country / Market Conversion

Örneğin İngiltere'den trafik yüksek ama conversion düşük. Neden?

Currency?

Language?

Payment?

Price?

Cancellation terms?

Trust?

Flight connectivity?

Bu analiz booking engine verisini marketing kararına dönüştürebilir.

70. Rate Plan Conversion

Hangi rate plan daha çok satıyor? Flexible mi? Non-refundable mı? Breakfast included mı? Room-only mi? Bu veri rate architecture tasarımını iyileştirebilir.

71. Room Type Conversion

Hangi oda booking engine'de çok görüntüleniyor ama az satılıyor? Belki fiyat farkı yüksek. Belki fotoğraf zayıf. Belki oda özelliği anlaşılmıyor. Belki kategori ismi yanlış. Booking data ürün sunumunu iyileştirebilir.

72. Analytics Entegrasyonu

Booking engine analytics ile entegre olmalıdır. Ama özellikle farklı domain veya subdomain kullanılıyorsa tracking doğru kurulmalıdır. Aksi halde kullanıcı website'den booking engine'e geçtiğinde yeni session gibi görünebilir. Bu attribution verisini bozar.

73. Cross-Domain Tracking

Website hotel.com, booking engine başka bir domain üzerindeyse; analytics kurulumu customer journey'yi doğru takip edecek şekilde yapılandırılmalıdır. Amaç:

Website → Booking Engine → Reservation

zincirini tek journey olarak okuyabilmektir.

74. Conversion Tracking

Sadece booking engine'e kaç kişinin girdiğini ölçmek yeterli değildir. Mümkünse şunlar event olarak izlenebilir:

Availability Search

Room View

Rate Selection

Checkout Start

Payment Start

Booking Complete

Revenue

Bu funnel optimization için çok daha değerlidir.

75. Marketing Attribution

Google Ads veya Meta kampanyasından gelen misafir rezervasyon yaptığında bu conversion'ın doğru kampanyaya bağlanabilmesi önemlidir. Booking engine tracking kapalı bir kutu olmamalıdır. Marketing ve booking data mümkün olduğunca bağlanmalıdır.

76. First-Party Guest Data

Direct booking'in önemli avantajlarından biri misafir ilişkisinin otele daha doğrudan gelmesidir. Booking engine şu verilerin uygun şekilde PMS/CRM sistemine aktarılmasını desteklemelidir:

Name

E-mail

Phone

Country

Stay Details

Rate

Preferences

uygun izin çerçevesinde. Bu gelecekte repeat booking ve CRM için değerlidir.

77. Guest Data Ownership

Booking engine sağlayıcısına şu soru sorulmalıdır:

Misafir verisinin sahibi kim?

Ayrıca:

Veriyi export edebilir miyiz?

Sözleşme bittiğinde ne olur?

Hangi veriler tutuluyor?

Nerede tutuluyor?

Kim erişebiliyor?

Entegrasyon API'si var mı?

Teknoloji tedarikçisi değiştiğinde otel müşteri verisini kaybetmemelidir.

78. Privacy

Booking sırasında kişisel veri işlenir. Bu nedenle privacy ve consent mekanizmaları ilgili hukuki çerçeveyle uyumlu olmalıdır. Marketing izni ile rezervasyon için zorunlu veri işleme aynı şey olarak düşünülmemelidir.

79. Marketing Consent

Misafir oda rezervasyonu yapıyor diye otomatik olarak marketing listesine eklenmemelidir. İlgili hukuki gereklilikler ve izin mekanizmaları doğru kurgulanmalıdır. Booking engine bu ayrımı destekleyebilmelidir.

80. Confirmation

Rezervasyon tamamlandığında misafir şunları görmelidir:

Booking Number

Guest Name

Hotel

Room

Check-In

Check-Out

Guests

Rate Plan

Total Price

Payment Status

Cancellation Policy

Contact

Bu bilgi confirmation e-mail'de de bulunmalıdır.

81. Confirmation Page Satışın Sonu Değildir

Confirmation page aynı zamanda next-step sayfasıdır. Örneğin şunlar sunulabilir:

Airport Transfer

Directions

Add to Calendar

Contact Hotel

Manage Booking

Pre-Arrival Information

Ama misafir rezervasyonu tamamladığı anda agresif satış yapılmamalıdır.

82. Pre-Arrival Entegrasyonu

Booking sonrası guest journey şöyle devam edebilir:

Booking → Confirmation → Pre-Arrival → Upsell → Arrival Information → Check-In

Booking engine veya bağlı CRM bu journey'yi otomatikleştirebilir. Bu hem operasyon hem gelir açısından değer yaratabilir.

83. Booking Engine ve CRM

İdeal durumda direct booking guest profile ile bağlanabilir. Böylece otel şunları anlayabilir:

İlk rezervasyon mu?

Repeat guest mi?

Hangi pazardan geliyor?

Hangi oda tercih ediyor?

Ortalama harcaması ne?

Hangi kampanyaya cevap verdi?

Bu direct booking'i yalnızca distribution değil; customer relationship kanalına dönüştürür.

84. Booking Engine ve Revenue Management

Booking engine rate strategy ile uyumlu olmalıdır. Örneğin şu gibi kuralları destekleme kapasitesi değerlendirilmelidir:

BAR

Restrictions

Minimum Stay

Closed to Arrival

Closed to Departure

Derived Rates

Packages

Promotions

Length-of-Stay Pricing

85. Derived Rates

Örneğin Non-refundable rate BAR'dan %10 düşük olarak tanımlanabilir. BAR değiştiğinde derived rate otomatik güncellenebilir. Bu manuel fiyat yönetimini azaltabilir.

86. Restriction Yönetimi

Revenue stratejisinde sadece fiyat değişmez. Availability kuralları da değişebilir. Örneğin:

MinLOS

MaxLOS

CTA

CTD

Stop Sell

Booking engine bu kuralları doğru uygulamalıdır.

87. Rate Loading Hatası

Booking engine'de yanlış fiyat yüklenmesi doğrudan gelir kaybına neden olabilir. Bu nedenle rate setup sonrası test rezervasyonları yapılmalıdır. Özellikle şu senaryolar kontrol edilmelidir:

Weekday

Weekend

High Season

Low Season

Holiday

Different Occupancy

Child

Extra Bed

88. Child Pricing

Çocuk politikası karmaşıksa booking engine bunu doğru desteklemelidir. Örneğin yaş aralıkları, extra bed, crib, meal ve occupancy kuralları yanlış hesaplanırsa hem gelir hem misafir deneyimi sorunu oluşabilir.

89. Occupancy Pricing

Tek kişilik ve çift kişilik fiyat farklıysa sistem doğru hesaplamalıdır. Aynı şekilde üçüncü kişi ve extra bed fiyatları da doğru uygulanmalıdır.

90. Vergi ve Fiyat Konfigürasyonu

Vergi inclusive veya exclusive gösterim mantığı pazara ve hukuki gerekliliklere uygun olmalıdır. Booking engine fiyatı yanlış hesaplarsa sorun yalnızca UX değildir. Muhasebe ve misafir ilişkisi sorununa dönüşebilir.

91. API ve Entegrasyon Yeteneği

Bugün ihtiyaç duymasanız bile gelecekte şunları bağlamak isteyebilirsiniz:

PMS

CRM

RMS

Loyalty

Marketing Automation

Payment

BI

Guest App

Bu nedenle booking engine'in entegrasyon mimarisi değerlendirilmelidir. Kapalı sistem gelecekte teknoloji borcu yaratabilir.

92. API Var Demek Yeterli Değildir

Satış sunumunda “API'miz var.” denebilir. Ama şunlar sorulmalıdır:

Hangi endpoints?

Read mi, write mı?

Real-time mı?

Documentation var mı?

Rate limit var mı?

Ek ücret var mı?

Webhook var mı?

Sandbox var mı?

Kim entegrasyon yapıyor?

Support nasıl?

Gerçek entegrasyon kapasitesi detayda anlaşılır.

93. Vendor Lock-In

Booking engine değiştirmek zor olabilir. Çünkü sistem şunlara bağlanır:

• website,
• PMS,
• payment,
• analytics,
• rate plans,
• guest data,
• confirmation,
• marketing.

Bu nedenle sözleşme öncesinde exit senaryosu da düşünülmelidir.

94. Sözleşmede Kontrol Edilecek Konular

Örneğin:

Setup fee

Monthly fee

Commission

Transaction fee

Payment fee

Integration fee

Support fee

Minimum term

Renewal

Termination

Data export

Data ownership

SLA

Support hours

Development charges

Toplam maliyet yalnızca aylık lisans değildir.

95. Booking Engine Maliyet Modeli

Sağlayıcı farklı modeller kullanabilir. Örneğin:

Fixed Monthly Fee

Commission per Booking

Transaction Fee

Hybrid

Setup + Subscription

Bu modeller otel hacmine göre farklı ekonomik sonuç üretebilir.

96. Effective Booking Engine Cost

Daha doğru hesap şöyle yapılabilir:

Effective Booking Engine Cost = Tüm Booking Engine ve İlgili İşlem Maliyetleri / Direct Booking Revenue

Böylece farklı vendor teklifleri aynı zeminde karşılaştırılabilir.

97. TCO — Total Cost of Ownership

Sadece yazılım faturası değil; şunlar da düşünülmelidir:

Setup

Integration

Payment

Training

Maintenance

Development

Support

Internal Labor

Migration

Lost Conversion

Özellikle sonuncusu çoğu karşılaştırmada unutulur.

98. SLA

Sistem Cuma akşamı çöktü. Ne olacak? Vendor ile şunlar net olmalıdır:

Support hours

Response time

Critical incident process

Uptime commitment

Escalation

Contact channel

Booking engine 7/24 gelir üreten sistemdir. Destek modeli buna uygun olmalıdır.

99. Downtime Maliyeti

Booking engine çalışmıyorsa misafir beklemek zorunda değildir. OTA'ya gidebilir. Dolayısıyla downtime yalnızca IT problemi değildir. Revenue Leakage problemidir.

100. Demo Nasıl Yapılmalı?

Vendor size PowerPoint göstermemelidir. Gerçek rezervasyon yapılmalıdır. Tercihen telefon üzerinden. Senaryo şöyle olabilir:

Tarih seç.

İki kişi seç.

Oda karşılaştır.

Flexible rate seç.

Promo code dene.

Extra ekle.

Kartla öde.

Confirmation gör.

PMS'e bak.

Confirmation e-mail'i kontrol et.

Bu test gerçek ürünü gösterir.

101. Vendor'a Sorulacak 25 Soru

1. PMS entegrasyonunuz var mı?
2. Channel manager entegrasyonunuz var mı?
3. Real-time inventory nasıl çalışıyor?
4. Mobile conversion veriniz var mı?
5. Kaç dil destekleniyor?
6. Hangi currency'ler destekleniyor?
7. Payment entegrasyonları neler?
8. 3D Secure nasıl çalışıyor?
9. Deposit destekleniyor mu?
10. Refund workflow nasıl?
11. Promo code var mı?
12. Corporate rate var mı?
13. Member rate var mı?
14. Package satılabiliyor mu?
15. Upsell yapılabiliyor mu?
16. Abandoned booking özelliği var mı?
17. Analytics entegrasyonu nasıl?
18. Cross-domain tracking destekleniyor mu?
19. Conversion events erişilebilir mi?
20. API var mı?
21. Guest data export edilebilir mi?
22. SLA nedir?
23. Support hangi saatlerde?
24. Toplam ücret modeli nedir?
25. Ayrılmak istersek veri ve entegrasyon süreci nasıl?

102. Booking Engine Scorecard

Vendor'ları puanlayabilirsiniz. Örneğin:

Toplam: %100. Bu seçimi yalnızca demo etkisine bırakmaz.

103. Conversion Capability Nasıl Puanlanır?

Şunlar değerlendirilebilir:

Mobile UX

Speed

Room presentation

Rate clarity

Checkout steps

Payment success

Flexible dates

No-availability recovery

Upsell

Abandonment recovery

Analytics

A/B testing capability

Vendor “yüksek conversion” diyorsa bunu hangi veriyle desteklediği sorulmalıdır.

104. Mevcut Müşteri Referansları

Benzer otel tiplerinde çalışan müşteriler sorulabilir. Örneğin küçük boutique hotel için 300 odalı resort referansı tek başına yeterli değildir. Şunlar daha değerlidir:

Benzer oda sayısı

Benzer pazar

Benzer ADR

Benzer PMS

Benzer ülke

Benzer direct booking strategy

105. Referans Otelin Booking Flow'unu Kendiniz Test Edin

Vendor'ın verdiği referans siteleri telefonunuzdan açın. Gerçek misafir gibi rezervasyon akışına girin. Şunlara bakın:

Hız

Tasarım

Oda sunumu

Rate clarity

Mobile

Payment flow

Brand continuity

Satış sunumundan çok daha fazla şey öğrenebilirsiniz.

106. Migration Plan

Booking engine değiştirilecekse geçiş planı yapılmalıdır. Örneğin:

Existing bookings

Future bookings

Rate plans

Room types

Policies

Payment tokens

Guest data

Promo codes

Analytics

URLs

Confirmation templates

PMS mapping

Eksik migration operasyonel kaos yaratabilir.

107. Parallel Testing

Mümkünse eski sistem kapatılmadan önce yeni sistem test ortamında kontrol edilmelidir. Özellikle şunlar test edilmelidir:

Rate

Inventory

Payment

PMS delivery

E-mail

Analytics

Cancellation

108. Test Rezervasyonu Zorunludur

Canlı sistem açıldığında otel ekibi gerçek rezervasyon yapmalıdır. Farklı senaryolar denenmelidir. Örneğin:

Flexible

Non-refundable

Mobile

Desktop

International card

Promo code

Cancellation

Modification

Refund

Sold-out date

Sistem “entegrasyon tamamlandı” denildiği için hazır kabul edilmemelidir.

109. Booking Engine QA Checklist

Availability doğru mu?

Rates doğru mu?

Taxes doğru mu?

Room names doğru mu?

Photos doğru mu?

Policies doğru mu?

Languages doğru mu?

Currency doğru mu?

Payment çalışıyor mu?

PMS'e düşüyor mu?

Confirmation geliyor mu?

Cancellation çalışıyor mu?

Mobile iyi mi?

Analytics çalışıyor mu?

Revenue tracking doğru mu?

Promo code çalışıyor mu?

Upsell doğru mu?

Sold-out logic doğru mu?

Support contact hazır mı?

110. Booking Engine Dashboard

Aylık dashboard örneği:

Ama rakamların yanında yorum olmalıdır.

111. Booking Engine Review Toplantısı

Aylık olarak şunlar sorulabilir:

Conversion neden değişti?

Mobile performansı nasıl?

En çok hangi oda satılıyor?

Hangi rate plan satılıyor?

Payment failure arttı mı?

Abandonment nerede?

Hangi market daha iyi dönüyor?

Upsell çalışıyor mu?

Booking value arttı mı?

Direct share değişti mi?

OTA ile fiyat tutarlılığı nasıl?

Teknik hata var mı?

Bu sistem booking engine'i aktif gelir yönetimi aracına dönüştürür.

112. Booking Engine ve OTA Ekonomisi

Direct booking otomatik olarak “ücretsiz rezervasyon” değildir. Direct kanalda şunlar olabilir:

Website cost

Booking engine cost

Payment fee

Advertising cost

CRM cost

Promotion / discount

Internal marketing labor

Bu nedenle OTA komisyonu ile yalnızca booking engine komisyonunu karşılaştırmak eksik analiz olur.

113. Net Channel Cost

Daha sağlıklı yaklaşım her kanalın toplam edinme ve dağıtım maliyetini hesaplamaktır. Basitleştirilmiş formül:

Net Channel Revenue = Gross Booking Revenue − Channel-Specific Costs

Sonra direct, OTA, corporate ve diğer kanallar karşılaştırılabilir.

114. Direct Booking'in Stratejik Değeri

Direct booking'in değeri yalnızca daha düşük komisyon değildir. Ayrıca şu gibi avantajlar yaratabilir:

Guest relationship

First-party data

Upsell opportunity

Repeat booking

Brand control

Communication

Customer lifetime value

Bu nedenle direct channel uzun vadeli marka stratejisinin parçasıdır.

115. Ancak OTA'yı Yok Etmek Amaç Değildir

Doğrudan rezervasyon stratejisinin amacı OTA kanallarını tamamen ortadan kaldırmak olmamalıdır. OTA şunları sağlayabilir:

Reach

Discovery

International demand

Trust

Market access

Asıl amaç sağlıklı kanal karması oluşturmaktır. Booking engine bu denge içinde direct kanalın teknik motorudur.

116. Booking Engine İçin 15 Yaygın Hata

1. En ucuz sistemi seçmek.
2. Mobile test yapmamak.
3. PMS entegrasyonunu kontrol etmemek.
4. Channel manager senkronizasyonunu test etmemek.
5. Booking engine'i markadan kopuk bırakmak.
6. Oda fotoğraflarını zayıf kullanmak.
7. Rate plan isimlerini anlaşılmaz bırakmak.
8. Cancellation koşullarını gizlemek.
9. Vergi ve ücretleri son adımda göstermek.
10. Çok uzun checkout formu kullanmak.
11. Payment failure senaryosunu test etmemek.
12. Analytics entegrasyonu kurmamak.
13. Conversion ölçmemek.
14. Guest data ownership konusunu sormamak.
15. Vendor çıkış planını düşünmemek.

117. Booking Engine İçin 20 Karar Kapısı

Karar Kapısı 1

PMS entegrasyonu var mı?

Karar Kapısı 2

Channel manager entegrasyonu güvenilir mi?

Karar Kapısı 3

Real-time inventory çalışıyor mu?

Karar Kapısı 4

Mobile UX güçlü mü?

Karar Kapısı 5

Rezervasyon akışı kısa ve anlaşılır mı?

Karar Kapısı 6

Oda sunumu yeterli mi?

Karar Kapısı 7

Rate plan'lar net mi?

Karar Kapısı 8

Cancellation koşulları açık mı?

Karar Kapısı 9

Vergi ve toplam fiyat şeffaf mı?

Karar Kapısı 10

Gerekli diller destekleniyor mu?

Karar Kapısı 11

Gerekli currency desteği var mı?

Karar Kapısı 12

Payment sistemi uygun mu?

Karar Kapısı 13

Refund ve cancellation workflow çalışıyor mu?

Karar Kapısı 14

Upsell ve package desteği yeterli mi?

Karar Kapısı 15

Analytics ve conversion tracking mümkün mü?

Karar Kapısı 16

Guest data otele ait mi?

Karar Kapısı 17

API ve entegrasyon kapasitesi yeterli mi?

Karar Kapısı 18

Support ve SLA yeterli mi?

Karar Kapısı 19

TCO kabul edilebilir mi?

Karar Kapısı 20

Sistem gerçek rezervasyon senaryolarıyla test edildi mi?

118. Küçük Bir Butik Otel İçin Minimum Booking Engine Gereksinimi

Küçük independent otel için minimum güçlü yapı şöyle olabilir:

Responsive / Mobile-First

PMS Integration

Channel Manager Integration

Real-Time Availability

Room Photos

Rate Plans

Cancellation Policies

Multilingual

Multi-Currency Display

Secure Payment

Promo Codes

Basic Packages

Confirmation E-mail

Booking Modification / Cancellation

Analytics

Conversion Tracking

Guest Data Export

Brand Customization

Support

Security

Reliable Backup / Infrastructure

Bu özellikler booking engine'i yalnızca rezervasyon formundan çıkarır. Gerçek direct sales altyapısına dönüştürür.

119. Booking Engine Seçim Sürecinin Doğru Sırası

Doğru süreç şöyle olabilir:

Business Requirements → PMS/Channel Architecture → Payment Requirements → Vendor Shortlist → Integration Review → Mobile UX Test → Real Booking Demo → Commercial Proposal → TCO Analysis → Security/Privacy Review → Contract Review → Configuration → Integration → QA → Test Booking → Launch → Measurement → Optimization

Bu sıralama önemlidir. Çünkü vendor seçimi demo ekranının güzelliğine göre yapılmamalıdır.

120. Booking Engine Workbook

Proje dosyası şu başlıklardan oluşturulabilir:

A — Business Requirements

B — Room & Rate Architecture

C — PMS Integration

D — Channel Manager

E — Payment

F — Languages & Currency

G — UX

H — Mobile

I — Brand Customization

J — Packages & Upsell

K — Analytics

L — Attribution

M — Guest Data

N — Privacy & Security

O — Vendor Comparison

P — Commercial Terms

Q — Implementation

R — QA

S — Dashboard

T — Optimization Log

Bu dosya booking engine seçimini kişisel beğeniden çıkarır; kurumsal karara dönüştürür.

121. Booking Engine'in Tam Ticari Zinciri

Bütün sistemi tek zincirde gösterirsek:

Brand → Traffic → Website → Room Interest → Availability Search → Booking Engine → Inventory → Room Selection → Rate Selection → Policy → Guest Details → Payment → Reservation → PMS → Confirmation → CRM → Pre-Arrival → Stay → Upsell → Guest Data → Review → Repeat Booking → Direct Demand

Booking engine bu zincirin yalnızca bir teknoloji parçası değildir. Niyet ile gelir arasındaki köprüdür.

122. Booking Engine'in Yönetim Döngüsü

Sistem kurulduktan sonra iş bitmez. Doğru döngü şudur:

Traffic → Search → Selection → Checkout → Booking → Revenue → Data → Funnel Analysis → Friction Detection → Hypothesis → Improvement → Measurement → Learning → New Optimization

Bu döngü sürekli çalışmalıdır. Çünkü booking engine bir kez kurulan ve sonra unutulan altyapı değildir.

123. Sonuç: Booking Engine Rezervasyon Formu Değil, Otelin Dijital Kasasıdır

Misafir otel web sitesine geldiğinde henüz gelir oluşmamıştır. Fotoğrafları beğenebilir. Odayı inceleyebilir. Lokasyonu kontrol edebilir. Markaya güvenebilir. Hatta rezervasyon yapmaya karar verebilir. Ama ticari işlem tamamlanmadığı sürece bütün bunlar yalnızca satın alma niyetidir. Booking engine'in görevi bu niyeti gelire dönüştürmektir.

Bu nedenle iyi booking engine misafirin önüne çıkmaz. Kendini hissettirmez. Süreci kolaylaştırır. Odayı iyi gösterir. Fiyatı anlaşılır gösterir. Koşulları saklamaz. Mobilde çalışır. Ödemede güven verir. Rezervasyonu PMS'e doğru aktarır. Confirmation gönderir. Veriyi ölçülebilir hale getirir. Ve otele yalnızca rezervasyon değil; müşteri ilişkisi kazandırır.

Bu nedenle booking engine seçerken sorulması gereken asıl soru şu değildir:

“En fazla özelliği hangi sistem sunuyor?”

Asıl soru şudur:

“Hangi sistem bizim misafirimizin en az sürtünmeyle rezervasyon yapmasını, operasyonumuzun bunu hatasız yönetmesini ve otelin direct channel ekonomisini sürdürülebilir şekilde geliştirmesini sağlar?”

Doğru cevap bulunduğunda booking engine web sitesinin sonuna eklenen bir form olmaktan çıkar. Otelin doğrudan satış motoruna dönüşür.

Ve doğrudan satış güçlendikçe otel yalnızca dağıtım maliyetini daha iyi yönetmez. Misafiri daha iyi tanır. Rezervasyon öncesi ilişkiyi kontrol eder. Upsell fırsatları yaratır. Repeat booking potansiyelini artırır. Ve zamanla OTA üzerinden kiraladığı müşteri erişiminin yanına kendi müşteri talebini inşa etmeye başlar.

Güçlü bir booking engine'in nihai değeri rezervasyon almak değil; markanın kendi talebini kendi kanalında gelire dönüştürebilme kapasitesini artırmaktır.

Otel Yatırım Rehberi — Cilt VII

Cilt VII — Satış, Pazarlama ve Marka, otelin marka stratejisinden başlayarak görünürlük, dağıtım, itibar ve doğrudan rezervasyon sisteminin nasıl kurulacağını bütünsel olarak ele alır.

Booking engine bu yapının transaction katmanıdır.

Ama sistem burada bitmez.

Ardından şu zincirin yönetilmesi gerekir:

SEO → Organic Demand → OTA → Google → Reputation → Social Media → Content → Digital Advertising → CRM → Repeat Guest → Direct Demand → Conversion → Revenue → Customer Lifetime Value

Amaç yalnızca daha fazla rezervasyon almak değildir. Amaç: doğru talebi doğru kanaldan, ölçülebilir maliyetle, mümkün olan en sağlıklı net gelirle ve uzun vadeli misafir ilişkisi yaratarak rezervasyona dönüştüren ticari bir sistem kurmaktır.