Uluslararası Hasta Operasyonları İçin Bir CRM Dashboard'u Nasıl Geliştirdim

CRM sistemimiz kayıtları tutuyordu ancak ihtiyaç duyduğumuz operasyonel görünümü tek başına sunmuyordu. Başvuru kalitesini, funnel hareketlerini, danışman performansını ve tahmini pazarlama getirisini aynı raporlama katmanında birleştirmek için Versatile Dashboard’u geliştirdim.

Neden geliştirdim, metrikleri nasıl tanımladım, sistem ne gösteriyor ve nerelerde hâlâ yetersiz kalıyor

Bir CRM raporu teknik olarak doğru çalışırken operasyonel olarak yanlış bir soruyu cevaplıyor olabilir.

CRM sistemimizde hasta kayıtları, başvuru kaynakları, danışmanlar ve güncel statüler zaten bulunuyordu. Ancak yönetim operasyonun tamamını görmek istediğinde cevap genellikle birkaç farklı ekran, dışa aktarılan dosyalar ve ayrıca yapılan bir hesaplama gerektiriyordu.

Kaç gerçek başvuru aldık?

Hangi kaynaklar yalnızca hacim değil, anlamlı bir ilerleme üretti?

Hastalar sürecin hangi noktasında ayrıldı?

Danışman performansları nasıl değişti?

Reklam harcaması tahmini bir getiri oluşturdu mu?

Bilgi vardı ancak operasyonel görünüm yoktu.

Versatile Dashboard’u bu boşluğu kapatmak için geliştirdim.

Sistemi uluslararası hasta operasyonunun ihtiyaçlarına göre bağımsız olarak tasarladım, geliştirdim ve yayına aldım. Halen işletmeye devam ediyorum. Versatile Dashboard mevcut CRM’in yerine geçmiyor. CRM’de bulunan veriyi operasyonun cevaplaması gereken sorulara dönüştürüyor.

Başta bir sınır koymak gerekiyor: Bu sistem bütün sağlık kuruluşları için hazırlanmış evrensel bir raporlama ürünü değil. Tek bir uluslararası hasta operasyonunun işleyişine, kullandığı terimlere ve ihtiyaçlarına göre geliştirildi. Arkasındaki yöntem başka kurumlara taşınabilir ancak metrik tanımları her operasyonun kendi sürecine göre yeniden değerlendirilmelidir.

İlk problem teknik değildi

İlk versiyona grafiklerle başlayamazdım. Önce tanımların netleşmesi gerekiyordu.

“Başvuru” kelimesi ilk bakışta basit görünüyor. Ancak aynı hasta CRM’e önce Lead olarak girebilir, daha sonra Contact’a dönüşebilir veya Lead modülünden hiç geçmeden doğrudan Contact olarak kaydedilebilir.

Yalnızca Lead kayıtlarını saymak operasyonun bir bölümünü dışarıda bırakır. Her Lead ve Contact kaydını doğrudan toplamak ise dönüşen bir hastanın iki kez sayılmasına neden olabilir.

Versatile Dashboard, başvuruları Lead ve Contact kayıtlarını bir araya getiren bir model üzerinden değerlendiriyor. Doğrudan gelen Contact kayıtları ve dönüşen Lead kayıtları için ayrıca kurallar uygulanıyor.

Buradaki amaç ulaşılabilecek en büyük sayıyı üretmek değil. İş sürecini tutarlı şekilde temsil eden bir sayı üretmek.

Raporlama tarihi konusunda da benzer bir problem vardı.

Bir kaydın oluşturulma veya son değiştirilme tarihi, CRM içerisinde ne zaman işlem yapıldığını gösterir. Hastanın gerçekten ne zaman başvurduğunu göstermeyebilir.

Bu nedenle dönemsel raporlarda gerçek başvuru tarihi kullanılıyor. Başvuru tarihi bulunmayan kayıtlar ana dönem metriklerine dahil edilmiyor ve ayrı bir veri kalitesi problemi olarak gösteriliyor.

Bu ayrım yapılmadığında bugün düzenlenen eski bir hasta kaydı yeni bir başvuru gibi görünebilir. Gerçek bir başvuru ise yanlış raporlama dönemine düşebilir.

Zor olan grafikleri hazırlamak değildi. Her sayının gerçekte ne anlama gelmesi gerektiğine karar vermekti.

Versatile Dashboard nedir

Bu operasyonda kullandığımız CRM altyapısı Zoho CRM.

Versatile Dashboard’u Zoho CRM’in Leads ve Contacts verilerinin çevresinde çalışan ayrı bir uygulama olarak geliştirdim. Sistem kayıtları ortak bir raporlama modelinde birleştiriyor ve kaynak, danışman, dil, ülke, statü ve başvuru dönemine göre analiz ediyor.

Arayüzü, cevaplanmak istenen sorulara göre ayırdım.

Genel Bakış ekranı yakın dönemler için sade bir yönetici özeti sunuyor.

Detaylı Analiz ekranı funnel, danışman performansı ve gerçek statü hareketlerine odaklanıyor.

Raporlar bölümü ise Google ve Meta reklam çalışmaları için tarih, kaynak ve dil bazlı raporlar üretiyor. Bu raporlar kopyalanabilir metin ve yazdırılabilir çıktı olarak kullanılabiliyor.

Bu ekranları ayrı tutmak bilinçli bir tercihti. Bütün operasyon tabloları Genel Bakış ekranına eklendiğinde yönetici özeti işlevini kaybediyor. Ajans raporları dahili danışman analizleriyle karıştığında okunması zorlaşıyor.

Daha fazla bilgi her zaman daha iyi bir dashboard anlamına gelmiyor. Bilginin, karar verilebilecek doğru bağlam içerisinde gösterilmesi gerekiyor.

Güncel statü yolculuğu göstermez

CRM’deki güncel statü tek bir soruyu cevaplar: Bu hasta şu anda nerede?

Hastanın o noktaya nasıl geldiğini göstermez.

Şu anda kayıp olarak işaretlenmiş bir hasta daha önce danışman görüşmesine geçmiş, fiyat almış ve birkaç gün boyunca aktif kalmış olabilir. Aynı son statüye sahip başka bir hasta ise ilk mesaja hiç cevap vermemiş olabilir.

Sonuç aynı görünüyor. Operasyonel hikâye aynı değil.

Bu farkı görebilmek için Versatile Dashboard gerçek statü geçmişini Zoho CRM Timeline API üzerinden okuyor. Lead ve Contact kayıtlarındaki ilgili statü değişikliklerini kronolojik olaylara dönüştürüyor.

Bu hareketler daha sonra gerçek funnel yapısına göre sınıflandırılıyor.

Yeni bir başvurunun telefon veya doktor görüşmesine ilerlemesi anlamlı bir hareket. Sıcak satış veya depozito aşamasına ulaşması daha güçlü bir ilerleme. Lost, ilgisiz veya iletişim kurulamıyor sonuçlarına düşmesi ise gerileme olarak değerlendiriliyor.

Her güncelleme olumlu hareket panelinde yer almıyor. WhatsApp mesajı gönderilmesi normal bir süreç adımı olabilir ancak depozito alınmasıyla aynı ağırlığa sahip değildir. Operasyonun tamamlanması genel raporlama açısından önemli olabilir ancak süreç ilerlemesini gösteren paneli daha olumlu göstermek için kullanılmamalıdır.

Sınıflandırma özellikle seçici tutuluyor. Rutin hareketler yönetimin görmesi gereken değişimleri saklıyorsa timeline işlevini kaybeder.

En önemlisi, dashboard eksik statü geçmişi üretmiyor. Timeline API bir hareketi sunamıyorsa sistem mevcut statüden yola çıkarak geçmişe yönelik bir hikâye tahmin etmiyor.

Lead sayısı pazarlama performansı değildir

Reklam raporları genellikle ulaşılması en kolay sayıda duruyor: Her platformdan kaç lead geldi?

Bu sayı faydalı ancak eksik.

Bir kaynak çok sayıda başvuru üretirken çok az ilerleme sağlayabilir. Başka bir kaynak daha az başvuru getirirken daha fazla görüşme, sıcak satış veya depozito oluşturabilir.

İki kaynağı yalnızca hacme göre değerlendirmek, funnel’ın iş sonucu üreten bölümünü görünmez hale getirir.

Versatile Dashboard reklam harcamalarını CRM sonuçlarıyla birleştiriyor.

KPI bölümü başvuru maliyeti, anlamlı iletişim maliyeti ve ilerleyen funnel aşamalarındaki edinme maliyetleri gibi değerleri hesaplıyor. Sonuçlar kaynak, dil ve ülke bazında ayrı ayrı incelenebiliyor.

Ortalama ciro varsayımı girildiğinde tahmini ROAS ve ROI hesabı da yapılabiliyor.

Burada “tahmini” kelimesi önemli.

Dashboard, girilen ortalama ciro değerini kesinleşmiş muhasebe geliri olarak değerlendirmiyor. Hesaplama reklam harcaması, gözlemlenen CRM sonuçları ve sisteme girilen ciro varsayımı üzerinden oluşturulan bir yönetim senaryosu.

Varsayımı görünür tutmak sonucu daha kullanışlı hale getiriyor. Aynı zamanda tahmini bir değerin daha sonra gerçek finansal sonuç gibi aktarılmasını engelliyor.

CRM sonuçları her şeyi açıklamıyor

CRM verisi bir başvurunun ilerlemediğini gösterebilir. Çoğu zaman neden ilerlemediğini açıklamaz.

Hastanın bütçesi mi uygun değildi?

Tedavi tarihi çok mu uzaktı?

Dil bariyeri mi vardı?

Hasta farklı klinikleri mi karşılaştırıyordu?

Danışmanlar o haftaki lead kalitesinin değiştiğini mi düşünüyordu?

Operasyonun bu tarafını kaydedebilmek için Versatile Dashboard’a ayrı danışman anket turları ekledim.

Danışmanlar Google ve Meta başvurularının kalitesini değerlendirebiliyor, karşılaştıkları zorlukları kaydedebiliyor ve pazara özel problemleri açıklayabiliyor. Birden fazla ülke seçildiğinde her ülkenin zorluk sebepleri ayrı tutuluyor.

Anket sonuçları daha sonra dashboard içerisinde bulunan CRM sonuçlarıyla karşılaştırılıyor.

Bu yöntem danışman görüşünü nesnel bir gerçeğe dönüştürmüyor. Danışman algısını kayıtlı performansın yanına yerleştiriyor.

Bu ayrım önemli. Danışmanlar bir haftayı zayıf olarak değerlendiriyor ve CRM funnel’ı da aynı düşüşü gösteriyorsa iki farklı sinyal birbirini destekliyor. Algı ile veri uyuşmuyorsa bu farkın kendisi araştırılması gereken bir konu haline geliyor.

Anket sistemi sayıların yerine geçmiyor. Sayıların tek başına cevaplayamadığı soruları bulmaya yardımcı oluyor.

Gerçek bir çalışma ortamı için geliştirmek

CRM’e bağlı bir dashboard teknik ve operasyonel sınırlar içerisinde çalışmak zorunda.

Her ekran açıldığında bütün veriyi doğrudan CRM API’den almak gereksiz istek oluşturur. Ayrıca raporlama deneyimini, ekran her açıldığında harici bir servisin yanıt vermesine bağımlı hale getirir.

Bu nedenle Versatile Dashboard kontrollü bir önbellek kullanıyor. Uygulama verileri kendi yenileme sürecine göre alıyor, kullanılabilir son veri kümesini saklıyor ve CRM geçici olarak erişilemez olduğunda mevcut veriyi koruyor.

Bu yalnızca bir hız kararı değil. Operasyonun devamlılığıyla ilgili bir karar.

Sistem özel erişim için tasarlandı ve kimlik doğrulama arkasında çalışıyor. Raporlama servisleri herkese açık değil. Sistem içerisindeki belirli kullanıcı hareketleri audit log üzerinden kaydedilebiliyor.

Ayrıca sunumlar için ayrı bir veri güvenliği modu geliştirdim.

Yetkili kullanıcı bu modu açtığında hasta isimleri ile hasta adı veya CRM kimliği içerebilecek anket alanları ilgili ekranlarda maskeleniyor.

CRM, anket ve önbellek içerisindeki orijinal veriler değişmiyor. Koruma yalnızca görüntüleme katmanında uygulanıyor ve sunum bittikten sonra kapatılabiliyor.

Bu özellik bir ekran görüntüsünü mevzuata uygunluk belgesine dönüştürmüyor. Daha sınırlı ve gerçek bir problemi çözüyor: Operasyonel analizleri ekranda hasta kimliklerini göstermeden sunabilmek.

Sonrasında ne değişti

İlk değişiklik tek bir KPI’daki ani yükseliş olmadı.

Asıl değişiklik tutarlılıktı.

Başvuru, raporlama dönemi ve dönüşüm kavramları artık sistem içerisinde tanımlanmış durumda. Aynı soru her raporda farklı bir yöntemle yeniden hesaplanmak zorunda kalmıyor.

Pazarlama değerlendirmesi lead sayısında bitmiyor. Kaynak performansı görüşme, sıcak satış ve depozito hareketleri üzerinden devam ettirilebiliyor.

Danışman performansı yalnızca atanan dosya sayısıyla değil, bu dosyaların ulaştığı aşamalar ve danışmanların sahadan verdiği geri bildirimlerle birlikte okunabiliyor.

Ajans raporları ile dahili yönetim raporları aynı CRM tanımlarını kullanabiliyor.

Dashboard veri kalitesi problemlerini de görünür hale getiriyor. Eksik başvuru tarihi veya atanmamış danışman, toplam sayıların içerisinde sessizce kaybolmuyor. Düzeltilmesi gereken ayrı bir konu olarak gösteriliyor.

Buradaki değer bütün kararların otomatik hale gelmesi değil. Karar sürecinin operasyonun ortak bir görünümüyle başlaması.

Dashboard’un çözmediği noktalar

Sistem hâlâ CRM’e girilen verinin kalitesine bağlı.

Başvuru tarihi eksikse dashboard bu tarihi tahmin etmiyor. Kaynak yanlış kaydedilmişse rapor aynı hatayı taşır. Danışmanlar statüleri tutarsız kullanıyorsa funnel da bu tutarsızlığı gösterir.

KPI hesaplamalarının da bir sınırı var. Tahmini pazarlama getirisi, sisteme girilen ciro varsayımlarına bağlıdır. Muhasebe verisinin veya tedavi bazlı kârlılık analizinin yerine geçmez.

Danışman anketleri ek bağlam sağlar ancak öznel değerlendirmelerdir. CRM sonuçlarıyla karşılaştırılmaları gerekir.

Versatile Dashboard ayrıca bir tıbbi kayıt sistemi değildir. Başvuru, pazarlama ve danışman süreçlerinin çevresinde çalışan bir operasyonel raporlama katmanıdır.

Son olarak sistemin yapısı bu operasyonun ihtiyaçlarına göre hazırlandı. Başka bir klinik ilerlemeyi farklı tanımlayabilir, farklı statü aşamaları kullanabilir veya Lead ve Contact kayıtlarını farklı şekilde ayırabilir.

Arayüzü kopyalamak kolay olurdu. Tanımları test etmeden kopyalamak ise hata olurdu.

Son bir not

Bu projeye veriler olmadığı için başlamadım. Veriler vardı ancak cevaplar yoktu.

İlk bakışta dashboard problemi gibi görünen konu, büyük ölçüde bir ölçüm problemiydi. Arayüzü geliştirmeden önce başvurunun ne olduğunu, raporlama döneminde hangi tarihin kullanılacağını, hangi statü hareketlerinin gerçek ilerleme sayılacağını ve hesaplamalara hangi noktada varsayım girdiğini belirlemem gerekti.

Versatile Dashboard’un değeri ekrana daha fazla grafik koymaktan gelmedi.

Sayıların ne anlama geldiğini netleştirmekten, varsayımları görünür tutmaktan ve pazarlama faaliyetini başvuru geldikten sonra yaşananlarla birleştirmekten geldi.

Arayüz sistemin görünen kısmı. Asıl proje, onun altında çalışan operasyon modeli.