चेकआउट से पहले जाँचना कि पता अपने बताए गए पिन कोड से मेल खाता है
ऑर्डर फ़ॉर्म पर पिन कोड और शहर का मेल न खाना एक छोटी सी टाइपिंग गलती लगती है, जब तक कि वह देश के बिल्कुल गलत हिस्से में भेजी गई डिलीवरी में न बदल जाए।
कस्टमर सपोर्ट चैट में लोकेशन संदर्भ जोड़ना
फ़ोन सपोर्ट एजेंट को बातचीत शुरू होने से पहले ही कॉल करने वाले का एरिया कोड मिल जाता है, जो छोटा लेकिन सचमुच उपयोगी संदर्भ है। इसकी तुलना में लाइव चैट एजेंट अक्सर केवल एक नाम और ग्राहक के पहले टाइप किए गए संदेश से शुरुआत करता है, और लाइव चैट सपोर्ट चलाने वाली एक सॉफ़्टवेयर कंपनी ग्राहक से कुछ भी अतिरिक्त पूछे बिना वैसा ही बुनियादी लोकेशन संदर्भ अपने आप दिखाकर यह कमी दूर करना चाहती थी।
समाधान पूरी तरह सर्वर साइड पर चला, उसी पल जब चैट सेशन शुरू होता था। /v1/ip ने विज़िटर के IP पते को देश, क्षेत्र, शहर और एक समय क्षेत्र फ़ील्ड में रिज़ॉल्व किया, और ये सब चैट विंडो के पास एक छोटे पैनल में एजेंट के संदर्भ के लिए दिखाए गए, ग्राहक को कभी नहीं, क्योंकि यह एजेंट के फ़ायदे के लिए संदर्भ था, कोई ऐसा फ़ीचर नहीं जिसे ग्राहक को देखना या इस्तेमाल करना हो।
तुरंत मिलने वाला फ़ायदा सीधा था: एजेंट जवाब देने से पहले ग्राहक का लोकल समय देख सकता था, जो यह तय करने में उपयोगी था कि "देरी के लिए माफ़ी" कहना ठीक है या ग्राहक वास्तव में अपने समय क्षेत्र के हिसाब से बिल्कुल सामान्य समय पर चैट कर रहा था। एजेंट बिना पूछे ग्राहक का देश और क्षेत्र भी देख सकता था, जो ऐसे प्रोडक्ट को संभालने वाली सपोर्ट टीम के लिए उपयोगी संदर्भ था जिसकी क्षेत्र-विशेष नीतियाँ, शिपिंग नियम या नियामक अंतर यह बदल देते थे कि कौन सी सलाह देना वास्तव में सही है।
कंपनी ने इस बात का ध्यान रखा कि यह लोकेशन संदर्भ किस काम के लिए था और किसके लिए नहीं। इससे यह तय होता था कि एजेंट जवाब को कैसे रखे और कभी-कभी क्षेत्र-विशेष प्रोडक्ट अंतरों को देखते हुए कौन सा नॉलेज बेस लेख सबसे प्रासंगिक है, लेकिन इसने एजेंट के अपने विवेक के बिना कभी अपने आप यह नहीं बदला कि एजेंट ग्राहक से क्या कहता है, और इसे कभी भी ग्राहक के सामने इस दावे के रूप में पेश नहीं किया गया कि वे ठीक कहाँ हैं, ताकि वह असहजता न हो जो कुछ ग्राहक स्वाभाविक रूप से तब महसूस करते हैं जब कोई कंपनी उनकी लोकेशन के बारे में उससे ज़्यादा जानती लगे जितना उन्होंने स्पष्ट रूप से बताया।
VPN या कॉर्पोरेट नेटवर्क पर मौजूद ग्राहकों के लिए दिखाई गई लोकेशन कभी-कभी उस जगह से मेल नहीं खाती थी जहाँ ग्राहक वास्तव में था, और एजेंटों को इसे पक्के तथ्य के बजाय मददगार संकेत मानने का प्रशिक्षण दिया गया था, खास तौर पर उन मामलों में जहाँ गलती का असर पड़ता, जैसे यह मान लेना कि कोई खास क्षेत्रीय नीति ऐसे ग्राहक पर लागू होती है जिसके खाते में वास्तव में कोई अलग, अधिक भरोसेमंद लोकेशन दर्ज थी। जहाँ दोनों में अंतर था, वहाँ खाते का अपना लोकेशन डेटा हमेशा IP आधारित संकेत से ऊपर रखा गया।
यह किसी नए प्रोडक्ट फ़ीचर के बजाय एक मौजूदा सपोर्ट टूल में छोटा सा जोड़ था, जिसे कंपनी की अपनी इंजीनियरिंग टीम ने सपोर्ट सॉफ़्टवेयर द्वारा पहले से दिए गए आंतरिक एजेंट डैशबोर्ड में जोड़ा, और इसके लिए ग्राहक की ओर से कुछ भी ज़रूरी नहीं था, न कोई अनुमति प्रॉम्प्ट, न लोकेशन शेयर करने का कोई डायलॉग, क्योंकि यह पूरी तरह चैट कनेक्शन में पहले से मौजूद IP पते से काम करता था।
अनुरोधों की मात्रा सीधे चैट सेशन की संख्या के बराबर थी, हर नए सेशन पर एक लुकअप, जो कंपनी के सपोर्ट चैट ट्रैफ़िक के लिए मुफ़्त दैनिक कोटा के भीतर आराम से रहा। ऐसे छोटे संदर्भ को शायद ही कभी नाम से पहचाना जाता है, लेकिन यह कई छोटे-छोटे तरीकों से यह बदल देता है कि बातचीत के बिल्कुल पहले संदेश का जवाब देते समय एजेंट खुद को कितना तैयार महसूस करता है।
एंडपॉइंट के दस्तावेज़ /docs/ipv4-lookup/ और /docs/ipv6-lookup/ पर हैं।