Küçük bir otelin sitesi nasıl kurulmalı? Kıranköy Dağ Evi

Küçük ölçekli konaklama işletmelerinin siteleri birbirine benziyor. Aynı şablon, aynı kayan görsel, aynı "Rezervasyon Talebi" formu. Mekânın karakteri kayboluyor ve asıl iş — hangi odanın hangi tarihte dolu olduğu — sitenin tamamen dışında, bir deftere ya da telefondaki mesajlara kalıyor.

Kıranköy Dağ Evi projesinde bunu tersine kurduk: misafirin gördüğü vitrin ile resepsiyonun gün içinde kullandığı panel aynı veriyi paylaşıyor. Vitrinde yapılan her talep panelde anında görünüyor, panelde yapılan her değişiklik vitrine anında yansıyor.

Aşağıda projede verdiğimiz kararları ve sebeplerini anlattım. Sonunda da işletmecilerin en çok sorduğu soruya geldim: rezervasyonu Booking gibi bir siteye bırakmak isterseniz ne oluyor?

Şablon site neden yetmiyor?

Hazır bir otel teması ilk gün iyi görünür. Sorun ikinci aydan sonra başlar.

Bir fiyat değişir, temanın fiyat alanı sadece tek bir para birimi kabul eder. Bir oda eklenir, tema dört odaya göre tasarlanmıştır. Sezonluk bir etkinlik duyurulacaktır, tema bunu bilmez. Her seferinde ya eklenti aranır ya da site "şimdilik böyle kalsın" diye bırakılır.

Asıl mesele şu: şablon, sizin işinizi değil, şablonu yazan kişinin hayal ettiği ortalama oteli tarif eder. Altı odalı bir dağ evi ortalama bir otel değil.

İki ayrı yüz, tek veri kaynağı

Projede iki arayüz var ve ikisi bilerek birbirine benzemiyor.

Vitrin tarafı sert bir editoryal dil izliyor: hiçbir köşe yuvarlatılmıyor, gölge yerine ince çizgi ızgaralar kullanılıyor. Bunu bir kural hâline getirdik — global bir CSS kuralı tarayıcının varsayılan yuvarlatmalarını tamamen siliyor. Panel ise kendi kapsamında ölçülü yarıçapları geri açıyor, çünkü orada amaç karakter değil, gün içinde yorulmadan kullanabilmek.

Görünüşleri ayrı ama verileri ortak. Odalar, etkinlikler ve rezervasyonlar tek bir yerde tutuluyor; iki taraf da oraya bakıyor. Şablon sitelerdeki kopukluğun sebebi tam olarak bu: veri tek yerde durmadığı için sitedeki fiyat ile defterdeki fiyat zamanla ayrışıyor.

Rezervasyon üç adım

Rezervasyon akışı üç ekrana bölündü: tarih ve kişi sayısı, oda ve etkinlik seçimi, özet ve onay.

Bölmenin sebebi estetik değil. Tek sayfalık uzun bir form, telefonda doldurulurken yarıda bırakılıyor. Üç adımda ilerleyen bir akışta misafir her adımda ne kadar yol kaldığını görüyor ve müsaitlik gerçek rezervasyon çakışmalarına göre hesaplandığı için dolu bir tarihi seçip sonunda "üzgünüz" yazısıyla karşılaşmıyor.

Takvim: hücre değil, çubuk

Paneldeki doluluk takvimi klasik hücre ızgarası olarak başlamıştı. Sorun şuydu: üç gecelik bir konaklama üç ayrı hücre olarak görünüyor, gözünüz onu tek bir konaklama olarak toparlayamıyordu.

Takvimi, her kaydın gerçek uzunluğuyla çizildiği bir zaman çizelgesine dönüştürdük. Artık boşluklar bir bakışta görülüyor — bu da resepsiyonun asıl işi.

Paneldeki grafikler de elle yazılmış SVG ve CSS ile üretildi; hiçbir grafik kütüphanesi eklenmedi. Üç grafik için yüzlerce kilobayt betik indirtmenin anlamı yok, telefonda bunun bedelini misafir ödüyor.

---

Peki rezervasyonu Booking'e bırakmak isterseniz?

Bu, işletmecilerin en sık sorduğu soru ve gayet meşru. Küçük konaklama işletmelerinin çoğu bugün Booking, Airbnb ya da benzeri bir platform üzerinden doluyor. Platform görünürlük getiriyor, ödeme ve iptal süreçlerini üstleniyor — karşılığında her rezervasyondan komisyon alıyor.

İkisi arasında doğru cevap tek değil. Üç yol da işliyor:

• Yalnızca kendi siteniz. Komisyon yok, misafir doğrudan sizin. Karşılığında müsaitliği ve iptalleri kendiniz yönetiyorsunuz.
• Yalnızca platform. Site vitrin olarak kalıyor, "Rezerve et" düğmesi platformun sayfasına gidiyor. Yönetim yükü sıfır, komisyon sabit gider.
• İkisi birden. En yaygını. Site kendi doğrudan talebini alıyor, yanında platform bağlantısı da duruyor. Doğrudan gelen misafirde komisyon ödemiyorsunuz.

Buradaki teknik mesele şu: bu karar site yapılırken verilmek zorunda değil, ama mimarinin bu kararın değişmesine izin vermesi gerekiyor.

Kıranköy'de rezervasyon akışı vitrinden ayrı bir parça. İşletme yarın "artık rezervasyonu platform üzerinden alalım" derse, o akışın yerine dış bağlantı konuluyor; oda bilgileri, galeri, fiyat ve etkinlik yönetimi panelde aynen kalıyor. Site baştan yazılmıyor, tek bir adım değişiyor. Tersi de geçerli: platformla başlayıp sonra kendi rezervasyonunuza geçmek isterseniz akış zaten yerinde duruyor.

Şablon sitelerde bu esneklik genelde yok. Rezervasyon eklentisi temaya gömülü olduğu için onu çıkarmak siteyi bozuyor, platforma yönlendirmek isteyince de sayfanın yarısı boşta kalıyor.

Bir uyarı: iki kanalı birlikte kullanacaksanız müsaitliğin iki yerde ayrı ayrı tutulması gerçek bir risk. Aynı odayı hem siteden hem platformdan satmamak için ya tek bir kanalı asıl kabul etmeli ya da takvimleri senkronize eden bir kanal yöneticisi kullanmalısınız. Bu, yazılımdan önce işletme kararı.

Sayılar

Proje 29 statik üretilen sayfa ve 37 arayüz bileşeninden oluşuyor. Statik üretim şu demek: sayfa, ziyaretçi geldiğinde hesaplanmıyor, önceden hazırlanmış hâlde duruyor — dağ başındaki bir pansiyonun sitesinde bunun pratik karşılığı, zayıf mobil bağlantıda bile hızlı açılmak.

Projenin tamamını vaka analizi sayfasında anlattık; canlı sürümü buradan gezebilirsiniz.

Sizin işletmeniz için

Bir otel ya da pansiyon sitesinde asıl soru "kaç sayfa olacak" değil, rezervasyonun nerede duracağı. Bu soruyu baştan netleştiren proje, bir yıl sonra fikir değiştiğinde de ayakta kalıyor.

İşletmenizin durumunu anlatın, hangi yolun size uyduğuna birlikte bakalım: projenizi anlatın, 24 saat içinde kapsam, süre ve bütçe hakkında net bir yanıtla dönelim.