हेल्थकेयर के लिए ElevenAgents: इनबाउंड अपॉइंटमेंट शेड्यूलिंग एजेंट बनाएं

फ़ोन अब भी स्वास्थ्य सेवाओं का मुख्य प्रवेश द्वार है, और उस पर भारी दबाव है। Mayo Clinic शोध और Epic केस स्टडी के डेटा, दोनों बताते हैं कि करीब 30% अपॉइंटमेंट शेड्यूलिंग सामान्य व्यावसायिक घंटों के बाहर होती है। जो कॉल वॉइसमेल पर चली जाती हैं, वे अक्सर चुपचाप छूट जाने वाले अपॉइंटमेंट बन जाती हैं, जबकि उन्हें संभालने वाला फ्रंट-डेस्क स्टाफ पहले से ही बहुत दबाव में है और तेजी से बदल रहा है। वॉइस एजेंट्स डेमो के दौर से आगे बढ़ चुके हैं और क्लीनिकों को यह कमी भरने में मदद करते हैं। शेड्यूलिंग सबसे आम शुरुआती उपयोग है: इसमें कॉल की मात्रा अधिक, काम दोहराव वाला और अनुमानित होता है, और फ्रंट डेस्क के काम का बड़ा हिस्सा ऐसा होता है जिसमें क्लिनिकल निर्णय की ज़रूरत नहीं पड़ती।

स्वास्थ्य सेवाओं में अपॉइंटमेंट शेड्यूलिंग का मानक भी ऊंचा होता है। गलत स्लॉट या आने का कारण गलत सुन लेना केवल खराब अनुभव नहीं है — यह सुरक्षा और अनुपालन की घटना है। फ्रंट-डेस्क शेड्यूलिंग एजेंट को अच्छी आवाज़ से कहीं अधिक चाहिए: भरोसेमंद पहचान सत्यापन, सख्त गार्डरेल्स, किसी व्यक्ति तक साफ़ एस्केलेशन पथ, संरक्षित स्वास्थ्य जानकारी संभालने के लिए अनुपालन व्यवस्था, और वास्तविक शेड्यूलिंग सिस्टम में बुकिंग पूरी करने, बदलने या रद्द करने की क्षमता।

इस गाइड में हम ElevenAgents के साथ ठीक यही बनाएंगे: टेलीफोनी से एक्सेस किया जा सकने वाला, एक सैंपल EHR से जुड़ा एजेंट, जो अपॉइंटमेंट को शुरू से अंत तक बुक, रीशेड्यूल और रद्द करता है, और ज़रूरत पड़ने पर एस्केलेट करता है। आपको इसे तय सीमाओं में रखने के लिए वर्कफ़्लो, गार्डरेल्स, टेस्टिंग और विश्लेषण मिलेगा — रेगुलेटेड हेल्थकेयर के लिए बने इन्फ्रास्ट्रक्चर पर डिप्लॉय किया गया।

यहां उस एजेंट का डेमो है, जो लाइव कॉल को शुरू से अंत तक संभालता है:

ज़रूरी शर्तें

शुरू करने के लिए, आपको इन चीज़ों की ज़रूरत होगी:

• एक ElevenLabs अकाउंट, जिसमें ElevenAgents प्लेटफ़ॉर्म और हमारी वॉइसेज़ का एक्सेस हो।
• एक Twilio अकाउंट और नंबर।
• Twilio Verify का एक्सेस।
• एक सैंडबॉक्स या डेवलपर EHR एनवायरनमेंट। इस गाइड में, हम HAPI FHIR का इस्तेमाल करेंगे, जो HL7 FHIR फ़ॉर्मैट का ओपन-सोर्स रेफरेंस इम्प्लीमेंटेशन है, ताकि सिंथेटिक मरीज रिकॉर्ड के आधार पर सत्यापन किया जा सके।
• आपके कार्यालय का कैलेंडर एप्लिकेशन। इस गाइड में, हम ElevenLabs के नेटिव इंटीग्रेशन का इस्तेमाल Cal.com के साथ करते हैं। 

वैकल्पिक

अगर आपके पास सैंडबॉक्स डेटा का एक्सेस नहीं है या आप डेमो के लिए साथ-साथ कर रहे हैं, तो हम HAPI FHIR R4 सैंडबॉक्स सर्वर का इस्तेमाल करेंगे और उसमें एक मॉक मरीज रिकॉर्ड जोड़ेंगे, जिसे आप सत्यापन चरण में इस्तेमाल कर सकते हैं। ऐसा करने के लिए, अपने टर्मिनल से मॉक डेटा के साथ यह API कमांड चलाएं:

curl -X POST "https://hapi.fhir.org/baseR4/Patient" \
  -H "Content-Type: application/fhir+json" \
  -H "Accept: application/fhir+json" \
  -d '{
    "resourceType": "Patient",
    "identifier": [
      { "system": "http://hospital.example.org/mrn", "value": "<YOUR-FAKE-MRN-NUMBER>" }
    ],
    "name": [ { "use": "official", "family": "<YOUR-FAKE-FAMILY-NAME>", "given": [ "<YOUR-FAKE-GIVEN-NAME>" ] } ],
    "gender": "<male or female>",
    "birthDate": "<YOUR-FAKE-DOB> (in YYYY-MM-DD format)"
  }'

मैच की पुष्टि तभी होती है जब क्वेरी से ठीक एक रिकॉर्ड लौटे — शून्य नतीजों का मतलब कोई मैच नहीं, और एक से अधिक का मतलब है कि खोज पैरामीटर सुरक्षित रूप से आगे बढ़ने लायक पर्याप्त विशिष्ट नहीं थे। 

आर्किटेक्चर

इस गाइड में, आप एक Twilio नंबर के ज़रिए चलने वाला शेड्यूलिंग एजेंट बनाएंगे, जो आपके ElevenAgent के साथ नेटिव रूप से इंटीग्रेटेड होगा। इनबाउंड कॉल कनेक्ट होने पर, एजेंट उपलब्ध टूल्स की मदद से मरीज के सत्यापन और अपॉइंटमेंट का विवरण लेगा — चाहे कॉलर नया विज़िट बुक करना चाहता हो, मौजूदा अपॉइंटमेंट रीशेड्यूल करना हो या रद्द करना हो — और ज़रूरत पड़ने पर कॉल को किसी व्यक्ति को ट्रांसफर कर सकेगा।

इस आर्किटेक्चर और टूलिंग के साथ, एक सफल कॉल फ़्लो में ये चरण शामिल होंगे:

1. कॉल शुरू होना: मरीज एजेंट से जुड़े Twilio नंबर पर कॉल करेगा, जो उसका स्वागत करेगा और उसका इरादा समझेगा।
2. EHR सत्यापन: एजेंट मरीज की जानकारी को EHR में मौजूद उसके रिकॉर्ड से सत्यापित करेगा।
3. वेरिफिकेशन: एजेंट अपने SMS टूल से अंतिम सत्यापन के लिए मरीज के फ़ोन नंबर पर एक वन-टाइम पासवर्ड (OTP) भेजेगा।
4. बुकिंग या बदलाव: एजेंट कैलेंडर में दर्ज इरादे के अनुसार काम करेगा — नए अपॉइंटमेंट के लिए बुकिंग विवरण लेकर उपलब्धता जांचेगा; रीशेड्यूल के लिए मौजूदा अपॉइंटमेंट ढूंढकर नया स्लॉट खोजेगा; और रद्द करने के लिए मौजूदा अपॉइंटमेंट की पुष्टि कर उसे हटाएगा।
5. ट्रांसफर: अगर बुकिंग या बदलाव सफल नहीं होता, मरीज किसी व्यक्ति से बात करने को कहता है, या एजेंट को कोई ऐसा इरादा मिलता है जिसे वह संभाल नहीं सकता, तो कॉल मानव एजेंट को ट्रांसफर कर दी जाएगी।
6. पुष्टि और समापन: बुकिंग, रीशेड्यूल या रद्दीकरण सफल होने के बाद, एजेंट कॉल का विवरण दोहराएगा और गर्मजोशी से बातचीत समाप्त करेगा।

सिस्टम प्रॉम्प्ट और एजेंट सेटिंग्स

एक असरदार ElevenAgent बनाने का पहला कदम उसके सिस्टम प्रॉम्प्ट में होता है। ElevenLabs की प्रॉम्प्टिंग गाइड के अनुसार, हम इसे किसी भी प्रोडक्शन एजेंट के लिए सुझाए गए मुख्य हिस्सों — व्यक्तित्व, लक्ष्य, टोन, टूल्स और गार्डरेल्स — में व्यवस्थित करते हैं। हर हिस्से का अलग, स्पष्ट लेबल वाला सेक्शन होता है, न कि निर्देशों का एक लंबा ब्लॉक।

हेल्थकेयर शेड्यूलिंग एजेंट के लिए, इस संरचना में कॉल के दूसरी ओर मौजूद व्यक्ति का ध्यान रखना होता है: वह बुज़ुर्ग हो सकता है, दर्द में हो सकता है, सुनने में कठिनाई हो सकती है या केवल कॉल करने के कारण से चिंतित हो सकता है। व्यक्तित्व और टोन सेक्शन गर्मजोशी भरी, बिना जल्दबाज़ी की गति तय करते हैं और जवाबों को छोटा व बातचीत जैसा रखते हैं। तारीखें, समय और संख्याएं वैसे बोली जाती हैं जैसे कोई व्यक्ति बोलता है, न कि स्क्रीन से पढ़ता है। लक्ष्य सेक्शन क्रमवार फ़्लो बताता है — पहले पहचान सत्यापित करें; फिर कॉलर बुकिंग, रीशेड्यूल या रद्द करने में से जो चाहता है उसके अनुसार उपलब्धता जांचें और स्लॉट की पुष्टि करें, मौजूदा अपॉइंटमेंट खोजकर बदलें, या हटाए जाने वाले अपॉइंटमेंट की पुष्टि करें। टूल्स के लिए उनके अपेक्षित सटीक बोले जाने वाले फ़ॉर्मैट के इनपुट दर्ज होते हैं। गार्डरेल्स में इस क्षेत्र के खास नियम होते हैं: कॉलर ने जितनी PHI साझा की है उससे अधिक कभी न बताएं, टूल विफल होने पर उपलब्धता या अपॉइंटमेंट विवरण न गढ़ें, क्लिनिकल सवालों के लिए कॉलर को उसके अपने प्रोवाइडर से बात करने को कहें, और कोई व्यक्ति तत्काल लक्षण या मेडिकल इमरजेंसी बताए तो तुरंत एस्केलेट करें। अपॉइंटमेंट पर कोई भी कार्रवाई करने से पहले पहचान सत्यापन एकमात्र नियम है जिसे सिर्फ़ एक बार नहीं, बार-बार दोहराया जाता है। यह वह सीमा है जिसे एजेंट किसी भी कीमत पर नहीं छोड़ सकता।

यहां से, आप अतिरिक्त एजेंट कॉन्फ़िगरेशन जोड़ सकते हैं, जैसे पहला मैसेज, अलग-अलग भाषाएं (सुनिश्चित करें कि detect language सिस्टम टूल सक्षम हो), अपनी पसंद का LLM, एक बातचीत के लिए उपयुक्त ElevenLabs टेक्स्ट-टू-स्पीच मॉडल और एक ElevenLabs वॉइस।

एक उदाहरण सिस्टम प्रॉम्प्ट यहां मिल सकता है।

गार्डरेल्स

सिस्टम प्रॉम्प्ट का गार्डरेल्स सेक्शन निर्देश-स्तर के नियमों को कवर करता है और मॉडल इसे बहुत महत्व देता है। लेकिन प्रॉम्प्ट फिर भी एक गैर-निर्धारक लेयर है और लंबी कॉल में भटक सकता है। ElevenAgents अपने स्वतंत्र रनटाइम एनफोर्समेंट के ज़रिए इन्हें गार्डरेल्स से मज़बूत बनाता है। इनमें Focus Guardrail शामिल है, जो बातचीत लंबी होने पर सिस्टम प्रॉम्प्ट को मज़बूत करता है; Manipulation Guardrails, जो एजेंट के जवाब देने से पहले प्रॉम्प्ट-इंजेक्शन की कोशिशें पकड़ते हैं; और Content व Custom Guardrails, जो हर जवाब का रीयल टाइम में मूल्यांकन करते हैं और कॉलर के सुनने से पहले उसे ब्लॉक कर सकते हैं। हर गार्डरेल के लिए एक एक्ज़ीक्यूशन मोड कॉन्फ़िगर होता है — लगभग शून्य लेटेंसी के लिए स्ट्रीमिंग, या जवाब को मंज़ूरी मिलने तक रोकने के लिए ब्लॉकिंग — और ट्रिगर होने पर क्या करना है इसकी एग्ज़िट स्ट्रैटेजी: कॉल खत्म करना, या अगले टर्न में सुधारात्मक फ़ीडबैक डालकर फिर कोशिश करना।

इस एजेंट के लिए हम हेल्थकेयर या क्लीनिक-विशेष नियमों के लिए कस्टम गार्डरेल्स तय कर सकते हैं: स्थितियों का निदान करने या इलाज सुझाने पर रोक, बिलिंग सवालों पर रोक, दवाओं की खुराक संबंधी मार्गदर्शन पर रोक, और लाइसेंसधारी क्लिनिशियन की सलाह का विकल्प बनने वाली किसी भी चीज़ पर रोक। तत्काल लक्षणों के लिए एग्ज़िट स्ट्रैटेजी को फ़ीडबैक के साथ रीट्राई पर सेट करें, जो कॉल को किसी व्यक्ति को ट्रांसफर करेगी, ताकि गार्डरेल केवल कॉल खत्म करने के बजाय उसे स्टाफ तक पहुंचाए।

टूल्स

फ़्लो के हर चरण में मरीज से बात करते समय खास कार्रवाइयां करने के लिए कुछ वेबहुक और इंटीग्रेशन टूल्स की ज़रूरत होगी।

EHR वेरिफिकेशन टूल

मरीज को EHR में मौजूद उसके रिकॉर्ड के आधार पर सत्यापित करने के लिए, हम FHIR GET /Patient API कार्रवाई इस्तेमाल करेंगे। इसे अपनी HAPI FHIR बेस URL की ओर पॉइंट करते हुए वेबहुक टूल के रूप में जोड़ें और family, given, identifier और birthdate को LLM-भरे जाने वाले पैरामीटर पर सेट करें। वेरिफिकेशन चरण की पहली टूल कॉल, कॉलर के नाम और जन्मतिथि के साथ एक ही क्वेरी में एंडपॉइंट को हिट करती है:

GET /baseR4/Patient?family={lastName}&given={firstName}&birthdate={YYYY-MM-DD}

मैच की पुष्टि तभी होती है जब क्वेरी से ठीक एक रिकॉर्ड लौटे, और एजेंट केवल इस शर्त के पूरे होने पर ही बुकिंग चरण में आगे बढ़ सकता है।

टूल का एक उदाहरण JSON यहां मिल सकता है।

Twilio SMS वेरिफिकेशन टूल्स

EHR मैच की पुष्टि होने पर, वेरिफिकेशन चरण दूसरे फ़ैक्टर पर जाता है: मरीज को टेक्स्ट से वन-टाइम कोड भेजना और कुछ भी आगे होने से पहले उसकी पुष्टि करना। इसे सेट अप करने के तीन चरण हैं:

1. SMS वेबहुक टूल्स बनाएं। दो टूल्स कॉन्फ़िगर करें, send_SMS_verification और check_SMS_verification, दोनों आपके Twilio Verify सर्विस की ओर पॉइंट करते हों। हर टूल को URL पाथ में Verify Service SID (आपकी Verify सर्विस सेटिंग्स का VA... वैल्यू) चाहिए, साथ ही सीक्रेट के रूप में स्टोर किए गए आपके Account SID और Auth Token से बना Basic auth हेडर चाहिए।

2. सिस्टम वेरिएबल से प्राप्तकर्ता सेट करें। ElevenAgents सिस्टम वेरिएबल देते हैं जो किसी भी वॉइस कॉल पर system__caller_id में कॉलर का फ़ोन नंबर अपने-आप भर देते हैं। इसलिए कॉलर से नंबर ज़ोर से पढ़ने को कहने के बजाय To पैरामीटर के रूप में {{system_caller_id}} पास करें। लाइव EHR से इंटीग्रेटेड प्रोडक्शन एनवायरनमेंट में, कोड कॉलर आइडेंटिफ़ायर के बजाय मरीज के रिकॉर्ड में स्टोर फ़ोन नंबर पर भेजा जाएगा।

3. skip_turn सक्षम करें। इसे सिस्टम टूल के रूप में वेबहुक टूल्स के साथ जोड़ने पर, कॉलर के टेक्स्ट ढूंढते समय एजेंट चुपचाप इंतज़ार कर सकता है, बजाय विराम के दौरान बोलते रहने के।

केवल वही कॉलर बुकिंग चरण तक जा सकता है जो EHR लुकअप और OTP जांच, दोनों पास कर लेता है। 

दोनों टूल्स का उदाहरण JSON यहां और यहां मिल सकता है।

कैलेंडर इंटीग्रेशन टूल्स

बुकिंग चरण में वास्तविक कैलेंडर पर उपलब्धता जांचना, बुकिंग करना, रीशेड्यूल करना और रद्द करना होता है। Cal.com इंटीग्रेशन सेट अप करने के तीन चरण हैं:

1. इंटीग्रेशन कनेक्ट करें। एजेंट के Tools टैब से Cal.com इंटीग्रेशन जोड़ें और Connect पर क्लिक करें।

2. इवेंट टाइप पिन करें। हर कैलेंडर टूल एक इवेंट टाइप ID लेता है, जो Cal.com को बताता है कि किस इवेंट के लिए बुकिंग करनी है। कनेक्टेड टूल्स में इसे ID का उपयोग करके एक फिक्स्ड पैरामीटर के रूप में सेट करें अपने Cal.com डैशबोर्ड से।

3. अटेंडी ईमेल सेट करें। बुकिंग टूल्स को अटेंडी ईमेल भी चाहिए। डेमो के लिए, इसे अपने ईमेल पते पर फिक्स्ड पैरामीटर के रूप में पिन करें ताकि कन्फ़र्मेशन आपके इनबॉक्स में आएं। वास्तविक EHR के साथ प्रोडक्शन में, आप हार्डकोडेड ईमेल की जगह मरीज के रिकॉर्ड में मौजूद ईमेल भरेंगे।

इसके बाद, बुकिंग फ़्लो Greeting में दर्ज इरादे पर निर्भर करता है। नए अपॉइंटमेंट के लिए, एजेंट calcom_get_available_slots को कोई स्लॉट ऑफ़र करने से पहले खुले समय खोजने के लिए कॉल करता है, फिर calcom_create_booking को कॉलर की पुष्टि के बाद कॉल करता है — हमेशा इसी क्रम में, क्योंकि पहले उपलब्धता जांचने से ही स्लॉट की डबल-बुकिंग रुकती है। रीशेड्यूल या रद्द करने के लिए, एजेंट पहले calcom_find_bookings_by_attendee से कॉलर का मौजूदा अपॉइंटमेंट खोजता है, कॉलर से उस खास बुकिंग की पुष्टि करता है, फिर इसे calcom_cancel_booking से हटाता है या रीशेड्यूल के लिए पुराना स्लॉट रद्द करने से पहले नया स्लॉट बुक करता है।

किसी व्यक्ति को ट्रांसफर

किसी व्यक्ति को ट्रांसफर करने के लिए, हम ElevenLabs का transfer_to_number सिस्टम टूल इस्तेमाल कर सकते हैं। इसे एजेंट स्तर पर सिस्टम टूल के रूप में जोड़ें, ताकि यह Greeting, Verification और Booking — सभी से उपलब्ध हो। ट्रांसफर नियम के लिए, गंतव्य फ़ोन नंबर E.164 फ़ॉर्मैट में जोड़ें और सादे शब्दों में बताएं कि यह कब सक्रिय होना चाहिए। LLM इन शर्तों और टूल के विवरण के आधार पर तय करता है कि कब और कहां ट्रांसफर करना है। ट्रांसफर टाइप को डिफ़ॉल्ट Conference ही रखें, क्योंकि यह गर्मजोशी भरे हैंडऑफ मैसेज को सपोर्ट करता है, जो मानव ऑपरेटर को बताता है कि कॉल उसके पास क्यों आ रही है।

मरीज की यात्रा को संरचित करना

वर्कफ़्लोज़ विज़ुअल, ग्राफ़-आधारित बातचीत फ़्लो हैं, जो कुछ नोड प्रकारों से बनते हैं: सबएजेंट नोड्स, जो कॉल के एक चरण के लिए सिस्टम प्रॉम्प्ट, टूल्स और नॉलेज बेस को ऑर्केस्ट्रेटर बेस एजेंट के ऊपर लेयर करते हैं; डिस्पैच टूल नोड्स, जो किसी खास टूल के चलने की गारंटी देते हैं और सफलता या विफलता के आधार पर ब्रांच करते हैं; हैंडऑफ के लिए एजेंट ट्रांसफर और ट्रांसफर-टू-नंबर नोड्स; और कॉल समाप्त करने के लिए एंड नोड। नोड्स एजेज़ से जुड़े होते हैं और फ़ॉरवर्ड एजेज़ में LLM शर्त हो सकती है — एक प्राकृतिक भाषा नियम जिसका मॉडल रीयल टाइम में मूल्यांकन करता है कि कौन सा पथ लेना है। हम एजेंट को पांच सबएजेंट नोड्स — Greeting, Verification, Booking, Transfer Notice और Close — के रूप में बनाते हैं, हर एक अपने टूल्स तक सीमित होता है, साथ ही Transfer Notice से पहुंचा जा सकने वाला एक Phone Number Transfer नोड होता है।

Greeting प्रवेश बिंदु है: यह कॉल का जवाब देता है, क्लीनिक का परिचय देता है और हैंडऑफ से पहले मरीज का इरादा समझता है — इसके अपने कोई टूल नहीं होते, केवल सही रूटिंग के लिए पर्याप्त जानकारी जुटाता है।

Verification पहले वाली टू-फ़ैक्टर जांच को संभालता है। यह FHIR GET /Patient टूल से पुष्टि करता है कि कॉलर का EHR में किसी रिकॉर्ड से मैच है, फिर send_SMS_verification और check_SMS_verification टूल्स से कॉलर के आगे बढ़ने से पहले वन-टाइम कोड भेजता और जांचता है। दोनों चरण पार करने वाला कॉलर ही आगे बढ़ता है; जो नहीं कर पाता, उसके लिए Transfer Notice की एक फ़ॉरवर्ड एज होती है।

Booking में पिछले सेक्शन के कैलेंडर टूल्स होते हैं और Greeting में दर्ज इरादा रास्ता तय करता है: नए अपॉइंटमेंट के लिए उपलब्धता जांचना और बुक करना, रीशेड्यूल के लिए मौजूदा बुकिंग खोजना और रद्द करने से पहले फिर बुक करना, या रद्दीकरण के लिए पुष्टि करके रद्द करना। यह नोड Transfer Notice के लिए फ़ेल-ओपन भी करता है — अगर कैलेंडर में कोई समय उपयुक्त नहीं है, कॉलर का किसी मौजूदा अपॉइंटमेंट से मैच नहीं हो पाता, या कॉलर स्टाफ से बात करना चाहता है, तो कॉल को अटकाने के बजाय एज उसे वहां रूट करती है।

Transfer Notice बाकी वर्कफ़्लो और वास्तविक हैंडऑफ के बीच होता है — एक छोटा सबएजेंट जिसका एकमात्र काम कॉलर को यह बताना है कि ट्रांसफर हो रहा है (जैसे, "मैं अब आपको हमारी टीम के एक सदस्य से कनेक्ट कर रहा हूं")। हर ट्रांसफर शर्त को पहले इस नोड से रूट करने पर, transfer_to_number को सीधे Greeting, Verification या Booking से चलाने के बजाय, यह सुनिश्चित होता है कि कॉलर हमेशा वह संदेश सुने, बजाय इसके कि सबएजेंट के शब्द अलग होने पर उसे चुपचाप ट्रांसफर कर दिया जाए।

Phone Number Transfer, जो transfer_to_number टूल पर बना है, वह नोड है जिस पर Transfer Notice हमेशा फ़ॉरवर्ड करता है। इसके नियम गंतव्य नंबर को अपस्ट्रीम से आई उन्हीं शर्तों — असफल वेरिफिकेशन, स्पष्ट अनुरोध या पूरी न हो सकने वाली बुकिंग — के साथ जोड़ते हैं और कॉलर को पहले से सूचना मिलने के बाद वास्तविक हैंडऑफ करते हैं।

Close केवल सफल बुकिंग के बाद पहुंचता है: यह कॉलर को अपॉइंटमेंट का विवरण दोहराता है और गर्मजोशी से कॉल समाप्त करता है।

वर्कफ़्लो का उदाहरण JSON टेम्पलेट यहां मिल सकता है।

विश्लेषण और टेस्टिंग

हेल्थकेयर वॉइस एजेंट में ज़्यादातर मेहनत हैप्पी पाथ पर नहीं होती — बल्कि उन सभी स्थितियों पर होती है जहां कॉल स्क्रिप्ट के अनुसार नहीं चलती और फिर भी सब कुछ सही होना चाहिए। ElevenAgents टेस्टिंग और विश्लेषण के लिए प्लेटफ़ॉर्म में ही बना है। इसका मतलब है कि लॉन्च से पहले टेस्ट करने के लिए जो मूल्यांकन मानदंड इस्तेमाल करते हैं, वही प्रोडक्शन में हर कॉल को स्कोर करते हैं; अलग टूल जोड़ने या मिलान करने की ज़रूरत नहीं होती।

सफलता के मानदंड

सफलता के मानदंड तय करें, ताकि आपके बिज़नेस और ऑपरेशनल लक्ष्यों के अनुरूप खास मूल्यांकन मानदंड दर्ज हो सकें। Analysis टैब में हर मानदंड एक सादे भाषा का प्रॉम्प्ट होता है, जिसे LLM ट्रांसक्रिप्ट पर चलाता है और कारण के साथ success, failure या unknown लौटाता है। इस एजेंट के लिए इनमें ऐसे मानदंड हो सकते हैं:

• patient_verified: "अगर एजेंट ने बुकिंग पर आगे बढ़ने से पहले EHR लुकअप और SMS वन-टाइम कोड, दोनों से कॉलर की पहचान की पुष्टि की हो, तो इसे सफल मार्क करें।"
• appointment_booked: "अगर मरीज का अपॉइंटमेंट बुक हुआ हो, तो इसे सफल मार्क करें"
• appointment_changed: "अगर मरीज ने मौजूदा अपॉइंटमेंट को रीशेड्यूल या रद्द करने को कहा हो और एजेंट ने कैलेंडर इवेंट को अपडेट या डिलीट करके बदलाव पूरा किया हो, और कॉलर को नतीजे की पुष्टि की हो, तो इसे सफल मार्क करें।" 
• call_escalated_when_requested: "अगर कॉलर ने किसी व्यक्ति से बात करने को कहा हो और एजेंट ने कॉल ट्रांसफर की हो, तो इसे सफल मार्क करें; अगर कॉलर ने कहा हो और एजेंट ने ट्रांसफर न किया हो, तो विफल मार्क करें।"

डेटा कलेक्शन

आप इन्हें डेटा कलेक्शन फ़ील्ड्स के साथ जोड़ सकते हैं। उदाहरण के लिए, requested_action (बुक, रीशेड्यूल या रद्द), appointment_date या appointment_type जोड़ें। ये हर ट्रांसक्रिप्ट से स्ट्रक्चर्ड स्ट्रिंग, बूलियन या नंबर वैल्यू के रूप में निकाले जाते हैं और पोस्ट-कॉल वेबहुक के ज़रिए कॉल नतीजों को ट्रैक करने वाले किसी भी सिस्टम में भेजे जाते हैं। 

सिमुलेशन और टेस्ट

हेल्थकेयर में, एजेंट को अपनी पहली वास्तविक कॉल से पहले भरोसा जीतना होता है — विफलताओं के तरीके टेस्टिंग में सामने आने चाहिए, मरीज के सामने नहीं। Conversation Simulation API वास्तविक जैसे कॉलर परिदृश्यों का, एंड-टू-एंड और लक्षित सेगमेंट, दोनों में सिमुलेशन करता है और प्रोडक्शन में चल रहे उन्हीं मानदंडों से नतीजों को अपने-आप स्कोर करता है — ऊपर तय किए गए ठीक patient_verified और appointment_booked जांचों से, न कि अलग टेस्ट-ओनली रूब्रिक से। पूरी कॉल के लिए पूर्ण सिमुलेशन चलाएं, या बातचीत के बीच से शुरू होने वाले आंशिक सिमुलेशन चलाकर किसी एक निर्णय बिंदु को सत्यापित करें। पूरे फ़्लो को फिर से चलाए बिना किसी एक नोड पर बदलाव करने का यह तेज़ तरीका है। 

इस एजेंट के लिए, इसका मतलब है हैप्पी पाथ से आगे के परिदृश्य लिखना: ऐसा कॉलर जिसका नाम किसी EHR रिकॉर्ड से मैच नहीं होता, कोई व्यक्ति जो OTP दो बार गलत डालता है, ऐसा मरीज जो बुकिंग के बजाय रीशेड्यूल करने को कहता है, और ऐसा कॉलर जो वेरिफिकेशन के बीच में साफ़ तौर पर किसी व्यक्ति से बात करने को कहता है। ये स्पष्ट, केंद्रित परिदृश्य आपको एज केस, टूल इस्तेमाल और फ़ॉलबैक लॉजिक का कवरेज देते हैं, बजाय इसके कि आप उनके प्रोडक्शन में सामने आने की उम्मीद करें।

अपना Twilio फ़ोन नंबर कनेक्ट करें

एजेंट बन जाने के बाद, इसे लाइव नंबर से कनेक्ट करने में कुछ मिनट लगते हैं:

1. ElevenLabs डैशबोर्ड में Phone Numbers पर जाएं और Import number पर क्लिक करें।
2. एक Label, Phone Number और अपना Twilio Account SID और Auth Token
3. इंपोर्ट होने के बाद, ड्रॉपडाउन से नंबर अपने एजेंट को असाइन करें।
4. नंबर पर कॉल करके टेस्ट करें, फिर Conversations history डैशबोर्ड में जांचें कि शुरुआती कुछ कॉल अपेक्षा के अनुसार हुईं।

वास्तविक मरीजों के लिए तैयार

हमने एक ऐसा मरीज शेड्यूलिंग एजेंट बनाया है जो केवल फ़ोन का जवाब देने से अधिक करता है: रिकॉर्ड को छूने से पहले वह EHR और सेकंड-फ़ैक्टर OTP से पहचान सत्यापित करता है, और Cal.com के API के ज़रिए लाइव कैलेंडर में सीधे बुक, रीशेड्यूल और रद्द करता है। साथ ही, वह यह भी जानता है कि कब पीछे हटकर कॉलर को किसी व्यक्ति तक पहुंचाना है। निर्धारक वर्कफ़्लो, रनटाइम गार्डरेल्स और मूल्यांकन मानदंड, टीमों को हेल्थकेयर डिप्लॉयमेंट के लिए ज़रूरी ऑडिट ट्रेल और दोहराए जा सकने वाले टेस्टिंग पैटर्न देते हैं।

लाइव होना वह चरण है जहां यह पैटर्न अपनी अहमियत साबित करता है। बिल्ड के दौरान तय किए गए मूल्यांकन मानदंड ही गो-लाइव थ्रेशोल्ड बनते हैं — जब एजेंट उन्हें लगातार पास करता है और मेट्रिक्स स्थिर हो जाते हैं, तो आपके पास अनुमान के बजाय लॉन्च करने का भरोसा होता है। लॉन्च के बाद, सीख सिम्युलेटेड टेस्ट से प्रोडक्शन ट्रांसक्रिप्ट पर आ जाती है। चरणबद्ध रोलआउट से लेकर बदलाव करना कब रोकना है, तक की इन प्रथाओं पर हमने पिछले ब्लॉग में चर्चा की है।

HIPAA अनुपालन की दिशा में एक अहम कदम डेटा हैंडलिंग है। Zero Retention Mode चालू करने पर, कॉल खत्म होते ही कॉल रिकॉर्डिंग, ट्रांसक्रिप्ट और PII वाले मेटाडेटा हट जाते हैं, जिससे फ़ोन-आधारित डिप्लॉयमेंट में अनुपालन जोखिम का सबसे बड़ा स्रोत खत्म हो जाता है। इसे पोस्ट-कॉल वेबहुक के साथ जोड़ने पर दृश्यता कम नहीं होती — कॉल खत्म होते ही हर बुकिंग नतीजा, वेरिफिकेशन परिणाम और मूल्यांकन स्कोर रीयल टाइम में आपके अपने सिस्टम को भेज दिया जाता है।

अब आपके पास अपनी क्लीनिक के मुख्य प्रवेश द्वार पर एजेंटिक वॉइस AI लगाने का एक टेम्पलेट है। शेड्यूलिंग सबसे अधिक वॉल्यूम वाला शुरुआती क्षेत्र है और यही पैटर्न मरीज इनटेक, प्रिस्क्रिप्शन रिफ़िल, बिलिंग और विज़िट के बाद के फ़ॉलो-अप तक बढ़ता है — इनमें से हर कॉल को अब घंटों बाद वॉइसमेल पर जाने की ज़रूरत नहीं है। हमारी Forward Deployed Engineering टीम हेल्थकेयर संगठनों के साथ मिलकर इस तरह के डिप्लॉयमेंट को ठोस प्रोडक्ट क्षमताओं में बदलती है। अगर आप हेल्थकेयर की अपेक्षित अनुपालन व्यवस्था के साथ मरीजों के लिए कोई वर्कफ़्लो ElevenAgents पर लाना चाहते हैं, तो इस तरीके को आज़माएं और हमें बताएं कि आपको कैसा लगा।