सीमा तक पहुँचने से पहले अपनी कुंजी के उपयोग पर नज़र रखें
काम के साथ-साथ अपने कोटा हेडर देखते रहने से पता चलता है कि कब सीमा करीब आ रही है, किसी अनुरोध के असल में अस्वीकार होने से काफ़ी पहले।
सपोर्ट डैशबोर्ड में लोकल समय वाली घड़ी का विजेट जोड़ें
जो सपोर्ट एजेंट यह तय कर रहा है कि ग्राहक को अभी कॉल करे या नहीं, उसके लिए यह जानना उपयोगी है कि ग्राहक जहाँ है वहाँ वास्तव में क्या समय है, न कि ऑफ़िस में क्या समय है।
ग्राहक का समय क्षेत्र पता करना
अगर आपके पास शिपिंग या बिलिंग पता पहले से दर्ज है, तो निर्देशांक पाने के लिए उसे एक बार जियोकोड करें, फिर वे निर्देशांक /v1/timezone को भेजें। अगर आपके पास केवल उनकी पिछली विज़िट का IP पता है, तो /v1/ip एंडपॉइंट अलग लुकअप के बिना सीधे timezone फ़ील्ड लौटाता है।
GET /v1/timezone?lat=35.6762&lon=139.6503{
"status": "ok",
"timezone": "Asia/Tokyo",
"utc_offset": "+09:00",
"abbreviation": "JST"
}जब न पता दर्ज हो और न IP
ऐसी लीड या टिकट के लिए जिसमें न पता है और न दर्ज IP, समय क्षेत्र लुकअप करने के लिए कोई भरोसेमंद निर्देशांक नहीं है, और फ़ोन के कंट्री कोड या भाषा सेटिंग के आधार पर अनुमान लगाना ऐसा काम नहीं है जो यह एंडपॉइंट आपके लिए कर सके। ऐसे में सीधे समय क्षेत्र या मोटी लोकेशन पूछें, बजाय ऐसी घड़ी दिखाने के जो एक अनुमान पर बनी हो और जिसके कई घंटे गलत होने की वास्तविक संभावना हो।
घड़ी रेंडर करना
timezone आइडेंटिफ़ायर को ग्राहक के रिकॉर्ड के साथ सेव करें, फिर डैशबोर्ड के हर बार रेंडर होने पर उसी से मौजूदा लोकल समय निकालें, बजाय एक तय ऑफ़सेट सेव करने के जो डेलाइट सेविंग बदलावों के आसपास पुराना पड़ जाएगा। चूँकि साइट पर कोई क्लाइंट-साइड JavaScript नहीं है, इसलिए मौजूदा लोकल समय को पेज लोड पर सर्वर साइड रेंडर करें और हर पेज अनुरोध पर उसे रीफ़्रेश करें, बजाय इसके कि ब्राउज़र में वह लाइव चलती रहे।
हर ग्राहक के लिए एक लुकअप, हर पेज व्यू के लिए नहीं
ग्राहक की लोकेशन का समय क्षेत्र आइडेंटिफ़ायर रोज़-रोज़ नहीं बदलता, इसलिए पता या IP पहली बार दर्ज होने पर उसे एक बार लुकअप करें और आइडेंटिफ़ायर सेव कर लें, बजाय इसके कि डैशबोर्ड लोड होने पर हर बार API कॉल करें। इससे यह फ़ीचर प्रति पेज व्यू एक अनुरोध के बजाय कुल मिलाकर गिने-चुने अनुरोधों तक सीमित रहता है, जो तब मायने रखता है जब सपोर्ट टीम डैशबोर्ड को दिन में कई बार खोलती है।
एक गलती जिससे बचना चाहिए
किसी पुराने सपोर्ट इंटरैक्शन का ऑफ़सेट उस इंटरैक्शन के टाइमस्टैम्प के बजाय आज के timezone लुकअप से दोबारा निकालने पर डेलाइट सेविंग बदलाव के आसपास गलत घंटा दिख सकता है। अगर डैशबोर्ड को यह दिखाना है कि किसी पुराने टिकट के दर्ज होने के समय ग्राहक के यहाँ लोकल समय क्या था, तो मौजूदा ऑफ़सेट पर निर्भर रहने के बजाय उस टिकट का अपना टाइमस्टैम्प time पैरामीटर में भेजें।
इसकी लागत क्या है
आइडेंटिफ़ायर को कैश किए बिना भी हर लुकअप एक ही अनुरोध है, इसलिए किसी भी उचित आकार की सपोर्ट टीम हर कुंजी के साथ शामिल 2,500 प्रतिदिन मुफ़्त अनुरोधों में, या बिना कुंजी के किसी एक पते से मिलने वाले उतने ही कोटा में, आराम से समा जाती है।
इसे अपडेट रखना
अगर ग्राहक का दर्ज पता बदलता है, तो उसी समय सेव किया गया timezone आइडेंटिफ़ायर भी रीफ़्रेश करें, बजाय इसके कि पुराना आइडेंटिफ़ायर रिकॉर्ड से हमेशा जुड़ा रहे। पुराने timezone आइडेंटिफ़ायर वाला स्थानांतरित ग्राहक तब तक गलत लोकल समय दिखाएगा जब तक रिकॉर्ड अपडेट न हो, और यह चुपचाप होगा, क्योंकि पुराना लुकअप अपने आप न विफल होता है और न कोई त्रुटि देता है।
टिकट के पास लोकल समय की घड़ी एक छोटा सा जोड़ है जो सपोर्ट एजेंट को हर कॉल से पहले मन में समय क्षेत्र का हिसाब लगाने से बचाता है। timezone लुकअप दस्तावेज़ में अनुरोध का पूरा विवरण है।