Rezervasyon Sistemli Web Sitesi Tasarımı

Rezervasyon alan bir sitenin başarısı tasarımdan çok, arkadaki kuralların ne kadar doğru tanımlandığına bağlıdır. Takvim ne kadar şık görünürse görünsün, kapasite yanlış girilmişse ya da ödeme yarıda kaldığında yer boşa çıkmıyorsa sorun sadece ekrandan kapıya taşınır.

Bu rehberde Talha Aslan ve ekibi olarak oda, saha, masa, tur ve etkinlik işletmeleriyle rezervasyon sistemi planlarken verdiğimiz kararları sırasıyla anlatıyoruz. Her bölümde kendi işletmenize uygulayabileceğiniz bir ölçüt, bir adım listesi ya da ajansınıza soracağınız somut bir soru var.

01Sattığınız birimi ve süresini tanımlamak

Rezervasyon sisteminin ilk kararı, tam olarak neyi sattığınızı yazmaktır: bir birim, bu birimin kapasitesi ve zamanı nasıl tükettiği. Halı sahada birim bir saattir, otelde bir gecedir, tekne turunda ise bir seanstaki koltuktur. Bu üç model farklı ekranlar, farklı kurallar ve farklı raporlar ister.

Birimi tanımlarken çoğu işletmenin atladığı ayrıntılar şunlardır:

• Bölünebilen alanlar: Büyük bir saha iki küçük sahaya ayrılabiliyorsa, büyük saha satıldığında iki küçüğün de kapanması gerekir.
• Birleşen birimler: Restoranda iki masa yan yana getirilip sekiz kişilik grup ağırlanıyorsa, sistem bu birleşimi tanımalıdır.
• Aynı tipteki birimler: Otelde müşteri belirli bir odayı değil bir oda tipini ayırtır; oda ataması sonradan yapılır.
• Kişi ve birim farkı: Atölyede kontenjan kişi başınadır, kortta ise tek kişi gelse de bütün kort dolar.

Bu ayrıntılar ekranda da karşılık bulur: oda tipi satan bir otel misafire oda numarası göstermez, bölünebilen saha satan işletme ise iki seçeneği yan yana ve hangisinin müsait olduğunu açıkça gösterir.

Bu listeyi kâğıda dökmeden geliştirmeye başlamak, ileride yeniden yazılan bir rezervasyon modülü demektir. Biz ilk toplantıda işletme sahibinden bir haftalık gerçek doluluk defterini isteriz; defterde elle yapılan istisnalar, sistemin hangi kuralları bilmesi gerektiğini gösterir. Sattığınız şey bir kişinin zamanıysa, örneğin bir diyetisyenin seansları, kapasite mantığı yerine takvim mantığı gerekir ve randevu sistemli web sitesi daha doğru bir başlangıç olur.

02Kural tablosunu tasarımdan önce yazmak

Ekranları çizmeden önce bütün rezervasyon kurallarını tek bir tabloda toplamak, sonradan çıkan sürprizlerin çoğunu önler. Personelin aklında duran her kural, sisteme yazılmadıkça ya çift satışa ya da gereksiz geri çevrilen misafire dönüşür.

Tabloyu şu sırayla doldurmanızı öneriyoruz:

1. Açık günler ve saatler: Haftalık düzen, resmî tatiller, bakım dönemleri ve sezon dışı kapanışlar.
2. Süre kuralları: En kısa ve en uzun konaklama ya da oyun süresi, seans uzunluğu, iki rezervasyon arasındaki temizlik veya hazırlık payı.
3. Zaman sınırları: Kaç gün sonrasına kadar rezervasyon alınacağı ve aynı gün için son rezervasyon saati.
4. Kişi kuralları: Birim başına en az ve en çok kişi, çocuk ve bebek tanımı, grup sınırı.
5. Özel durumlar: Abone takımlara ayrılan sabit saatler, kurumsal bloklar, personele ayrılan kontenjan.

Tablo bittiğinde her satır için bir soru sorun: bu kural hangi ekranda misafire gösterilecek ve hangisi yalnız arka planda işleyecek. Örneğin iki gecelik en kısa konaklama kuralı, misafir tek gece seçtiğinde açık bir cümleyle anlatılmalı; aksi halde takvim sebepsiz yere dolu görünür ve misafir siteyi bozuk sanar. Bu tablo aynı zamanda ajansla yapılacak yazılı teklifin kapsamını da belirler.

03Geçici tutma ve çift rezervasyonun önlenmesi

Çift rezervasyonu önleyen şey takvimin görünüşü değil, iki kişi aynı anda aynı birimi seçtiğinde sistemin ne yaptığıdır. Doğru kurulmuş bir rezervasyon sisteminde seçilen birim ödeme adımı bitene kadar kısa bir süre tutulur, bu sürede başkasına satılmaz, ödeme tamamlanmazsa kendiliğinden kapasiteye geri döner.

Tutma süresi işletmeye göre ayarlanır. Çok kısa olursa kart doğrulaması sırasında süre dolar ve misafir ödemeyi yaptığı halde yeri kaybeder; çok uzun olursa yoğun saatlerde birimler boşuna kilitli kalır. Ödeme sağlayıcısının 3D Secure doğrulamasının ne kadar sürebildiğini hesaba katarak süreyi belirlemek gerekir.

Geliştiricinize ya da hazır motor sağlayıcınıza şu soruları sorun:

• Aynı saniyede iki ödeme aynı birime gelirse hangisi kazanır, diğer misafire ne gösterilir?
• Ödeme sağlayıcısı onayı geç bildirirse rezervasyon nasıl eşleşir, kayıt kaybolur mu?
• Panelden elle girilen telefon rezervasyonu, sitede o anda ödeme adımındaki misafiri nasıl etkiler?
• Tutma süresi dolan rezervasyonlar ayrıca raporlanıyor mu?

Son soru küçük görünür ama önemlidir: süresi dolan tutmalar, ödeme adımında misafir kaybettiğinizin en açık işaretidir. Bunları görmeden ödeme ekranındaki sorunu fark etmek zordur. Yayından önce iki telefonla aynı birimi aynı anda ayırtmayı denemek, bu bölümdeki her şeyi on dakikada sınamanın en pratik yoludur.

04Hazır motor mu, siteye özel sistem mi

Hazır bir rezervasyon motoru, kuralları standart olan ve hızlı başlamak isteyen işletmeler için genellikle yeterlidir; siteye özel sistem ise kurallarınız hazır çözümlere sığmadığında anlam kazanır. Karar, tasarım beğenisine göre değil, kural tablonuza göre verilmelidir.

Hazır motor şu durumlarda mantıklıdır:

• Konaklama gibi kuralları sektör genelinde benzer olan bir işiniz var.
• Zaten bir kanal yöneticisi kullanıyorsunuz ve motor onunla doğrudan konuşuyor.
• Aylık abonelik ve sağlayıcıya bağlı kalmak sizin için sorun değil.

Özel sistem şu durumlarda daha uygun olur:

• Bölünen sahalar, birleşen masalar, abone saatleri gibi istisnalarınız çok.
• Rezervasyonun muhasebe, giriş turnikesi ya da sadakat programı gibi başka sistemlerle konuşması gerekiyor.
• Misafir verisinin ve raporların tamamen sizin sunucunuzda kalmasını istiyorsunuz.

Hazır motoru seçtiyseniz sitenin işi, motorun ekranını tasarıma uyumlu yerleştirmek ve tarih seçimini her sayfadan erişilebilir kılmaktır. Seçmeden önce sağlayıcıdan deneme hesabı isteyin ve kendi kural tablonuzdaki üç zor senaryoyu, örneğin bayram döneminde üç gecelik en kısa konaklamayı, gerçekten tanımlayıp tanımlayamadığınızı deneyin. Burada sık görülen sorun, motorun ayrı bir alan adında açılması ve ölçümün orada kopmasıdır; ayrıntısını ölçüm bölümünde anlatıyoruz. Kurallarınız gerçekten özelse sistemi özel yazılım geliştirme ile kurmak, hazır motoru yamalarla zorlamaktan uzun vadede daha sağlıklıdır.

05Tarife, sezon ve indirim kurallarının kurulması

Fiyat mantığı, müsaitlik kadar dikkatli kurulması gereken ikinci kural setidir; misafirin ödeme ekranında ilk kez gördüğü bir ek tutar, yarım kalan rezervasyonların en sık sebeplerinden biridir. Bu yüzden toplam tutar, tarih ve kişi seçildiği anda eksiksiz gösterilmelidir.

Tarife tasarlarken netleştirilmesi gereken sorular şunlardır:

• Fiyat birimi: Birim başına mı, kişi başına mı, yoksa ikisinin birleşimi mi; ek kişi ve çocuk nasıl fiyatlanıyor.
• Dönemler: Hafta içi ve hafta sonu, sezon ve bayram dönemleri, akşam saatleri için ayrı tarifeler.
• Kampanyalar: Erken rezervasyon, uzun konaklama, indirim kodu; hangisinin hangisiyle birleşebileceği.
• Ekstralar: Kahvaltı, ekipman kiralama, transfer gibi isteğe bağlı kalemler ve bunların kapasitesi.

Kampanyaların birbiriyle birleşip birleşmeyeceğini önceden yazmak çok önemlidir. Erken rezervasyon indirimi ile indirim kodu üst üste uygulanırsa, beklemediğiniz bir tutarla satış yapmış olursunuz. Kural basittir: her kampanyanın başlangıç ve bitiş tarihi, geçerli olduğu birimler ve birleşme durumu sistemde tanımlı olmalı.

Ekstraların da kapasitesi vardır. On kişilik tekne turuna on beş öğle yemeği satılmaması ya da tek bir kiralık raketin aynı saatte iki kez verilmemesi için ekstralar da birer küçük birim gibi takip edilmelidir. Fiyat değişikliklerinin geçmiş rezervasyonlara dokunmaması da kural olarak yazılmalı; misafir hangi tutarla rezervasyon yaptıysa, sonradan tarife güncellense bile o tutar geçerli kalır.

06Ön ödeme, kapora ve iptal koşulları

Ödeme modeli, işletmenin gelmeyen misafire karşı ne kadar korunmak istediğiyle misafirin ne kadar kolay karar verdiği arasındaki dengedir. Tam ödeme kapasiteyi en güçlü biçimde korur ama kararı zorlaştırır; ödemesiz talep kararı kolaylaştırır ama boş kalan birimi geri getirmez.

Üç temel seçenek ve uygun olduğu durumlar:

• Tam ödeme: Kısa süreli, son anda yeniden satılması zor birimler için; örneğin tek seanslık tur ya da atölye.
• Kapora: Konaklama ve grup rezervasyonları için; kalan tutarın ne zaman ve nasıl alınacağı açıkça yazılır.
• Ödemesiz talep: İşletmenin onaylayarak kabul ettiği özel istekler, kurumsal ve kalabalık grup talepleri için.

Mesafeli Sözleşmeler Yönetmeliği'nin 15. maddesi, belirli bir tarihte ya da dönemde verilen konaklama, yiyecek içecek ve boş zaman hizmetlerini, taraflar aksini kararlaştırmadıkça cayma hakkı istisnaları arasında sayar. Bu, iptal koşullarının işletmenin kendi metnine kaldığı anlamına gelir; dolayısıyla metnin açık olması, misafirle sonradan yaşanacak tartışmayı en çok azaltan şeydir.

İptal metnini yazarken kaç gün öncesine kadar ücretsiz iptal olduğunu, sonrasında ne kadarının iade edileceğini ve tarih değişikliğinin iptal sayılıp sayılmadığını tek tek belirtin. Bu metin ödeme düğmesinin hemen üstünde, kısa ve okunur halde durmalı, onay e-postası içinde de aynen tekrarlanmalıdır. Nihai hukuki değerlendirmeyi hukuk danışmanınızla yapmanızı öneririz.

07Kanal yöneticisi ve takvim senkronunun sınırları

Platformlarda da satış yapıyorsanız tek kural geçerlidir: müsaitlik tek bir yerde tutulur ve diğer her yer oradan beslenir. Kanal yöneticisi, sitedeki ve platformlardaki müsaitliği aynı veriyle güncelleyen yazılımdır; takvim senkronu ise daha basit, dosya tabanlı bir eşleştirmedir.

İkisi arasındaki fark çoğu zaman gözden kaçar. iCal gibi takvim dosyalarıyla yapılan senkron, karşı tarafın dosyayı belirli aralıklarla okumasına dayanır; iki okuma arasında yapılan satış diğer tarafa hemen yansımaz. Az birimi ve sakin dönemleri olan küçük bir tesis için bu kabul edilebilir bir risk olabilir, yoğun dönemlerde ise çift satış kaynağıdır.

Kanal kurulumunda kontrol edilmesi gerekenler:

• Senkron yalnız müsaitliği mi taşıyor, yoksa fiyatı ve kuralları da mı?
• Platformdan gelen rezervasyon panelinize misafir bilgisiyle mi düşüyor, yalnız dolu gün olarak mı?
• Bir kanalda iptal edilen rezervasyon diğer kanallarda yeri kendiliğinden açıyor mu?
• Senkron hata verdiğinde size bildirim geliyor mu, yoksa sessizce mi duruyor?

Son madde sahada en çok sorun çıkaran maddedir. Senkronun durduğunu çift rezervasyon yaşanınca fark etmek yerine, bir hata bildirimi kurmak ve haftada bir platform takvimini panelle karşılaştırmak basit ama etkili bir alışkanlıktır. Bu karşılaştırmayı sezon başında, tarifeler ve kapanış günleri güncellendikten hemen sonra yapmak ayrıca önemlidir; hataların çoğu toplu değişikliklerden sonra ortaya çıkar.

08Telefonda hızlı çalışan rezervasyon ekranı

Rezervasyonların büyük kısmı telefondan ve çoğu zaman akşam saatlerinde yapıldığı için ekranı önce mobil için tasarlıyoruz. Tarih, kişi ve birim seçimi tek elle, kaydırmadan ve yazı yazmadan tamamlanabilmelidir.

Mobil ekranda dikkat ettiğimiz ölçütler:

• Tarih seçici: Dolu günler gri ve seçilemez, başlangıç ve bitiş tek takvimde seçilir; klavye açılmaz.
• Adım sayısı: Seçim, misafir bilgisi, ödeme ve onay; bunun dışındaki her adım gerekçelendirilmeli.
• Üye olmadan rezervasyon: İlk rezervasyonda hesap açtırmak, akışa gereksiz bir engel ekler.
• Dokunma alanları: Saat dilimleri ve kişi sayısı düğmeleri parmakla rahat basılacak büyüklükte olmalı.

Hız tarafında Google'ın Core Web Vitals ölçütleri iyi bir hedef verir. LCP, sayfadaki en büyük öğenin yüklenme süresini ölçer ve iyi kabul edilen sınır 2,5 saniye ya da altıdır; INP, dokunuşa verilen tepki süresini ölçer ve sınırı 200 milisaniyedir; CLS, sayfa yüklenirken öğelerin kaymasını ölçer ve sınırı 0,1'dir.

Rezervasyon ekranında INP özellikle önemlidir, çünkü her tarih seçiminde müsaitlik sorgusu çalışır ve takvim gecikirse misafir aynı güne iki kez dokunur. Bu yüzden müsaitlik sorgusunun hızı, sayfanın genel hızından ayrı olarak ve yoğun bir akşam saatinde ölçülmelidir.

Sitenizin bugünkü durumunu mobil uyumluluk testi ile görebilirsiniz.

09Onay, hatırlatma ve gelmeyen misafir

Rezervasyon onayı, misafirin kafasındaki bütün soruları tek mesajda kapatmalıdır; eksik bir onay mesajı, telefonun yeniden çalması demektir. İyi bir onay ayrıca gelmeyen misafir sayısını azaltmanın ilk adımıdır.

Onay mesajında bulunması gerekenler:

1. Rezervasyon numarası, tarih, saat ya da gece sayısı ve birim adı.
2. Ödenen tutar, kalan tutar ve kalan tutarın nasıl ödeneceği.
3. İptal ve tarih değişikliği koşulları, ödeme ekranındaki metinle aynı sözlerle.
4. Adres, harita bağlantısı, otopark ve giriş bilgisi.
5. Değişiklik için tek dokunuşla ulaşılabilecek iletişim kanalı.

Hatırlatma mesajının zamanı işletmeye göre değişir. Halı sahada maçtan birkaç saat önce gelen kısa bir mesaj yeterliyken, konaklamada bir iki gün önce giriş saatini ve yol tarifini hatırlatmak daha işe yarar. Hatırlatmaya iptal ya da değişiklik seçeneği koymak ilk bakışta ters görünür, ama gelmeyecek misafirin yeri önceden bildirmesi, boş kalan bir birimden her zaman iyidir.

WhatsApp ile bildirim gönderilecekse misafirden bu kanal için açık bir tercih alınmalı ve mesaj şablonları kısa tutulmalıdır. Aynı bilgiyi hem e-posta hem WhatsApp ile göndermek yerine, ayrıntılı bilgiyi e-postayla, kısa hatırlatmayı mesajla vermek daha düzenlidir. Mesajın hangi numaradan gittiği de önemlidir; misafir cevap yazdığında bu mesajı okuyan biri olmalı, aksi halde iptal bildirimi kimseye ulaşmadan kaybolur.

10Yönetim paneli ve personelin günlük düzeni

Rezervasyon sisteminin işletme tarafındaki başarısı, telefonla gelen rezervasyonun da aynı panele girilmesine bağlıdır. Personel defter tutmaya devam ederse, tek müsaitlik kaynağı fikri ilk yoğun akşamda dağılır.

Bu yüzden paneli personelin gerçek iş akışına göre kuruyoruz. Telefonda konuşurken yeni rezervasyon girmek birkaç dokunuştan fazla sürmemeli, günün listesi tek ekranda görünmeli ve bir saati bakım ya da özel kullanım için kapatmak tek işlemle yapılabilmelidir.

Panelde istenmesi gereken özellikler:

• Rol ayrımı: Resepsiyon rezervasyon girer ve değiştirir; tarife ve iade yetkisi yalnız yöneticidedir.
• İşlem kaydı: Hangi rezervasyonu kimin, ne zaman değiştirdiği veya iptal ettiği görünür.
• Günlük görünüm: Bugün gelecek misafirler, ödenmemiş bakiyeler ve özel istekler tek listede.
• Kaynak bilgisi: Rezervasyonun siteden mi, telefondan mı, platformdan mı geldiği her kayıtta yazılı.
• Dışa aktarma: Rezervasyon listesi tarih aralığına göre tabloya aktarılabiliyor; muhasebe ve sezon değerlendirmesi elle yazmadan yapılıyor.

Yayına almadan önce personelle bir prova günü yapmanızı öneriyoruz. Herkes birkaç sahte rezervasyon girer, birini iptal eder, birinin tarihini değiştirir; prova sonunda sahte kayıtlar silinir. Bu bir saatlik çalışma, ilk haftadaki soruların çoğunu önler. Provada en çok takılınan noktaları not edin; bunlar genellikle personel için hazırlanacak tek sayfalık kullanım notunun maddeleri olur.

11Misafir verisi, KVKK ve çerez izni

Rezervasyon formu kişisel veri topladığı için formun kendisi kadar, bu verinin nerede tutulduğu ve kimin eriştiği de planlanmalıdır. KVKK, yani 6698 sayılı Kişisel Verilerin Korunması Kanunu, 10. maddesinde veri toplanırken ilgili kişinin aydınlatılmasını ister; bu yüzden form yanında aydınlatma metni bulunmalıdır.

Formda yalnız rezervasyonu yürütmek için gereken alanlar yer almalıdır: ad, telefon, e-posta ve gerekiyorsa kişi sayısı. Kimlik numarası, doğum tarihi ya da adres gibi bilgiler gerçekten gerekmiyorsa sorulmamalı; konaklamada giriş sırasında istenen bilgiler zaten resepsiyonda tamamlanır.

Veri tarafında kontrol listesi:

• Aydınlatma metni formun hemen altında, bağlantıyla değil kısa bir açıklamayla birlikte duruyor.
• Pazarlama izni, rezervasyon onayından ayrı ve işaretlenmemiş bir kutuyla isteniyor.
• Özel istek alanında sağlık bilgisi gibi hassas veri istenmiyor; alerji sorusu gerekiyorsa ayrıca değerlendiriliyor.
• Panele erişen her kişinin kendi kullanıcısı var, ortak şifre kullanılmıyor.
• Eski rezervasyon kayıtlarının ne kadar süre tutulacağı belirlenmiş.

Avrupa Ekonomik Alanı'ndan misafir alıyorsanız, zorunlu olmayan ölçüm ve reklam çerezleri için önceden onay gerekir; Google da bu ziyaretçilerde ölçüm ve kişiselleştirilmiş reklam özellikleri için izin modunu şart koşar. Çerez bandı, rezervasyon düğmesinin üstünü kapatmayacak biçimde yerleştirilmelidir.

12Rezervasyonu ölçmek ve aramada bulunmak

Rezervasyon sitesinde ölçülmesi gereken şey ziyaretçi sayısı değil, rezervasyon akışının hangi adımında kaç kişinin ayrıldığıdır. Bu bilgi olmadan sorunun takvimde mi, fiyatta mı, ödemede mi olduğunu tahmin edersiniz.

Kurduğumuz temel ölçüm adımları:

1. Tarih ve kişi seçimi yapıldı.
2. Müsait birim seçildi.
3. Misafir bilgisi dolduruldu ve ödeme adımı açıldı.
4. Rezervasyon tamamlandı, tutar ve kaynakla birlikte.

Hazır motor ayrı bir alan adında çalışıyorsa, misafirin hangi kanaldan geldiği bilgisi geçişte kaybolabilir; motor sağlayıcısına alanlar arası ölçümü destekleyip desteklemediğini mutlaka sorun. Adımlar arasındaki oranları dönüşüm oranı hesaplama aracıyla izlemek, iyileştirmenin nereden başlayacağını gösterir.

Her adımla birlikte tarih aralığı ve birim tipi de kaydedilirse daha somut sorular sorulabilir: örneğin hafta sonu gecelerinde ödeme adımına gelip vazgeçenler artıyorsa, sorun büyük olasılıkla fiyatta ya da iptal koşulundadır. Reklam ve sosyal medya bağlantılarını UTM bağlantı oluşturucu ile etiketlerseniz, hangi kanalın gerçek rezervasyon getirdiğini de ayırt edebilirsiniz.

Arama tarafında rezervasyon ekranı tek başına aranmaz; aranan şey birimdir. Her oda tipi, her saha ya da her tur için gerçek fotoğraflı, kuralları ve kapasiteyi anlatan ayrı bir sayfa, hem aramada görünmeyi hem de misafirin karar vermesini kolaylaştırır. Sayfada birimin kuralları da yazmalı: en kısa konaklama, kişi sınırı, iptal koşulu. Konaklama işletmeleri için bu sayfaların ayrıntısını otel web sitesi rehberimizde ele alıyoruz.

13Rezervasyon sistemlerinde sık yapılan hatalar

Rezervasyon projelerinde gördüğümüz hataların çoğu yazılımdan değil, eksik karar verilmiş kurallardan çıkar. Aşağıdaki altı hata, her biri için daha doğru yaklaşımla birlikte en sık karşılaştıklarımızdır. Yayındaki bir sistemde bunlardan birini görüyorsanız, düzeltmek çoğu zaman yeni bir yazılım değil, bir kuralın yazılması demektir:

• Telefon rezervasyonunu panele girmemek: Defter ve panel yan yana yaşarsa çift satış kaçınılmaz olur; telefonla gelen her rezervasyon da aynı panele girilmeli.
• Toplam tutarı son adımda göstermek: Ekstralar ve vergiler ödeme ekranında ortaya çıkınca misafir vazgeçer; toplam, seçim yapıldığı anda eksiksiz gösterilmeli.
• İptal metnini sayfanın altına gömmek: Görülmeyen koşul tartışma doğurur; metin ödeme düğmesinin hemen üstünde ve onay e-postası içinde yer almalı.
• Tutma süresini hiç kurmamak: Ödeme yarıda kalınca birim ya sonsuza kadar kilitli kalır ya da iki kez satılır; kısa ve otomatik serbest kalan bir tutma süresi tanımlanmalı.
• Senkronu kurup unutmak: Sessizce duran bir takvim senkronu, yoğun günde çift rezervasyon üretir; hata bildirimi ve haftalık karşılaştırma alışkanlığı kurulmalı.
• Formu uzun tutmak: Gereksiz alanlar hem misafiri yorar hem veri riskini büyütür; yalnız rezervasyon için gereken bilgiler sorulmalı, geri kalanı girişte tamamlanmalı.

14Doğru ekibi seçmek ve sonraki adım

Rezervasyon sistemli bir site yaptırırken ajansı tasarım örnekleriyle değil, kurallarınızı ne kadar doğru sorduğuyla değerlendirin. İlk görüşmede kapasiteyi, tutma süresini, iptal koşulunu ve kanal yapınızı sormayan bir ekip, bu soruları proje ortasında size geri getirir.

Görüşmede sorabileceğiniz sorular:

• Aynı birime aynı anda iki ödeme gelirse sistem ne yapıyor?
• Kanal senkronu durduğunda bunu nasıl fark ediyoruz?
• Panelde kimin neyi değiştirdiğini görebiliyor muyuz?
• Rezervasyon verisi kimin sunucusunda tutuluyor ve sözleşme bitince bize nasıl teslim ediliyor?
• Yayından sonra tarife ya da kural değişikliğini kendimiz mi yapıyoruz, yoksa her seferinde size mi yazıyoruz?

Teklifleri karşılaştırırken kapsamın yazılı olup olmadığına bakın: kaç birim, hangi kurallar, hangi ödeme sağlayıcısı, hangi kanal bağlantısı ve yayından sonra kimin destek vereceği tek tek yazmalıdır. Kapsamı belirsiz bir teklif, ilk değişiklik isteğinde yeni bir pazarlığa dönüşür.

Biz projeye kural tablonuzla başlıyor, ardından akışı, ekranları ve ödeme bağlantısını aynı belgede yazılı teklif olarak sunuyoruz. Rezervasyon alan sitelerimizden örnekleri referanslar sayfasında görebilir, genel çalışma biçimimizi web tasarım hizmeti sayfamızda inceleyebilirsiniz.

Önce rezervasyonsuz bir siteyle başlayıp modülü sonra eklemek de mümkündür; sabit fiyatlı paketler fiyatlar bölümünde yer alıyor. Ne sattığınızı, kapasitenizi ve bugün rezervasyonu nasıl aldığınızı iletişim formundan kısaca yazarsanız, size uygun akışı birlikte çıkarırız.