Randevu Formu Sonrası Geri Arama Hangi Adımda Aksar?

Randevu Formu Sonrası Geri Arama sürecinde yalnızca “form geldi” ve “randevu oluştu” sayılarına bakmak, aksamanın yerini göstermez. Talep web sitesinde başarıyla alınmış olabilir; fakat CRM görevi geç oluşabilir, görev sahiplenilmeyebilir, çağrı kuyruğa girmeyebilir, hasta aranmasına rağmen anlamlı temas kurulamayabilir veya randevu kaynak forma bağlanmayabilir.

Bu nedenle kliniklerin formdan aramaya geçen süreyi tek sayaçla değil, olay zinciri olarak izlemesi gerekir. Amaç ekibi yalnızca daha hızlı aramaya yöneltmek değil; teknik gecikmeyi, operasyonel beklemeyi, iletişim sonucunu ve randevu kaydını birbirinden ayırmaktır.

Randevu Formu Sonrası Geri Arama neden tek metrikle ölçülmemeli?

Nihai randevu sayısı, sürecin hangi aşamada durduğunu açıklamaz. Büyük bir akademik sağlık sistemindeki 103.737 uzmanlık randevusu planlama girişiminin %34,8’i belgelenmiş tamamlanmış randevuyla sonuçlanırken girişimlerin %38,9’unda randevu tarihi bulunmadı. Hastaların yaklaşık %6’sına planlama amacıyla ulaşılamadı, %12’si planlamayı reddetti ve bazı randevular özgün sevk kaydıyla ilişkilendirilmeden oluşturuldu. Bu çalışma reklam formu veya sağlık turizmi talebi üzerine değil, uzmanlık sevklerinin planlanması üzerine yapılmıştır; dolayısıyla oranlar kliniklerin geri arama hedefi olarak kullanılamaz. Bulguların bu makale açısından değeri, “ulaşılamadı”, “istemedi” ve “kayıt ilişkilendirilemedi” sonuçlarının aynı hata altında toplanmaması gerektiğini göstermesidir. Araştırmayı inceleyin.

Örneğin “formdan randevuya dönüşüm düştü” ifadesi tek başına eyleme dönük değildir. Düşüş, formun CRM’e ulaşmamasından da uygun randevu bulunamamasından da kaynaklanabilir. İlk durumda entegrasyon ve bilgi teknolojileri ekibi; ikinci durumda kapasite ve randevu yönetimi ekibi devreye girmelidir.

Talep zincirindeki olayları ayrı kaydedin

Her talep için aynı olay sözlüğünün kullanılması, farklı sistem kayıtlarının karşılaştırılmasını kolaylaştırır. Asgari olay zinciri şöyle kurulabilir:

OpenTelemetry’de bir span, tek bir işlem veya iş birimini temsil eder; başlangıç ve bitiş zamanlarıyla birlikte olay, öznitelik, bağlantı ve durum bilgisi taşıyabilir. Form kabulü, CRM görevi ve çağrı kuyruğu gibi adımları ayrı işlem birimleri olarak kaydetmek bu teknik veri modeliyle uyumludur. Bu, OpenTelemetry kullanan her kliniğin otomatik olarak doğru randevu analitiğine sahip olduğu anlamına gelmez; olay sözlüğü ve iş kuralları ayrıca tanımlanmalıdır. OpenTelemetry trace modeline bakın.

Form, CRM, çağrı motoru ve randevu yazılımındaki kayıtları ortak bir talebe bağlamak için korelasyon kimliği kullanılabilir. W3C Trace Context, işlemlerin farklı yazılım bileşenleri boyunca ortak trace kimliğiyle ilişkilendirilmesini tanımlar. Standart ayrıca traceparent ve tracestate alanlarında kişiyi tanımlayan veya hassas bilgi bulunmamasını öngörür. Bu nedenle hasta adı, telefon numarası, tanı veya tedavi talebi korelasyon kimliğine yazılmamalıdır. W3C standardını inceleyin.

Dört ayrı süre metriği oluşturun

Toplam süreyi alt bileşenlere ayırmak, darboğazın sahibini belirlemeyi kolaylaştırır:

1. CRM görev oluşturma süresi: crm_görevi_oluşturuldu − form_alındı
2. Görev sahiplenme süresi: görev_sahiplenildi − crm_görevi_oluşturuldu
3. İlk geri arama süresi: ilk_arama_başladı − form_alındı
4. Temastan randevuya geçen süre: randevu_booked − anlamlı_temas_kuruldu

İlk metrik entegrasyon gecikmesini, ikinci metrik iş kuyruğunu, üçüncü metrik hastaya yansıyan toplam beklemeyi, dördüncü metrik ise iletişim sonrasındaki planlama akışını görünür kılar. Her süre için yalnızca ortalama yerine medyan ile yüksek gecikme diliminin birlikte raporlanması, az sayıdaki uzun beklemenin görünmez kalmasını önlemeye yardımcı olur.

Zaman ölçümünden önce sistem saatleri kontrol edilmelidir. NIST’in genel bilgisayar güvenliği günlük yönetimi rehberi, farklı cihazların saatleri tutarsız olduğunda günlüklerin olay sırasını yanlış gösterebileceğini belirtir. Bu teknik uyarı sağlık turizmi performansına özgü değildir; ancak form, CRM ve telefon sistemleri eşzamanlı değilse hesaplanan sürelerin hatalı, hatta negatif çıkabileceğini açıklar. NIST rehberini inceleyin.

Görev oluştu, fakat gerçekten işlendi mi?

“CRM görevi oluşturuldu” kaydı, görevin ekip tarafından kabul edildiğini veya tamamlandığını kanıtlamaz. HL7 FHIR görev durumları requested, received, accepted, rejected, ready, in-progress, on-hold, failed ve completed gibi aşamaları birbirinden ayırır. Bu kodlar her CRM’in zorunlu özelliği değildir; görev yaşam döngüsünü tasarlarken kullanılabilecek standart bir referans sözlüğüdür. FHIR görev durumlarına bakın.

Klinik, kendi sistemindeki durumları en azından “oluşturuldu”, “sahiplenildi”, “işleniyor”, “beklemede”, “başarısız” ve “tamamlandı” biçiminde eşleyebilir. Böylece otomatik geri arama hataları ile personel kuyruğundaki bekleme ayrılır. Teknik hata kodu da mümkün olduğunca aşamayı göstermelidir: CRM yazma hatası, çağrı kuyruğuna aktarma hatası ve arama başlatma hatası aynı başlıkta birleştirilmemelidir.

Bu ayrıştırma için sistemler arası veri akışını ayrıca gözden geçirmek isteyen ekipler HBYS ve CRM Entegrasyon Rehberi üzerinden entegrasyon sınırlarını değerlendirebilir.

“Randevu açıldı” ile booked randevuyu ayırın

Randevu yazılımında bir kayıt bulunması, randevunun kesinleştiği anlamına gelmeyebilir. HL7 FHIR randevu durumları proposed, pending, booked, cancelled, waitlist ve entered-in-error gibi farklı durumlar tanımlar. “Randevu booked oranı” hesaplanırken yalnızca kesinleştirilmiş kayıtlar sayılmalı; önerilen, bekleyen, bekleme listesindeki ve hatalı kayıtlar ayrı tutulmalıdır. Buradaki FHIR sözlüğü de kliniklerin kullandığı her yazılımın yetenek iddiası değil, durum eşlemesi için referanstır. FHIR randevu durumlarını inceleyin.

Temel geçiş oranları şu şekilde izlenebilir:

• Form → CRM görevi
• CRM görevi → sahiplenilen görev
• Sahiplenilen görev → ilk arama
• İlk arama → anlamlı temas
• Anlamlı temas → booked randevu
• Form → booked randevu

Paydalar açıkça belirtilmelidir. Örneğin booked randevu sayısını tüm formlara bölmek genel dönüşümü; yalnızca anlamlı temas kurulan taleplere bölmek ise temas sonrası planlama sonucunu gösterir. İki oran farklı operasyon sorularını yanıtlar.

Çağrı sonucunu ve dil segmentini birlikte inceleyin

“Arandı” sonucu yeterli değildir. İlk arama; yanıt yok, yanlış numara, iletişim kuruldu, daha sonra aranmak istiyor, hizmeti istemiyor, uygun slot yok veya booked gibi ayrı sonuçlara bağlanabilir. “Anlamlı temas” tanımı da ekipler arasında değişmemelidir. Örneğin yalnızca telefonun çalması değil, karşılıklı iletişim kurulması ve sonraki adımın kaydedilmesi şartı kullanılabilir.

Çok dilli hasta geri arama operasyonlarında dil ayrı bir analiz boyutu olmalıdır. EHR tabanlı otomatik erken randevu tekliflerini inceleyen bir çalışmada 60.660 teklifin %11’i kabul edildi ve %8,9’u tamamlanmış ziyarete dönüştü; kabul olasılığı İngilizce konuşanlara kıyasla Çince konuşanlarda ve diğer dil gruplarında daha düşüktü. Bu araştırma otomatik telefon geri aramasını veya Türkiye’deki sağlık turizmini incelememiştir. Bu yüzden oranlar hedef olarak taşınamaz; yalnızca otomatik randevu akışlarının dil segmentinde ayrı ölçülmesi gerektiğine kanıt sağlar. Çalışmanın kapsamını inceleyin.

Raporlarda ülke ve dilin yanında vardiya, saat dilimi, reklam kaynağı, hizmet türü ve uygun slot bulunup bulunmadığı filtrelenebilir. Çağrı kapsaması için hedef belirleyecek aracı kuruluşlar ayrıca Sağlık Turizmi Aracı Kuruluş Çağrı Merkezi SLA Rehberi içindeki operasyon çerçevesinden yararlanabilir. Mesai dışı birikimi ayrı ele almak için Hafta Sonu Sağlık Turizmi Leadleri Nasıl Sıralanır? yazısı kullanılabilir.

KVKK açısından ölçüm veri setini sınırlayın

Randevu olaylarının yalnızca sıradan iletişim verisi içerdiği varsayılmamalıdır. KVKK’nın özel nitelikli kişisel veriler rehberi, kişinin randevu aldığı hastane, klinik veya birimin bazı durumlarda sağlık durumuna ilişkin çıkarım sağlayabileceğini; psikiyatri polikliniği randevusunu buna örnek olarak verir. Dolayısıyla hizmet türü, klinik adı ve formdaki serbest metin alanları ölçüm tasarımında ayrıca değerlendirilmelidir. KVKK rehberini inceleyin.

Operasyon panelinde doğrudan kimlik bilgisi göstermek yerine rastgele talep kimliği, olay zamanı, kanal, dil, görev durumu, çağrı sonucu ve randevu durumu gibi ölçüm için gerekli alanlarla çalışmak daha kontrollü bir tasarım sağlar. Erişim yetkileri ile saklama yaklaşımı kurumun veri işleme süreçlerine göre belirlenmelidir. Bu makale KVKK uyumluluğu garantisi veya hukuki danışmanlık sunmaz.

Uygulanabilir kontrol listesi

• Her olayın sahibini ve kesin tanımını yazın.
• Tekrarlanan formları ayrı işaretleyin; sessizce silmeyin.
• Sistem saatlerini ve zaman dilimlerini doğrulayın.
• Ortak korelasyon kimliğinde kişisel veya hassas veri tutmayın.
• Teknik hata, yanıtsızlık, hasta tercihi ve kapasite sorununu ayırın.
• Görev oluşturma ile görev sahiplenmeyi aynı kabul etmeyin.
• Yalnızca kesinleşmiş randevuları booked olarak sayın.
• Sonuçları dil, kanal, vardiya ve hizmet türü kırılımında inceleyin.
• Her metriğin payını, paydasını ve hariç tutma kuralını dokümante edin.

Bu ölçüm düzeni klinik karar verme mekanizması değildir ve sağlık profesyonelinin değerlendirmesinin yerini alamaz. İşlevi, talebin formdan kesinleşmiş randevuya kadar hangi teknik veya operasyonel adımda durduğunu görünür kılmaktır.

Sık Sorulan Sorular

Formdan aramaya geçen süre nerede başlamalıdır?

Başlangıç, kullanıcının düğmeye bastığı tahmini an yerine formun sunucu tarafından başarıyla kabul edildiğini gösteren form_alındı olayı olmalıdır. Bitiş ise çağrı kuyruğuna giriş değil, ilk gerçek arama girişiminin başladığı zaman olarak tanımlanabilir.

CRM görev oluşturma süresi neden ayrıca ölçülür?

Bu süre form sistemi ile CRM arasındaki aktarımı gösterir. Görev hızlı oluştuğu hâlde arama gecikiyorsa sorun entegrasyondan sonraki sahiplenme veya çağrı kuyruğu aşamasında aranmalıdır.

Anlamlı temas oranı nasıl tanımlanır?

Klinik yazılı bir operasyon tanımı belirlemelidir. Karşılıklı iletişim kurulması ve görüşme sonucunun kaydedilmesi, yalnızca telefonun çalması veya sesli mesaja düşmesinden ayrı tutulabilir.

Randevu kaydı bulunan her talep booked sayılır mı?

Hayır. Önerilen, bekleyen, iptal edilmiş, bekleme listesindeki veya hatalı kayıtlar kesinleşmiş booked randevudan ayrılmalıdır. FHIR randevu durumları bu ayrım için standart bir referans sözlüğü sunar. Durum değerlerini inceleyin.

Hasta bilgisi korelasyon kimliğine yazılabilir mi?

W3C Trace Context, trace alanlarında kişiyi tanımlayan veya hassas bilgi bulunmamasını öngörür. Hasta adı, telefon numarası, tanı veya tedavi talebi yerine kişisel anlam taşımayan bir kimlik kullanılmalıdır. W3C gizlilik hükümlerine bakın.

Form kaydının CRM tarafına nasıl aktarıldığı [CRM entegrasyonu](/kurulum-ucretleri/crm) sayfasında anlatılıyor.