IVR Nedir? Tuşlu Menü ile AI Agent Farkı

IVR nedir? Interactive Voice Response kelimelerinin kısaltması olan IVR, Türkçede sesli yanıt sistemi diye bilinir. Telefonla arayan kişiyi kayıtlı anonslarla karşılar; tuşlama ya da sesli girdiyle onu doğru bölüme, bekleme sırasına veya bilgiye yönlendirir. "Randevu için 1'e basın" diye başlayan her karşılama bir IVR menüsüdür; günlük dilde buna tuşlu menü de denir.

Bir klinik için en yararlı cevap ise gelen bir hasta çağrısını baştan sona izleyince çıkar: Arayan nasıl karşılanıyor, talebini nasıl söylüyor, doğru ekibe nasıl ulaşıyor? Sesli yanıt sistemi bu yolculuğun etkileşim bölümüdür; yalnızca “randevu için bir tuşlayın” anonsundan ibaret değildir. W3C VoiceXML standardı, telefon uygulamalarında hem konuşma hem tuş girdisini kapsar.

IVR ve AI Agent farkını anlamak için yalnız sesli konuşmaya bakmak yetmez. Aşağıdaki rehber telefon altyapısını ve diyalog işlevlerini ayrı ele alıyor; klinik için menü örnekleri, ölçülebilir karşılaştırma ölçütleri ve güvenli geçiş adımları veriyor.

Teknolojileri birbirinin kesin alternatifi gibi sıralamayacağız. Asıl iş, hastanın talebinin doğru hizmete ulaştığı yolu kurmak.

IVR nedir, nasıl çalışır?#

IVR, interaktif sesli yanıt anlamında kullanılan ve telefon üzerinden otomatik etkileşim sağlayan bir uygulamadır. W3C VoiceXML standardının kapsamı; konuşulan girdinin ve DTMF adı verilen telefon tuş girdisinin tanınmasını, ses üretimini, ses kaydını ve çağrı aktarımı gibi telefon işlevlerini içerir. Yine de her IVR ürünü bu özelliklerin hepsini sunmayabilir.

Arayan bir tuşa bastığında seçim, telefon ağında tuş sinyali olarak taşınır. İnternet üzerinden taşınan çağrılarda bu sinyaller ses içinde değil ayrı olay paketleri olarak da gönderilebilir; IETF'in RFC 4733 standardı rakamların, yıldız ve kare tuşlarının bu yolla nasıl taşınacağını tanımlar. Bazı hatlarda tuşlama algılanmıyorsa operatör ile santral arasındaki bu ayarı da kontrol listesine ekleyin.

IVR nasıl çalışır? Temelde arayana sunulan seçenek ile ondan sonra gelen adım arasındaki bağa dayanır. W3C, menüleri seçenek sunan; formları ise bilgi sunup girdi toplayan yapılar olarak tanımlar. Yani bir adımda hizmet seçilebilir, başka bir adımda belirli bir bilgi istenebilir. Kullandığınız platformun bunları nasıl uyguladığını ayrıca doğrulayın.

Girdi gelmemesi ile girdinin tanımlı seçeneklere uymaması da farklı durumlardır. W3C standardındaki noinput ve nomatch olayları bu ayrımı açıkça yapar. Sessiz kalan arayana seçenekleri yeniden sunun. Yanıtı anlaşılmayan arayana ise farklı bir açıklama yapın ya da görevliye bağlanmayı önerin; her durum için ayrı adımlar hazırlayın. Standart bu olayları tanımlar; kliniğin hangi anonsu ve aktarım yolunu kullanacağını belirlemez.

Konuşma tanıyan bir menü, sırf sesli girdi kabul ettiği için üretken yapay zekâ ajanı sayılmaz. W3C konuşma girdisini zaten IVR uygulamalarının içinde ele alır. Üretken ajanın nasıl farklı çalıştığını aşağıda, yalnız ilgili ürün belgesine dayanarak anlatıyoruz.

IVR türleri#

Teklif alırken "sesli yanıt" ifadesinin hangi yapıyı kastettiğini sorun; kapsam ve kurulum işi buna göre değişir. Aşağıdaki ayrımı bu rehber kendi kullanımı için yapıyor:

• Tuşlamalı IVR: Arayan yalnız tuş takımıyla seçim yapar. Kurulumu basittir, gürültülü ortamda da çalışır; ancak seçenek ağacının dışına çıkamaz.
• Sesli komutlu IVR: "Randevu", "sonuç" gibi önceden tanımlı ifadeleri tanır. Tanımlı listenin dışındaki cümleyi anlamayabilir.
• Konuşmaya dayalı karşılama: Arayanın serbest cümlesinden talebi çıkarır, eksik bilgiyi sorar ve tanımlı işleme ya da insana yönlendirir. Telefon AI Agent'ı bu gruptadır.

Santralle farkı da kısaca şöyle: Santral çağrıyı taşıyan ve dahililere dağıtan altyapıdır. IVR ise arayanla konuşan karşılama ve menü katmanıdır, çoğu zaman da santralin bir modülü olarak çalışır.

Klinik için IVR menü örnekleri#

Aşağıdaki IVR menü örnekleri operasyonel tasarım önerisidir; hazır ürün özelliği veya mevzuatın zorunlu tuttuğu akış değildir. Menü seçeneklerini kliniğinizin gerçek ekipleri, desteklenen dilleri ve çalışma düzeniyle eşleştirin.

Hizmet odaklı karşılama#

“Kliniğimize hoş geldiniz. Yeni randevu talebi için bir, mevcut randevunuzla ilgili işlemler için iki, uluslararası hasta ekibi için üç, görevliyle görüşmek için sıfır tuşlayabilirsiniz.”

Bu örnekte her seçeneğin bir sahibi olsun: Yeni randevu talebini hangi ekip alacak, mevcut randevu işlemleri nereye aktarılacak, uluslararası hasta ekibi kapalıysa arayana ne sunulacak? Bu soruları klinik yönetimi cevaplar. Teknik bir örnek olarak Microsoft Teams belgesi, otomatik operatör seçeneklerinin personel, operatör, çağrı kuyruğu, başka otomatik operatör, sesli posta veya harici numara gibi hedeflerle eşleştirilebildiğini açıklar.

Konuşma girdili karşılama#

“Randevu talebi, mevcut randevu veya uluslararası hasta ekibi seçeneklerinden hangisiyle ilgili aradığınızı söyleyebilirsiniz.”

Bu örnek, konuşma girdisini desteklediği doğrulanan bir platform için tasarım önerisidir. W3C, konuşma girdisini standart kapsamında tanımlar; belirli bir kliniğin telefon sisteminde bu özelliğin bulunduğunu veya her ifadeyi doğru tanıyacağını kanıtlamaz.

Branşa göre örnek seçenekler#

Aşağıdaki listeler de tasarım önerisidir; seçenek adlarını hastanın kullandığı kelimelerle yazın ve en sık aranan konuyu ilk sıraya koyun.

Ana menüde dört seçeneği aşmamaya çalışın. Seçenek sayısı arttıkça arayan ilk seçenekleri unutabilir ve doğrudan görevliyi seçmeye yönelebilir.

Hangi seçeneğin ne sıklıkla seçildiğini de kaydedin. Menü sırasını ve hangi ekipte kaç kişinin çalışacağını bu veriye bakarak yeniden düzenlersiniz.

Dil seçimi ve ekip eşleştirmesi#

Uluslararası hasta kabulünde yalnızca yabancı dilde bir karşılama anonsu hazırlamakla yetinmeyin. Seçilen dilde menü metnini, girdi tanımayı ve aktarılacak ekibin dilini birlikte test edin. W3C, dil belirtmeye imkân verir ancak standarda uygunluğun çok dilliliği zorunlu kılmadığını açıkça söyler.

Bölümler arası aktarım ayrı bir konu; onu çok bölümlü klinik santral akışları yazısı anlatıyor. Burada odaklandığımız soru, menüde seçilen talebin hangi hizmete ulaştığı.

IVR’ın sınırları: tuşlama, bekleme ve kaçan çağrı#

IVR çağrıyı dağıtır; sorunun yanıtını kendiliğinden vermez. Klinikte bu sınır çoğu zaman şöyle görünür:

• Menüye sığmayan talep: "Ameliyat olacağım ama randevumu da değiştirmem gerekiyor" diyen kişi hangi seçeneği seçeceğini bilemeyebilir.
• Dil bakımı: Her dil için ayrı menü metni, kayıt ve test gerekir; uluslararası hasta kabul eden kliniklerde bu iş büyür.
• Bilgi kaydı: Klasik tuşlamalı menü, arayanın adını, talebini veya tercih ettiği günü yazıya dökmez; bilgi görevliye yeniden anlatılır.

Bir menünün çağrıyı karşılaması ile bir temsilcinin talebi ele alması aynı aşama değildir. Microsoft Teams belgesinde çağrı kuyruğu, uygun temsilci bulunana kadar arayanı bekleten yapı olarak açıklanır. Bekleyen çağrı sayısının sınırı aşması, bekleme süresinin dolması ve temsilci bulunmaması için ayrı çıkış kuralları tanımlanabilir. Bunlar Microsoft ürününün belgelenen özellikleridir ve kimseye sıfır bekleme garantisi vermez.

Beklemeyi tek bir süreyle raporlamak da yanıltıcı bir karşılaştırma oluşturabilir. NHS England’ın genel pratisyenlik telefon verisi açıklamasında, yanıt öncesi bekleme ile görüşme süresi ayrı ölçülür. Bu sınıflandırma İngiltere’deki ilgili veriye aittir; Türkiye’deki klinikler için performans sonucu sunmaz.

Çağrı bekleme süresini incelerken üç zamanı ayrı tutun: menüde geçen süre, temsilciyi beklerken geçen süre ve görüşme süresi. Böylece menünün hızlı cevap vermesiyle hastanın doğru ekibe hızlı ulaşmasını birbirine karıştırmazsınız.

“IVR’da sona eren çağrı” da otomatik olarak “kaçan çağrı” demek değildir. NHS England, bilgi edinme, başka hizmete yönlendirme veya mevcut randevuyu doğrulama gibi işlemlerin IVR aşamasında tamamlanabileceğini belirtir. Aynı açıklama, karmaşık çağrı yollarında bir çağrının birden fazla sonuca atanabildiğini veya sonuçla eşleştirilemeyebildiğini de bildirir.

Bu nedenle çağrı terk oranı, tamamlanan işlem ve başarısız aktarım için ayrı kayıt tanımları hazırlayın. Örneğin Amazon Connect belgesindeki terk oranı, sırada beklerken bağlantıyı kesen arayanların sıraya alınan temaslara oranının yüzle çarpılmasıdır; geri arama için sıraya alınan temaslar terk edilmiş sayılmaz. Bu, o ürünün ölçüm tanımıdır; her platformun aynı hesabı kullandığını varsaymayın.

Tuşlu menü ile AI Agent farkı: Asıl fark nerede?#

IVR ve AI Agent farkını “tuşlama veya konuşma” karşıtlığı üzerinden kurmak doğru değildir. W3C konuşma girdisini IVR kapsamında ele alırken, Google Dialogflow CX belgesi üretken ajanlarda playbook verilerinin büyük dil modeline sağlandığını açıklar. Bu ürünün playbook yapısı bilgi sunabilir, dış hizmetlere sorgu gönderebilir veya konuşmayı başka bir akışa devredebilir.

Asıl fark, dil modelinin görevin içinde nasıl kullanıldığıdır. Sesin yazıya çevrilmesi bu ayrımı belirlemez.

Öte yandan Google’ın belgesi, herhangi bir klinikte hazır randevu veya CRM bağlantısı bulunduğunu kanıtlamaz. Telefon AI Agent değerlendirmesinde “randevu hakkında bilgi verme”, “randevu talebi alma” ve “takvimde işlem gerçekleştirme” işlerini birbirinden ayırın. Hangi işlemi ve hangi bağlantıyı istediğinizi yazılı kapsamda tek tek belirtin.

Üretken sistemin daha hızlı olacağı da peşinen söylenemez. Google Dialogflow CX, bir görev playbook’unun başka bir görev playbook’unu çağırmasının ek model çağrısı oluşturduğunu ve uzun zincirlerin gecikmeyi artırabileceğini belirtir. Belge evrensel bir yanıt süresi vermez.

Örnek bir çağrıda, hastanın talebini söylemesinden uygun ekibe bağlanmasına kadar geçen yolu test edin. Görevliye bağlandığında hastanın her şeyi yeniden anlatması gerekip gerekmediğini de ölçün. Telefonla başlayıp WhatsApp ya da web formu gibi başka bir yolda süren iletişim için kanal geçişinde bağlamın korunması yazısı işinize yarar.

IVR, sanal santral ve telefon AI Agent karşılaştırması#

Tablo etkileşim ve telefon altyapısı katmanlarını karşılaştırır; bir klinik bu katmanların birkaçını aynı anda kullanabilir. Santral tarafında Microsoft Teams, üretken diyalog tarafında Google Dialogflow CX belgelerindeki örnekleri kullandık, sonuçları bütün ürünlere genellemeyin.

Tablodaki ölçümler bu rehberin önerisidir. “İlk anlamlı yanıt” için de bir test tanımı koyun. Örneğin karşılama anonsunu saymayın; arayanın talebine karşılık gelen ilk bilgiyi ya da yönlendirmeyi esas alabilirsiniz. Bu tanım da rehberin önerisi, kaynaklarda ortak bir standart olarak geçmez.

Ortalama beklemeyi yorumlarken hangi çağrıların hesaba girdiğini kontrol edin. Amazon Connect, ortalama kuyruk yanıt süresinde temsilciye bağlanmayan kayıtları dışarıda bırakır. Yani o ürünün ortalaması, temsilciye hiç ulaşamayan arayanların deneyimini göstermez.

Klinikte geçiş adımları#

Geçişe bütün telefon sistemini değiştirme kararıyla başlamayın; önce belirli bir hasta yolculuğunu doğrulayın. Aşağıdaki sıra bir tasarım önerisidir:

• Mevcut yolu çıkarın: Karşılama, dil seçimi, hizmet seçimi, bekleme, temsilci bağlantısı ve çağrının nasıl kapandığını kaydedin. Birkaç haftalık veriyle hangi seçeneğin ne kadar seçildiğini ve yoğun saatleri görün.
• Çağrı nedenlerini sınıflandırın: Randevu, bilgi, sonuç, şikâyet ve acil benzeri nedenleri ayırın. Konuşan bir katmana önce düşük riskli ve sık tekrarlanan nedenleri verin.
• Bilgi kaynağını hazırlayın: Çalışma saatleri, hekim listesi, hazırlık talimatları ve yanıtlanacak sık sorular tek ve onaylı bir belgede toplansın.
• Hedefleri eşleştirin: Her seçeneğin sorumlu ekibini ve mesai dışı alternatifini belirleyin. Açık olmayan hedefleri menüye eklemeyin.
• Hata yollarını test edin: Girdi gelmemesi, eşleşmeyen girdi, temsilci bulunmaması ve aktarım hatası için ayrı denemeler yapın.
• Aynı görevlerle karşılaştırın: Mevcut menüde ve önerilen yeni düzende aynı hasta taleplerini kullanın. Karşılama hızının yanında hastanın doğru hizmete ulaşıp ulaşmadığını da değerlendirin.
• Sonuç kayıtlarını kontrol edin: Aynı çağrının birden fazla sonuç altında sayılmasını ve sonucu belirsiz çağrıların rapordan kaybolmasını önleyin.
• Sınırlı başlatın: Önce mesai dışı veya yoğun saat taşması gibi dar bir kapsamla başlayın; mevcut menüyü yedek olarak tutun.

IVR'ı kaldırmak gerekmez.

Çoğu klinikte santral altyapı olarak kalır, basit karşılama menüsü korunur ve konuşan bir katman yalnız belirli saatlerde ya da belirli çağrı nedenlerinde devreye girer.

Gelen çağrıda hangi bağlantılara ve ekip takip adımlarına ihtiyaç olduğunu yapay zekâ sesli yanıt sistemi sayfasında görebilirsiniz. Mesai kapandıktan sonraki seçenekler için mesai dışı sağlık çağrılarının yönetimi ayrı bir çerçeve sunar.

Acil bildirim ve sistem hatası#

Acil durum için önerilen güvenlik tasarımı şöyle: Klinikte hekimlerce onaylanan acil ifade listesiyle eşleşen bir bildirimde akış, arayanı bulunduğu yerdeki yerel acil yardım kanalına hemen ve koşulsuz yönlendirecek şekilde tasarlansın. Buna ek olarak çağrı, doğrudan belirlenmiş insan görevliye veya klinik ekibe aktarılsın. İnsan aktarımı acil yardım yönlendirmesinin yerine geçmesin; yönlendirme aktarımın başarısına bağlanmasın.

Aktarım veya otomasyon hatasında çağrının sessizce kapanmaması için hekim onaylı acil yönlendirme mesajı ve alternatif klinik iletişim yolu yedek telefon akışında da tanımlansın. Telefon bağlantısı tamamen kesilirse otomasyonun o bağlantı üzerinden iletişimi sürdüreceği varsayılmasın; kesinti prosedürü ayrıca hazırlansın.

WHO’nun sağlıkta yapay zekâ ilkeleri, sağlık sistemleri ve tıbbi kararlar üzerindeki kontrolün insanlarda kalmasını vurgular. Kaynağın desteklediği sınır budur; acil ifade listesini, telefon aktarım düzenini veya kesinti prosedürünü tarif etmez. Bunlar kliniğin kendi klinik onayıyla belirleyeceği tasarım kararlarıdır. Otomasyon klinik kararın veya tıbbi değerlendirmenin yerine konulmamalıdır.

Kayıt ve transkript bildirimi nasıl ele alınmalı?#

Projede ses kaydı, transkript ya da görüşme özeti oluşturmayı planlıyorsanız bunları tek bir özellik gibi değerlendirmeyin. W3C ses kaydını standart kapsamında ele alır; bu kaynak transkript doğruluğunu veya bir ürünün özet özelliğini kanıtlamaz.

Görüşmenin başında, içerik toplamaya geçmeden önce, yapılacak işlemleri açıkça söyleyen bir bildirim sunun. Kayıt yapılıyorsa kaydı, transkript ya da özet hazırlanıyorsa o işlemi ayrıca belirtin.

Bildirimin desteklenen her dilde anlaşıldığını test edin.

KVKK Aydınlatma Tebliği, bilgilendirmenin sözlü veya çağrı merkezi gibi ortamlarda yapılabilmesini düzenler; veri sorumlusu, amaç, aktarım, toplama yöntemi, hukuki sebep ve ilgili kişi hakları hakkında içerik öngörür. Bu yüzden yalnız “görüşmeniz kaydedilmektedir” demek bu unsurların hepsini karşılamaz. Kurulun 2024/1361 sayılı kararında da sabit hatta görüşmelerin kaydedildiğine ilişkin bilgi verildiği tespit edilmiş; ancak bu bilgilendirmenin Kanunun 10. maddesine uygun bir aydınlatmaya yönlendirmediği gerekçesiyle aydınlatma yükümlülüğünün yerine getirilmediğine karar verilmiştir. Kaynak hukuki bilgilendirme çerçevesini verir; bildirimin otomasyonda hangi sırayla kurulacağı yukarıdaki tasarım önerisidir.

KVKK, sağlık verilerini özel nitelikli kişisel veriler arasında sayar ve işleme şartlarıyla yeterli önlemleri açıklar. Her hasta çağrısını otomatik olarak aynı veri kategorisine koymadan gerçek içerik ve veri akışını değerlendirin. Aydınlatma metni hazırlama aracı taslak çalışmasına yardımcı olabilir; araç kullanımı hukuki değerlendirme yerine geçmez.