एजेंट स्टेप्स और हैंडऑफ

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

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

हर एजेंट एक एकल प्रॉम्प्ट के रूप में शुरू होता है। जब तक आप स्टेप्स या हैंडऑफ्स नहीं जोड़ते, इसमें कुछ नहीं बदलता।

स्टेप्स या एकल प्रॉम्प्ट?#

स्टेप्स कोई स्क्रिप्टेड फोन ट्री नहीं हैं। किसी स्टेप के भीतर मॉडल बातचीत को उसी तरह चलाता है जैसे वह एकल प्रॉम्प्ट के साथ चलाता है। स्टेप तय करता है कि वह किस पर काम कर रहा है, कौन से टूल्स का उपयोग कर सकता है और बाहर निकलने से पहले उसे क्या चाहिए।

स्टेप्स वाले एजेंट को कैसे बनाया जाता है#

जब किसी एजेंट में स्टेप्स होते हैं, तो उसका prompt साझा निर्देशों को रखता है: वह पर्सोना और नियम जो हर स्टेप पर लागू होते हैं। हर स्टेप इसके ऊपर अपने निर्देश जोड़ता है। हर टर्न पर मॉडल साझा निर्देश, वर्तमान स्टेप का नाम और निर्देश, और अब तक इकट्ठा किए गए मान देखता है।

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

API में, steps और handoffs, agent के फ़ील्ड हैं। हर एजेंट फ़ील्ड की तरह, PATCH उन्हें ड्राफ्ट में स्टेज करता है; POST /v1/agents/{agent_id}/deploy उन्हें लाइव करता है। "steps": null भेजने से एजेंट फिर से एकल प्रॉम्प्ट पर स्विच हो जाता है। टेस्ट कॉल्स और बात करें ड्राफ्ट चलाते हैं।

स्टेप फ़ील्ड्स#

ग्राफ स्वयं {"start_step": "<step id>", "steps": [...]} है। कॉल start_step में शुरू होती है।

ट्रांज़िशन#

हर ट्रांज़िशन में to, एक स्टेप आईडी, और ठीक इनमें से एक होता है:

• when: साधारण भाषा, और मॉडल निर्णय लेता है। एजेंट को एक बिल्ट-इन go_to_step टूल मिलता है, जिसमें वे स्टेप सूचीबद्ध होते हैं जिन पर वह जा सकता है, और हर when उसे चुनने का कारण होता है।
• condition: कलेक्ट किए गए मानों पर एक नियम, और कोड निर्णय लेता है। मॉडल इसे स्किप नहीं कर सकता या बातचीत करके इसके आसपास नहीं जा सकता।
• "always": true: बिना जांच के आगे बढ़ें। कोड पहले निर्णय लेता है: जैसे ही किसी स्टेप में प्रवेश किया जाता है, या उसके जरूरी मान कलेक्ट हो जाते हैं, मॉडल के when चुनने से पहले पहली मैचिंग condition या always ट्रांज़िशन लागू होती है। इसलिए always को शर्तों के बाद उनके फॉलबैक के रूप में रखें, या किसी स्टेप को सीधे अगले स्टेप से जोड़ने के लिए इसे अकेले रखें। always वाला स्टेप कभी भी when विकल्प की प्रतीक्षा नहीं करता।

एक condition है {"value": <collected name or dotted path>, "op": <op>, "target": <literal>}:

eq, ne, in और not_in स्पेस हटाने के बाद टेक्स्ट की तुलना केस-इंसेंसिटिव तरीके से करते हैं। संख्याओं की तुलना संख्या के रूप में और तारीखों की तुलना YYYY-MM-DD स्ट्रिंग के रूप में होती है। ऐसा मान जो कभी कलेक्ट नहीं किया गया था, missing को छोड़कर हर ऑप के लिए असत्य होता है।

when और global_when को किसी कथन के बजाय एक शर्त के रूप में लिखें, जैसे "कॉलर अपॉइंटमेंट बुक करना चाहता है"। एजेंट इन्हें आंतरिक रूटिंग नोट्स के रूप में देखता है और उसे इन्हें कभी ज़ोर से न पढ़ने या यह उल्लेख न करने के लिए कहा जाता है कि वह स्टेप बदल रहा है।

जब मॉडल go_to_step कॉल करता है:

1. स्टेप में हर required मान मौजूद होना चाहिए। यदि कोई मान मौजूद नहीं है, तो मॉडल को बताया जाता है कि कौन सा मान मौजूद नहीं है, और वह कॉलर से उसे पूछता है।
2. मान स्टोर किए जाते हैं।
3. condition और always ट्रांज़िशन को क्रम से जांचा जाता है। पहला मैच लागू होता है।
4. अन्यथा एजेंट उस स्टेप पर जाता है जिसे मॉडल ने चुना।
5. यदि कुछ भी मैच नहीं होता और मॉडल ने किसी स्टेप का नाम नहीं दिया, तो एजेंट वहीं रहता है।

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

हर बार किसी स्टेप में प्रवेश करने पर condition और always ट्रांज़िशन की भी जांच होती है, इसलिए कोड-निर्णीत स्टेप का क्रम एक ही बार में पूरा होता है। यह क्रम रुकता है:

• उस स्टेप पर जिस पर इस रन में पहले ही जाया जा चुका है;
• 8 हॉप्स के बाद;
• ऐसे स्टेप पर जिसमें अभी भी जरूरी मान कलेक्ट करने हैं, जब तक स्टेप में on_enter_tool न हो (वेबहुक स्टेप हमेशा अपने परिणाम पर रूट होता है)।

जिस स्टेप पर क्रम रुकता है, केवल उसकी say लाइन बोली जाती है।

बिना ट्रांज़िशन वाला स्टेप टर्मिनल होता है। एजेंट वहीं पूरा करता है और अपने सामान्य बिल्ट-इन एक्शन के साथ कॉल समाप्त या ट्रांसफर करता है।

मान कलेक्ट करना#

किसी स्टेप के लिए आवश्यक चीज़ों को collect में सूचीबद्ध करें। मॉडल जब go_to_step कॉल करता है, तो मान पास करता है, और वे कॉल के बाकी समय के लिए उपलब्ध रहते हैं।

कलेक्ट किए गए मान कॉल कंटेंट हैं। वे ट्रांसक्रिप्ट के साथ कॉल पर दिखते हैं और उन्हीं रिटेंशन, डिलीशन और रिडैक्शन नियमों का पालन करते हैं। जब एजेंट की कॉल रिकॉर्डिंग बंद होती है, तो कलेक्ट किए गए मान न तो स्टोर होते हैं और न ही वेबहुक में भेजे जाते हैं; स्टेप टाइमलाइन फिर भी रहती है। देखें कॉल पर इसे कहाँ देखें।

पंक्तियाँ कहें#

एजेंट के स्टेप में प्रवेश करते ही say को ठीक वैसे ही बोला जाता है जैसा लिखा है। मॉडल फिर उसी उत्तर में नए स्टेप पर आगे बढ़ता है और जानता है कि पंक्ति अभी बोली गई थी, इसलिए उसे दोहराता नहीं है। अभिवादन, आवश्यक डिस्क्लोज़र और तय शब्दावली के लिए say का उपयोग करें, और उत्तर का बाकी हिस्सा मॉडल पर छोड़ दें।

स्टार्ट स्टेप का say एजेंट की शुरुआती पंक्ति होती है, जब वह किसी सहमति घोषणा के बाद पहले बोलता है। जब कॉलर पहले बोलता है, तो यह किसी व्यक्ति को एजेंट के पहले उत्तर से शुरू होता है, IVR या वॉइसमेल अभिवादन से कभी नहीं।

कॉल __previous__ या हैंड-बैक के ज़रिए किसी स्टेप पर लौटने पर उस स्टेप का say दोबारा नहीं बोला जाता। इसे वैसे लिखें जैसा इसे सुनाई देना चाहिए: ऐसी किसी भी चीज़ को पूरा लिखें जिसे आवाज़ गलत पढ़ सकती है। Say पंक्तियाँ {{var}} कॉल वेरिएबल को सपोर्ट करती हैं, लेकिन कलेक्ट किए गए वैल्यू को नहीं।

Webhook स्टेप#

on_enter_tool को एजेंट के किसी एक टूल पर सेट करें और स्टेप में प्रवेश होते ही वह मॉडल की प्रतीक्षा किए बिना चल जाता है। इसके आर्ग्युमेंट वे कलेक्ट किए गए वैल्यू होते हैं जिनके नाम टूल के पैरामीटर नामों से मेल खाते हैं। परिणाम को <tool>_result नाम के कलेक्टेड वैल्यू के रूप में स्टोर किया जाता है, जिसे 4 KB तक ट्रंकेट किया जाता है, और स्टेप के condition और always ट्रांज़िशन तुरंत जांचे जाते हैं, ताकि लुकअप अपने परिणाम के आधार पर स्वयं कॉल को रूट कर सके।

स्टोर किए गए वैल्यू में दो फ़ील्ड होते हैं:

बॉडी फ़ील्ड के आधार पर lookup_account_result.response.<field> से और स्टेटस कोड के आधार पर lookup_account_result.status से रूट करें।

लुकअप अधिकतम 8 सेकंड तक चलता है, या टूल के अपने टाइमआउट तक यदि वह इससे कम हो। यदि इसमें 3 सेकंड से अधिक समय लगता है, तो एजेंट एक छोटी पंक्ति बोलता है ताकि कॉलर को चुप्पी में न छोड़ा जाए। यदि आपका एंडपॉइंट 400 या उससे अधिक का स्टेटस लौटाता है, या समय पर उत्तर नहीं देता, तो एजेंट कॉलर को बताता है कि वह अभी इसे जांच नहीं सका और जो वह कर सकता है उसके साथ आगे बढ़ता है।

ग्लोबल स्टेप#

global_when वाला स्टेप किसी भी स्टेप से पहुंचा जा सकता है, जब भी वह विवरण लागू हो। when की तरह मॉडल निर्णय लेता है। इसका उपयोग उन विषयों के लिए करें जिन्हें कॉलर किसी भी समय उठा सकता है: बिलिंग संबंधी सवाल, किसी इंसान से बात करने का अनुरोध, शिकायत।

ग्लोबल स्टेप पर "to": "__previous__" वाला ट्रांज़िशन कॉल को उस स्टेप पर वापस ले जाता है जो उससे पहले सक्रिय था, ताकि कॉलर वहीं से जारी रख सके जहाँ उसने छोड़ा था। स्टेप फिर से शुरू होता है: उसका on_enter_tool दोबारा नहीं चलता, उसका say दोहराया नहीं जाता, और एजेंट उसे शुरुआत से शुरू किए बिना जारी रखता है।

हैंडऑफ#

handoffs आपके संगठन के उन अन्य एजेंटों की सूची देता है जो कॉल संभाल सकते हैं:

[{"agent_id": 413, "when": "The caller asks about billing or a refund"}]

एजेंट को उन एजेंटों और कारणों के साथ एक बिल्ट-इन hand_off टूल मिलता है। ट्रांज़िशन की तरह, हर when एक आंतरिक रूटिंग नोट है, जिसे कभी पढ़कर नहीं सुनाया जाता।

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

कॉल के पहली बार किसी एजेंट तक पहुँचने पर, वह उस एजेंट के start_step में शुरू होती है: स्टेप का on_enter_tool चलता है और उसका say बोला जाता है। जब कॉल किसी पहले देखे जा चुके एजेंट को वापस हैंडऑफ की जाती है, तो वह एजेंट बिना on_enter_tool चलाए, अपना say दोहराए या फिर से परिचय दिए बिना, उसी स्टेप से आगे बढ़ता है जिस पर वह था। एकत्रित वैल्यू कॉल के हर एजेंट के साथ साझा होती हैं।

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

स्टेप्स या हैंडऑफ वाले एजेंटों पर go_to_step और hand_off आरक्षित हैं, इसलिए आपके अपने टूल्स इन नामों का उपयोग नहीं कर सकते।

कॉल पर इसे कहाँ देखें#

कॉल को कॉल हिस्ट्री में खोलें। ट्रांसक्रिप्ट के पास एक स्टेप टाइमलाइन हर उस स्टेप को दिखाती है जिसमें कॉल पहुँची और उसका कारण बताती है, और इसके साथ एकत्रित वैल्यू सूचीबद्ध होती हैं।

कॉल ऑब्जेक्ट और कॉल-पूर्ण वेबहुक (telephony.complete / web.complete) में steps_trace और collected_values के रूप में वही डेटा होता है। स्टेप्स के बिना कॉल पर दोनों अनुपस्थित होते हैं।

"steps_trace": [
  {"t_ms": 0, "agent": "a412", "step": "greet", "via": "start"},
  {"t_ms": 51230, "agent": "a412", "step": "verify", "via": "model"},
  {"t_ms": 98410, "agent": "a412", "step": "minor", "via": "condition"}
],
"collected_values": {"full_name": "Dana Reyes", "dob": "2010-04-02", "age": 15}

agent, एजेंट ID से पहले लगा a होता है। via बताता है कि कॉल को किसने आगे बढ़ाया:

स्टेप्स कहाँ चलते हैं#

स्टेप्स Spark, Bolt और हर Storm प्रोडक्ट पर, इनबाउंड, आउटबाउंड और कैंपेन कॉल्स, टेस्ट कॉल्स, और वेब व विजेट कॉल्स में नेटिव रूप से चलते हैं।

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

• प्रयोगात्मक Bolt प्रोडक्ट्स;
• Realtime सेशन, जिनमें सेव किए गए एजेंट के सेशन भी शामिल हैं;
• डायनामिक कॉल कॉन्फ़िगरेशन वेबहुक द्वारा लौटाए गए इनलाइन कॉन्फ़िगरेशन। agent_id लौटाने वाला वेबहुक उस एजेंट के स्टेप्स का उपयोग करता है।

सीमाएं#

किसी नियम को तोड़ने वाला सेव खराब फ़ील्ड के पथ के साथ 400 लौटाता है, जैसे steps.steps[2].transitions[0].to। tools और on_enter_tool में टूल नाम एजेंट से जुड़े टूल होने चाहिए।

प्रति-चरण भाषाएं, मॉडल को स्किप करने वाले स्क्रिप्टेड चरण, और say लाइनों के अंदर एकत्र किए गए मान समर्थित नहीं हैं।

इंपोर्ट किए गए एजेंट#

Retell, Bland, Vapi या ElevenLabs से इंपोर्ट करना मल्टी-प्रॉम्प्ट एजेंट, फ्लो, पाथवे और वर्कफ़्लो को चरणों के रूप में, और स्क्वाड्स व एजेंट ट्रांसफ़र को इंपोर्ट किए गए एजेंटों के बीच हैंडऑफ के रूप में लाता है। इंपोर्ट करने से पहले रिव्यू पेज दोनों दिखाता है।

उदाहरण: डेंटल इंटेक#

क्रम में तीन चरण: अभिवादन, मरीज की जानकारी एकत्र करना, बुक करना।

{
  "prompt": "You are Ava, the front desk assistant at Acme Dental. Be warm and brief. Ask one question at a time.",
  "steps": {
    "start_step": "greet",
    "steps": [
      {
        "id": "greet",
        "name": "Greeting",
        "instructions": "Greet the caller and ask how you can help.",
        "say": "Thanks for calling Acme Dental, this is Ava. How can I help you today?",
        "tools": null,
        "collect": [],
        "transitions": [
          {"to": "details", "when": "The caller wants to book an appointment"}
        ]
      },
      {
        "id": "details",
        "name": "Patient details",
        "instructions": "Ask for the caller's full name, date of birth and the reason for the visit. Read the date of birth back and ask the caller to confirm it.",
        "tools": null,
        "collect": [
          {"name": "full_name", "type": "string", "description": "Caller's full name", "required": true},
          {"name": "dob", "type": "date", "description": "Date of birth", "required": true},
          {"name": "reason", "type": "string", "description": "Reason for the visit", "required": true},
          {"name": "new_patient", "type": "boolean", "description": "First visit to the practice", "required": false}
        ],
        "transitions": [
          {"to": "book", "when": "The caller has confirmed their details"}
        ]
      },
      {
        "id": "book",
        "name": "Book",
        "instructions": "Offer the two earliest open slots from book_slot and book the one the caller picks. Confirm the date and time, then say goodbye and end the call.",
        "tools": ["book_slot"],
        "collect": [],
        "transitions": []
      }
    ]
  }
}

इसे PATCH /v1/agents/{agent_id} के साथ स्टेज करें, Talk से आज़माएं, फिर डिप्लॉय करें। नाम, जन्म तिथि और कारण एकत्र होने तक details चरण बुकिंग को हैंडऑफ नहीं कर सकता; new_patient वैकल्पिक है।

उदाहरण: आयु-आधारित ब्रांच#

मॉडल किसी से भी बात कर सकता है, लेकिन किसकी बुकिंग होगी यह कोड तय करता है। आयु एकत्र करें, फिर मॉडल के अपने चयन पर विचार करने से पहले उसके आधार पर रूट करें।

{
  "id": "verify",
  "name": "Verify age",
  "instructions": "Ask for the caller's age.",
  "tools": null,
  "collect": [
    {"name": "age", "type": "number", "description": "Caller's age in years", "required": true}
  ],
  "transitions": [
    {"to": "guardian", "condition": {"value": "age", "op": "lt", "target": 18}},
    {"to": "book", "when": "The caller has given their age"}
  ]
}

पंद्रह कहने वाला कॉलर guardian पर जाता है, चाहे मॉडल कुछ भी तय करे। बाकी सभी book पर जाते हैं। दोनों ग्राफ़ में अन्यत्र सामान्य चरण हैं।

उदाहरण: अकाउंट लुकअप वेबहुक स्टेप#

कॉलर अकाउंट नंबर देता है, अगले स्टेप में प्रवेश करते ही लुकअप चलता है, और उसका परिणाम रूट चुनता है। संक्षिप्तता के लिए not_found, collections और support स्टेप छोड़े गए हैं।

[
  {
    "id": "identify",
    "name": "Identify",
    "instructions": "Ask for the caller's account number and read it back digit by digit.",
    "tools": null,
    "collect": [
      {"name": "account_number", "type": "string", "description": "Account number", "required": true}
    ],
    "transitions": [
      {"to": "lookup", "when": "The caller has confirmed their account number"}
    ]
  },
  {
    "id": "lookup",
    "name": "Look up account",
    "instructions": "Tell the caller what you found on their account and ask how you can help.",
    "tools": ["lookup_account"],
    "collect": [],
    "on_enter_tool": "lookup_account",
    "transitions": [
      {"to": "not_found", "condition": {"value": "lookup_account_result.response.found", "op": "eq", "target": false}},
      {"to": "collections", "condition": {"value": "lookup_account_result.response.account_status", "op": "in", "target": ["past_due", "suspended"]}},
      {"to": "support", "when": "The caller needs help with an active account"}
    ]
  }
]

lookup_account को account_number मिलता है क्योंकि उसके पैरामीटर का वही नाम है। अगर रिस्पॉन्स बॉडी में "found": false है, तो कॉल not_found पर जाती है। अगर उसका account_status past_due या suspended है, तो वह collections पर जाती है। एक सक्रिय अकाउंट lookup में रहता है, जहाँ मॉडल सहायता करता है और फिर support पर आगे बढ़ता है। विफल लुकअप को उसके अपने स्टेप पर भेजने के लिए, पहले स्टेटस पर कंडीशन जोड़ें: एरर रिस्पॉन्स अपना स्टेटस कोड स्टोर करता है, इसलिए {"value": "lookup_account_result.status", "op": "gte", "target": 400} उसे कैच करता है, और टाइमआउट या कोई जवाब न मिलने पर "error" स्टोर होता है, इसलिए {"value": "lookup_account_result.status", "op": "eq", "target": "error"} उसे कैच करता है।

उदाहरण: फ्रंट डेस्क से बिलिंग#

दो एजेंट। फ्रंट डेस्क (एजेंट 412) हर कॉल का जवाब देता है और बिलिंग सवालों को अपने प्रॉम्प्ट, टूल्स और वॉइस वाले बिलिंग एजेंट (एजेंट 413) को हैंडऑफ करता है।

फ्रंट डेस्क पर:

{
  "handoffs": [
    {"agent_id": 413, "when": "The caller asks about a bill, a payment or a refund"}
  ]
}

बिलिंग एजेंट पर, ताकि वह कॉलर को वापस हैंडऑफ कर सके:

{
  "handoffs": [
    {"agent_id": 412, "when": "The billing question is resolved and the caller needs something else"}
  ]
}

फ्रंट डेस्क एक छोटी पंक्ति कहता है, जैसे "मैं आपको हमारी बिलिंग टीम से जोड़ता हूँ", और बिलिंग एजेंट अपना परिचय देता है और बातचीत को वहीं से आगे बढ़ाता है जहाँ फ्रंट डेस्क ने छोड़ा था। जब बिलिंग वापस हैंडऑफ करता है, तो फ्रंट डेस्क कॉलर का फिर से अभिवादन किए बिना वहीं से जारी रखता है जहाँ वह था। कॉल का प्रोडक्ट, भाषाएँ, सहमति घोषणा और अन्य कॉल सेटिंग्स फ्रंट डेस्क के साथ रहती हैं, क्योंकि उसी ने जवाब दिया था।

अगर बिलिंग को केवल अपने निर्देश चाहिए, अपना एजेंट नहीं, तो इसके बजाय फ्रंट डेस्क पर ग्लोबल स्टेप इस्तेमाल करें। सवाल का जवाब मिलने पर, कॉल उस स्टेप पर वापस जाती है जिसमें कॉलर था:

{
  "id": "billing",
  "name": "Billing questions",
  "instructions": "Answer questions about bills and payments. Offer to send a payment link by email.",
  "tools": null,
  "collect": [],
  "transitions": [
    {"to": "__previous__", "when": "The billing question is answered"}
  ],
  "global_when": "The caller asks about a bill or payment at any point"
}

अगले चरण#