Hasta koordinatörü ve CRM: kaynak-randevu atıfı
Klinik CRM'inde kaynak-randevu atıfını koordinatörün hafızasına bırakmadan kurmak: veri modeli, koordinatör iş akışı, aşama tanımları ve geri besleme.
Yazan Roozbeh Nazari · CEO
Uluslararası hasta alan bir klinikte kaynak-randevu atıfının koptuğu yer genellikle teknoloji değil, masa. WhatsApp Business Platform'un kurulumunu ve konuşmaya kaynak bilgisinin nasıl bindiğini WhatsApp funnel'ı yazısında, hangi temasın gerçek lead sayılacağını lead kalitesi yazısında anlatmıştık. Bu yazı aradaki insan katmanına bakıyor: hasta koordinatörünün iş akışı ve CRM'in veri modeli, kaynak bilgisini randevuya kadar taşıyacak biçimde nasıl kurulur. Amaç, "bu hasta nereden geldi" sorusunun cevabının koordinatörün hafızasında değil kayıtta olması.
Atıf neden koordinatörün masasında kopuyor
Çalıştığımız kliniklerde tekrar eden dört örüntü var. Birincisi, kaynak bilgisinin hastaya sorulması: "bizi nereden duydunuz" sorusuna verilen cevap, hastanın hatırladığı son temas oluyor; arama motorundan gelip Instagram'da kliniği takip eden hasta "Instagram" diyor ve arama kanalı kayıttan siliniyor. İkincisi, dil bazlı koordinatör yapısı: Arapça, Farsça ve İngilizce konuşan koordinatörler ayrı telefonlarla, bazen ayrı elektronik tablolarla çalışıyor ve aynı hasta iki kayıt oluyor. Üçüncüsü, serbest metin: CRM'de kaynak alanı serbest yazıldığında aynı kanal on farklı yazımla görünüyor ve rapor alınamıyor. Dördüncüsü, depozito ve randevunun CRM dışında, muhasebede ya da hastane bilgi sisteminde kaydedilmesi; kaynak bilgisi temasla başlıyor, randevu bilgisi başka sistemde bitiyor ve ikisi hiç birleşmiyor.
Bu dört sorun aynı kökten çıkıyor: kaynak alanını insan dolduruyor. Çözüm, kaynağı otomasyonun yazması ve koordinatörün yalnızca aşama ile tedavi bilgisini girmesi.
CRM veri modeli: hangi alanlar, kim yazar
Kliniğe özel bir CRM gerekmiyor; gereken, her lead kaydında aşağıdaki alanların bulunması ve kimin yazacağının belirlenmiş olması.
- Otomasyonun yazdığı alanlar: ilk temas kaynağı, aracı ve kampanya (sayfa URL'sindeki parametrelerden), tıklama kimlikleri (Google için gclid, wbraid ve gbraid; Meta için fbclid), giriş sayfası, sayfanın dili ve ziyaretçinin ülkesi, temas kanalı (form, WhatsApp, telefon), temas zamanı.
- Koordinatörün yazdığı alanlar: ilgilenilen tedavi, aşama ve aşama tarihi, teklif tutarı, seyahat tarihi, sorumlu koordinatör, hastanın kendi söylediği kaynak (ayrı bir alanda, otomasyon alanının üstüne yazılmadan).
- Sistemin türettiği alanlar: lead kimliği, aşamalar arası süre, tekrar temas sayısı.
Kural basit ama uygulaması disiplin istiyor: otomasyonun yazdığı alanlar koordinatör tarafından düzenlenemez. Hastanın söylediği kaynak, tutarsızlığı görmek için tutulur; kanal raporunun kaynağı değildir. WhatsApp'tan gelen konuşmalarda anahtar telefon numarası, formdan gelenlerde e-posta; iki kanal aynı kişiye aitse kayıt birleştiriliyor ve ilk temasın kaynağı korunuyor.
Koordinatör iş akışı
Veri modeli doğru olsa da koordinatör ilk cevabı verirken kaydı açmıyorsa zincir yine kopuyor. Uyguladığımız akış beş adımdan oluşuyor. İlk cevap konuşmadan değil CRM'den başlıyor: koordinatör önce kaydı buluyor ya da otomasyonun açtığı kaydı üstleniyor, sonra yanıt yazıyor. Telefonla gelen aramalarda dil bazlı sayfalara ayrı takip numaraları veriliyor; koordinatör aramanın hangi numaraya geldiğini kaydediyor, hastaya kaynağı sormuyor. Koordinatörler arası devirde lead kimliği taşınıyor; Arapça koordinatörden İngilizce koordinatöre geçen hasta yeni kayıt olmuyor. Teklif ve depozito aynı gün kayda giriyor; muhasebe sisteminde kaydedilen depozito, günlük bir eşleme ile CRM'deki kayda bağlanıyor. Haftalık hijyen toplantısında kaynağı "bilinmiyor" görünen kayıtlar ve mükerrer kayıtlar tek tek ele alınıyor.
Aşama tanımı bu akışın en çok atlanan parçası. "Randevu" kelimesi bir klinikte tarih verilmesi, diğerinde depozito alınması, üçüncüsünde hastanın uçağa binmesi anlamına geliyor. Tanımı bir kez yazıp CRM'deki aşama listesine gömmek gerekiyor; önerdiğimiz sıra temas, nitelikli temas, teklif gönderildi, depozito alındı, seyahat tarihi kesinleşti, tedavi uygulandı ve kontrol. Raporda "randevu" dendiğinde herkesin aynı aşamayı anlaması, kanal karşılaştırmasının ön koşulu. Aşama değişikliğini yalnızca sorumlu koordinatörün yapabilmesi ve her değişikliğin tarih damgasıyla kaydedilmesi, sonradan "bu hasta ne zaman depozito verdi" sorusunun tek cevabı olmasını sağlıyor.
Geri besleme: randevuyu reklam ve analitik sistemlerine döndürmek
Kaynak bilgisi CRM'e düştüğünde işin yarısı bitiyor; diğer yarısı, depozito ve tedavi bilgisinin reklam ve analitik sistemlerine geri dönmesi. Google Ads'in çevrimdışı dönüşüm içe aktarma dokümanı, reklamın tıklanmasından sonra çevrimdışı dünyada olan şeyi ölçmeyi bu yöntemle mümkün kılıyor ve tıklama kimliğinin lead bilgisiyle birlikte saklanıp dönüşüm gerçekleştiğinde geri verilmesini anlatıyor. Aynı doküman, 15 Haziran 2026'dan itibaren çevrimdışı dönüşüm ve potansiyel müşteri için gelişmiş dönüşüm yüklemelerinin Data Manager API'ye taşındığını ve Google Ads API'de engellendiğini yazıyor; entegrasyonu bugün kuran bir kliniğin doğrudan Data Manager ile başlaması gerekiyor. Tıklama kimliği saklanmamış kayıtlar için gelişmiş dönüşümler, hastanın verdiği e-posta ya da telefon numarasının karma değeriyle eşleme yapıyor.
GA4 tarafında Data Import özelliği dış kaynaklardan gelen veriyi analitik verisiyle birleştiriyor; içe aktarılabilen türler arasında olaylar ve kullanıcı verisi var, yani depozito aşamasını GA4'te bir olay olarak görmek mümkün. User-ID özelliği ise kliniğin kendi tanımlayıcısını farklı oturum ve cihazlardaki davranışa bağlıyor; CRM'deki lead kimliğinin GA4'e User-ID olarak verilmesi, ilk ziyaretle depozito arasındaki yolu tek kullanıcı altında topluyor. Bu geri besleme katmanının rıza, karma ve kişisel veri yükümlülükleri var; çerezsiz dünyada bu yapının nasıl kurulacağını first-party data planı yazısında ayrıntılı anlatmıştık.
Rapor: koordinatörü değil, zinciri ölçmek
Bu düzen kurulduğunda alınabilen rapor, kanal bazında temas, nitelikli temas, depozito ve tedavi sayıları ile aşamalar arası süre; dil sürümü ve ülke boyutlarıyla kırılmış hali. İzlediğimiz üç gösterge var: kaynağı bilinmeyen kayıtların payı, depozitoya en kısa sürede giden kanal ve koordinatör başına aşama ilerletme süresi. Son gösterge koordinatörü sıralamak için değil, hangi dilde ve hangi kanalda yığılma olduğunu görmek için kullanılıyor. Bu raporun kurulumu analitik ve veri çalışmamızın parçası; klinikler için yürüttüğümüz projelerde reklam bütçesi kararları bu tablodan çıkıyor, form sayısından değil.
Sonuç
Kaynak-randevu atıfı bir yazılım özelliği değil, bir iş akışı kararı: kaynağı otomasyon yazar, koordinatör aşamayı yazar, aşama tanımı tektir ve depozito bilgisi reklam ile analitik sistemlerine geri döner. Bu dört kural CRM'in markasından bağımsız çalışıyor. Zincirin hangi halkasının koptuğunu görmek için bugün CRM'de kaynağı "bilinmiyor" olan kayıtların payına bakmak yeterli; o pay düşmeden hiçbir kanal karşılaştırması güvenilir değil.