Diş kliniğinde hasta adayı takibi: ilk aramadan tedavi onayına kadar kurulum

Diş kliniğinde hasta adayı takibi, uzun bir aşama listesi yazmakla başlamaz. Asıl karar, gelen talebin hangi anda aday olmaktan çıkıp kişi ve fırsat kaydına dönüşeceğidir. Zoho içinde bu dönüşüm geri alınamadığı için sahiplik, zorunlu alanlar, randevu düzeni ve teklif akışı ancak bu sınır açıkça tanımlandıktan sonra sağlıklı biçimde kurulabilir ve ekip tarafından aynı anlamda uygulanabilir. Bu sıra, ekibin aynı talebi farklı anlamlarla işlemesini de baştan önler.

Bu sınır belirsiz kalırsa danışman, hekim ve yönetici aynı talebi farklı kayıtlar üzerinden izler. İlk aramadaki bilgi bir yerde, konsültasyon başka yerde, tedavi kararı ise üçüncü yerde kalabilir. Kurulumun amacı her ayrıntıyı ilk günde toplamak değil, kaydın yaşam döngüsünü ve her adımın sorumlusunu kanala, sürüme ve erişim düzenine uygun biçimde belirlemektir. Böylece her kayıt kararı, sonraki işlemin nedenini görünür ve tartışılabilir kılar.

Kurulum ilk aramadan değil, o aramanın nereye yazıldığından başlar

Telefonu açan kişi önce talebin aday mı yoksa kişi mi olduğunu bilmeli. Aday, ilgilenecek kişinin ve ilerleyişin henüz kesinleşmediği talebi temsil eder. Kişi ise kliniğin kalıcı kaydına alınmış hastadır. Zoho aday dönüşümünü geri alamadığı için bu ayrım, geçici bir etiket değil, kayıt yapısını değiştiren kalıcı bir işletme kararıdır. Bu karar, sonraki erişim ve sorumluluk tasarımının ortak başlangıç noktası olur.

Hasta konsültasyona geldiğinde hekim ekranda yalnız adı ve telefonu görür; ilk aramada yazılan notlar, dönüştürülmemiş aday kaydında kalmıştır ve hekimin açtığı hasta kaydında görünmez. Sorun notun eksikliği değil, iki kaydın henüz birleşmemesidir. Bu nedenle klinik, dönüşüm olayını ekipçe anlaşılabilen tek bir cümleyle tanımlamadan alan veya aşama tasarlamamalı. Ortak tanım, danışmanın dönüşümü erken ya da geç yapma riskini azaltır.

Dönüştürme anını aşama listesinden önce kararlaştırın

Dönüşüm tamamlandığında önce kişi, adayda şirket adı varsa ayrıca hesap oluşur; fırsat ise isteğe bağlıdır. Bireysel hastada şirket adı boş bırakıldığında hesap açılmaz. Aday alanlarındaki bilgiler, yalnız kişinin karşılık gelen alanı boşsa aktarılır ve mevcut değerleri ezmez. İşlemi yapacak profilin aday dönüştürme iznine sahip olması gerekir. Bu aktarım davranışı, dönüşüm öncesinde hangi bilginin kontrol edileceğini önemli kılar.

Fırsat oluşturulacaksa dönüşüm ekranı Fırsatlar modülündeki zorunlu alanları ister. Toplu dönüşümde fırsat adı doldurulur, diğer alanlar tek tek eklenir; iş akışıyla yapılan dönüşümde ise fırsat alanları listelenir ve zorunlu alanlar dönüşüm eşlemesine göre önceden doldurulur. Klinik bu geri alınamaz sınırı, örneğin talebin kişi sayılmasını sağlayan doğrulanabilir olay üzerinden tanımlamalı; sonraki aşamaları ancak bu kararın ardından yazmalı. Karar cümlesi, ekip üyelerinin aynı olayı aynı kayıt sınırı saymasını sağlar.

Talebin geldiği kanal, kuralların yarısını baştan belirler

Atama kuralı yalnız içe aktarma, web formu veya API ile oluşturulan kayıtlarda çalışır; telefon ya da yüz yüze görüşme sonrasında elle açılan kaydı kapsamaz. Kullanıcının Zoho oturumunu ve vardiya içinde bulunmasını kontrol edebilir. Çevrimiçi durum bilgisi beş dakikaya kadar gecikebildiğinden dağıtım mantığı anlık görünürlüğe koşulsuz güvenmemelidir. Bu yüzden kanal bilgisi, dağıtım tasarımının yanında kontrol sorumluluğunu da belirler.

Cuma akşamı gelen aramayı danışman kendi ekranından açar, pazartesi sabaha kadar kayda kimse bakmaz; kayıt elle açıldığı için dağıtım kuralının kapsamına girmez ve hâlâ onu açan kişinin üzerinde durur. Elle açılan kayıtlar için sahip atama eylemi içeren bir iş akışı düşünülebilir. Kontrol görünümü ise boş sahipliği değil, varsayılan ya da beklenmeyen sahibi süzmelidir. Görünümün amacı, geciken talebi doğru kişiye yeniden görünür kılacak düzenli kontroldür.

Zorunluluğu tek bir yere koyun, ikisine birden değil

Bir alanın zorunluluğu kanala göre tek yerde kurulmalıdır. Doğrulama kuralı hata vererek kaydı durdurabilir, fakat yalnız elle oluşturma ve düzenlemede çalışır. İçe aktarma, iş akışı alan güncellemesi, onay süreci, Blueprint ve API güncellemelerinde devre dışıdır. Düzen kuralı alanı sayfada zorunlu gösterir, ancak içe aktarma, web formu ve aday dönüştürme ekranında çalışmaz. Bu ayrım, aynı alanın farklı giriş yollarında farklı davranabileceğini ekibe açıklar.

Blueprint geçişinin During bölümü, aşama geçişini koşula bağlayabilir. Kayıt bu süreçteyken Blueprint doğrulaması normal doğrulama kuralından önce gelir. Aynı zorunluluğu iki mekanizmaya birden yazmak bu nedenle doğru değildir. İş akışı da alternatif değildir: alanı zorunlu kılamaz, kaydı durduramaz veya aşama geçişini engelleyemez. Klinik her alan için geçerli kanalı açıkça kaydetmelidir. Böyle bir tablo, kuralların çakışmasını ve beklenmedik kayıt davranışlarını da azaltır.

Konsültasyon randevusu için iki ayrı modül vardır ve ikisi aynı işi yapmaz

Toplantılar modülünde aday veya kişi katılımcı olarak eklenebilir; davet e-postası CRM üzerinden gider ve hatırlatma katılımcıyı uyarır. Kabul, ret ya da bekletme yanıtı kayıt sahibine bildirilir. En fazla elli katılımcı çağrılabilir. Bu yapı, konsültasyonu katılımcı iletişimi ve yanıt takibi üzerinden yöneten klinikler için bütün sürümlerde kullanılabilir. Seçim, kliniğin yanıt takibini hangi kayıt üzerinden yürüteceğine göre önceden yapılır.

Randevular modülü, Hizmetler etkinleştirildiğinde Zoho içinde otomatik olarak eklenir ve varsayılan olarak kapalıdır. Oluşturma, erteleme ve iptal için üç düzeni vardır; sistem alanları silinemez, ancak düzenlere yeni alan eklenebilir. Müşteri, hizmet ve başlangıç zamanı girilir. Süre hizmetin uygunluk ayarından gelir, randevuda değiştirilemez ve yalnız bir üye atanabilir. Bu nedenle iki yapı, ekip içinde aynı işlevi görüyormuş gibi değerlendirilmez.

Teklif kurgusunun önkoşulu ürün kataloğudur

Teklif satırı bir alt formdur ve ürün yalnız açılır listeden seçilir. Listede bulunmayan implant, kanal tedavisi veya zirkonyum gibi bir kalem satıra serbestçe yazılamaz; önce ürün kataloğunda tanımlanması gerekir. Bir teklifte en fazla iki yüz kalem bulunabilir. Fiyat listesi bağlanırsa indirim ve vergi değerleri satıra kendiliğinden gelir. Katalogdaki adlandırma, danışmanın teklif hazırlarken aynı tedavi dilini tutarlı biçimde kullanmasını destekler.

Klinik, tedavi onayını teklif kaydında mı yoksa fırsat aşamasında mı izleyeceğine kurulumdan önce karar vermelidir. Ürün adı sistem tanımlı olduğundan kaldırılamaz. Teklif satırını özelleştirme imkânı yalnız Enterprise ve Ultimate sürümlerindedir; satıra en fazla on alan, bir düzene ise en fazla on toplam alan eklenebilir. Teklifler Professional ve üzerindeki sürümlerde bulunur. Bu seçim, onayın nerede izleneceğini ve kimin kontrol edeceğini netleştirir.

Hekimin göreceği kayıt, sahiplikten geçer

Kayıt erişimi sahibine, rol hiyerarşisine, bölgeye ve veri paylaşım kurallarına göre yürür. Hekim sahibin astı ya da üstü değilse kayıt üzerinde onu işaretleyen bir kullanıcı alanı açılabilir. Bu alana salt okuma, okuma ve yazma veya tam erişim seviyesi verilir. Böylece görünürlük, hekim adını sıradan bir metin alanında tutmaya bırakılmaz. Erişim kararı, klinik içindeki iş bölümünün kayıt yapısına nasıl yansıyacağını belirler.

Her modülde en fazla beş tek kullanıcılı ve bir çok kullanıcılı alan bulunabilir; çok kullanıcılı alan on kişi taşır ve Görevler, Aramalar ile Toplantılar modüllerinde kullanılamaz. Alanı profile göre gizlemek veya salt okunur yapmak Professional ve üzerindeki sürümlerde mümkündür. Bu izin tek bir düzene değil, modülün bütün düzenlerine uygulanır. Bölge Yönetimi Enterprise ve üzerini gerektirir. Bu sınırlar, hekim erişimini tasarlarken kullanıcı alanlarının özellikle amaçlı kullanılmasını gerektirir.

İlk ayın kurulumunu sürümün sınırına göre kısaltın

Tam kurgu Professional ve üzerini gerektirir: Teklifler, Hizmetler ile Randevular, Blueprint ve alan düzeyi izin bu eşikte bulunur. Enterprise özel fonksiyonu ve kalem satırı özelleştirmesini açar; satır özelleştirmesi Ultimate sürümünde de vardır. Toplantılar bütün sürümlerdedir. Satış hattının sürüm eşiği bilinmediğinden Zoho kurulum ekranında teklif verilmeden önce ayrıca doğrulanmalıdır. Bu eşikler, ilk kurulum kapsamının eldeki sürüme göre gerçekçi tutulmasını sağlar.

Standard sürümde modül başına on özel alan ve iş akışı ölçütünde beş koşul sınırı vardır. Professional yüz elli beş alan ve beş koşul, Enterprise üç yüz alan ve on koşul, Ultimate beş yüz alan ve on koşul sunar. Free sürümde özel alan ve özel modül yoktur; asgari düzen hazır alanlar ve kendiliğinden dolan, fakat bildirim üretmeyen özel görünümlerle sınırlı kalır. Bu yüzden alan listesi, yalnız ihtiyaçla değil kullanılabilir kapasiteyle de sınanır.

Alan veri tipi oluşturulduktan sonra değiştirilemez; yalnız alan adı değiştirilebilir. Düzenden kaldırılan alan Unused Fields listesine geçer ve kotayı tüketmeyi sürdürür. Bu yüzden ilk ayda çekirdek alanları ayırmak, kalanları sonraki aşamaya bırakmak gerekir. Özel görünüm kayıtları ölçüte göre toplar, ancak görev, bildirim, hatırlatma veya sahiplik işlemi başlatmaz; sabah kontrolü ekip alışkanlığı olmalıdır. Bu disiplin, kullanılmayan alanların kotayı tüketmesini ve kontrolün yalnız ekrana bırakılmasını zaman içinde önler.

Klinikler için Zoho CRM