SLA ट्रैकर: समय-सीमाएं, विराम और टीम रिपोर्ट बनाएं

ग्राहक ऑपरेशंस टीमें SLA की समय-सीमाएं क्यों खो देती हैं

ग्राहक ऑपरेशंस टीमें आमतौर पर इसलिए SLA नहीं चूकतीं कि किसी ने तारीख को नज़रअंदाज़ किया। समय-सीमाएं बदलती रहती हैं, टिकट एक व्यक्ति से दूसरे के पास जाते हैं और ग्राहक के जवाब से काम कई दिनों तक रुक सकता है। हर बदलाव के बाद कोई व्यक्ति देय तारीख अपडेट न करे, तो केवल एक देय-तिथि वाले कॉलम वाली स्प्रेडशीट जल्दी बेकार हो जाती है।

पहली समस्या यह है कि हर SLA लक्ष्य को एक ही समय-सीमा मान लिया जाता है। पहली प्रतिक्रिया का लक्ष्य यह मापता है कि एजेंट नए अनुरोध को कितनी जल्दी स्वीकार करता है। समाधान का लक्ष्य यह मापता है कि टीम के पास समस्या हल करने के लिए कितना समय है। कोई टिकट 15 मिनट में प्रतिक्रिया की समय-सीमा पूरी कर सकता है और फिर भी तीन दिन बाद समाधान की समय-सीमा चूक सकता है। एक देय तारीख यह नहीं बता सकती कि कौन-सी प्रतिबद्धता पूरी नहीं हुई।

जिम्मेदारी भी एक समस्या पैदा करती है। एजेंट जवाब दे सकता है, विशेषज्ञ जांच कर सकता है और मैनेजर समाधान को मंज़ूरी दे सकता है। अगर सक्रिय SLA टाइमर का मालिक कोई नहीं है, तो हर व्यक्ति मान सकता है कि कोई और उस पर नज़र रख रहा है। टिकट कतार में पड़ा रहता है, जब तक उसका समय खत्म नहीं हो जाता।

मान लीजिए, अकाउंट एक्सेस की समस्या सुबह 10:00 बजे दर्ज हुई। एजेंट ने 10:12 बजे जवाब देकर 30 मिनट की प्रतिक्रिया समय-सीमा पूरी कर दी और 10:20 बजे स्क्रीनशॉट मांगा। ग्राहक ने अगले दिन दोपहर में जवाब दिया। अगर ट्रैकर इस प्रतीक्षा अवधि को समाधान की समय-सीमा में गिनता है, तो वह सपोर्ट को ऐसे समय के लिए दोषी ठहराएगा जिसका उपयोग टीम कर ही नहीं सकती थी। अगर टाइमर रुक जाए लेकिन दोबारा शुरू न हो, तो परिणाम उल्टी दिशा में गलत होगा।

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

छोटी और स्थिर कतार के लिए मैनुअल शीट काम कर सकती हैं। लेकिन जब समय-सीमाएं प्राथमिकता, कारोबारी घंटों, पुनर्वितरण और विराम पर निर्भर हों, तो ट्रैकर को एक जैसे नियमों की जरूरत होती है।

तय करें कि हर SLA रिकॉर्ड में क्या चाहिए

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

फिर समय-सीमा नियंत्रित करने वाले फ़ील्ड जोड़ें:

• SLA नीति, जैसे «Standard support» या «Priority support»
• शुरुआत का समय
• पहली प्रतिक्रिया और समाधान की देय तिथि
• विराम का कारण और विराम शुरू होने का समय
• दोबारा शुरू होने का समय या कुल रुका हुआ समय

पहली प्रतिक्रिया और पूरे समाधान को अलग रखें। टीम चार कारोबारी घंटों में पहला जवाब देने का वादा कर सकती है, लेकिन समाधान के लिए दो कारोबारी दिन रख सकती है। एक ही देय तारीख तेज़ी से दिए गए जवाब के पीछे अनसुलझे टिकट को छिपा देती है।

एजेंटों से «breached» स्थिति हाथ से चुनने को न कहें। इसे वर्तमान समय, देय समय, टिकट की स्थिति और मान्य विरामों से निकालें। उदाहरण के लिए, कोई टिकट तब समाधान SLA से बाहर जाता है जब उसकी देय तारीख बीत चुकी हो, टिकट खुला हो और टाइमर सक्रिय हो।

AppMaster इस लॉजिक को एक ही जगह रख सकता है। इसका Data Designer टिकट फ़ील्ड मॉडल कर सकता है और विजुअल Business Process एजेंट के टिकट बनाने या अपडेट करने पर देय तिथियां तथा उल्लंघन की स्थिति निकाल सकता है।

ट्रैकर बनाने से पहले SLA नियम तय करें

स्पष्ट नियम SLA के परिणामों को निष्पक्ष बनाते हैं। फ़ॉर्मूले या रिपोर्ट बनाने से पहले हर टिकट श्रेणी का लक्ष्य तय करें। वरना दो एजेंट एक ही अनुरोध को अलग तरह से संभाल सकते हैं और उल्लंघन की गिनती का अर्थ खत्म हो जाता है।

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

हर नियम को सरल भाषा में लिखें। «प्रीमियम ग्राहक की उच्च-प्राथमिकता वाली बिलिंग समस्या पर दो कारोबारी घंटों के भीतर पहली प्रतिक्रिया चाहिए» कहने से साफ हो जाता है कि कौन-सा डेटा रखना है: प्राथमिकता, प्लान, अनुरोध प्रकार, बनाने का समय और पहली प्रतिक्रिया का समय।

कार्य कैलेंडर तय करें

तय करें कि लक्ष्य चौबीसों घंटे चलेगा या केवल सपोर्ट घंटों में। अगर सपोर्ट सोमवार से शुक्रवार, 9:00 से 17:00 तक चलता है, तो शुक्रवार 16:30 पर मिले दो घंटे के लक्ष्य वाले टिकट की देय तारीख शुक्रवार शाम नहीं, बल्कि सोमवार 10:30 होगी।

कार्यदिवस, सपोर्ट घंटे, समय क्षेत्र, छुट्टियां और अलग 24/7 घटना कैलेंडर लिखित रूप में रखें। जहां संभव हो, हर नीति के लिए एक नामित कैलेंडर इस्तेमाल करें। अलग-अलग देशों के ग्राहकों वाली टीमों को क्षेत्रीय कैलेंडर चाहिए हो सकते हैं, लेकिन हर ग्राहक के लिए अलग कैलेंडर रखना अनावश्यक रखरखाव पैदा करता है।

शुरुआत और नीति की जिम्मेदारी तय करें

टाइमर ठीक कब शुरू होगा, यह तय करें। नए टिकट अक्सर सिस्टम के उन्हें प्राप्त करते ही शुरू होते हैं। दोबारा खोले गए टिकटों के लिए अलग नियम चाहिए: बचा हुआ समय जारी रखें, मूल टाइमर फिर शुरू करें या नया लक्ष्य शुरू करें। एक तरीका चुनें और लगातार उसी का पालन करें।

नीति में बदलाव की जिम्मेदारी किसी व्यक्ति या छोटी टीम को दें। एजेंट टिकट का डेटा ठीक कर सकते हैं, लेकिन उल्लंघन हटाने के लिए लक्ष्य समय नहीं बदलना चाहिए। हर रिकॉर्ड पर नीति का संस्करण सेव करें और स्वीकृत अपवाद का कारण तथा तारीख दर्ज करें।

AppMaster ऐप नीतियों को एक एडमिन क्षेत्र में रख सकता है और टिकट सिस्टम में आते ही मिलते-जुलते नियम लागू कर सकता है। इससे अलग-अलग स्प्रेडशीट फ़ॉर्मूलों की जगह एक समान टाइमर मिलता है।

ट्रैकर के पीछे का डेटा मॉडल करें

पहला संस्करण इतना सरल रखें कि ऑपरेशंस लीड टिकट देखकर समझ सके कि उसकी देय तारीख क्यों बदली।

एक tickets तालिका से शुरुआत करें, जिसमें ID, विषय, ग्राहक, प्राथमिकता, स्थिति, बनाने का समय, पहली प्रतिक्रिया का समय, समाधान का समय, देय तिथियां, नियुक्त मालिक और जिम्मेदार टीम हों। कई लोग टिप्पणी करें तब भी हर टिकट का एक वर्तमान मालिक और एक टीम होनी चाहिए।

टीमों और SLA नीतियों के लिए अलग रिकॉर्ड बनाएं। टीम रिकॉर्ड में उसका नाम और कारोबारी घंटों का शेड्यूल रखा जा सकता है। हर नीति में यह लिखा होना चाहिए कि वह किन टिकटों पर लागू होती है, प्रतिक्रिया और समाधान के लक्ष्य क्या हैं, टाइमर का प्रकार क्या है और ग्राहक की प्रतीक्षा टाइमर रोकती है या नहीं।

छुट्टियों का रिकॉर्ड जोड़ें, जिसमें तारीख, संबंधित टीम या स्थान और छोटा लेबल हो। सभी टाइमस्टैम्प एक ही समय क्षेत्र में रखें, आमतौर पर UTC, और जरूरत पड़ने पर इंटरफ़ेस में स्थानीय समय दिखाएं। मिले-जुले समय क्षेत्र सप्ताहांत और daylight-saving बदलावों के आसपास गलतियां पैदा करते हैं।

पुराने रिकॉर्ड मिटाने के बजाय स्थिति का इतिहास रखें। हर प्रविष्टि में टिकट ID, पुरानी और नई स्थिति, घटना का समय तथा बदलाव करने वाले व्यक्ति या नियम को दर्ज करें। «Waiting for customer», «Customer replied», «Assigned» और «Resolved» जैसी घटनाएं रिकॉर्ड करें।

यह इतिहास समय-सीमा में हुए बदलाव समझाता है। अगर देय तारीख मंगलवार सुबह से मंगलवार दोपहर हो जाती है, तो मैनेजर देख सकता है कि ग्राहक की प्रतीक्षा में टीम ने SLA तीन घंटे रोका था। AppMaster का visual Data Designer ऐसे संबंधित रिकॉर्ड मॉडल कर सकता है और उसका Business Process Editor स्थिति बदलने के बाद समय-सीमाएं अपडेट कर सकता है।

टिकट की देय तिथियां निकालें

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

इसके बाद ग्राहक के प्लान, टिकट प्रकार, प्राथमिकता या क्षेत्र के आधार पर सही SLA नीति चुनें। फिर देय तारीख निकालें:

1. टिकट का लक्ष्य पढ़ें, जैसे चार घंटे की प्रतिक्रिया समय-सीमा।
2. नीति के अनुसार मिलने वाला केवल कार्य समय जोड़ें।
3. नीति में शामिल न होने पर बंद घंटे, सप्ताहांत और छुट्टियां छोड़ दें।
4. समय-सीमा टिकट पर सेव करें।
5. प्राथमिकता, प्लान या श्रेणी बदलकर दूसरी नीति लागू हो तो फिर से गणना करें।

कारोबारी घंटे इस गणना को थोड़ा जटिल बनाते हैं। अगर चार घंटे का SLA शाम 4:00 बजे शुरू होता है और सपोर्ट 9:00 से 17:00 तक चलता है, तो उस दिन एक घंटा उपलब्ध है। टिकट अगले कार्यदिवस दोपहर 12:00 बजे देय होगा, रात 8:00 बजे नहीं।

टिकट की प्राथमिकता बदलने पर मूल शुरुआत का समय रखें और लिखे हुए escalation नियम को लागू करें। कुछ टीमें मूल शुरुआत से अत्यावश्यक लक्ष्य लागू करती हैं, जबकि कुछ टिकट के escalate होने पर नया लक्ष्य शुरू करती हैं। दोनों तरीके सही हो सकते हैं, अगर सभी एक ही नियम मानें।

सटीक देय समय और बचा हुआ समय दोनों दिखाएं। «2h 15m left», «due in 1 day» और «overdue by 35m» जैसे लेबल एजेंटों को टाइमस्टैम्प की तुलना में कतार जल्दी समझने में मदद करते हैं। सामान्य टिकटों के लिए शांत स्थिति, समय-सीमा के पास चेतावनी और समय बीतने के बाद स्पष्ट उल्लंघन स्थिति दिखाएं।

ग्राहक के जवाब के लिए टाइमर रोकें

टाइमर तभी रोकें जब ग्राहक के बिना टीम टिकट को आगे न बढ़ा सके। सामान्य कारणों में जानकारी, पुष्टि, एक्सेस, मंज़ूरी या फ़ाइलों की प्रतीक्षा शामिल हैं। किसी सहकर्मी की प्रतीक्षा जैसी आंतरिक देरी से SLA न रोकें।

स्थितियों का छोटा और स्पष्ट सेट रखें:

• ग्राहक की जानकारी की प्रतीक्षा
• ग्राहक की मंज़ूरी की प्रतीक्षा
• ग्राहक के एक्सेस की प्रतीक्षा
• ग्राहक की फ़ाइलों की प्रतीक्षा

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

ग्राहक के जवाब देने पर जवाब के समय टाइमर फिर शुरू करें। प्रतीक्षा अवधि को total paused time में जोड़ें और कारोबारी घंटों के नियमों के अनुसार बचा हुआ समय फिर निकालें। ग्राहक की 90 मिनट की प्रतीक्षा देय तारीख को 90 मिनट आगे बढ़ाएगी, बंद घंटों को ध्यान में रखते हुए।

टिकट व्यू में रुका हुआ समय दिखाएं। एजेंटों को पता होना चाहिए कि टिकट 15 मिनट से रुका है या तीन दिनों से। सुपरवाइज़र को यह भी दिखना चाहिए कि कौन-से टिकट बार-बार प्रतीक्षा की स्थिति में लौटते हैं।

विराम के कारणों को SLA नीति में स्वीकृत विकल्पों तक सीमित रखें। विराम स्वीकार करने से पहले ग्राहक के अनुरोध की घटना अनिवार्य करें। AppMaster में Business Process नई स्थिति जांच सकता है, विराम शुरू होने का समय सेव कर सकता है और SLA रिकॉर्ड अपडेट करने से पहले गलत बदलाव रोक सकता है।

स्वचालित «हमें आपका संदेश मिल गया» ईमेल से टाइमर फिर शुरू नहीं होना चाहिए। ग्राहक का आने वाला संदेश या एजेंट द्वारा पुष्टि किया गया जवाब इस्तेमाल करें और टिकट के साथ पूरा विराम इतिहास रखें।

ग्राहक सपोर्ट का उदाहरण देखें

एक ग्राहक मंगलवार को 10:00 बजे बिलिंग से जुड़ा प्रश्न भेजता है: «मेरे इनवॉइस में दो शुल्क क्यों दिख रहे हैं?» ट्रैकर टिकट B-184 बनाता है, उसे Support को सौंपता है और बिलिंग SLA लागू करता है। टीम के पास उपयोगी पहली प्रतिक्रिया के लिए चार कारोबारी घंटे और समाधान के लिए आठ कारोबारी घंटे हैं।

Support सोमवार से शुक्रवार, 9:00 से 17:00 तक काम करता है। 10:35 बजे एजेंट पुष्टि करता है कि टीम अकाउंट की जांच कर रही है। पहली प्रतिक्रिया का टाइमर 35 मिनट पर रुकता है और 3 घंटे 25 मिनट बचते हैं। टिकट पहली प्रतिक्रिया का लक्ष्य पूरा कर लेता है।

11:00 बजे एजेंट को इनवॉइस नंबर चाहिए और टिकट को «Waiting for customer» करता है। एक घंटे के सक्रिय काम के बाद समाधान टाइमर रुक जाता है। ट्रैकर विराम का समय और कारण सेव करता है।

ग्राहक 15:30 बजे जवाब देता है। ट्रैकर रुके हुए 4 घंटे 30 मिनट को देय तारीख में जोड़ता है। मूल समाधान समय-सीमा मंगलवार 18:00 थी, इसलिए बचा हुआ समय अगले कार्यदिवस में जाने के बाद संशोधित देय तारीख बुधवार 14:30 हो जाती है।

एजेंट बुधवार 15:10 बजे समस्या हल करता है। टिकट 40 मिनट देर से पूरा हुआ। Support के लिए यह एक अतिदेय समाधान गिना जाएगा, जबकि पहली प्रतिक्रिया समय पर रही।

उल्लंघन रिपोर्ट में यह विभाजन साफ दिखना चाहिए: Support को एक बिलिंग टिकट मिला, पहली प्रतिक्रिया का लक्ष्य पूरा हुआ, समाधान लक्ष्य 40 मिनट से चूका और 4 घंटे 30 मिनट ग्राहक की प्रतीक्षा में बीते। टिकट की कुल आयु अकेले गलत कहानी बताएगी।

टीम के अनुसार SLA उल्लंघन रिपोर्ट करें

टिकट का SLA तब टूटता है जब आवश्यक कार्रवाई होने से पहले देय तारीख बीत जाती है। मान्य ग्राहक-विराम के बाद की संशोधित देय तारीख का उपयोग करें।

खुले अतिदेय टिकटों को देर से हल किए गए टिकटों से अलग रखें। खुले अतिदेय टिकटों पर अभी ध्यान चाहिए। देर से हल हुए टिकट प्रदर्शन रिपोर्ट में जाने चाहिए। दोनों को मिलाने से जरूरी काम छिप जाता है और रिपोर्ट का उपयोग कठिन हो जाता है।

हर अवधि के परिणाम उस टीम के अनुसार समूहित करें जिसके पास देय तारीख बीतने के समय टिकट था। नीति, प्राथमिकता और तारीख सीमा से फ़िल्टर करें। चार घंटे की प्रतिक्रिया नीति वाली बिलिंग टीम की सीधे उस तकनीकी escalation टीम से तुलना न करें जिसकी समाधान नीति दो कारोबारी दिनों की है।

गिनती के साथ दरें भी रखें:

• सक्रिय SLA वाले कुल टिकट
• लक्ष्य के भीतर हल किए गए टिकट
• खुले अतिदेय टिकट
• समय-सीमा के बाद हल किए गए टिकट
• उल्लंघन दर, यानी SLA वाले टिकटों में से उल्लंघन वाले टिकटों का अनुपात

50% उल्लंघन दर का अर्थ दो टिकटों में से एक देर से होने पर अलग होगा और 100 में से 50 टिकट देर से होने पर अलग। टिकट विवरण के साथ रुझानों की समीक्षा करें। बार-बार होने वाले उच्च-प्राथमिकता उल्लंघन पूरे काम के बोझ के बजाय escalation नियम या हैंडऑफ की समस्या बता सकते हैं।

अच्छी रिपोर्ट में मैनेजर देर से हुए टिकटों की सूची खोलकर नीति, प्राथमिकता और उल्लंघन के समय की जिम्मेदारी देख सकता है। रिपोर्ट का उद्देश्य टीमों को बहुत जल्दी टिकट बंद करने के लिए पुरस्कृत करना नहीं, बल्कि सुधार योग्य काम की व्यावहारिक समीक्षा करना होना चाहिए।

एजेंटों और मैनेजरों के लिए व्यू बनाएं

एजेंटों को पुराने टिकटों से भरी रिपोर्ट नहीं, बल्कि छोटी कामकाजी सूची चाहिए। हर खुले टिकट में मालिक, टीम, प्राथमिकता, देय तारीख, टाइमर की स्थिति और बचा हुआ समय दिखना चाहिए। टिकट टीमों के बीच जाने पर जिम्मेदारी तुरंत बदलें।

सरल टाइमर लेबल रखें। «Active» का अर्थ है कि अगले कदम की जिम्मेदारी टीम की है। «Paused - waiting for customer» का अर्थ है कि टाइमर रुका हुआ है। सक्रिय और रुके हुए समय को अलग दिखाएं, ताकि उपयोगकर्ता समझ सकें कि टिकट कई दिनों से खुला क्यों है।

एजेंट व्यू में अगले चार घंटों में देय टिकट, अतिदेय टिकट, ग्राहक के जवाब की प्रतीक्षा वाले टिकट और आज पुनः सौंपे गए टिकट शामिल हो सकते हैं। समय-सीमा से पहले चेतावनी भेजें। चार घंटे की प्रतिक्रिया नीति को तीन दिन की समाधान नीति की तुलना में पहले चेतावनी चाहिए।

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

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

AppMaster से टीमें एजेंटों और मैनेजरों के लिए अलग वेब व्यू बना सकती हैं, जबकि दोनों के पीछे एक ही टिकट डेटा और बिज़नेस नियम रखे जा सकते हैं।

वे गलतियां जो SLA परिणाम बिगाड़ती हैं

साफ-सुथरे चार्ट भी गलत कहानी बता सकते हैं, अगर मूल नियम गलत हों।

समय के नियमों को शाब्दिक न मानें

जब समझौते में कारोबारी घंटों का वादा हो, तो कैलेंडर घंटे से गणना न करें। शुक्रवार शाम 4:30 बजे खुले टिकट की आठ कारोबारी घंटे की प्रतिक्रिया समय-सीमा शनिवार सुबह 12:30 बजे समाप्त नहीं होगी। नीति में तय काम के घंटे और छुट्टियां ही गिनें।

विराम पर भी यही सावधानी रखें। «Waiting for customer» स्थिति SLA तभी रोके जब टीम ने स्पष्ट अनुरोध भेजा हो और जवाब के बिना आगे न बढ़ सकती हो। इस लेबल वाले हर टिकट को रोकने से टीम की अपनी देरी छिप जाती है।

हर परिणाम समझाने वाली तारीखें रखें: मूल देय तारीख, इस्तेमाल की गई नीति, हर विराम का शुरू और खत्म होने का समय, विराम का कारण, संशोधित देय तारीख, समाधान का समय और टिकट बंद करने वाला व्यक्ति। इस इतिहास के बिना कोई यह जांच नहीं सकता कि टिकट समय पर क्यों दिखा।

जिम्मेदारी एक बार गिनें

टीम रिपोर्टिंग में एक ही जिम्मेदारी नियम इस्तेमाल करें। अगर Support टिकट Billing को सौंपता है, तो उसी उल्लंघन को दोनों टीमों के खाते में न गिनें। परिणाम उस टीम को दें जिसके पास देय तारीख बीतने के समय टिकट था और हैंडऑफ को अलग से रिपोर्ट करें।

टिकट बंद करने से पहले समाधान का टाइमस्टैम्प अनिवार्य करें। बंद स्थिति यह साबित नहीं करती कि काम कब खत्म हुआ। उदाहरण के लिए, टिकट दोपहर 2:00 बजे Support से Billing को जाता है और 3:00 बजे SLA से बाहर हो जाता है, तो ownership-at-breach नियम के तहत उल्लंघन Billing का होगा। रिपोर्ट में पहले का Support हैंडऑफ दिख सकता है, लेकिन दूसरा उल्लंघन नहीं गिना जाना चाहिए।

लॉन्च से पहले ट्रैकर जांचें

एजेंटों के भरोसे इस्तेमाल करने से पहले हर SLA नीति की समीक्षा करें। हर नीति में स्पष्ट लक्ष्य, जैसे चार घंटे की पहली प्रतिक्रिया या दो कारोबारी दिनों का समाधान, और उससे जुड़ा कैलेंडर होना चाहिए। ऐसे टिकटों के लिए डिफ़ॉल्ट नीति तय करें जो ग्राहक, प्लान या प्राथमिकता के नियम से मेल नहीं खाते।

सिर्फ सामान्य मामलों की नहीं, कठिन समय-स्थितियों की भी जांच करें:

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

डैशबोर्ड की कुल गिनती की तुलना उसके पीछे की टिकट सूची से करें। अगर रिपोर्ट कहती है कि Team A के 12 उल्लंघन हैं, तो रिकॉर्ड फ़िल्टर करके उन्हें गिनें। इससे डुप्लिकेट टिकट, गायब टीम असाइनमेंट और दो बार गिने गए दोबारा खुले टिकट पकड़े जा सकते हैं।

रिलीज़ से पहले एक्सेस नियम तय करें। एजेंट अपने टिकट अपडेट करें, मैनेजर टीम रिपोर्ट देखें और एडमिन नीति सेटिंग नियंत्रित करें। AppMaster में हर भूमिका को अलग अकाउंट से जांचें, ताकि SLA उल्लंघन रिपोर्ट देखने के लिए मैनेजर को एडमिन एक्सेस की जरूरत न पड़े।

छोटे स्तर से शुरू करें और वर्कफ़्लो सुधारें

एक टिकट प्रकार और एक SLA नीति से शुरुआत करें। कोई सपोर्ट टीम सामान्य ईमेल अनुरोधों और 24 घंटे की पहली प्रतिक्रिया नीति से शुरू कर सकती है। इससे देय तिथियों, स्वीकृत विराम और उल्लंघन रिकॉर्ड की जांच के लिए पर्याप्त आधार मिल जाता है।

कुछ ग्राहक ऑपरेशंस कर्मचारियों से वास्तविक टिकटों पर वर्कफ़्लो चलवाएं, जिसमें सामान्य मामला, ग्राहक की प्रतीक्षा वाला मामला और चूकी हुई समय-सीमा शामिल हो। विशिष्ट प्रतिक्रिया लें। एजेंटों को ग्राहक की प्रतीक्षा और दूसरी टीम की प्रतीक्षा के लिए अलग स्थितियां चाहिए हो सकती हैं। मैनेजरों को लग सकता है कि सामान्य «paused» लेबल बहुत कम जानकारी देता है।

जब स्प्रेडशीट प्रक्रिया को सीमित करने लगे, तो AppMaster में ट्रैकर को नो-कोड ऐप के रूप में बनाएं। आप टिकट फ़ॉर्म बना सकते हैं, visual Business Process Editor में टाइमर लॉजिक तय कर सकते हैं और एजेंट तथा मैनेजर के अलग डैशबोर्ड दे सकते हैं। जब ट्रैकर को साझा तालिका से आगे काम करना हो, AppMaster backend, वेब ऐप और native mobile app बना सकता है।

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