इनकमिंग कॉल्स के लिए फोन स्क्रिप्ट: उपयोग के लिए तैयार टेम्प्लेट

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

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

विषय सूची

• हर incoming call के लिए सात चरण
  • अंतिम प्रश्न क्यों महत्वपूर्ण है
• urgent कॉल्स को routine कॉल्स से अलग करने वाली ओपनिंग लाइनें
• quoting और booking लाइनें जो टिकती हैं
  • spoken pricing और booking लाइनें
  • चुनें कि booking dispatch तक कैसे पहुंचे
• HVAC, plumbing और electrical के लिए trade variations
  • dispatch निर्णय से प्रश्नों का मिलान करें
• सामान्य पूछताछ और missed calls के लिए ready-to-use लाइनें
  • जब कोई पूरी कॉल नहीं ले सकता
• बहुभाषी संकेत और सैंपल कॉल ट्रांसक्रिप्ट
  • illustrative call का अंग्रेजी में अनुवाद
• live होने से पहले स्क्रिप्ट का परीक्षण करें
  • नियंत्रित पायलट चलाएं

हर incoming call के लिए सात चरण

1. उत्तर दें और सुरक्षा जांचें। कंपनी का नाम बताएं, कॉलर की पसंदीदा भाषा पूछें, और जांचें कि क्या तत्काल इमरजेंसी है। किसी खतरे की रिपोर्ट करते समय ग्रीटिंग पूरी न करें।
2. कॉलर का नाम, कॉलबैक नंबर, सर्विस एड्रेस, प्रॉपर्टी टाइप और requested trade कैप्चर करें। प्रत्येक प्रश्न अलग से पूछें।
3. लक्षण-विशिष्ट प्रश्न पूछें। HVAC के लिए no heat, असामान्य गंध, पानी का रिसाव या carbon-monoxide चिंता जांचें। plumbing के लिए पूछें कि पानी सक्रिय रूप से बह रहा है या नहीं और मुख्य shutoff बंद किया गया है या नहीं।
4. अनुरोध को emergency, urgent, routine, estimate-only, या non-service के रूप में वर्गीकृत करें। वह वर्गीकरण अगली कार्रवाई निर्धारित करता है।
5. केवल स्वीकृत price-book आइटम्स का quote करें। diagnostic fee, after-hours surcharge, parts, labor और अज्ञात शर्तों को अलग करें।
6. सबसे जल्दी वैध अपॉइंटमेंट ऑफर करें। तारीख, arrival window और एड्रेस दोहराएं, फिर स्पष्ट हां का इंतजार करें।
7. बंद करें: “क्या हमने इस visit के लिए आवश्यक सब कुछ कवर कर लिया है?”

इसे decision tree के रूप में मानें, न कि पढ़ने के लिए पैराग्राफ। सुरक्षा चिंता अनुक्रम को बाधित करती है। गलत नंबर इसे समाप्त करता है। estimate अनुरोध repair से अलग scheduling पथ का अनुसरण करता है।

प्रक्रिया ग्राफिक को विस्तृत intake fields के साथ डेस्क रेफरेंस के रूप में उपयोग करें।

प्रत्येक कॉल स्टेज के लिए लक्ष्य समय

ये वर्कफ्लो प्राथमिकताएं हैं, न कि सार्वभौमिक कॉल-अवधि बेंचमार्क।

अंतिम प्रश्न क्यों महत्वपूर्ण है

अंतिम प्रश्न gate code, tenant संपर्क या access restriction पकड़ता है जो अन्यथा एक और फोन कॉल बन जाता है। first-call resolution का मतलब first-call resolution definition और benchmark guidance के अनुसार कॉलबैक, escalation या repeat संपर्क के बिना संपर्क हल करना है।

आवश्यक fields अनिवार्य बनाएं। फोन-नंबर और एड्रेस read-back, स्पष्ट SMS सहमति और unverified quote को guaranteed के रूप में प्रस्तुत करने के खिलाफ hard stop की आवश्यकता है। एजेंट को कॉल complete मार्क करने न दें जबकि आवश्यक जानकारी अभी भी गायब है।

urgent कॉल्स को routine कॉल्स से अलग करने वाली ओपनिंग लाइनें

जिस कॉलर के छत से पानी बह रहा है उसे ईमेल एड्रेस या विस्तृत diagnosis से शुरू करने की जरूरत नहीं। उन्हें स्पष्ट प्रतिक्रिया और सही अगला कदम चाहिए। ऐसी ओपनिंग का उपयोग करें जो कॉलर को तकनीकी दोष पहचानने के लिए कहे बिना कॉल को सॉर्ट करे:

“[कंपनी] को कॉल करने के लिए धन्यवाद, यह [नाम] है। क्या आप active समस्या से निपट रहे हैं, या नई जॉब प्लान कर रहे हैं?”

फिर एक समय में एक प्रासंगिक सुरक्षा प्रश्न पूछें। अगर कोई तुरंत जवाब नहीं दे सकता, wait स्वीकार करें और कॉलर को बताएं कि आगे क्या होगा। unexplained silence घर्षण बढ़ाता है, खासकर जब कोई active समस्या से निपट रहा हो। customer-service study on hold-time expectations कवर करता है कि कॉलर hold times का अनुभव कैसे करते हैं। पहला आदान-प्रदान उनकी स्थिति और अगली कार्रवाई पर केंद्रित रखें।

कॉल प्रकार, संकेत और triage कार्रवाई

ये श्रेणियां routing गाइड करती हैं। वे समस्या का निदान नहीं करतीं। एक कॉलर पहले flickering lights रिपोर्ट कर सकता है, फिर burning odor का जिक्र कर सकता है। जब नई डिटेल्स सुरक्षा चिंता बढ़ाएं तो वर्गीकरण बदलें। मूल कॉल पथ का अनुसरण जारी न रखें।

scheduling से पहले सुरक्षा: technician callback emergency assistance का विकल्प नहीं है।

gas smell के लिए कहें:

“कृपया अब building छोड़ें और बाहर से gas utility को कॉल करें। मैं booking रोक रहा हूं ताकि आप पहले मदद प्राप्त कर सकें।”

अगर तत्काल खतरा हो, कॉलर को सुरक्षित स्थान से emergency services के लिए निर्देशित करें। उन्हें उपकरण inspect करने, model number खोजने या intake पूरा करने के लिए अंदर रहने के लिए न कहें। कॉल का पहला भाग उन्हें सबसे सुरक्षित अगला कदम उठाने में मदद करे, न कि फॉर्म पूरा करने में।

quoting और booking लाइनें जो टिकती हैं

“The diagnostic visit fee [approved fee] है। वह [approved scope] कवर करता है। इसमें repairs शामिल नहीं हैं जब तक कि हमारा price book विशेष रूप से अन्यथा न कहे।”

यह “यह आमतौर पर लगभग...” से stronger ओपनिंग है। एजेंट को approved charge समझानी चाहिए, न कि लक्षण से likely repair total improvise करना चाहिए।

disclosure order consistent रखें: diagnostic fee, after-hours surcharge, parts, labor, फिर unknown conditions। इन लाइनों को सेवा में लगाने से पहले हर ब्रैकेट में shop-approved values का उपयोग करें।

spoken pricing और booking लाइनें

“इस appointment window के लिए, after-hours charge [approved charge] है।”

“अगर parts की जरूरत हो, technician repair शुरू करने से पहले उन्हें हमारे approved pricing के तहत quote करेगा।”

“Labor [approved rate या pricing basis] है, [applicable exclusions] के साथ।”

“मैं technician द्वारा system देखने तक अंतिम संख्या promise नहीं कर सकता, लेकिन आप किसी भी repair work शुरू होने से पहले कुल approve करेंगे।”

अगर price book अनुरोध कवर नहीं करता, quoting बंद करें। कहें:

“उस work के लिए assessment की जरूरत है। मैं visit अरेंज कर सकता हूं, लेकिन फोन पर guaranteed repair price नहीं दे सकता।”

representative को approved pricing reference की जरूरत है, handwritten guess की नहीं।

booking के लिए, कॉलर से पूछने के बजाय real opening ऑफर करें कि वे कब चाहते हैं:

“हमारी सबसे जल्दी उपलब्ध arrival window [date] [start time] और [end time] के बीच है। क्या आप वह अपॉइंटमेंट चाहेंगे?”

acceptance के बाद:

“मेरे पास [date], [arrival window], [full service address] पर है। क्या वह सही है?”

जवाब का इंतजार करें। pause confirmation नहीं है।

चुनें कि booking dispatch तक कैसे पहुंचे

receptionist approved price book और shared calendar का उपयोग कर सकता है। AI front-office system समान pricing rules पढ़ सकता है, itemized quote बोल सकता है, और appointment calendar में लिख सकता है। जहां dispatch अभी भी paper का उपयोग करता है, calendar entry claim करने के बजाय booking और transcript dispatcher को भेजें।

इन common failures से बचें:

• exact arrival promises: authorized window दें, unsupported arrival time नहीं।
• incomplete labor quotes: caller accept करने से पहले exclusions बताएं।
• missing address confirmation: billing address job location है ऐसा assume न करें।

HVAC, plumbing और electrical के लिए trade variations

intake structure consistent रखें। symptom questions और escalation rules trade द्वारा बदलें। receptionist को normal booking रोकने के लिए system diagnose करने की जरूरत नहीं।

trade-specific questions और escalation triggers

डिस्पैच निर्णय से प्रश्नों का मिलान करें

HVAC intake को ऑपरेटिंग लक्षण और ऑक्यूपेंट संदर्भ की आवश्यकता होती है। “No heat” का अर्थ तब अलग होता है जब कमजोर ऑक्यूपेंट मौजूद हों। एक HVAC answering service को उस भेद को अपनी escalation rules में शामिल करना चाहिए, न कि उसे सामान्य नोट्स फ़ील्ड में दबा देना चाहिए।

plumbing के लिए यह स्थापित करें कि समस्या अभी भी बढ़ रही है या नहीं। पूछें कि कॉलर मुख्य shutoff लोकेशन जानता है या नहीं और क्या उसे बंद किया गया है। किसी को खड़े पानी को पार करने या असुरक्षित क्षेत्र में प्रवेश करने के लिए निर्देश न दें।

electrical intake को स्क्रीनिंग और ट्रबलशूटिंग के बीच एक दृढ़ सीमा की आवश्यकता होती है। कॉलर ने क्या रिपोर्ट किया है उसे रिकॉर्ड करें। उन्हें पैनल खोलने, हॉट आउटलेट को छूने या बार-बार ब्रेकर रीसेट करने के लिए कोचिंग न दें।

General contracting को estimator के पास भेजें जब स्कोप approved pricing से बाहर हो। प्रोजेक्ट, बजट रेंज और इच्छित टाइमलाइन कैप्चर करें बिना प्रारंभिक बातचीत को बाइंडिंग कोट में बदलें।

Property-management calls को यूनिट, टेनेंट संपर्क, प्रवेश की अनुमति और पसंदीदा एक्सेस विंडो की आवश्यकता होती है। समस्या रिपोर्ट करने वाले व्यक्ति को काम को मंजूरी देने वाले व्यक्ति से अलग करें।

एक उपयोगी technician summary बताती है कि प्राथमिकता क्या बदली, न कि केवल कॉलर ने कौन सा trade मांगा।

सामान्य पूछताछ और missed calls के लिए तैयार-उपयोग लाइनें

“धन्यवाद [Company] को कॉल करने के लिए, मैं [name] हूँ। आज मैं आपकी कैसे मदद कर सकता हूँ?”

यह सामान्य ऑफिस लाइन के लिए काम करता है यदि अगला प्रश्न अनुरोध को रूट करता है:

“क्या आप pricing, existing appointment, या पहले से इंस्टॉल चीज पर service ढूंढ रहे हैं?”

छोटे जवाबों का उपयोग करें जो कार्रवाई के साथ समाप्त हों:

• Pricing: “मैं आपको अभी diagnostic fee और call-out rate बता सकता हूँ।”
• Existing appointment: “क्या मुझे बुकिंग पर नाम या फ़ोन नंबर मिल सकता है?”
• Billing or office matters: “मैं आपके विवरण लूंगा और ऑफिस को [confirmed window] तक आपको कॉल बैक करने दूंगा।”
• Service inquiry: “मुझे बताएं क्या हो रहा है, और मैं जांचूंगा कि आपको कौन सी service चाहिए।”

जब कोई पूर्ण कॉल नहीं ले सकता

first 30 seconds को स्वीकृति और risk detection के आसपास डिज़ाइन करें, न कि लंबे कंपनी परिचय के। इसे workflow design window मानें, न कि यह वादा कि हर intake पूरा होगा।

एक answering agent के लिए जो बातचीत जारी रख सकता है, उपयोग करें:

“क्षमा करें हम आपकी कॉल सीधे नहीं ले सके। मैं अभी आपके विवरण ले सकता हूँ।”

“service address क्या है, और क्या water, heat, power, या gas से संबंधित immediate concern है?”

“यदि हम डिस्कनेक्ट हो जाएं तो आपको पहुंचने के लिए सबसे अच्छा नंबर क्या है?”

routine requests के लिए, वास्तविक callback window ऑफर करें:

“हमारी अगली उपलब्ध callback window [start time] से [end time] है। क्या यह आपके लिए काम करता है?”

फिर सहमति मांगें:

“क्या मैं इस नंबर पर address और callback window टेक्स्ट कर सकता हूँ?”

safety-critical report के लिए, जारी रखने से पहले emergency protocol लागू करें:

“आपके बताए अनुसार, मैं अभी on-call technician को अलर्ट कर रहा हूँ।”

एक after-hours answering service को इस escalation को ordinary message से अलग करना चाहिए। surges के दौरान, simultaneous answering एक अन्य विकल्प है; missed-call text-back हैंग-अप के बाद संपर्क रिकवर कर सकता है, लेकिन यह emergency triage की जगह नहीं लेता।

एक voicemail greeting को shop के वास्तविक emergency contact का नाम देना चाहिए और gas smell वाले कॉलर्स को मदद के लिए कॉल करने से पहले बाहर जाने का निर्देश देना चाहिए। रिकॉर्डिंग से पहले हर ब्रैकेट बदलें।

कोई service call “Someone will get back to you.” के साथ समाप्त नहीं होना चाहिए। अगली कार्रवाई के owner का नाम बताएं और realistic window दें।

Multilingual Cues और एक नमूना कॉल ट्रांसक्रिप्ट

संक्षिप्त greeting से शुरू करें, फिर पूछें:

“इस कॉल के लिए आप कौन सी भाषा पसंद करेंगे?”

यदि कॉलर दूसरी भाषा में जवाब देता है, तो समर्थित होने पर उस भाषा में जारी रखें। उन्हें समस्या रिपोर्ट करने से पहले लंबे मेनू से गुजरने न दें। भाषा की परवाह किए बिना समान required fields और safety rules रखें।

desk reference को intake fields दिखाना चाहिए, न कि केवल अनुवादित greetings।

Language support तभी उपयोगी है जब agent कार्य पूरा कर सके। एक bilingual answering service का मूल्यांकन करें कि क्या यह symptom details को संरक्षित रखता है, addresses सटीक रूप से पुष्टि करता है, और caller की language preference को technician handoff में ले जाता है।

अंग्रेजी में अनुवादित उदाहरण कॉल

यह काल्पनिक training exchange स्पेनिश-भाषा कॉल का प्रतिनिधित्व करता है। यह customer case study नहीं है, और सभी ब्रैकेटेड विवरणों को live confirmation की आवश्यकता है।

Agent: “धन्यवाद [Company] को कॉल करने के लिए। आप कौन सी भाषा पसंद करेंगे?”

Caller: “Spanish, please. मेरे अपार्टमेंट में no heat है, और यहां एक बच्चा है।”

Agent: “हम Spanish में जारी रख सकते हैं। क्या gas smell, carbon-monoxide alarm, या कोई अस्वस्थ महसूस कर रहा है?”

Caller: “नहीं। heating चल नहीं रही।”

Agent: “मैं इसे emergency escalation के रूप में मान रहा हूं क्योंकि बच्चे के साथ no heat है। कृपया सभी को सुरक्षित, गर्म जगह पर रखें।”

Caller: “अगला क्या होता है?”

Agent: “मैं on-call technician से संपर्क कर रहा हूं। पहले, आपका नाम, service address, unit, और callback number क्या है?”

Caller: “[विवरण प्रदान करता है।]”

Agent: “मैंने उन विवरणों को वापस पढ़ा है, और आपने उनकी पुष्टि की है। on-call callback window [verified window] है। क्या मैं इस नंबर पर उस पुष्टि को टेक्स्ट कर सकता हूं?”

Caller: “हां।”

agent ने immediate danger के लिए स्क्रीन किया इससे पहले कि अनुरोध को heating dispatch के रूप में माना। उन्होंने invented technician arrival time के बजाय callback window ऑफर किया। gas concern या illness report के लिए safety branch की आवश्यकता होगी।

निम्नलिखित वीडियो phone handling के मूल्यांकन के लिए अतिरिक्त संदर्भ प्रदान करता है।

technician को संक्षिप्त summary, structured job details, और transcript भेजें। language preference और escalation का कारण प्रमुखता से शामिल करें। रिकॉर्ड को searchable रखें ताकि ऑफिस स्टाफ prior conversation बिना tenant से पुनर्निर्माण पूछे ढूंढ सके।

स्क्रिप्ट को लाइव होने से पहले टेस्ट करें

एक कॉलर voicemail या answering agent तक पहुंचता है क्योंकि ऑफिस में कोई उठा नहीं सकता। पहले 30 सेकंड में, स्क्रिप्ट को अगला कदम स्पष्ट करना चाहिए, कॉल का कारण कैप्चर करना चाहिए, और ऐसे promises से बचना चाहिए जिन्हें dispatch पूरा नहीं कर सकता। उस recovery workflow को टेस्ट करें, न कि केवल greeting polished लगे।

केवल पूर्ण परिणाम मापें, न कि केवल छोटी कॉल्स। आठ measures ट्रैक करें: answer rate, abandonment, emergency-triage accuracy, quote acceptance, booking conversion, appointment-show rate, repeat-contact rate, और first-call resolution। pilot से पहले प्रत्येक measure परिभाषित करें, फिर call type, language, channel, और समय के अनुसार परिणामों की तुलना करें।

परिणामों का उपयोग करें जहां कॉलर प्रगति रोकते हैं और कौन सा handoff काम की जरूरत है ढूंढने के लिए।

कॉल हैंडलिंग, बुकिंग, और रेजोल्यूशन के मेट्रिक्स

healthcare contact-center benchmark कॉल-सेंटर मापन के लिए संदर्भ प्रदान करता है, लेकिन इसके thresholds को trade-business standards के रूप में नहीं माना जाना चाहिए। नीचे दिए गए formulas का उपयोग करें, अपनी क्षमता और service rules से प्रारंभिक operating targets सेट करें, और pilot calls की समीक्षा के बाद उन्हें संशोधित करें।

किसी भी प्रारंभिक threshold को operating choice मानें, न कि universal benchmark। उदाहरण के लिए, एक बिजनेस pilot के दौरान locally chosen hold-time goal या disconnect limit का उपयोग कर सकता है, फिर staffing, call mix, और वास्तव में प्रदान की जा सकने वाली service के अनुसार समायोजित कर सकता है।

एक नियंत्रित pilot चलाएं

after-hours forwarding से शुरू करें। यह पूरे ऑफिस workflow को बदले बिना परीक्षण को परिभाषित call segment तक सीमित करता है। पुष्टि करें कि existing number सही ढंग से forwards होता है, on-call destination काम करता है, और booking rules वास्तविक availability से मेल खाते हैं।

live traffic स्वीकार करने से पहले simulated calls चलाएं। एक routine tune-up, uncovered service address, price objection, unavailable appointment, language switch, और emergency report शामिल करें। agent को भी interrupt करें। कॉलर अक्सर prompt पर बोलते हैं या agent के finish करने से पहले विषय बदलते हैं।

• एक variable बदलें: opening wording, emergency-question order, या booking offer को अलग-अलग टेस्ट करें।
• समान अवधियों की तुलना करें: call mix और weather conditions का हिसाब रखें। छोटे बदलाव को सुधार का प्रमाण न मानें।
• साप्ताहिक रिकॉर्डिंग्स की समीक्षा करें: safety escalation, approved pricing, consent, और क्या agent ने promised action पूरा किया जांचें।
• handoffs का निरीक्षण करें: पुष्टि करें कि technician को usable details मिले और dispatch record ढूंढ सके।

resolution की व्याख्या करते समय emergency escalations को अलग रखें। एक सही safety escalation एक सफल प्रतिक्रिया है, न कि escalation को हतोत्साहित करने का कारण।

pilot आपके operating criteria को पूरा करने के बाद ही daytime calls तक विस्तार करें। यदि कॉलर्स को उत्तर मिलता है लेकिन confirmed appointment के बिना चले जाते हैं, तो volume बढ़ाने से पहले booking flow ठीक करें। यदि agent ऐसे callbacks promise करता है जिनका कोई owner नहीं, तो staffing और escalation coverage ठीक करें। greeting बदलने से unowned callback हल नहीं होगा।

Mercateer trade businesses के लिए AI answering, price-book quoting, calendar booking, और post-call records प्रदान करता है। incoming-call script, missed-call fallback, और on-call escalation rules कॉन्फ़िगर करने के लिए Mercateer पर जाएं, फिर उन्हें अपने dispatch workflow के विरुद्ध टेस्ट करें।