चेकआउट से पहले जाँचना कि पता अपने बताए गए पिन कोड से मेल खाता है
ऑर्डर फ़ॉर्म पर पिन कोड और शहर का मेल न खाना एक छोटी सी टाइपिंग गलती लगती है, जब तक कि वह देश के बिल्कुल गलत हिस्से में भेजी गई डिलीवरी में न बदल जाए।
समय क्षेत्र के अनुसार सपोर्ट टिकट रूट करना
बिलिंग देश के अनुसार सपोर्ट टिकट रूट करना सुनने में काम करने वाला लगता है, पर ज़्यादातर करता नहीं। बिलिंग देश बताता है कि खाता कहाँ सेट किया गया था, यह नहीं कि टिकट दर्ज करने वाला व्यक्ति अभी कहाँ बैठा है। तीन शिफ़्टों में फैले सपोर्ट एजेंटों वाली एक कंपनी ऐसे जवाब भेजती रही जो रात के दो बजे उन ग्राहकों तक पहुँचते थे जो यात्रा कर रहे थे, किसी दूसरे देश से रिमोट काम कर रहे थे, या बस ऐसी जगह रहते थे जो उनके बिलिंग पते से नहीं झलकती थी।
कंपनी ने इसके बजाय ग्राहक के वास्तविक मौजूदा समय के अनुसार रूटिंग शुरू की। हर आने वाला टिकट विज़िटर का IP पता साथ लाता है, जिसे /v1/ip देश, क्षेत्र, शहर और निर्देशांक में बदलता है, और उसी रिस्पॉन्स में एक समय क्षेत्र फ़ील्ड भी होता है। रिकॉर्ड में दर्ज बिलिंग देश के बजाय वही समय क्षेत्र तय करता था कि टिकट किस शिफ़्ट में जाएगा। जो टिकट ऐसे IP से आता था जो उस समय अपने क्षेत्र के कामकाजी घंटों में था, वह उस शिफ़्ट को जाता था जो दुनिया के उस हिस्से में स्टाफ़ वाली और जागी हुई थी। जो टिकट कामकाजी घंटों से काफ़ी बाहर आता था, वह अगली ऐसी शिफ़्ट की कतार में जाता था जिससे उचित रूप से उम्मीद हो कि उसका जवाब सामान्य घंटे पर पहुँचेगा।
जिन टिकटों के लिए असिंक्रोनस जवाब के बजाय शेड्यूल की गई कॉलबैक चाहिए थी, उनके लिए टीम ने एक और कदम उठाया: पहचाने गए निर्देशांक /v1/timezone को भेजे, जो उस बिंदु के लिए IANA समय क्षेत्र का नाम और UTC ऑफ़सेट दोनों लौटाता है, और यह उस भविष्य के क्षण के लिए गणना करता है जिसके लिए कॉलबैक शेड्यूल की जा रही थी। यह इसलिए मायने रखता था क्योंकि अलग-अलग देशों में डेलाइट सेविंग बदलावों के साथ ऑफ़सेट अलग-अलग समय पर बदलते हैं, और तीन हफ़्ते बाद बुक की गई कॉलबैक को उस तारीख़ पर सचमुच लागू होने वाला ऑफ़सेट चाहिए था, आज लागू ऑफ़सेट नहीं।
नतीजा यह हुआ कि साफ़ तौर पर बुरे घंटों पर कम जवाब भेजे गए, और एक ऐसा रूटिंग सिस्टम बना जो ग्राहकों के स्थान बदलने, यात्रा करने, या बस ऐसी जगह रहने पर अपने आप ढल जाता था जो उनके खाते के रिकॉर्ड से नहीं झलकती थी। इससे टीम को एक सचमुच उपयोगी मीट्रिक भी मिला जो पहले उसके पास नहीं था: कितने टिकट किसी भी शिफ़्ट के कामकाजी घंटों के बाहर आ रहे थे। यह किसी एक थके हुए एजेंट के अंदाज़े के बजाय शिफ़्ट शेड्यूल बदलने के लिए डेटा पर आधारित तर्क बन गया।
इसमें से कुछ भी ग्राहक के कुछ दर्ज करने पर निर्भर नहीं था। IP पता पहले से ही सपोर्ट विजेट के हर अनुरोध का हिस्सा था, इसलिए पूरा सिस्टम बिना किसी अतिरिक्त फ़ॉर्म फ़ील्ड के या किसी से उसका समय क्षेत्र पुष्टि करने को कहे बिना चलता था, जिसे लोग वैसे भी अक्सर छोड़ देते हैं या यात्रा के दौरान ग़लत भर देते हैं।
अनुरोधों की मात्रा टिकटों की मात्रा के साथ एक-एक के अनुपात में चली, और इस आकार के हेल्प डेस्क के लिए हर My Geocode कुंजी के साथ मिलने वाले मुफ़्त दैनिक कोटा के भीतर आराम से रही, और अगर टिकटों की मात्रा उससे आगे बढ़ती तो सामान्य प्रीपेड विकल्प उपलब्ध था। चालू होने के बाद टीम को कभी लागत के बारे में सोचना नहीं पड़ा, जो आम तौर पर इस बात का संकेत है कि इंफ़्रास्ट्रक्चर का कोई हिस्सा पृष्ठभूमि में चुपचाप अपना काम कर रहा है।
दोनों एंडपॉइंट के फ़ील्ड का पूरा संदर्भ /docs/ipv4-lookup/ और /docs/timezone-lookup/ पर है, और रेट लिमिट का व्यवहार /docs/rate-limits/ पर समझाया गया है।