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

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

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

इस गाइड में हम ElevenLabs Agents के साथ ठीक ऐसा ही बनाते हैं: एक टेलीफोनी-एक्सेसिबल एजेंट, जो सैंपल EHR से जुड़ा है, अपॉइंटमेंट को शुरू से अंत तक बुक, रीशेड्यूल और रद्द करता है, और ज़रूरत पड़ने पर एस्केलेट करता है। आपको ऐसा workflow, guardrails, testing और analysis मिलेगा जो इसे तय सीमाओं में रखे—और जिसे रेगुलेटेड हेल्थकेयर के लिए बने इन्फ्रास्ट्रक्चर पर डिप्लॉय किया गया है।

यहां उस एजेंट का डेमो है जिसे आप बनाएंगे और जो लाइव कॉल को शुरू से अंत तक संभालता है:

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

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

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

वैकल्पिक

अगर आपके पास sandbox डेटा का एक्सेस नहीं है, या आप डेमो के लिए साथ-साथ कर रहे हैं, तो हम 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 से अधिक कभी न बताएं, टूल फेल होने पर उपलब्धता या अपॉइंटमेंट की जानकारी न गढ़ें, क्लिनिकल सवालों के लिए कॉलर को उसके अपने प्रोवाइडर के पास भेजें, और किसी के तत्काल लक्षण या मेडिकल इमरजेंसी बताने पर तुरंत एस्केलेट करें। अपॉइंटमेंट से जुड़ी किसी भी कार्रवाई से पहले पहचान सत्यापन वह नियम है जिसे सिर्फ एक बार कहने के बजाय दोहराया जाता है। यही वह सीमा है जिसे एजेंट बिल्कुल नहीं छोड़ सकता।

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

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

गार्डरेल्स

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

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

टूल्स

फ़्लो के हर चरण में मरीज से बात करते समय खास कार्रवाई करने के लिए विशिष्ट webhook और integration tools की ज़रूरत होगी।

EHR सत्यापन टूल

EHR में मौजूद रिकॉर्ड के साथ मरीज को सत्यापित करने के लिए हम FHIR GET /Patient API action का इस्तेमाल करेंगे। इसे अपने HAPI FHIR base URL पर पॉइंट करने वाले webhook tool के रूप में जोड़ें, जिसमें family, given, identifier और birthdate को LLM द्वारा भरे जाने वाले पैरामीटर के रूप में सेट करें। Verification चरण की पहली tool call कॉलर के नाम और जन्मतिथि के साथ एक ही क्वेरी में endpoint को हिट करती है:

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

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

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

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

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

1. SMS webhook tools बनाएं। दो टूल्स कॉन्फ़िगर करें, send_SMS_verification और check_SMS_verification, दोनों आपके Twilio Verify service पर पॉइंट करने चाहिए। हर टूल के URL path में Verify Service SID (आपकी Verify service settings का VA... मान) और secret के रूप में स्टोर किए गए Account SID व Auth Token से बना Basic auth header चाहिए।

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

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

सिर्फ वही कॉलर Booking चरण में जा सकता है जो EHR lookup और OTP check, दोनों पास करे। 

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

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

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

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

2. इवेंट टाइप पिन करें। हर कैलेंडर टूल में एक event type ID होता है, जो Cal.com को बताता है कि किस इवेंट के लिए बुकिंग करनी है। कनेक्ट किए गए टूल्स में इसे एक fixed parameter के रूप में उस ID से सेट करें जो आपके Cal.com dashboard में है।

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

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

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

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

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

वर्कफ़्लो विज़ुअल, ग्राफ़-आधारित बातचीत फ़्लो होते हैं, जो कुछ प्रकार के nodes से बनते हैं: subagent nodes, जो कॉल के किसी एक चरण के लिए ऑर्केस्ट्रेटर बेस एजेंट के ऊपर सिस्टम प्रॉम्प्ट, टूल्स और knowledge base जोड़ते हैं; dispatch tool nodes, जो किसी खास टूल के चलने की गारंटी देते हैं और सफलता या विफलता के आधार पर ब्रांच करते हैं; हैंडऑफ़ के लिए agent transfer और transfer-to-number nodes; और कॉल खत्म करने के लिए end node। Nodes edges से जुड़े होते हैं और forward edges में LLM condition हो सकती है—एक सामान्य भाषा का नियम, जिसे मॉडल रियल टाइम में जांचकर तय करता है कि कौन सा रास्ता लेना है। हम एजेंट को पांच subagent nodes—Greeting, Verification, Booking, Transfer Notice और Close—के रूप में बनाते हैं। हर node के अपने टूल्स होते हैं, साथ में Transfer Notice से पहुंचा जा सकने वाला एक Phone Number Transfer node होता है।

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

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

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

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

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

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

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

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

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

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

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

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

डेटा कलेक्शन

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

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

हेल्थकेयर में, एजेंट को अपनी पहली वास्तविक कॉल से पहले भरोसा कमाना होता है—विफलताएं मरीज के सामने नहीं, टेस्टिंग में सामने आनी चाहिए। कन्वर्सेशन सिमुलेशन API वास्तविक कॉलर जैसे परिदृश्यों को, शुरू से अंत तक और लक्षित हिस्सों में, सिम्युलेट करता है। यह प्रोडक्शन में चल रहे उन्हीं मानदंडों से नतीजों को अपने आप स्कोर करता है—ऊपर बताए गए बिल्कुल वही patient_verified और appointment_booked checks, न कि केवल टेस्ट के लिए अलग rubric से। पूरी कॉल के लिए full simulations चलाएं, या बातचीत के बीच से शुरू होने वाले partial simulations चलाकर किसी एक decision point को सत्यापित करें। पूरे फ़्लो को फिर से चलाए बिना एक node पर बदलाव दोहराने का यह तेज़ तरीका है। 

इस एजेंट के लिए इसका मतलब है ऐसे परिदृश्य लिखना जो happy path से आगे जाएं: ऐसा कॉलर जिसका नाम किसी EHR रिकॉर्ड से मेल नहीं खाता, कोई व्यक्ति जो OTP दो बार गलत डालता है, बुक करने के बजाय रीशेड्यूल करने वाला मरीज, और सत्यापन के बीच में किसी व्यक्ति से बात करने का स्पष्ट अनुरोध करने वाला कॉलर। ये स्पष्ट और केंद्रित परिदृश्य edge cases, टूल उपयोग और fallback logic की कवरेज देते हैं, बजाय इसके कि आप उम्मीद करें कि वे प्रोडक्शन में अपने आप सामने आएंगे।

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

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

1. ElevenLabs dashboard में फ़ोन नंबर पर जाएं और नंबर इम्पोर्ट करें पर क्लिक करें।
2. एक लेबल, फ़ोन नंबर और अपना Twilio अकाउंट SID और ऑथ टोकन
3. दर्ज करें। इंपोर्ट होने के बाद, dropdown से नंबर को अपने एजेंट को असाइन करें।
4. नंबर पर कॉल करके टेस्ट करें, फिर Conversations history dashboard में देखें कि शुरुआती कुछ कॉल उम्मीद के अनुसार हुईं या नहीं।

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

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

लाइव जाना वह चरण है जहां यह तरीका अपनी उपयोगिता साबित करता है। बिल्ड के दौरान तय किए गए evaluation criteria ही go-live threshold बन जाते हैं—जब एजेंट इन्हें लगातार पास करता है और metrics स्थिर हो जाते हैं, तो अनुमान के बजाय आपके पास लॉन्च करने का भरोसा होता है। लॉन्च के बाद, सीखने का माध्यम simulated tests से बदलकर production transcripts हो जाता है। चरणबद्ध रोलआउट से लेकर कब दोहराव बंद करना है, इन तरीकों पर हमने पिछले ब्लॉग में बात की है।

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

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