Yurt dışından gelen hastada kaparo konuşması çoğu zaman satış, finans ve operasyon arasında bölünür. Tutar bir yerde, ödeme tarihi başka yerde, ayrılan zaman ise takvimde görünür. Zoho CRM açısından asıl karar, paraya yeni bir ad vermek değildir. Ön ödeme bilgisinin hangi kayıtta tutulacağı ve hangi aşamanın hangi koşul sağlandığında açılacağı birlikte tasarlanır. Böylece satış kaydı ile operasyon kararı aynı mantıkta buluşur. Kararın görünür olması, ekiplerin aynı kaydı aynı gerekçeyle yorumlamasını sağlar.
Bu ayrım yapılmadığında ödeme alınmış olsa bile randevu yolu açılmayabilir veya para gelmeden operasyon zamanı ayrılabilir. Zoho içinde ön ödeme, kayıt üzerindeki para ve tarih alanlarıyla temsil edilir. Aşama koşulu ise Blueprint geçişinde ele alınır. Aynı zorunluluğu ayrıca doğrulama kuralına taşımamak gerekir. Kur, hesaplama yöntemi, randevu bağlantısı ve kullanılan sürüm de teklif hazırlanırken bu tasarımın açık parçaları olmalıdır. Bu çerçeve, ödeme bilgisini aşama kararından ayırmadan sorumluluğu da belirginleştirir.
Para geldi, peki sistemde nerede duruyor
Ön ödeme banka dekontunda görünürken satış konuşması mesajlaşma uygulamasında kalabilir. Operasyon ekibi ise ayrı bir takvime bakar. Bu parçalar ortak bir kayıt çevresinde birleşmediğinde herkes kendi ekranında doğru bilgi görür, fakat hiç kimse bütün kararı açıklayamaz. Sorun yalnız paranın bulunduğu yer değildir; ödeme ile zaman ayırma kararının birbirinden kopmasıdır ve sorumluluk sınırlarının görünmez hale gelmesidir. Ortak bağlam kurulmadıkça ödeme kanıtı, zaman kararını tek başına açıklayamaz.
Danışman ekranda kaparo alındığını belirten bir onay kutusunu işaretler. Aynı gün ameliyathane defterine bir isim yazılır. İki hafta sonra dekontun hangi kayda ait olduğu bulunamaz; çünkü kutu işaretlidir, ancak tutarın yazıldığı bir yer yoktur. Bu tablo, tek başına evet veya hayır bilgisinin ödeme izini ve operasyon kararının gerekçesini taşımaya yetmediğini açık biçimde gösterir. Tutar ve tarih görünmediğinde, sonraki kararın dayanağı da izlenebilir kalmaz.
Kaparo bir nesne değil, bir alandır
Zoho CRM içinde kaparo, ön ödeme veya tahsilat adıyla ayrı bir nesne bulunmaz. Envanter tarafında Teklifler, Satış Emirleri ve Faturalar vardır. Bu nedenle ön ödeme, seçilen kayıtta açılan alanlarla tutulur. Para alanı alınan miktarı, tarih alanı ödeme tarihini taşır. Kullanılabilecek alan tipleri tanımlı bir listeyle sınırlıdır; para, tarih, seçim listesi ve onay kutusu bu seçenekler arasındadır. Alanların birlikte okunması, ödeme olayını tek bir işaretin ötesine taşır.
Yabancı para kullanılacaksa çoklu para birimi etkinleştirildiğinde kayda sistemin Currency ve Exchange Rate alanları eklenir. Bu özellik açıldıktan sonra kapatılamaz. Ana para birimi bir kez değiştirildikten sonra yeniden değiştirilemez; tanımlanan para birimleri de silinmek yerine pasife alınabilir. Dolayısıyla para alanını açma kararı ile para birimi yönetimini başlatma kararı aynı ağırlıkta değildir ve birlikte değerlendirilmemelidir. Bu ayrım, geri dönüşü sınırlı ayarları erken değerlendirmeyi gerektirir.
Hangi aşamanın hangi koşulla açıldığını Blueprint'e yazın
Aşama geçişini koşula bağlayan belgelenmiş mekanizma Blueprint'tir. Bir geçiş Before, During ve After bölümlerinden oluşur. Before, geçişi yapabilecek kişiyi ve görünürlük ölçütünü belirler. During, geçiş sırasında istenecek alanları ve öğeleri toplar. After ise geçiş sonrasında yürütülecek otomasyon eylemlerini barındırır. Zoho kurgusunda ön ödeme koşulu, satış aşamasının anlamıyla birlikte bu geçiş yapısında tanımlanır ve tek yerde yönetilir. Böylece geçiş, alan doldurmanın ötesinde açık bir karar noktasıdır.
Blueprint tek bir modül, tek bir düzen ve tek bir birincil alan üzerine kurulur. Bu alan yalnız Transition API, Workflow API, iş akışındaki özel fonksiyon, iş akışı alan güncellemesi veya Command Center alan güncellemesi üzerinden güncellenebilir. Aynı birincil alanı ayrıca iş akışıyla beslemek, tasarlanan geçiş yolunu elinizle atlatır. Bu nedenle aşama alanının sahipliği başka otomasyonlarla paylaşılmaz ve istisna gibi kullanılmaz. Aksi durumda kayıt, tanımlanan sürecin dışından aynı sonuca taşınabilir.
Aynı zorunluluğu iki yere yazmayın
Doğrulama kuralı elle kayıt oluşturma ve düzenleme sırasında çalışır. İçe aktarma, iş akışı alan güncellemesi, onay süreci, Blueprint ve API üzerinden yapılan güncellemelerde alan değişikliği bu kuralın önüne geçer. Bir kayıt Blueprint sürecindeyse Blueprint doğrulaması ayrıca öncelik kazanır. Ön ödeme alanlarının geçişte istenmesi bu nedenle ikinci bir doğrulama kuralıyla yinelenmez; sorumluluk tek mekanizmada açıkça bırakılır. Tek kaynak, değişiklikte hangi koşulun korunacağını da görünür kılar.
Bu sınır, içe aktarma veya API ile gelen verinin elle düzenleme kuralıyla korunmuş sayılmaması gerektiğini de gösterir. Ancak aynı zorunluluğu iki farklı yerde tanımlamak kapsama sorununu çözmez; yalnız bakım sırasında iki ayrı doğruluk kaynağı yaratır. Zoho tasarımında geçiş koşulu Blueprint'te kalır, diğer giriş kanalları ise kendi davranışları bilinerek değerlendirilir. Böylece bir kuralın çalışmadığı kanal yanlışlıkla güvence kabul edilmez. Bu değerlendirme, kanal farklarının ayrıca izlenmesini ve belgelenmesini gerektirir.
Kur, tutarın kendisi kadar belirleyicidir
Çoklu para biriminde rapor, analiz ve tahmin toplamları bugünkü kuru değil, kaydın üzerinde saklanan kuru kullanır. Kurun sonradan değişmesi varsayılan olarak mevcut kayıtları dönüştürmez. Exchange Rate değeri, bir ana para biriminin kaç kayıt para birimine eşit olduğunu anlatır. Kaydın tutarını ana para birimine çevirmek için miktar bu kura bölünür; yönü sezgisel varsayımla ters okumamak gerekir. Kayıt kuru, aynı tutarın raporlarda nasıl okunacağını doğrudan belirler.
Fiyat euro olarak konuşulur, tahsilat başka bir kurdan geçer, rapor ise üçüncü bir rakam gösterir. Toplantıda üç kişi üç ayrı ekrana bakar ve hiçbiri yanılmaz. Farkın kaynağı, ekranların aynı kur anını temsil etmemesidir. Kayıt düzeyinde kuru yenilemek bir alan güncellemesi sayılır ve otomasyonu tetikler. Bu yüzden kur düzeltmesi yalnız rakamsal değil, süreç üzerinde etkili bir değişikliktir. Bu etki, kur değişikliğinin işlem bağlamıyla değerlendirilmesini gerekli kılar.
Hesabı alan güncellemesine yıkmayın
İş akışındaki alan güncelleme eylemi, seçilen alana yalnız önceden belirlenmiş sabit bir değer veya boş değer yazar; kalan tutarı ya da iki tarih arasındaki gün farkını hesaplamaz. Bu hesaplar salt okunur formül alanıyla veya özel fonksiyonla kurulabilir. Formül alanı Professional ve üstünde, özel fonksiyon ise Enterprise ve üstünde kullanılabilir. Seçim, hesabın yalnız görüntülenmesiyle işlenmiş bir sonuç üretme ihtiyacına göre yapılır. Yöntem seçimi, beklenen sonucun niteliğini ve sürdürülebilirliğini birlikte belirler.
Formül alanı hesaplanan değeri donduramaz. Ayrıca sonradan açılan yeni bir formül alanı, hesaba katılan alanlardan biri değişene kadar mevcut kayıtlarda boş görünebilir. Bu davranış, geçmiş ön ödeme kayıtlarının kendiliğinden tamamlanacağı varsayımını geçersiz kılar. Sabit değer yazan alan güncellemesini hesap aracı gibi kullanmak da doğru değildir. Kalan tutarın nerede gösterileceği, hangi sürümün kullanılacağıyla beraber baştan kararlaştırılır. Geçmiş kayıtların durumu, yeni hesap tasarımında ayrıca ele alınır.
Operasyon takvimi hastaya bağlanır, fırsata değil
Randevu; Randevular modülünden, CRM takviminden, Hizmetler modülünden veya Appointments For alanında listelenen modüllerden açılabilir. Sistem tanımlı çoklu modül arama alanı olan Appointments For, varsayılan olarak Kişiler modülünü listeler. Bu nedenle randevu Fırsat kaydına değil, müşteri kaydına bağlanır. Zoho ayrıca geçmiş tarihli randevu oluşturulmasına izin verir; bağlantının anlamı randevunun açıldığı zamandan bağımsızdır. Bu bağ, operasyon zamanını satış aşamasından ayrı değerlendirmeyi kolaylaştırır.
Randevunun başlangıcı kurumun iş saatleri içinde olmalı, süresi ise hizmet uygunluğundan gelmelidir ve randevu ekranında değiştirilemez. Hizmet uygunluğu dışında randevu açma tercihi etkinleştirilebilir; iş saatleri dışı seçeneği ancak bundan sonra görünür. Tamamlanan randevudan otomatik Fırsat üretildiğinde tutar hizmet fiyatına, kapanış tarihi başlangıç tarihine salt okunur biçimde eşlenir. Ad değiştirilemez, varsayılan aşama Closed Won olur. Bu eşlemeler, tamamlanmış randevunun ürettiği kaydın sınırlarını açıkça belirler.
Sürüm eşiğini teklifin içine yazın
Özel alanlar en az Standard gerektirir ve Free sürümde bulunmaz. Envanter modülleri, Blueprint, formül alanı ve Randevular modülü Professional eşiğinden başlar. Randevular Professional, Enterprise ve Ultimate sürümlerinde yer alır; özel fonksiyon Enterprise ve üstündedir. Çoklu para biriminin eşiği ise mevcut bilgilerde çelişkilidir. Bu özellik için sürüm tahmini yapılmaz, müşterinin kendi Setup ekranındaki kullanılabilirlik doğrulanır. Bu kontrol, teklif kapsamının kullanılabilir ayarlarla uyumunu baştan korur.
Blueprint sayısı Professional sürümünde 3, Enterprise'da 20, Ultimate'ta 100'dür. Bir geçişin During bölümünde istenebilecek alan tavanı aynı sırayla 4, 10 ve 50 olur. Teklif, kullanılacak modülü, zorunlu geçiş alanlarını, hesap yöntemini ve doğrulanması gereken çoklu para birimi eşiğini ayrı ayrı yazmalıdır. Böylece Zoho CRM kurgusunda ön ödeme kaydı ile operasyon zamanının açılması, sürümün gerçekten taşıdığı sınırlar içinde kalır. Sınırlar yazıldığında, kararın teknik dayanağı taraflar için görünür olur.
