हर महीने दस तारीख के आसपास, अकाउंटिंग टीम एक ही तरह का अनुरोध भेजती है। उन्हें प्रत्येक क्लाइंट से पांच फाइलें चाहिए होती हैं: एक बैंक स्टेटमेंट, एक रसीद आर्काइव (receipt archive), एक पेरोल रिपोर्ट, एक सेल्स समरी, और एक इन्वेंट्री डॉक्यूमेंट। टेम्पलेट मैत्रीपूर्ण, सटीक और परीक्षित है। यह क्लाइंट का नाम लेकर उनका अभिवादन करता है, फाइलों की सूची देता है, और एक स्पष्ट समय सीमा (deadline) प्रदान करता है। पहली बार भेजने पर, यह काम करता है। क्लाइंट एक व्यवस्थित सूची देखता है और जवाब देता है।

समस्या दूसरे ईमेल से शुरू होती है।

कल्पना कीजिए कि एक क्लाइंट चार फाइलें भेजता है। पांचवां बैंक स्टेटमेंट कभी नहीं आता। रसीद आर्काइव तो आता है, लेकिन वह गलत महीने का होता है, इसलिए टीम उसे अस्वीकार (reject) कर देती है। पेरोल रिपोर्ट वास्तव में तीन दिन पहले Slack पर आ गई थी, और किसी ने उसे पहले ही फाइल कर दिया है। इन्वेंट्री डॉक्यूमेंट इस क्लाइंट पर बिल्कुल भी लागू नहीं होता है, यह एक ऐसी जानकारी है जिसका पता आपको पहला संदेश भेजने के बाद चला। यदि आप मूल टेम्पलेट को फिर से भेजते हैं, तो आप फिर से पांच फाइलों की मांग करते हैं। उनमें से चार अनुरोध अब निरर्थक हैं। एक सक्रिय रूप से भ्रामक है। शब्द चयन ठीक है। ईमेल में बस कोई याददाश्त नहीं है।

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

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

जब 'ओपन' (Open) होना ही काफी न हो

यदि आप पूरे अनुरोध को "open" जैसी एकल स्थिति (status) के रूप में ट्रैक करते हैं, तो आप उन विवरणों को खो देते हैं जो महत्वपूर्ण हैं। आइटम स्वतंत्र रूप से आगे बढ़ते हैं। प्रत्येक को अपनी अलग स्थिति (state) की आवश्यकता होती है ताकि अगला संचार सटीक हो सके:

  • Bank statement: गायब है। क्लाइंट ने इसे नहीं भेजा है।
  • Receipt archive: अपलोड किया गया है लेकिन समीक्षा (review) नहीं की गई है। यह आंतरिक जांच की प्रतीक्षा में एक फोल्डर में पड़ा है।
  • Payroll report: अस्वीकार (Rejected)। क्लाइंट ने कुछ भेजा था, लेकिन वह गलत फॉर्मेट या गलत पे-पीरियड का था।
  • Sales report: दूसरे माध्यम से प्राप्त हुआ। यह Slack, फोन कॉल, या डाक प्रति के माध्यम से आया, और आपकी टीम ने इसे पहले ही लॉग कर लिया है।
  • Inventory document: लागू नहीं। इस क्लाइंट को इसे प्रदान करने की आवश्यकता नहीं है, और सिस्टम को पूछना बंद कर देना चाहिए।

इस विस्तृत विवरण के बिना, आपका रिमाइंडर अंधा है। यह एक गायब फाइल और एक अस्वीकार की गई फाइल के साथ एक जैसा व्यवहार करता है। यह पहले से प्राप्त फाइल के साथ ऐसा व्यवहार करता है जैसे वह कभी आई ही न हो। इससे क्लाइंट का समय बर्बाद होता है और विश्वास कम होता है। दो या तीन अप्रासंगिक रिमाइंडर्स के बाद, क्लाइंट उन्हें सरसरी तौर पर देखते हैं। वे मान लेते हैं कि आपका सिस्टम खराब है।

केवल वही बनाएं जिसकी आपको आवश्यकता है

सबसे पहले एक विशाल रूल्स इंजन (rules engine) न बनाएं। आपको पहले दिन से बीस कंडीशनल ब्रांचों (conditional branches) वाले वर्कफ्लो ऑटोमेशन की आवश्यकता नहीं है। केवल इतना डेटा ट्रैक करने से शुरुआत करें जो एक प्रश्न का उत्तर दे सके: क्लाइंट की ओर से अभी किस पर कार्रवाई करने की आवश्यकता है?

प्रत्येक अनुरोधित आइटम को एक टिकाऊ परिणाम की आवश्यकता होती है। इसका अर्थ है एक ऐसा रिकॉर्ड जो ईमेल थ्रेड के बाहर, ऐसी जगह रहे जिसे एप्लिकेशन अगले संदेश का ड्राफ्ट बनाते समय पढ़ सके। रिकॉर्ड का जटिल होना आवश्यक नहीं है। यह एक स्ट्रक्चर्ड टेबल (structured table) जितना सरल हो सकता है जिसमें आइटम का नाम, उसकी वर्तमान स्थिति, टाइमस्टैम्प और एक छोटा नोट हो। महत्वपूर्ण यह है कि डेटा इनबॉक्स से परे जीवित रहे।

यह ईमेल की भूमिका को बदल देता है। टेम्पलेट अभी भी लहजे और संरचना को नियंत्रित करता है। अभिवादन गर्मजोशी भरा रहता है, निर्देश स्पष्ट रहते हैं। लेकिन दस्तावेज़ सूची अनुरोध डेटा (request data) से आनी चाहिए। रिमाइंडर एक क्वेरी (query) बन जाता है। आप सूची को फ़िल्टर करते हैं ताकि केवल वे आइटम दिखें जिन पर क्लाइंट की कार्रवाई की आवश्यकता है। आप आंतरिक समीक्षा की प्रतीक्षा कर रहे आइटमों को बाहर कर देते हैं। आप पहले से स्वीकार किए गए आइटमों को बाहर कर देते हैं।

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

हैंडऑफ टेस्ट (The Handoff Test)

यह जानने का एक सरल तरीका है कि क्या आपको इस अतिरिक्त डेटा मॉडल की आवश्यकता है। पूछें:

क्या कोई अन्य टीम सदस्य पूरे ईमेल थ्रेड को पढ़े बिना इस अनुरोध को संभाल सकता है?

एक अकेली फ़ाइल के लिए, उत्तर मायने नहीं रखता। लेकिन कई जटिल पहलुओं वाले आवर्ती मासिक अनुरोधों के लिए, यह बहुत मायने रखता है। यदि मुख्य संपर्क छुट्टी पर है, तो क्या कोई सहकर्मी कुछ ही सेकंडों में देख सकता है कि क्या कमी है? क्या एक मैनेजर दस ईमेल और तीन साझा फ़ोल्डर्स खोले बिना यह बता सकता है कि क्लाइंट का काम पूरा हो गया है या नहीं? यदि किसी अस्वीकृति को दर्ज करने का एकमात्र स्थान किसी थ्रेड का चौथा संदेश है, जो हस्ताक्षरों और फॉरवर्ड्स के नीचे दबा हुआ है, तो आपका सिस्टम इंसानों को वह काम करने के लिए मजबूर कर रहा है जो एक डेटाबेस को करना चाहिए।

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

स्क्रिप्ट नहीं, क्वेरीज़

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

यह