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