Bir hizmet için randevu isteyen ziyaretçi, formu gönderdiğinde hangi saatin ayrıldığını, talebin yalnızca alındığını ya da kesinleştiğini anlamalıdır. Bu durumlar aynı değildir. Ekrandaki takvimde boş görünen saat, ekip tarafından başka bir kanalda tutulmuş olabilir; formun başarıyla kaydedilmesi de takvimin değiştiğini kanıtlamaz. Bu rehber, web sitesi üzerinden hizmet randevusu seçen kullanıcı için uygunluk, bekleyen talep, kesin onay, değişiklik ve iptal adımlarını birlikte tasarlamaya odaklanır.

Buradaki senaryo, danışma görüşmesi veya hizmet randevusu planlayan işletmeler içindir. Restoran sayfasında menü ve rezervasyon talebini nasıl ayırabileceğinizi Sarıyer Web Tasarım restoran sayfası rehberinde okuyabilirsiniz. Bu yazı restoran rezervasyon mesajını sosyal kanaldan yönetmeye veya çevrim içi mağazada ürün ayırmaya odaklanmaz; ziyaretçinin web arayüzünde bir zaman aralığı seçtiği randevu akışını tasarım kararı olarak ele alır.

Takvimi kurmadan önce randevunun ne anlama geldiğini belirleyin

İşletme önce “randevu” sözcüğünün kendi hizmetinde ne ifade ettiğini netleştirmelidir. Bu bir ön görüşme, ücretli seans, ürün gösterimi, teknik inceleme ya da başvuru sonrası yapılacak değerlendirme olabilir. Süre, gerekli hazırlık ve hizmeti verecek kişi değiştikçe aynı takvim kuralı uygun olmayabilir.

Bir randevu, yalnızca takvim hücresi değildir. Hizmet türü, görüşmenin süresi, yüz yüze veya uzaktan yapılması, hazırlanması gereken bilgi, konum veya bağlantı, katılımcı sayısı ve işletmenin sorumlusu bir arada düşünülür. Saat gösterilmeden önce süre ve hazırlığı etkileyen bilgileri anlaşılır biçimde alın. Form alanlarının gerekçesini ayrı değerlendirmek için iletişim formu tasarımı rehberine bakabilirsiniz.

Talep alma ile anında randevu onayını ayırın

İşletmenin uygun saatleri tek bir güvenilir takvimde güncel tuttuğu ve seçilen sürenin anında ayrılabildiği durumlarda arayüz doğrudan onay verebilir. Buna karşılık personel veya kaynak uygunluğu başka bir ekip tarafından sonradan inceleniyorsa ziyaretçi bir “randevu talebi” göndermiş olur. Bu durumda seçtiği saati kesinleşmiş gibi göstermek yanıltıcıdır. İlk ekranda, seçimden sonra hangi durumun oluşacağını açıkça söyleyin: “Saat tercihiniz alındı; ekip onayından sonra kesinleşecek” ile “Randevunuz onaylandı” aynı mesaj değildir.

Bekleyen talebin ne kadar süreyle açık kalacağı, işletmenin ne zaman inceleyeceği ve bu sırada saatin başkasına sunulup sunulmayacağı önceden kararlaştırılmalıdır. Kesin onay için gerekli koşul oluşmadan takvimde kalıcı blok yaratılıyorsa o bloğun sona erme kuralı da tanımlanmalıdır. Yanıt süresi bilinmiyorsa sayı uydurmayın; ziyaretçiye incelemenin beklediğini ve hangi yoldan güncel durum sorabileceğini bildirin.

Süreyi ve araya gereken hazırlık zamanını gerçek işten çıkarın

Bir hizmet türü için ekranda gösterilen dakika miktarı, görüşmenin kendisinden ibaret olmayabilir. Çalışan notları inceleyebilir, odayı veya ekipmanı hazırlayabilir, önceki işi tamamlayabilir ya da görüşme sonrasında kayıt girebilir. Zaman çizelgesinde bu işler gerekiyorsa, onları görünmez varsaymak yerine randevular arasında işletmenin belirlediği bir hazırlık aralığı bırakın. Aynı kaynağa bağlı farklı hizmetlerin süreleri değişiyorsa takvim, her seçenek için aynı uzunlukta blok ayırmamalıdır.

Randevunun ön koşulu varsa ziyaretçiye saat seçmeden önce söyleyin. Örneğin gerekli dosyanın hazır olması, doğru katılımcının görüşmede bulunması ya da önce kısa bir bilgi formunun tamamlanması gerekebilir. Bu koşulları randevu alındıktan sonra sürpriz olarak bildirmek, hem ziyaretçinin hazırlığını hem de işletmenin planını bozabilir. Ancak gereksiz evrak veya kişisel bilgi talep etmeyin; her istenen bilginin randevunun hazırlanmasına nasıl katkı sağladığını açıklayabilmelisiniz.

Uygunluğu kimin ve hangi kaydın belirlediğini yazın

Takvimde görünen uygunluk, gerçek hizmet kapasitesine dayanmalıdır. Bu kapasite bir kişinin çalışma düzeni, bir odanın kullanımı, bir cihaz, bir ekip veya bir hizmet türüyle sınırlı olabilir. Birden fazla takvim veya mesajlaşma kanalı kullanılıyorsa hangi kaydın son karar sayılacağını belirlemeden “boş saat” göstermek risklidir. Bir sorumlu, izinleri ve istisnaları güncellemeli; ekip de başka kanaldan alınan randevuyu aynı kayıt düzenine işlemelidir. Başka bir sistemle eşitleme varsa kimlik, güncelleme gecikmesi ve başarısız eşitleme durumlarını teknik ekip ayrıca tanımlamalıdır.

Arayüz takvimi ne sıklıkta yenilediğini ve ziyaretçinin seçim sırasında uygunluğun değişebileceğini dikkate almalıdır. İki kişi aynı boşluğu seçtiğinde sistemin davranışı belirsiz kalmamalı; birinin talebi beklemede, diğeri kesinleşmiş gibi çelişkili kayıt oluşmamalıdır. Ürün veya platform özelliği hakkında genel bir garanti vermek yerine, proje tesliminde eşzamanlı seçim denemesi yapın ve hangi kaydın esas alındığını gözlemleyin.

Bekleyen, onaylanan ve iptal edilen durumları görünür kılın

Ziyaretçinin görebileceği durumları az sayıda ve anlaşılır kelimelerle belirleyin: talep alındı, onay bekliyor, onaylandı, değişiklik istendi, iptal edildi veya görüşme tamamlandı gibi. Her durumun kim tarafından ve hangi olayla değiştirildiği tanımlanmalıdır. “İşleniyor” gibi belirsiz bir etiket, ziyaretçinin bir şey yapması gerekip gerekmediğini açıklamaz. Müşteriye teknik hata adı yerine sonraki eylemi anlatın.

Onay mesajında tarih, saat, hizmet adı ve gerektiğinde katılım yolu yeniden gösterilsin. Ziyaretçi yanlış hizmet veya günü fark ederse, destek ekibini aramadan önce neyi değiştirebileceğini görmelidir. Değişiklik yapılamıyorsa başvurabileceği gerçek ve işletmenin izlediği iletişim yolunu sunun. Otomatik e-posta gönderiliyorsa, randevu kaydının başarıyla oluşturulması ile iletinin alıcı posta kutusuna ulaşması ayrı kontrollerdir; arayüz, doğrulanmamış bir e-posta teslimi iddiasında bulunmamalıdır.

Değişiklik, geç kalma ve iptal senaryolarını da tasarlayın

Randevunun ilk kez alınması kadar, tarih veya hizmet değişikliği ve iptal de birer kullanıcı görevidir. Ziyaretçi talebini değiştirdiğinde eski saat hâlâ ayrılmış mı, yeni saat uygunluk kontrolünden geçti mi, ekipte hangi kayıt güncellendi? Sistem aynı işlemi iki kez gönderirse ikinci kayıt yaratılmamalı veya eski onay sessizce kaybolmamalıdır.

Geç kalma, gelmeme veya işletmenin saati değiştirmesi gibi istisnalar işin gerçek politikasına göre açıklanmalıdır. Metin, ücret veya iptal koşulu gibi kararları işletme adına uydurmamalı; geçerli koşullar onaylanıp site sahibince verilmeden yayımlanmamalıdır. “Bizi arayın” seçeneği konuyorsa telefonun gerçekten izlenip izlenmediğini ve çalışma saatlerini doğrulayın. Alternatif yol yoksa olmayan bir numara veya kesin geri dönüş süresi yazmak yerine, belirsizliği dürüstçe bildirin.

Yayından önce gerçek kullanıcı görevleriyle sınayın

Bir deneme turunu ana sayfadan başlatıp hizmet seçimi, gün ve saat seçimi, bilgi girişi, onay bekleme veya kesin onay, değişiklik ve iptal adımlarına kadar sürdürün. Her aşamada “şimdi ne oldu, sıradaki adım ne?” sorusunu yanıtlayın. Eksik alan, uygun olmayan saat, takvimde son anda değişen boşluk, yinelenen tıklama ve gönderim sırasında bağlantı kesilmesi gibi senaryoları deneyin. Hata oluştuğunda randevu kaydı var mı, yok mu? Ekran bunu bilmiyorsa kesin başarı veya başarısızlık mesajı göstermemelidir.

Telefonda uzun hizmet adlarının kesilmediğini, takvimde gezinmenin anlaşılır olduğunu ve seçilen saatin form boyunca görünür kaldığını kontrol edin. Kullanıcı önceki adıma döndüğünde verdiği bilgiler kaybolmamalı veya yanlış hizmete taşınmamalıdır. Ekran okuyucu ve klavye ile çalışan kişilerin hizmeti seçebildiğini, seçim durumunu fark ettiğini ve hata mesajına ulaşabildiğini denemek de yararlıdır. Yayına geçmeden önceki kapsamlı kullanıcı turu için web sitesi yayın kontrolü rehberine bakabilirsiniz.

Teslimi takvim ekranından değil, sahiplik ve kanıtla tamamlayın

Web tasarım tesliminde işletme, hangi hizmet türünü kimin düzenleyeceğini, izin ve istisnaların nasıl güncelleneceğini, bekleyen taleplerin kimde görüneceğini ve yanlış randevunun nasıl düzeltileceğini bilmelidir. Sistemi yapan ekip de uygulama, takvim sağlayıcısı ve e-posta bildirimleri arasındaki sorumluluk sınırını açıklamalıdır. Yönetim hesabı veya gizli erişim bilgisi teslim belgesine düz metin yazılmamalı; yetkili erişim kanalı kullanılmalıdır. Bu maddeler bir platformu diğerinden üstün ilan etmez; işletmenin işleyişi ile tasarımın birbirine uyup uymadığını görünür kılar.

Kabul kaydında kullanılan sürüm, denenen hizmet türleri, başarılı ve başarısız akışlar, bekleyen/onaylanan durum kanıtı, çakışan seçim denemesi, değişiklik ve iptal sonucu, sorumlu roller ve açık kalan sınırlamalar yer alabilir. Gerçek sistemde denenmeyen bir adımı “tamamlandı” diye işaretlemeyin. Kabul ölçütü, ziyaretçinin doğru seçimi ve işletmenin doğru kaydı işlemesidir.

Sık Sorulan Sorular

Randevu formu gönderilince seçilen saat kesinleşmiş sayılır mı?

Yalnızca akış saat uygunluğunu anında kontrol edip takvimde gerçekten ayırıyorsa kesinleşmiş olabilir. Ekip talebi sonradan inceliyorsa form, saat tercihi toplamıştır; onay değildir. Arayüzde bu farkı açıkça söyleyin. Bekleyen talebin saati tutup tutmadığını, ne zaman inceleneceğini ve sonuç bildirimini kimin göndereceğini işletme belirlemelidir.

Bekleyen bir talep takvimde ne kadar süre tutulmalı?

Bu süre, işletmenin talep inceleme düzeni ve gerçek kapasitesine göre belirlenir; tüm hizmetlere uygulanabilecek tek bir dakika kuralı yoktur. Talep açık kalırken saat başka kullanıcıya sunuluyor mu, yoksa geçici olarak ayrılıyor mu sorusunu yanıtlayın. Süre dolduğunda hangi durum mesajının verileceğini ve ziyaretçinin yeni saat seçip seçemeyeceğini de tanımlayın.

Hizmet süresinin yanına hazırlık aralığı eklemek gerekir mi?

Hizmet öncesi veya sonrası ekip, oda ya da ekipman hazırlığı gerekiyorsa bu zaman işletme takviminde hesaba katılmalıdır. Ziyaretçiye gösterilen seans süresi ile kaynak takviminde ayrılan toplam blok farklı olabilir. Her hizmet türü için bu farkı belirleyin; her randevuya aynı süreyi eklemek yerine gerçek iş akışından hareket edin.

Aynı boş saate iki kişi tıklarsa ne olmalı?

Uygulama, işletmenin belirlediği kapasite ve onay kuralına göre tek bir tutarlı sonuç üretmelidir. Bir kayıt kesinleşirken diğerine hâlâ aynı saatin onaylandığını söylememelidir. Canlı sistemde eşzamanlı seçim senaryosu deneyin; hangi kaydın oluştuğunu, diğer kullanıcıya hangi alternatifin gösterildiğini ve ekip ekranında ne görüldüğünü kanıt olarak kaydedin.

Randevu onayını e-posta ile göndermek yeterli midir?

E-posta işletmenin seçtiği bildirim yolu olabilir, fakat ziyaretçi onay durumunu ekranda da anlayabilmelidir. İleti gönderim servisine kabul edildi diye alıcının posta kutusunda göründüğü varsayılmaz. Mesajın hangi randevu kaydına ait olduğu, tarih ve saat bilgisi, değişiklik yolu ve sorumlu iletişim kanalı tutarlı olmalıdır. E-posta dışı bildirim gerekiyorsa bunu ayrıca planlayın.

Ziyaretçi randevuyu kendisi değiştirebilir veya iptal edebilir mi?

Bu seçenek işletmenin hizmet politikasına ve kullandığı takvim akışına bağlıdır. Değişiklik izni varsa yeni saat yeniden uygunluk kontrolünden geçmeli, eski saat doğru biçimde serbest kalmalı ve hem ziyaretçi hem ekip güncel durumu görmelidir. İptal için de aynı randevu kaydının kapandığını doğrulayın. İşletmenin uygulamadığı bir koşulu sayfada vaat etmeyin.

Takvimde boş görünen bir saatin dolu çıkması nasıl ele alınmalı?

Arayüz yeni uygunluğu tekrar kontrol etmeli ve saat artık alınamıyorsa bunu erken, anlaşılır biçimde söylemelidir. Ziyaretçinin yazdığı diğer bilgiler mümkünse kaybolmamalı; ona yeni zaman seçme yolu sunulmalıdır. Ekip hangi kaydın son söz olduğunu ve farklı kanallardan gelen randevuların nasıl eşitlendiğini belirlemelidir. Boşluk varmış gibi kesin onay göstermek yerine, doğrulanmış durumu gösterin.

Yayına çıkmadan hangi senaryolar test edilmeli?

En azından uygun saat, uygun olmayan saat, bekleyen talep, kesin onay, değişiklik, iptal, eksik bilgi, yinelenen gönderim ve son anda uygunluğun değişmesi denenmelidir. Ayrıca telefon ekranında seçilen gün ve saatin görünür kaldığını, klavyeyle gezinmenin mümkün olduğunu kontrol edin. Gerçek üretim sisteminde denenmeyen entegrasyonu çalışıyor olarak yazmayın; açık kalan adımı teslim kaydında belirtin.