Sağlık turizminde lead yönetimi: Manuel dağıtımdan gerçek zamanlı satış sistemine nasıl geçtik?

💡 Özet (TL;DR):

• İş problemi: Vanity’de yılda yaklaşık 100.000 lead’i yöneten Google Sheets tabanlı dağıtım, farklı diller, ülkeler, vardiyalar ve izinler arasında sürekli manuel müdahale gerektiriyordu.
• Karar: CRM’i değiştirmek yerine, operasyon kurallarını gerçek zamanlı uygulayan ve CRM ile reklam verisini birbirine bağlayan Agent Yönetim Sistemi’ni (AYS) kurduk.
• Sonuç: Yönlendirme süresi 5–15 dakikadan gerçek zamanlı atamaya indi. Doğruluk %99’u aştı; ekip liderleri ve yöneticiler kapasiteyi, performansı ve dönüşüm akışını aynı sistemden izlemeye başladı.

Bu vaka çalışmasının ele aldığı dönemde Vanity Cosmetic Surgery Hospital, yılda yaklaşık 100.000 lead alan, on binlerce ameliyatın gerçekleştirildiği ve 200’ü aşkın kişinin çalıştığı bir sağlık kuruluşuydu. Hasta adaylarının büyük bölümü yurt dışından geliyordu. Talepler farklı ülkelerden, dillerden ve saat dilimlerinden gün boyunca ulaşıyordu.

Bu ölçekte sağlık turizmi lead yönetimi, bir formun CRM’e kaydedilmesinden ibaret değil. Her talebin o anda doğru dili konuşan, vardiyada olan, izinli olmayan ve kapasitesi bulunan satış temsilcisine yönlendirilmesi gerekiyor. Yanlış veya geciken atama, ekibin zamanını harcıyor ve hasta adayıyla kurulacak ilk teması geciktiriyor.

Ben Vanity’e Aralık 2022’de Bilgi Teknolojilerinden Sorumlu Genel Müdür Yardımcısı, yani CTO olarak katıldım. Önümdeki problem yeni bir yazılım geliştirmekten önce bir işletim sistemi problemiydi: Kurallar biliniyordu, fakat kararlar hâlâ insanlar tarafından Google Sheets üzerinde uygulanıyordu.

Bu yazı, Aralık 2022’de başlayan çalışma dönemindeki manuel dağıtımı nasıl otomatikleştirdiğimizden çok, tekrar eden bir operasyon kararını nasıl görünür, ölçülebilir ve yönetilebilir hale getirdiğimizi anlatıyor. Şirketin veya sistemin bugünkü durumunu değil, o dönemdeki çalışmayı kayda geçiriyor.

Başlangıç noktası: Kurallar vardı, sistem yoktu

Vanity’e katıldığımda farklı ülkelerden ve dillerden gelen taleplerin doğru satış temsilcilerine yönlendirilmesi, uzun süredir konuşulan fakat henüz çözülemeyen bir ihtiyaçtı. Basit bir kapsam dokümanı vardı. Çalışan bir sistem yoktu.

Her dil için ayrı formlar açılmıştı. Talepler Google Sheets’e aktarılıyor, ardından ilgili temsilcilere manuel olarak dağıtılıyordu. Bir çalışan izin kullandığında, vardiya değiştirdiğinde, işten ayrıldığında veya ekibe yeni biri katıldığında tabloların da güncellenmesi gerekiyordu. Hafta sonları ve bayramlar yeni istisnalar yaratıyordu.

Dağıtımın kendisi 5–15 dakika sürebiliyordu. Daha önemli sorun ise kararın neden o temsilciye verildiğini tutarlı biçimde izleyememekti. Ülke, dil, kaynak, öncelik, kapasite ve önceki sahiplik gibi kurallar vardı. Ancak bu kurallar bir karar sistemi içinde değil, insanların dikkatinde yaşıyordu.

Yeni bir CRM değil, karar katmanı gerekiyordu

İlk bakışta bu, yeni bir CRM satın alma veya mevcut CRM’e birkaç kural ekleme problemi gibi görünebilir. Bizim başlangıç koşulumuz farklıydı. CRM zaten satış kaydını tutuyordu; Google Ads de talebin hangi kampanyadan geldiğini gösteriyordu. Eksik olan, atama öncesinde operasyon koşullarını değerlendiren ve verilen kararı diğer sistemlere taşıyan katmandı.

Sıradan bir sıra tabanlı dağıtım yeterli değildi. Sistem aynı anda şunları değerlendirmeliydi:

• Talebin bağlı olduğu ülke, dil, kaynak ve pipeline
• Temsilcinin vardiyası, izin durumu ve azami lead kapasitesi
• Temsilciler arasındaki dağıtım oranı ve öncelik
• Daha önce görüşülmüş bir lead’in mevcut sahibinin korunması
• Atama sonrasında CRM aşamalarının ve zorunlu alanların durumu

Bu nedenle CRM’i değiştirmek yerine çevresine dar kapsamlı bir karar katmanı kurduk. Agent Yönetim Sistemi, yani AYS, sağlık turizmi CRM’inin tamamını yeniden geliştirmeye çalışmıyordu. Tek bir pahalı ve sık tekrarlanan kararı güvenilir biçimde çalıştırıyordu: Bu talep şimdi kime gitmeli?

Bu ayrım, özel yazılım kararında belirleyiciydi. Kurallar işletim modelinin kenarında duran ayarlar olmaktan çıkıp işin kendisini tarif etmeye başladığında, o kuralları açık ve ölçülebilir hale getiren bir sistem anlamlı olabiliyor.

İlk sürümde neyi çözmeyi seçtik?

İlk sürümün görevi basitti: Tanımlanmış kuralları okuyup gelen talebi doğru satış temsilcisine otomatik olarak atamak.

Sistemi baştan modüler kurduk. Temsilciler pipeline’lara atanabiliyor; çalışma saatleri, izinler, dağıtım oranları, öncelikler ve lead sınırları yönetilebiliyordu. Aynı kişi daha önce belirli bir temsilciyle görüşmüşse sahiplik korunuyordu.

Bu ilk sürüm bize iki şey kazandırdı. Dağıtım kararını insan hafızasından çıkardı ve kural değişikliklerini tek bir yerde görünür hale getirdi. Böylece yeni özelliklere geçmeden önce temel akışın güvenilir çalışıp çalışmadığını görebildik.

Dağıtım aracından yönetim sistemine

Temel yönlendirme güvenilir hale geldikten sonra AYS’nin rolü değişti. Sistem artık talebi dağıtmakla kalmıyor, satış akışında ne olduğunu da görünür kılıyordu.

Zaman içinde şu bileşenleri ekledik:

• Ülke, temsilci, kanal, kaynak ve kampanya bazlı performans panoları
• Google Ads ve CRM entegrasyonu üzerinden uçtan uca dönüşüm takibi
• Sanal Satış Danışmanlarının sisteme ve raporlamaya bağlanması
• CRM aşamalarının büyük bölümünün otomatik güncellenmesi
• Eksik zorunlu CRM alanları için uyarı ve bildirimler
• Ekip liderlerinin yalnızca kendi ekiplerini izleyebildiği panolar
• Yöneticilere her sabah gönderilen günlük özet raporlar

Böylece aynı veri farklı yönetim katmanlarında farklı kararları desteklemeye başladı. Bir ekip lideri kapasite ve temsilci performansını görebiliyordu. Satış ve pazarlama yönetimi, kampanyadan CRM aşamalarına uzanan akışı izleyebiliyordu. Üst yönetim ise günlük özetlerle nerede müdahale gerektiğini daha erken fark edebiliyordu.

Teknolojinin iş sonucu burada ortaya çıktı. AYS, yeni bir kayıt ekranı olmaktan çok satış operasyonunun ortak karar altyapısına dönüştü.

Sonuçlar ve kanıtın sınırı

Paylaşabildiğimiz en net önce-sonra ölçümü dağıtım performansında:

• Yönlendirme süresi 5–15 dakikadan gerçek zamanlı atamaya indi.
• Yönlendirme doğruluğu %99’un üzerine çıktı; hatalar sıfıra yaklaştı.
• Düzenli manuel dağıtım ve kontrol ihtiyacı büyük ölçüde ortadan kalktı.
• Temsilciler tablo yönetmek yerine hasta adaylarıyla iletişime daha fazla odaklanabildi.
• Ekip liderleri ve yöneticiler performansı, kapasiteyi ve dönüşüm akışını anlık izleyebilir hale geldi.

Dönüşüm oranı, maliyet ve ekip verimliliğinde de iyileşmeler gözlemledik. Ancak bu yazıda bu etkiler için ayrıntılı önce-sonra rakamları paylaşmıyorum. Bu nedenle onları tek başına AYS’ye bağlanan kesin bir nedensellik iddiası olarak değil, sistemin daha geniş operasyonel etkisi olarak değerlendiriyorum.

Benim rolüm neydi?

Bu projede işletme probleminin tanımlanmasından ürün kapsamına, yazılım mimarisinden geliştirme sürecine ve ekipler arası koordinasyona kadar her aşamada çalıştım.

Benim için projenin önemli tarafı, çalışan bir algoritma geliştirmekten çok daha fazlasıydı. Aynı sistemin hem teknik olarak güvenilir çalışmasından hem de satış operasyonunda gerçekten kullanılmasından sorumluydum. AYS’nin geliştirilmesi boyunca bu iki sorumluluk birbirinden ayrılmadı.

Bu vakadan çıkarılabilecek karar ilkesi

Sağlık turizminde lead yönetimi için ilk soru “Hangi CRM’i almalıyız?” olmamalı. Önce tekrar eden kararın kendisini incelemek gerekiyor:

• Atama kararını hangi bilgiler değiştiriyor?
• Bu bilgiler güncel ve erişilebilir mi?
• İstisna oluştuğunda kararın sahibi kim?
• Gecikme ve hata bugün nasıl ölçülüyor?
• Mevcut CRM bu kararı gerçekten uyguluyor mu, yoksa yalnızca sonucunu mu kaydediyor?

Bizim vakamızda sorun, teknoloji eksikliği kadar kararın insanlar arasında dağılmış olmasıydı. AYS’nin kalıcı değeri, bu kararı otomatikleştirmesinden önce onu açık, yönetilebilir ve ölçülebilir hale getirmesinden geldi.

Bu tür sistemlerde sonraki değerlendirme alanı, raporlama katmanında AI ve makine öğrenmesinden yararlanmak olabilir. Fakat buradaki eşik de aynı: Üretilen yorum veya tahmin hangi yönetim kararını iyileştirecek ve bunu hangi sonuçta göreceğiz? Bu sorunun cevabı yoksa daha fazla teknoloji, daha iyi bir işletim sistemi anlamına gelmiyor.