Sağlık Turizminde WhatsApp Lead Yönetimi ve Yapay Zekâ Otomasyonu

Sağlık turizmi sektöründe en büyük maliyet kalemi reklamlarla hasta adayı (lead) çekmektir. Gelen taleplere verilen geç dönüşler ise asıl kayıptır. Bir hasta adayı WhatsApp üzerinden kliniğe ulaştığında geciken yanıt, rakip kliniklere yönelme ve takibin kopması riskini artırır. Ekiplerin manuel olarak her mesaja yetişmesi, hastanın diline göre doğru satış temsilcisini ataması ve bilgileri CRM sistemine girmesi ciddi bir zaman kaybıdır. Bu yazıda, bu sürecin otonom olarak nasıl çözüleceğini ele alacağız.

Giriş ve Problem Analizi

Reklamlarla elde edilen hasta adaylarının takibi, hızı ve doğruluğu kliniğin büyüme oranını doğrudan etkiler. Manuel yönetim süreçlerinde en yetenekli satış ekibi dahi geceleri veya yoğun saatlerde gelen mesajları kaçırabilir. WhatsApp entegrasyonu ve yapay zekâ mimarisi, bu süreci 7/24 çalışır ve mesai dışı talepleri de sıraya alır; hata durumlarını insan denetimine ve yeniden denemeye yönlendirir.

Yapay Zekâ ve CRM Entegrasyon Mimarisi

Gelen her WhatsApp mesajı, bir webhook aracılığıyla otomasyon motorumuza aktarılır. Sistemimiz süreci şu adımlarla yönetir:

• Dil Analizi: Gelen mesajın dilini analiz eder (İngilizce, Almanca, Arapça vb.).
• Niyet Tespiti: Hastanın hangi tedaviyle (Saç ekimi, diş tedavisi, obezite cerrahisi) ilgilendiğini belirler.
• Otomatik Temsilci Atama: Dil ve uzmanlık eşleşmesine göre satış temsilcisi otonom atanır.
• CRM (Zoho) Kartı: Hasta bilgileri, CRM sisteminde bir hasta kartı olarak saniyeler içinde oluşturulur.

Manuel vs. Otonom Süreç Karşılaştırması

Aşağıdaki tablo, entegrasyon öncesi ve sonrası performans metriklerini göstermektedir:

Uçtan Uca Çözümler ve İç Bağlantılar

Bu yapının kurulması, klinikler için sadece bir WhatsApp entegrasyonu değildir; tüm pazarlama ve satış bütçesini verimli kullanma adımıdır. Konu hakkında daha detaylı bilgi ve amiral gemisi dönüşüm hikayelerimizi incelemek için Sağlık Turizminde Yapay Zekâ ve Klinik Otomasyonu sayfamızı ziyaret edebilirsiniz.

Çalışılmış Örnek: Bir Mesajın Webhook'tan CRM Kaydına Yolculuğu

Mimarinin ne yaptığını en iyi tek bir mesajın izlediği yol anlatır. Aşağıdaki akış temsilî bir kurgudur; gerçek bir hasta kaydı veya müşteri verisi içermez. Amacı, hangi adımda hangi alanın üretildiğini ve sistemin nerede durduğunu göstermektir.

Girdi. Kliniğin numarasına İngilizce bir mesaj gelir: Hi, I had a consultation last month, can I get a date for September? Bu mesaj hem yeni bir talep hem de mevcut bir kayda ait olabilir - mimarinin ilk işi bunu ayırt etmektir.

1. Webhook alımı: Mesaj, otomasyon motoruna bir webhook yükü olarak düşer. Yükten üç alan hemen okunur: gönderen numarası, mesaj metni ve zaman damgası. Zaman damgası sonraki ölçümlerin temelidir; hesaplanmaz, kaynağından alınır.
2. Tekillik kontrolü: Gönderen numarası CRM'de aranır. Kayıt varsa yeni kart açılmaz, mevcut karta bir etkileşim eklenir. Tekillik anahtarı numaradır; ad-soyad değildir, çünkü aynı isim farklı kişilere, aynı kişi farklı yazımlara sahip olabilir.
3. Dil ve niyet çıkarımı: Model mesajı okur ve iki yapılandırılmış alan üretir: dil kodu ve niyet etiketi (yeni talep, randevu talebi, bilgi talebi, şikâyet). Serbest metin buradan sonra kayda ham hâliyle de saklanır - model yanlış etiketlerse insanın geri dönebileceği bir kaynak kalmalıdır.
4. Atama: Dil ve niyet eşleşmesine göre sorumlu danışman atanır. Eşleşme bulunamazsa kayıt kaybolmaz; genel kuyruğa düşer ve bir uyarı üretilir.
5. Taslak hazırlama: Sistem yanıtı otonom göndermez. Danışmanın ekranına bir taslak yazar; fiyat, tedavi kararı ve tıbbi değerlendirme içeren hiçbir ifade taslağa girmez.
6. Kapanış: Danışman taslağı onaylayıp gönderdiğinde, gönderim zamanı da kayda yazılır. İlk yanıt süresi bu iki damganın farkıdır.

Çıktı. Süreç sonunda CRM'de mükerrer olmayan tek bir kart, doldurulmuş dört yapılandırılmış alan, ham mesaj metni ve iki zaman damgası bulunur. Bu yapı olmadan yapılan her raporlama tahmindir; bu yapı kurulduktan sonra rapor bir sorgudan ibarettir.

Şablon Yönetimi ve 24 Saatlik Pencere

WhatsApp üzerinde kurulan her otomasyonun tasarımını belirleyen kural, kullanıcının mesajıyla açılan 24 saatlik müşteri hizmetleri penceresidir: pencere kapandıktan sonra serbest metin gönderilemez, yalnızca önceden onaylanmış şablon mesajlar iletilebilir. Bu kuralı hesaba katmayan takip akışları gönderdiğini sanıp sessizce başarısız olur.

Maliyet tarafı da aynı belgeden okunur. Meta, 1 Temmuz 2025 itibarıyla mesaj başına ücretlendirmeye geçtiğini ve şablon olmayan mesajların ücretsiz olduğunu belgeler; açık pencere içinde gönderilen utility şablonları da ücretsizdir, marketing kategorisindeki şablonlar ise her durumda ücretlendirilir. Reklamdan başlayan sohbetlerde 72 saatlik ücretsiz giriş noktası penceresi açılır.

Bu üç kuralın mimariye tercümesi şudur: takip akışı hastanın son mesajı üzerinden sayılan pencerenin içinde tasarlanır; pencere dışına taşan her adım için önceden onaylanmış bir utility şablonu hazır bulundurulur ve şablon içeriği tanıtım diline kaymadan işlemsel kalır. Pazarlama içerikli şablonları takip akışına karıştırmak hem maliyeti hem mevzuat riskini birlikte yükseltir.

Veri ve Ölçüm: Entegrasyonun Sağlığı Nereden Okunur?

Bir entegrasyonun sağlıklı çalıştığını gösteren şey mesajların gitmesi değil, hataların nereye gittiğidir. Otomasyon platformunun yeniden deneme davranışını bilmeden kurulan akış, geçici bir kesintide veri kaybeder.

Make tarafında bu davranış belgelidir: bağlantı hataları ve modül zaman aşımlarında üstel geri çekilme ile en fazla sekiz deneme yapılır ve denemeler arası gecikme, senaryoda tamamlanmamış çalıştırmaların saklanıp saklanmadığına göre değişir. Tamamlanmamış çalıştırmalar kapalıyken gecikmeler ilk denemede bir dakikadan başlayıp sekizinci denemede yirmi dört saate kadar uzar. Kritik ayrıntı şudur: tamamlanmamış çalıştırmaları saklama seçeneği varsayılan olarak kapalıdır ve senaryo ayarlarından açılması gerekir. Yani hiçbir ayar yapılmamış bir kurulumda, sekiz denemeden sonra düşen bir mesaj hiçbir kuyrukta beklemez.

Ölçülmesi gereken dört sayı bunun üzerine kurulur: ilk yanıt süresinin medyanı ve doksanıncı yüzdeliği, tekillik ihlali sayısı (aynı numaradan açılan mükerrer kart), atanamayan kayıt oranı ve tamamlanmamış çalıştırma sayısı. Dördü de tahmin değil, sistemin kendi kayıtlarından okunan değerlerdir. Otomasyon öncesinde iki hafta ölçüp sonrasında aynı yöntemle yeniden ölçmek, iyileşmeyi iddia olmaktan çıkarıp veri hâline getirir.

Hata Desenleri: Mükerrer Kayıt, Kayıp Mesaj, Yanlış Atama

Klinik WhatsApp entegrasyonlarında tekrar eden dört hata vardır ve dördü de kurulum aşamasında kapatılabilir.

Tekillik anahtarını yanlış seçmek. Kaydı ad-soyad veya e-posta üzerinden tekilleştiren sistemler, aynı hastanın ikinci mesajında yeni kart açar. Sonuç, aynı kişiye iki danışmanın ayrı ayrı yazması ve raporlamanın şişmesidir. Doğru anahtar, kanalın kendi kimliğidir - WhatsApp akışında telefon numarası.

Hata kuyruğu kurmamak. Yeniden deneme hakkı tükendiğinde işin nereye düşeceği tanımlı değilse mesaj kaybolur. Her akışta başarısız işlerin gideceği bir kuyruk ve bu kuyruğu izleyen bir uyarı bulunmalıdır; tamamlanmamış çalıştırmaların saklanması bunun platform tarafındaki karşılığıdır.

Modelin çıktısını doğrulamadan yazmak. Dil ve niyet etiketi model çıktısıdır ve yanlış olabilir. Etiketi doğrudan CRM'in zorunlu alanına yazmak, hatalı veriyi kalıcılaştırır. Doğru tasarım, ham metni de saklamak ve düşük güvenli çıkarımları insan doğrulamasına düşürmektir.

Otonomi sınırını belirsiz bırakmak. Fiyat, tedavi kararı ve tıbbi değerlendirme otonom sistemin yetki alanı dışındadır; bu sınır kodda değil tasarımda çizilir. Sınırın mevzuat tarafındaki karşılığı ve klinik lead yönetiminin bütünü sağlık turizminde yapay zekâ ile lead yönetimi yazısında, CRM tarafındaki genel entegrasyon disiplini ise CRM ve kurumsal otomasyon entegrasyonu rehberinde ele alınmıştır.

Kurulumun Sırası: Hangi Adım Neyi Açar?

Bu mimari tek seferde kurulmaz; her adım bir sonrakinin ön koşuludur ve sıra bozulduğunda sonraki adım ölçülemez hâle gelir. Aşağıdaki sıra, klinik büyüklüğünden bağımsız olarak aynı kalır.

1. Kanal ve numara düzeni: Önce hangi numaranın hangi klinik birimine ait olduğu netleşir. Tek numaradan yürüyen bir operasyonda atama kuralları da tek merkezden yazılır; birden fazla numara varsa her biri ayrı bir giriş kapısıdır ve raporlama baştan buna göre kurulur.
2. Kayıt şeması: CRM tarafında hangi alanların zorunlu olduğu, tekillik anahtarının ne olacağı ve serbest metnin nerede saklanacağı kararlaştırılır. Bu karar verilmeden yazılan hiçbir otomasyon taşınabilir değildir.
3. Webhook ve ham kayıt: Gelen mesaj önce ham hâliyle kaydedilir, sonra işlenir. Ham kayıt olmadan model çıkarımı yanlış olduğunda geri dönülecek bir kaynak kalmaz.
4. Çıkarım ve atama: Dil ve niyet etiketleri üretilir, sorumlu atanır, eşleşmeyen kayıtlar genel kuyruğa düşer. Bu adım ancak önceki üçü tamamlandıktan sonra anlamlıdır.
5. Takip ve şablonlar: Pencere içi takip akışı ve pencere dışı için onaylı şablonlar tanımlanır; her şablon işlemsel dilde yazılır.
6. Ölçüm ve uyarı: En son adım, dört temel sayının raporlanması ve hata kuyruğunun izlenmesidir. Ölçüm en sona bırakılır ama en baştan tasarlanır - zaman damgaları ilk adımdan itibaren kaydedilmezse geriye dönük ölçüm mümkün olmaz.