Klinikte “randevu” sözcüğü iki ayrı işi örtebilir. Biri hekimin belirli bir hizmeti uygulayacağı zaman, diğeri danışmanın hasta adayıyla yapacağı ön görüşmedir. Konuşmada aynı adı taşımaları, aynı kayıt oldukları anlamına gelmez. Zoho CRM kurgusuna başlamadan önce bu ayrım görünür değilse ekipler farklı kaynaklardan aynı zamanı planlayabilir, takvimdeki uyarıları kesin bir engel sanabilir ve rezervasyon sınırlarını yanlış yerde arayabilir. Bu ortak dil, kurulum kararlarının başlangıç noktası olarak ele alınır.
Sağlam yaklaşım, iki akışı tek bir genel randevu fikrine sıkıştırmak yerine amaçlarına göre ayırır. Uygulama, hizmeti verecek üyeye ve hizmet uygunluğuna bağlıdır. Ön görüşme ise toplantı olarak planlanır ve gerektiğinde rezervasyon sayfasının sayısal sınırlarından yararlanır. Böylece hangi kontrolün kayıt oluştururken devreye girdiği, hangisinin yalnız kullanıcıyı uyardığı ve hangi sınırların teklif öncesinde doğrulanacağı açıkça konuşulabilir. Ayrım, aynı zaman kaydından farklı sonuçlar çıkarma riskini azaltır.
İki randevu aynı ad altında yaşadığında
Karışıklık genellikle ekranlardan önce dilde başlar. Danışman “randevu verdim” derken görüşmeyi, hekim aynı sözcükle uygulama saatini kastedebilir. Operasyon sorumlusu bu iki anlamı ortak bir ad altında izlediğinde, kimin neyi planladığını ayırmak zorlaşır. Gün görünüşte düzenli olsa bile kayıtların amacı, sahibi ve hizmetle ilişkisi belirsiz kalabilir. Sorun yalnız takvim yoğunluğu değil, ortak tanım eksikliğidir. Net adlandırma, günlük değerlendirmede hangi taahhüdün konuşulduğunu görünür kılar.
Hekimin sabahı iki kere satılmıştır: biri danışman ekranından, biri ön görüşme defterinden. İkisi birbirini ancak hasta kapıda beklerken görür ve o an kimin haklı olduğu artık önemli değildir. Bu gerilim, tek başına daha dikkatli çalışma çağrısıyla çözülmez. Ekip önce ön görüşme ile uygulamayı adlandırmalı, ardından her birinin hangi kayıt yapısında yaşayacağını ve günlük planlamada kim tarafından izleneceğini belirlemeli. Karar, yoğunluk konuşmasını kayıt amacı ve sorumluluk üzerinden somutlaştırır.
Uygulama randevusu ile ön görüşmeyi ayrı nesnelerde tutun
Zoho CRM içinde uygulama akışı, Hizmetler modülüne bağlı Randevu kaydıyla kurulabilir. Hizmetler etkinleştirildiğinde sistem tanımlı Randevular modülü hesaba eklenir. Önceden tanımlı alanları bulunan bu modül silinemez; oluşturma, erteleme ve iptal için üç düzen taşır. Ön görüşme ise Toplantı kaydı olarak kalır. Bu ayrım, aynı takvimde görünen iki zaman kaydının işlevsel olarak aynı nesne sayılmasını önler. Operasyon böylece iki akış için farklı kayıt beklentileri belirleyebilir.
Hizmet kaydı, hizmeti verecek CRM kullanıcılarını, yeri, uygun gün ve saatleri, isteğe bağlı tarih aralığını, süreyi, fiyatı ve iş emri gereksinimini taşır. Randevuda tek üye seçilir; süre hizmetin uygunluk ayarından gelir ve randevu ekranında değiştirilemez. Hizmet geçici olarak kullanım dışı bırakılabilir. Takvim tercihlerinde Toplantılar ve Randevular ayrı açılır veya kapatılır; kapalı tür oluşturulamaz ve görüntülenemez. Bu yapı, planlamada hizmet bağlamını toplantı bağlamından ayırmayı kolaylaştırır.
Ürün nerede engeller, nerede yalnız uyarır
Bir uygulama randevusunun başlangıcı varsayılan olarak kurumun iş saatleri içinde ve hizmetin uygun olduğu zamanda olmalı. Zoho, hizmet uygunluğu dışında randevu oluşturmaya izin veren tercihle bu kapıyı açar. İş saatleri dışına izin veren ikinci tercih ancak ilki seçildiğinde görünür. İş saati dışında kayıt oluşturulduğunda uyarı gösterilir, fakat kullanıcı randevuyu yine kaydedebilir. Bu nedenle uyarı, kesin engelle karıştırılmamalıdır. Ekip, hangi seçeneğin kuralı gevşettiğini kayıt öncesinde bilerek değerlendirmelidir.
Takvim etkinliklerinde de benzer bir ayrım vardır. Etkinlik, o gün uygun olmayan ya da çalışma günü bulunmayan kullanıcıya atanırsa uyarı çıkar; kullanıcı yeniden planlayabilir veya atamayı sürdürebilir. Kullanıcının belirli bir saati uygun değil olarak işaretlemesi ve vardiya molasına etkinlik yerleştirilmesi de uyarı üretir. Bu bildirimlerin hiçbiri atamayı durdurmaz. Operasyon tasarımı, uyarıya rağmen verilen kararın sorumluluğunu ayrıca tanımlamalıdır. Takvim uyarıları, ekip içi karar düzeninin yerine doğrudan geçmez.
Ön görüşmeyi rezervasyon sayfasına taşıyın
Takvim Rezervasyonu, Team Booking ve User Booking seçeneklerini sunar; takvim türü Toplantılar ya da Aramalar olabilir. Gelişmiş ayarlarda her iki türde gösterim dilimi, en yakın rezervasyona kalan asgari saat, ileri tarih sınırı ve ev sahibi tamponu tanımlanır. Aynı zaman dilimindeki ve bir gündeki azami toplantı sayısı ise belgede yalnız Team Booking gelişmiş ayarlarında sayılır. Zoho böylece ön görüşme için sayısal rezervasyon tavanlarını doğrudan sayfanın kurallarına yerleştirmenize imkân verir. Bu tavanlar, görüşme kapasitesini sayfanın sunduğu seçenekler üzerinden yönetir.
Beklenen sonuç şudur: gün dolduğunda o saat rezervasyon sayfasında görünmez ve ekibin bunu ayrıca duyurması gerekmez. Belge bu davranışı bu ayrıntıda tanımlamaz, takvimde zaten duran toplantı ve randevuların bu tavan hesabına katılıp katılmadığını da yazmaz; bu nedenle hedef hesapta doğrulanması gerekir. Team Booking ev sahibini Users, Groups veya etkin Bölge Yönetimi varsa Territories arasından round robin yöntemiyle atar. Bağlantı kopyalanabilir, siteye gömülebilir veya e-posta imzasına eklenebilir. Team Booking yönetim izni, User Booking ise ilgili kayıt oluşturma izni ister. Bu sonuç ancak hedef hesapta doğrulandıktan sonra ekip kuralına dönüştürülür.
Çakışmayı liste ölçütüyle bulmaya çalışmayın
Özel görünüm ölçütü, her kaydı kendi alanlarına göre değerlendirir. Bir randevuyu başka randevularla karşılaştıramadığı için doğrudan çakışma, mükerrerlik veya tekrar sorgusu yazamaz. Bu sınır, görünümde tarih ve üye alanlarını yan yana getirmenin kayıtlar arası denetim oluşturmayacağı anlamına gelir. Zoho görünümü yalnız mevcut kayıt üzerindeki değerlere göre filtreler; karşılaştırma mantığı görünüm ölçütünün dışında kurulmalıdır. Dolayısıyla görünüm, karşılaştırma motoru değil, belirlenmiş sonuçların sunum katmanıdır.
Belgelenmiş kurgu, bir özel fonksiyonun kayıt üzerindeki işaret alanını doldurması ve görünümün bu alanı filtrelemesidir. İşaretin hangi koşulda üretileceği, operasyonun açıkça tanımladığı karşılaştırma mantığına dayanır. Görünüm sonuçları gösterir, fakat çakışmayı kendi başına keşfetmez ve kaydı engellemez. Bu yaklaşım özel fonksiyon gerektirdiğinden Enterprise veya Ultimate sürümüne dayanır; daha alt sürüm için aynı mekanizma varmış gibi yazılamaz. Ayrım, tespit mantığı ile sonuç listesinin görevlerini birbirinden ayırır.
Randevu modülünün otomasyon sınırları
Randevular modülündeki iş akışı eylemleri webhook, e-posta bildirimi, özel fonksiyon, alan güncelleme ve etiketle sınırlıdır. Görev eylemi bulunmaz. Alan güncelleme, kaydın kendi alanlarını ve belgelenmiş üst kayıt eşleşmelerini günceller. Randevudan bağlı Potansiyel Müşteri kaydına veri yazılması gerekiyorsa iş akışına bağlı özel fonksiyon gerekir. Zoho otomasyonu burada kayıt sınırlarına göre tasarlanmalı, alan güncellemesine belgesiz bir erişim yüklenmemelidir. Bu sınır, ihtiyaçların eylem türüne göre baştan sınıflandırılmasını gerektirir.
Randevular, Toplantılar, Aramalar ve Görevler modüllerinde özet alanı bulunmaz; bu modüllerden ilişkili liste toplamı alınamaz. Enterprise için modül başına on, Ultimate için modül başına on beş olan özet alanı kapasitesi bu yokluğu değiştirmez. Ayrıca Toplantılar, Aramalar ve Görevlerde benzersiz alan yoktur ve bu üç modüle arama alanı eklenemez. Raporlama tasarımı, bulunmayan alan türlerini varsaymak yerine mevcut kayıt sınırlarını kabul etmelidir. Beklenen toplamlar ve bağlantılar tasarım görüşmesinde ayrıca dikkatle sorgulanır.
Erteleme ve iptal kaydın kendi tarihçesidir
Bir randevu en fazla on kez ertelenebilir ve erteleme sayısı kendiliğinden kaydedilir. Erteleme veya iptal sırasında sebep ile not girilmesi zorunludur. Varsayılan seçenekler müşteri kaynaklı ve ekip kaynaklı nedenleri ayırır; kurum listeye kendi sebeplerini ekleyebilir. Böylece sonraki inceleme, serbest metin hatırlamalarından önce kaydın kendi sayısına, seçilmiş sebebine, notuna ve detay sayfasındaki erteleme geçmişine dayanır. Kurum nedenlerinin ayrılması, sonraki operasyon yorumlarını daha tutarlı kılar.
Randevu geçmiş bir tarihe de ertelenebilir. Randevu sahibine e-posta bildirimi gönderilir; kendi randevusunu erteleyen kullanıcıya aynı bildirim gitmez. Bu ayrıntılar, tarihçenin yalnız son başlangıç saatinden ibaret olmadığını gösterir. Operasyon ekibi sebep listesini günlük karar diline uyarlayabilir, ancak kayıtlı nedenlerden sonuç üretirken neyin gerçekten kaydedildiğini esas almalı ve belgelenmeyen bir otomasyon etkisi varsaymamalıdır. Kayıt tarihçesi, operasyon yorumunun sınırını ve dayanağını birlikte gösterir.
Kurmadan önce canlı organizasyonda denenecekler
Teklif sınırı nettir: Hizmetler Professional, Enterprise ve Ultimate sürümlerindedir, başlangıçta kapalıdır ve yalnız yönetici etkinleştirir; etkinleştirme Randevular modülünü ekler. Takvim, Toplantılar ve Aramalar sürümden bağımsızdır. Özel fonksiyonlu çakışma işareti Enterprise veya Ultimate ister. Territories seçimi, Enterprise ve üstünde Bölge Yönetimi açıkken görünür. Takvim Rezervasyonu için ayrı sürüm eşiği belirtilmediğinden teklif öncesinde doğrulanır; gerekli Team ve User izinleri ayrıca kontrol edilir. Bu çerçeve, teklif kapsamıyla kurulum varsayımlarının birbirine karışmasını önler.
Canlı organizasyonda aynı üyeye aynı saatin nasıl ele alındığını ve rezervasyon uygunluğunun mevcut kayıtlarla ilişkisini ayrı sorular olarak deneyip teyit edin. Eksenium tarafındaki ilgili varlık, Klinik CRM Pattern Kütüphanesi'ndeki hasta-kabul kalıbıdır. On iki kalıplı kütüphanede ayrı bir takvim ya da randevu kalıbı yoktur. Teyit sonuçları, hangi kurgunun önerileceğini ve hangisinin açık bırakılacağını belirler.
