Kapanmış ama tedaviye başlamamış hastayı görmek

Kaparo alınan hasta kaydı kazanıldı işaretlenir ve danışman ekranını kapatır. Üç hafta sonra hasta tarih sorduğunda kaydın kimin listesinde durduğunu kimse söyleyemez; çünkü kayıt o gün açık işler ekranından düşmüştür. Bu durum kaydın yok olduğu anlamına gelmez. Zoho içindeki kategori işareti günlük görünürlüğü değiştirmiş, kapanış sonrası soruyu ise cevapsız bırakmıştır. Kazanılan iş ile başlayan tedavi yanlışlıkla aynı olay gibi sayılmıştır. Bu ayrım yapılmadığında kayıt durur, fakat iş sırası görünmez kalır.

Klinik yöneticisinin ihtiyacı kapanmış fırsatları yeniden açık saymak değildir. Kazanıldı, sürecin ticari sonucunu gösterirken tedavi başlangıcı başka bir olayı ölçer. Bu nedenle kapanışı anlatan aşama ile kapanış sonrasındaki gerçekleşmeyi anlatan alan ayrılmalıdır. Ardından yalnız bu alana bakan bir görünüm kurulabilir. Böylece ekip, kazanılan iş sayısını korurken henüz tedaviye başlamayan hastaları ayrı ve düzenli bir çalışma ekranında görebilir. Ayrı ölçüm, iki sonucun aynı raporlama dilinde erimesini önler.

Kazanıldı bir bitiş değil, bir kategori işaretidir

Fırsat aşaması tek başına duran bir etiket değildir. Yapı; aşama, olasılık, fırsat kategorisi ve tahmin kategorisinden oluşur. Fırsat kategorisi açık, kazanıldı veya kaybedildi olabilir. Sistem aşamalarının yanına özel aşamalar eklenebilir ve her aşama bu kategorilerden birine bağlanır. Tahmin kategorisi de buna göre açıkta pipeline, kazanıldı durumunda closed, kaybedildi durumunda omitted değerine otomatik eşlenir. Bu eşleme, görünen süreç adları değişirken kategorik anlamı sabit tutar.

Zoho üzerinde kazanıldı kategorisine bağlı bir aşama seçildiğinde Verify Details penceresi açılır; tutar, kapanış tarihi ve aşama bilgisi istenir. Kapanış aşamaları kayıt ayrıntısında ayrıca gruplanır ve bir simgeyle gösterilir. Dolayısıyla kapanma etkisini yaratan şey yalnız aşamanın adı değildir. Asıl belirleyici, o aşamaya bağlanan kategoridir. Sonraki tasarım kararları bu ayrımı koruduğunda ticari sonuç ile operasyonel başlangıç birbirine karışmaz. Bu nedenle adlandırma kararı, kategori eşlemesi görülmeden tek başına yorumlanmamalıdır.

Kayıt silinmez, yalnız kimsenin günlük ekranından düşer

Liste ölçütleri fırsat kategorisini doğrudan okuyabilir. Stage is open açık fırsatları, stage is won kazanılmış fırsatları, stage is lost ise kaybedilmiş fırsatları getirir. Aşamanın görünen adı değişse bile bu ölçütler bağlı kategoriye bakar. Bu yüzden kazanıldı kategorisine geçen kayıt, açık işler için hazırlanmış günlük görünümden çıkar; ancak kazanılmış fırsatları gösteren uygun listede görünmeye devam eder. Günlük liste böylece ticari sonuca değil, açık iş tanımına dayanır.

Buradaki boşluk bir silme veya arşivleme olayı değildir. Sorun, ekibin yalnız açık kategoriyi gösteren ekranla çalışmasıdır. Kapanıştan sonraki sorular aynı ekranda temsil edilmediğinde hasta kaydı operasyonel dikkatten uzaklaşır. Çözüm kategoriyi geriye çevirmek değil, kapanmış kayıtların içindeki başlanmamış işleri seçen ikinci bir görünüm oluşturmaktır. Böylece ticari kapanış korunur ve günlük takip için gereken ayrı kuyruk görünür kalır. İkinci ekran, kapanışı bozmadan eksik operasyon adımını yeniden görünür kılar.

Kapanış sonrasını ölçen alanı kapanışın kendisinden ayırın

Kapanıştan sonra tedavi planlandı veya tedavi başladı gibi özel aşamalar eklenebilir. Bu aşamalar kazanıldı kategorisine bağlı kaldığı sürece fırsat hedefe sayılmaya devam eder. Çünkü hedef hesabında aşama adından çok bağlı kategori belirleyicidir. Kapalı fırsatın tahmin kategorisi de kullanıcı tarafından değiştirilemez. Böylece süreç dili ayrıntılandırılırken kazanılmış iş sonucu korunabilir; tedavi başlangıcı ayrıca açılan alan üzerinden ölçülür. Alan boşluğu, sonuç kategorisini değiştirmeden bekleyen işi ayırt eder.

Başlama tarihi, ticari kapanış tarihinin yerine kullanılmamalıdır. Başlamama sebebi için yeni alan açmadan önce hazır Reason for Loss alanı da incelenmelidir. Bu alan yalnız closed lost kategorisindeki aşamalarda görünür; kayıt kazanılan bir aşamaya geçtiğinde gizlenir ve önceden seçilmiş değer gösterilmez. Klinikteki diğer sebep alanlarıyla birlikte adları birleştirilirse aynı kavramın farklı başlıklarla çoğalması önlenir. Böylece kayıp gerekçesi ile kazanıldı sonrası bekleme gerekçesi karıştırılmaz.

Listeyi kuran ölçüttür, listeyi dolduran bir kural yoktur

Özel görünüm, kaydın kendi alanlarını okuyabildiği gibi arama alanı üzerinden üst modül alanlarını, alt form alanlarını ve ilişkili kayıtların varlığını da değerlendirebilir. Bu nedenle ölçüt veri modeline göre kazanılmış ve tedavi başlangıç tarihi boş olan fırsatları seçebilir. İşlem ayrı bir ilişkili kayıtsa, kazanılmış fakat ilgili işlem kaydı bulunmayan fırsatlar aynı amaçla listelenebilir. Seçim mevcut kayıt yapısına göre yapılır. Her iki yaklaşımda da ölçüt, kaydın mevcut verisini sorgular.

Zoho görünümünde en fazla üç ilişkili modül veya alt form kullanılabilir ve her birinden en fazla üç alan okunabilir. Ayrıca en çok üç arama alanı ve aranan modüllerden toplam beşer alan ölçüte katılabilir. Kullanıcının ilişkili modüle izni yoksa görünüm çalışır, fakat ilgili ölçüt maskelenir. Kayıtlar koşula uydukça görünüm kendiliğinden dolar; herhangi bir kural onları bu listeye taşımaz. Yetki tasarımı bu yüzden listenin yorumlanabilirliğini de doğrudan etkiler.

Liste kendiliğinden kimseye haber vermez

Özel görünüm yalnız uygun kayıtları gösterir; kendi başına bildirim veya takip başlatmaz. Listeyi harekete bağlayan belgelenmiş mekanizma Cadences'tir. Hedef kitle elle seçilebilir ya da mevcut bir özel görünümden alınabilir ve yeni kayıtların ne zaman diziye katılacağı ayrıca belirlenir. Hedeflenen yanıt geldiğinde kayıt diziden kendiliğinden çıkar. Bu ayrım, görünümün seçme işini takip akışından ayrı tutar. Önce seçim yapılır, ardından ayrı mekanizma bu seçimi çalışmaya çevirir.

Hedef görünüm Campaign Name alanını içeremez, çoklu seçim listelerinde Include All, Include Any, Exclude All veya Exclude Any kullanamaz. İlişkili modül ölçütü ve kullanıcı alanlarında belongs to karşılaştırıcısı da bulunamaz. Takipler e-posta, görev, arama ve WhatsApp olabilir; ancak arama Fırsatlar modülünde desteklenmez, WhatsApp Business Messaging etkin olmalıdır. İlk kurulumda beş takibe kadar tanımlanır; oluşturulanlardan yalnız sondaki kaldırılabilir. Bu kısıtlar, görünüm tasarlanırken takip amacının baştan bilinmesini gerektirir.

Zorunluluğu doğru kural türüne kurun

Planlanan işlem tarihinin belirli bir aşamada istenmesi, düzen kuralındaki Set Mandatory Fields eylemiyle kurulabilir. Aşama kayıt ayrıntısından, Blueprint üzerinden veya Pipeline görünümünden değiştirildiğinde zorunlu alanlar açılır pencerede sorulur. Kural, Kanban görünümündeki sürükle bırak işleminde değerlendirilir ve onay akışlarında geçerlidir. Buna karşılık içe aktarma, web formu ve lead dönüştürme sayfasında çalışmaz; API yalnız zorunlu alan eylemini destekler. Bu kapsam farkları, veri girişinin hangi yüzeyde yapıldığını önemli kılar.

Doğrulama kuralı farklı davranır: kaydetmeyi durdurabilir veya uyarı gösterebilir, fakat aşama geçişi kavramı taşımaz. Kayıt Blueprint içindeyken Blueprint doğrulaması önce gelir. Aşama geçişini sürecin şartına dönüştürmek bu nedenle Blueprint gerektirir. Düzen başına on kural, en fazla yirmi beş ana koşul, koşul başına beş dal ve dal başına yirmi beş eylem sınırı vardır; kurgu bu kapasite içinde sade tutulur. Ayrı roller, beklenen davranışı sınamayı ve açıklamayı kolaylaştırır.

Erteleme sayacı ile bekleme süresi aynı mekanikle çözülmez

Alan güncellemesi yalnız önceden belirlenmiş sabit bir değeri veya boş değeri yazar; mevcut sayıyı okuyup artıramaz. Erteleme sayacı iş akışına bağlı özel fonksiyonla artırılır ya da ekip alışkanlığı olarak tanımlanıp elle güncellenir. Formül alanı salt okunurdur ve katılan alanlar değişince yeniden hesaplanır; anlık değeri dondurmaz. Bekleme süresi ise modül başına tek seçim listesinde açılan geçmiş takibinden incelenir.

Ay sonu toplantısında kazanılan iş sayısı ekrandadır; koltuğa oturan hastalar danışman notlarından birleştirilir ve iki kişi aynı hasta için farklı cevap verir. Standard, özel alan, özel görünüm ve Cadences için asgari düzeydir; düzen kuralı sürümden bağımsızdır. Blueprint ve formül alanı Professional düzeyinde, kendiliğinden artan sayaç özel fonksiyonla Enterprise düzeyindedir. İlişkili kayıt sayısı Enterprise'ta on, Ultimate'ta on beş özet alanıyla izlenebilir; alt sürümlerde yoktur. Free sürümde özel alan bulunmadığından kurgu kurulamaz.

Kurulum sırası en ucuz adımdan başlar

Önce aşama ve kategori eşlemesi gözden geçirilir; kazanıldı sonrasındaki adların hangi kategoriye bağlı olduğu açıkça yazılır. Sonra tedavi başlangıcını taşıyan alan açılır ve başlanmamış kayıtları seçen görünüm kurulur. Görünüm uygunsa Zoho Cadences için hedef kitle yapılır, koşullu zorunluluk ise tek bir düzen kuralında tutulur. Yönetici görünümü için yonetici-cockpit kalıbı hazırlanmıştır. Her adım bir sonraki yatırımın gerçekten gerekip gerekmediğini gösterir.

İlişkili kayıt kullanan görünüm Cadences hedefi olamayacağından, takip ihtiyacı varsa ölçüt tasarımı bu kısıtla birlikte ele alınır. Zorunluluk için düzen kuralı, kontrollü aşama geçişi için Blueprint, artan sayaç için özel fonksiyon seçilir. Her araç yalnız kendi sorusunu çözer. Sonuçta kazanılan iş sayısı ile başlayan tedavi sayısı iki ayrı yönetim sorusudur; biri ticari kapanışı, diğeri kapanıştan sonraki gerçekleşmeyi gösteren ayrı ekranlarda izlenir.

Klinikler için Zoho CRM