Klinikte hasta adayı hattı: ilk temastan tedavi kararına kadar aşama yapısı

Bir hasta adayı hattının güvenilirliği, kaç aşama içerdiğiyle değil, her aşamanın ne zaman tamamlandığının herkes tarafından aynı biçimde anlaşılmasıyla başlar. Zoho CRM üzerinde de asıl mesele uzun bir liste kurmak değildir. Her aşamanın tek bir çıkış koşuluna, her kaydın tek bir sahibine bağlanması ve kullanılan kuralın hangi giriş kanalında çalıştığının bilinmesi gerekir.

Pazartesi sabahı danışman ekranını açıp hattaki kayıtların yarısının “görüşülüyor” aşamasında olduğunu söyler. İki danışman aynı kaydı farklı basamakta tuttuğu için hangi hastanın kimi beklediği toplantıda tek tek sorularak çıkarılır. Sorun kayıt eksikliği değil, aşama adlarının gözlenebilir sonuçlar yerine kişisel yorumları anlatmasıdır.

Aşama bir karar noktasıdır, bir ruh hali değildir

“Görüşülüyor” farklı kişiler için farklı anlamlara gelebilir. Bir danışman ilk aramayı yeterli görürken diğeri karşılıklı konuşmayı bekleyebilir. “Teklif verildi” ise denetlenebilir bir sonucu anlatır. Çıkış koşulu, “teklif hastaya iletildi” gibi tek cümle ve tek fiille yazılabilir.

Zoho CRM’de Fırsatlar modülündeki aşamalar, sistem tanımlı Seçim Listesi alanında tutulur. Listeye eklenen her değer gerçek bir karar noktasına karşılık gelmelidir. Aşama tanım belgesinde ad, çıkış koşulu ve o koşulu doğrulayacak bilgi yan yana yazılır. Böylece ekip bir kaydı ilerletirken ruh halini değil, gerçekleşmiş sonucu seçer.

Hasta adayı hattını kuran şey aşama listesinin uzunluğu değil, her aşamanın tek bir çıkış koşuluna ve tek bir sahibe bağlanmasıdır; hattın işlemesi ise hangi kuralın hangi kanaldan gelen kayıtta çalıştığını bilmeye bağlıdır. Bu ilke, alan ve otomasyon kararlarından önce gelir.

Çıkış koşulunu deneme üzerinden değil, sonuç üzerinden yazın

Aranıp telefonu açmayan aday “iletişim kuruldu” aşamasına geçmez, çünkü karşılıklı görüşme gerçekleşmemiştir. Bununla birlikte arama denemesini görünmez bırakmamak gerekir. Deneme bilgisi, ek bir alan türü ya da otomasyon davranışı varsayılmadan ekip sürecinde görünür tutulur. Aşama görüşmenin sonucunu anlatır; denemenin nasıl işaretleneceği ayrıca tanımlanır.

Çıkış koşulu “ilk temas denemesi yapılmıştır” diye yazılırsa ekip deneme gerçekleştiği anda kaydı ilerletir. Aşamanın adı iletişim kurulduysa tanım kendi içinde çelişir. Doğru ayrım, karar hattını faaliyet günlüğüne çevirmeden çalışmayı mümkün kılar. Aynı nedenle her arama sonucu için yeni bir aşama açmak yerine, aşamayı yalnız kararın yönü değiştiğinde ilerletmek daha açık bir dil oluşturur.

Zoho CRM'de hazır bir aşama ve kategori yapısı zaten vardır

Zoho CRM’de aşamalar açık, kazanıldı ve kaybedildi olmak üzere üç kayıt kategorisinden birine eşlenir; bu eşleme değiştirilebilir. Kazanıldı veya kaybedildi kategorisine bağlı bir aşama seçildiğinde ayrıntı doğrulama penceresi açılır. Kaybedilen aşamalarda hazır “Reason for Loss” Seçim Listesi sorulur. Kayıt kazanılan aşamaya taşındığında bu sebep gizlenir; daha sonra yeniden kaybedilen bir aşama seçilirse eski değer gösterilmez ve sebep yeniden seçilir.

Bu nedenle kliniğin ilerleme aşamaları yanında kazanıldı ve kaybedildi değerleri ayrı tutulur. İkisini tek satırda birleştirmek, kayıp sebebini kaybedildi kategorisine bağlayan yapıyı bozar. Kazanıldı da tek başına teknik bir kapatma komutu değildir; kapanma etkisi değerin eşlendiği kategoriden doğar. Kliniğin kendi listesini yazmadan önce hazır eşlemeyi okuması, aynı kavramı iki kez kurmasını önler.

Atama kuralı elle açılan kayıtta çalışmaz

Atama kuralı yalnız içe aktarma, web formu ve API ile oluşturulan kayıtlarda çalışır. Telefonla veya yüz yüze gelen talep danışman tarafından elle açıldığında tetiklenmez. Bu kanalda sahibin kayıt girişinde seçilmesi ayrı bir çalışma kuralı olmalıdır. Bir kaydın sahipliği her zaman tek kullanıcıdadır; sahibi olmayan ortak bir havuz bulunmaz.

Telefonla gelen bir talep danışmanın kendi ekranından elle açılır. Ekip kayıtların kurala göre dağıtıldığını düşündüğü için kimse sahibine bakmaz ve kayıt iki hafta boyunca onu açan kişinin üzerinde bekler. Burada kontrol edilmesi gereken “sahibi boş” kayıtlar değildir. Atanamayan kayıt zaten varsayılan kullanıcıya gider: içe aktarmada işlemi başlatan kişiye, API’de token sahibine, web formunda kuralı oluşturan kullanıcıya, bu kişi pasifse süper yöneticiye atanır.

Zoho CRM atama öncesinde kullanıcının sisteme giriş yapmış olmasını ve şirket ayarlarındaki vardiya saatinde bulunmasını birlikte kontrol edebilir. İki seçenek kullanılırsa iki koşul da sağlanmalıdır; çevrimiçi durum bilgisinde en fazla beş dakikalık gecikme olabilir. Bu nedenle kontrol görünümü, varsayılan kullanıcı veya süper yönetici üzerinde biriken kayıtlara göre kurulmalıdır.

Zorunluluğu üç yerden birine koyun, ikisine birden değil

Bir alanı zorunlu kılmanın yeri, durdurulmak istenen adıma göre seçilir. Doğrulama kuralı bir düzen, bir birincil alan, ölçütler ve hata ya da uyarı mesajından oluşur. “Stop with error” seçeneği kaydı durdurur, ancak kural yalnız elle kayıt oluşturma ve düzenlemede çalışır. İçe aktarma, web formu ve API gibi diğer kanallar ayrıca ele alınır.

Düzen kuralının “Set Mandatory Fields” eylemi alanı sayfa üzerinde zorunlu gösterir. Düzen kuralları içe aktarma, web formu ve aday dönüştürme sayfasında çalışmaz; API işlemlerinde yalnız zorunlu alan eylemi desteklenir. Blueprint ise geçişin “During” bölümünde istenen alanı zorunlu tutarak aşama değişimini şarta bağlar. Kayıt süreç içindeyken Blueprint doğrulaması doğrulama kuralından önce gelir.

Aynı zorunluluğu iki yere kurmak yerine kanal ve karar anına uygun olan tek mekanizma seçilir. İş akışı bu seçeneklerden biri değildir. Zoho CRM iş akışı eylemleri bir alanı zorunlu kılamaz, kaydın kaydedilmesini durduramaz, aşama geçişini engelleyemez veya kaydı özel görünüme taşıyamaz.

Aşamada geçen süreyi rapor kendiliğinden hesaplamaz

Bir rapora aşama alanını eklemek, kaydın o aşamada ne kadar kaldığını üretmez. İlgili Seçim Listesi alanında geçmiş takibi açıldığında değer, süre, değiştirilme zamanı, değiştiren kişi ve taşınılan değer ilişkili listede tutulur. Bu özellik modül başına yalnız bir Seçim Listesi alanında açılır; Fırsatlar modülünde aşama geçmişi varsayılan olarak gelir.

İş akışı alan güncellemesinin bir Tarih Saat alanına dinamik işlem anı yazıp yazamadığı doğrulanmış değildir; bu nedenle aşamaya giriş zamanını bu davranışa bağlamayın. Datecomp kullanan Formül alanı iki mevcut tarih alanı arasındaki farkı dakika olarak verir; salt okunurdur, katılan alanlar değiştiğinde yeniden hesaplanır, değeri dondurmaz ve mevcut kayıtlarda katılan alanlardan biri değişene kadar boş kalabilir. Bu kurguda aşamada geçen süre Seçim Listesi geçmiş takibindeki süre değerinden okunur.

Hattın uzunluğunu değil, kayıtların nerede biriktiğini ölçün

İlk dönemde iki özel görünüm kullanılabilir: seçilen aşamalardaki kayıtlar ile varsayılan kullanıcıya atanmış kayıtlar. Bir kaydın aşamasının ne zamandır değişmediğini özel görünüm kendiliğinden hesaplamaz; böyle bir süre Seçim Listesi geçmiş takibinden okunur. Özel görünüm yalnız ölçüte uyan kayıtlarla kendiliğinden dolar, bildirim göndermez, görev açmaz, sahip atamaz ve hatırlatma üretmez. Onun sabah açılan çalışma listesi olması ekip alışkanlığıdır.

Liste görünümündeki toplu işlemler otomasyondan ayrıdır ve kullanıcı tıklamasını bekler. Sahip değiştirme bu işlemlerden biridir; izne çıkan danışmanın açık kayıtları gerektiğinde buradan devredilebilir. Görünüm yalnız sorunu görünür kılar. Kimin ne zaman bakacağı ve görülen kayda hangi işlemi uygulayacağı ayrıca kararlaştırılır.

Kurulumu tanımdan başlatın, alandan değil

Önce yakın dönemde gelen talepler masaya konur ve ekipten her kaydın hangi aşamada olduğunu, o aşamadan çıkmak için hangi sonucun beklendiğini söylemesi istenir. Cevaplar ayrışıyorsa yeni alan açmak sorunu çözmez. Önce aşama sözlüğü üzerinde ortak dil kurulur, ardından alanlar ve kurallar seçilir.

Sürüm eşiği: Aşama geçişini şarta bağlayan Blueprint Professional ve üzeri sürümlerde bulunur. İki mevcut tarih alanı arasındaki farkı dakika olarak hesaplayan Formül alanı da Professional ve üzerindedir, ancak bu alan aşamaya giriş tarihini üretmez. Standard sürümde modül başına on özel alan açılır; doğrulama kuralı ile düzen kuralı için belgede ayrı bir sürüm eşiği verilmez. Aşamada geçen süre Seçim Listesi geçmiş takibinden okunur. Bu özelliğin sürüm eşiği belgede belirtilmemiştir, sürüme göre değişir ve teklif öncesi hedef hesapta doğrulanır; açmak için Module Customization izni gerekir, müşteri talebiyle sürüm düşürüldüğünde takip verisi anında ve kalıcı olarak silinir. Free sürümde özel alan ve özel modül bulunmadığından bu yazıdaki kurgu Free sürümde uygulanamaz.

Alan tipi baştan doğru seçilmelidir, çünkü oluşturulduktan sonra değiştirilemez. Tanımı net, çıkış koşulu gözlenebilir ve sahibi belli bir hat kurulduğunda ekip aynı kayda aynı anlamı verir. Son adım daha fazla aşama eklemek değil, birikme noktalarını düzenli okuyup tanımların çalışıp çalışmadığını sakin biçimde gözden geçirmektir.

Klinikler için Zoho CRM