Slack में पुराने निर्णय कैसे खोजें (जब सर्च काफी न हो)
Slack में पुराने निर्णय खोजें जब कीवर्ड सर्च विफल हो। निर्णय क्यों गायब होते हैं, लॉग क्यों काम नहीं करते और निर्णय-केंद्रित सिस्टम कैसा दिखता है।
By Ellis Keane · 2026-03-14
जल्दी बताइए: आपकी टीम ने पोलिंग की जगह वेबहुक इस्तेमाल करने का फैसला कहाँ किया था? यह नहीं कि आपने क्या तय किया – वह निर्णय अभी कहाँ लिखा हुआ है, किसी ऐसी जगह जहाँ अगले महीने जुड़ने वाला कोई व्यक्ति उसे खोज सके?
अगर आप हमारे जैसे हैं, तो ईमानदार जवाब "शायद किसी Slack थ्रेड में" और "मुझे लगता है यह #eng-backend में था, शायद तीन हफ्ते पहले, और मुझे यकीन है कि दो-तीन लोग शामिल थे लेकिन मुझे सच में याद नहीं कि कौन से" के बीच कहीं है। जब आप इसके बारे में सोचते हैं तो यह वाकई एक दिलचस्प स्थिति है – निर्णय खुद इतना महत्वपूर्ण था कि पूरे सिस्टम के काम करने के तरीके को बदल दिया, लेकिन जाहिर है इतना महत्वपूर्ण नहीं कि किसी ने उसे टाइमस्टैम्प के आधार पर व्यवस्थित चेतना की धारा के अलावा किसी अन्य जगह लिखा हो। और यही, संक्षेप में, Slack में पुराने निर्णय खोजने की कोशिश करने की समस्या है – सारी जानकारी वहाँ मौजूद है, बस इस तरह व्यवस्थित नहीं है कि आप उसे निर्णय के रूप में प्राप्त कर सकें।
मैं काफी समय से इस बात पर गौर कर रहा हूँ कि Slack में पुराने निर्णय कैसे खोजे जाएं, और जितना गहरा जाता हूँ, उतना ही लगता है कि मुख्य समस्या न तो अनुशासन है, न आदत है, न ही वे अन्य चीजें जिन पर लोग दोष मढ़ते हैं। यह एक आर्किटेक्चरल समस्या है। Slack की सर्च संदेश खोजने के लिए बनाई गई थी, और निर्णय संदेश नहीं होते – वे अर्थ होते हैं जो संयोगवश संदेशों के माध्यम से व्यक्त होते हैं, एक ऐसा अंतर जो पांडित्यपूर्ण लगता है जब तक आप बीस मिनट सर्च परिणामों को स्क्रॉल करते हुए यह पता लगाने की कोशिश नहीं करते कि "webhooks" के सत्रह उल्लेखों में से कौन-सा वह था जहाँ आपकी टीम ने वास्तव में उनका उपयोग करने का निर्णय लिया था।
Slack सर्च वास्तव में कैसे काम करती है (और कहाँ टूट जाती है)
इस बारे में सटीक रहें, क्योंकि "Slack सर्च खराब है" सही निदान नहीं है – Slack सर्च वास्तव में जो करती है उसमें काफी अच्छी है। समस्या यह है कि वह जो करती है और जब आप किसी निर्णय की तलाश में हों तब आपको उससे जो चाहिए, वे दो मौलिक रूप से अलग चीजें हैं।
Slack संदेशों को मेटाडेटा के साथ टेक्स्ट के रूप में इंडेक्स करता है: टाइमस्टैम्प, प्रेषक, चैनल और (यदि आप भुगतान वाले प्लान पर हैं) पूरा थ्रेड संदर्भ। जब आप "webhook" सर्च करते हैं, तो Slack वफादारी से वह हर संदेश लौटाता है जिसमें वह शब्द है, हाल की और प्रासंगिकता के किसी संयोजन के आधार पर रैंक किया गया। आप सर्च ऑपरेटर से चीजें सीमित कर सकते हैं – in:#eng-backend from:@sarah before:2026-02-15 – लेकिन आप बस मेटाडेटा के आधार पर संदेशों की उसी सपाट सूची को फ़िल्टर कर रहे हैं। यह कीवर्ड रिट्रीवल है, और किसी ऐसे विशिष्ट संदेश को खोजने के लिए जो आपको आधा याद हो, यह ठीक काम करता है।
लेकिन निर्णय कोई कीवर्ड नहीं है। निर्णय एक प्रश्न, विकल्पों के एक समूह, लोगों के एक समूह और उस क्षण के बीच का संबंध है जब समूह एक विकल्प पर सहमत हुआ। निर्णय का वास्तविक पाठ हो सकता है "हाँ, चलो बस webhooks करते हैं, पोलिंग अप्रोच हमारी रेट लिमिट खा रही है" – जो बोलचाल की भाषा में है, संदर्भगत है और केवल तभी अर्थपूर्ण है जब आप पहले से उस थ्रेड को जानते हों जिसमें यह प्रकट हुआ था। या यह "यह काम करता है, मुझे प्रोटोटाइप बनाने दो" हो सकता है, जिसमें उस तकनीकी निर्णय से संबंधित कोई भी कीवर्ड नहीं है जिसका वह प्रतिनिधित्व करता है।
यही आर्किटेक्चरल विसंगति है: Slack संदेशों को कालानुक्रमिक रूप से संग्रहीत करता है और उन्हें कीवर्ड द्वारा पुनः प्राप्त करता है। निर्णय सिमेंटिक होते हैं (वे अर्थ के बारे में होते हैं) और संबंधात्मक होते हैं (वे कार्यों, लोगों और परिणामों से जुड़ते हैं)। आप एक कालानुक्रमिक स्टोरेज सिस्टम से सिमेंटिक रिट्रीवल करने के लिए कह रहे हैं, और यह नहीं कर सकता क्योंकि इसे कभी ऐसा करने के लिए डिज़ाइन नहीं किया गया था। "खोजने योग्य" और "ढूंढने योग्य" के बीच का अंतर बहुत बड़ा निकलता है – आपके Slack इतिहास का हर संदेश तकनीकी रूप से खोजने योग्य है, लेकिन इसका मतलब यह नहीं कि आपको जिस निर्णय की जरूरत है वह किसी व्यावहारिक अर्थ में ढूंढने योग्य हो।
"Slack ने इतिहास में सांगठनिक निर्णय-निर्माण के सबसे बड़े भंडारों में से एक बनाया है, और उसका लगभग कुछ भी निर्णय के रूप में पुनर्प्राप्त करने योग्य नहीं है – हर शब्द पूरी तरह से सुरक्षित और लगभग पूरी तरह से अढूंढने योग्य।" – Ellis Keane
जब आप Slack में पुराने निर्णय खोजने की कोशिश करते हैं तो क्या होता है
व्यवहार में यह विसंगति कैसी दिखती है। मान लीजिए आपकी टीम ने तीन हफ्ते पहले GitHub इंटीग्रेशन के लिए पोलिंग से webhooks पर स्विच करने का फैसला किया था। आपको याद है कि चर्चा #eng-backend में हुई थी और कुछ इंजीनियर शामिल थे। तो आप उस चैनल में "webhook" सर्च करते हैं।
जो वापस आता है: #eng-backend में कभी भी webhooks का उल्लेख करने वाला हर संदेश। छह महीने पहले के बग रिपोर्ट। कोई एक पूरी तरह अलग संदर्भ में webhook रिट्री लॉजिक के बारे में सवाल पूछ रहा है। किसी ने webhook बेस्ट प्रैक्टिसेज़ के बारे में ब्लॉग पोस्ट का लिंक शेयर किया (जो, एक खूबसूरत विडंबना में, शायद सर्च परिणामों में उस वास्तविक निर्णय से ऊँचा रैंक करता है जिसके पास वह बैठा है)। निर्णय खुद – एक थ्रेड में एक उत्तर जहाँ किसी ने कहा था कि पोलिंग अप्रोच रेट लिमिट को छू रही थी – पेज तीन में कहीं दबा है, उसके आसपास के हर दूसरे संदेश जैसा दिखता है।
और यह वह परिदृश्य है जहाँ आपको लगभग याद है कि कौन से शब्द इस्तेमाल हुए थे। आधे समय, निर्णय इतनी संदर्भगत भाषा का उपयोग करते हैं कि वे एन्क्रिप्टेड भी हो सकते हैं। "चलो ऑप्शन B के साथ जाते हैं" में "webhook" शब्द बिल्कुल नहीं है, भले ही ऑप्शन B webhooks थे। "यह काम करता है, मुझे प्रोटोटाइप बनाने दो" में "ऑप्शन" शब्द भी नहीं है। निर्णय का वास्तविक क्षण अक्सर पूरे थ्रेड में सबसे छोटा, सबसे कम कीवर्ड-समृद्ध संदेश होता है, क्योंकि उस बिंदु पर बातचीत में सभी के पास पहले से संदर्भ है और वे बस संरेखण की पुष्टि कर रहे हैं।
मुझे यह सूचना वास्तुकला की समस्या के रूप में वास्तव में दिलचस्प लगता है (ठीक है, दिलचस्प और जब आप खोज रहे हों तब थोड़ा निराशाजनक भी)। Slack ने इतिहास में सांगठनिक निर्णय-निर्माण के सबसे बड़े भंडारों में से एक बनाया है, और उसका लगभग कुछ भी निर्णय के रूप में पुनर्प्राप्त करने योग्य नहीं है – हर शब्द पूरी तरह से सुरक्षित, और लगभग पूरी तरह से अढूंढने योग्य।
निर्णय लॉग बेहतर संकेतों वाला कब्रिस्तान क्यों है
यदि आप समाधान खोजने जाएं, तो मानक सलाह है निर्णय लॉग रखना। एक Notion डेटाबेस, एक समर्पित Slack चैनल (जिसकी विडंबना इसकी सिफारिश करने वालों से स्पष्ट रूप से छूट जाती है), एक विकी पेज – कोई एकल स्थान जहाँ निर्णय जैसे-जैसे होते हैं दर्ज किए जाते हैं।
हमने यह कोशिश की। यह लगभग छह हफ्ते चला। पहले दो हफ्ते बहुत अच्छे रहे – सभी प्रतिबद्ध थे, प्रविष्टियाँ विस्तृत थीं, लॉग वास्तव में उपयोगी था। तीसरे हफ्ते तक प्रविष्टियाँ छिटपुट होने लगीं। पाँचवें हफ्ते तक एक व्यक्ति अभी भी इसे अपडेट कर रहा था, "auth के बारे में कुछ तय किया" जैसी चीजें लिख रहा था बिना किसी लिंक, संदर्भ या इस बात के संकेत के कि कौन शामिल था या विकल्प क्या थे। छठे हफ्ते तक हमने चुपचाप नाटक करना बंद कर दिया।
समस्या यह नहीं है कि हमारी टीम में अनुशासन की कमी है (मतलब, शायद, लेकिन यह यहाँ प्रासंगिक मुद्दा नहीं है)। समस्या यह है कि निर्णय लॉगिंग बिल्कुल गलत क्षण पर एक कर लगाता है। आपने अभी एक उत्पादक चर्चा की है, संरेखण प्राप्त किया है, कोई निर्माण शुरू करने के लिए तैयार है – और अब आपको रुकना होगा, एक अलग टूल खोलना होगा, सारांश लिखना होगा, संबंधित लोगों को टैग करना होगा और मूल बातचीत से वापस लिंक करना होगा। यह प्रति निर्णय तीन से पाँच मिनट है, और एक ऐसी टीम के लिए जो चैनलों और थ्रेडों में प्रतिदिन पाँच से दस सार्थक निर्णय लेती है, ओवरहेड ऐसी चीज में जमा हो जाता है जिसे कोई भी स्वामित्व नहीं लेना चाहता।
और सिस्टम केवल 100% अनुपालन पर काम करता है। 70% निर्णयों वाला निर्णय लॉग कुछ मायनों में बिना लॉग के भी बदतर है, क्योंकि अब आप दो जगहें जाँच रहे हैं और किसी पर भरोसा नहीं कर रहे। आप लॉग में देखते हैं, निर्णय वहाँ नहीं है, तो वैसे भी Slack सर्च करते हैं – और आप वापस वहीं हैं जहाँ से शुरू किया था, सिवाय इसके कि अब आपने पहले लॉग जाँचने में दो मिनट भी बर्बाद किए।
निर्णय घटनाएं नहीं हैं – वे ग्रेडिएंट हैं
मैन्युअल लॉगिंग के विफल होने का एक कारण यह है कि यह मानता है कि निर्णय असतत, पहचाने जाने योग्य क्षण होते हैं। वास्तव में, अधिकांश निर्णय बातचीत के माध्यम से धीरे-धीरे उभरते हैं, और "निर्णय का क्षण" अक्सर वास्तव में अस्पष्ट होता है।
विचार करें कि एक विशिष्ट इंजीनियरिंग निर्णय वास्तव में कैसे प्रकट होता है। कोई Figma कमेंट में चिंता उठाता है: "यह इंटरेक्शन पैटर्न मोबाइल पर काम नहीं कर सकता।" एक इंजीनियर Slack थ्रेड में जवाब देता है, मूल कमेंट को टैग करते हुए: "हाँ, मैंने यह देखा – कम्पोनेंट लाइब्रेरी इसे सपोर्ट नहीं करती।" एक डिज़ाइनर उसी थ्रेड में एक वैकल्पिक अप्रोच सुझाता है। इंजीनियर कहता है "यह काम करता है, मुझे प्रोटोटाइप बनाने दो।" दो दिन बाद, विकल्प को लागू करते हुए एक PR खुलता है, और Linear इश्यू अपडेट होता है।
निर्णय कहाँ लिया गया? क्या यह Figma कमेंट था जिसने समस्या उठाई? वह Slack थ्रेड जहाँ विकल्प प्रस्तावित किया गया? वह क्षण जब इंजीनियर ने "यह काम करता है" कहा? वह PR जिसने इसे लागू किया? व्यवहार में, निर्णय उन चार क्षणों में वितरित था, दो टूल्स और तीन दिनों में फैला। यह कोई ऐसी घटना नहीं थी जिसे आप लॉग कर सकते थे – यह एक ग्रेडिएंट था जो एक परिणाम में हल हुआ, और हम केवल इसलिए जानते हैं कि एक निर्णय लिया गया क्योंकि कोड बदल गया।
यही (मुझे लगता है) वह हिस्सा है जो अधिकांश "निर्णय ट्रैकिंग" सलाह गलत करती है। यह निर्णयों को ऐसी चीजों के रूप में मानती है जिन्हें आप कैप्चर करते हैं, जैसे फोन नंबर लिखना। लेकिन अधिकांश वास्तविक निर्णय ऐसी चीजें हैं जिन्हें आप पुनर्निर्मित करते हैं – आप देखते हैं क्या बदला, उन बातचीतों को पीछे की ओर ट्रेस करते हैं जो वहाँ तक पहुँचीं, और तथ्य के बाद तर्क को एक साथ जोड़ते हैं। जिसका अर्थ है कि आपको जिस सिस्टम की जरूरत है वह लॉग नहीं है। यह एक ग्राफ है।
एक ग्राफ आपको क्या देता है जो एक लॉग नहीं दे सकता
एक ग्राफ टूल्स और समय में सिग्नल को जोड़ता है। किसी के मैन्युअल रूप से "हमने रेट लिमिट की वजह से webhooks उपयोग करने का फैसला किया" लिखने के बजाय, ग्राफ उस Slack थ्रेड को जोड़ता है जहाँ रेट लिमिट पर चर्चा हुई थी, वह Linear इश्यू जो इंटीग्रेशन कार्य को ट्रैक कर रहा था, वह PR जिसने webhooks लागू किए, और बातचीत में शामिल लोगों को। निर्णय दर्ज नहीं किया जाता – यह पहले से हो रही चीजों के बीच के कनेक्शन से पुनर्निर्माण योग्य है।
व्यावहारिक अंतर एक विशिष्ट परिदृश्य में दिखाई देता है। webhook निर्णय के तीन हफ्ते बाद, एक नया इंजीनियर जुड़ता है और पूछता है: "हम GitHub के लिए पोलिंग की जगह webhooks का उपयोग क्यों कर रहे हैं? पोलिंग सरल लगती है।" बिना किसी जुड़े सिस्टम के, कोई कहता है "ओह, हमने यह कुछ समय पहले तय किया था", किसी को याद नहीं कौन-सा चैनल था, कोई Slack में खोजने में पंद्रह मिनट बिताता है, और या तो उसे मिलता है या (अधिक संभावना है) स्मृति से तर्क को पुनर्निर्मित करता है, जो जोखिम भरा है क्योंकि स्मृति अविश्वसनीय है और मूल तर्क लगभग निश्चित रूप से उससे अधिक सूक्ष्म था जो कोई तीन हफ्ते बाद याद करता है।
एक ग्राफ के साथ, इंजीनियर GitHub इंटीग्रेशन टास्क देखता है। हर सिग्नल जिसने उस टास्क को छुआ वह जुड़ा हुआ है: रेट लिमिट के बारे में मूल चर्चा, वह थ्रेड जहाँ पोलिंग बनाम webhooks का मूल्यांकन किया गया था, वह PR जिसने बदलाव लागू किया। पूरी निर्णय-सूत्र, शुरू से अंत तक, बिना किसी ने कुछ खोजे और बिना किसी ने कुछ लॉग किए।
अंतर "अच्छी सर्च" और "बुरी सर्च" के बीच नहीं है – यह कीवर्ड द्वारा रिट्रीवल और संबंध द्वारा रिट्रीवल के बीच है। निर्णय उन्हें व्यक्त करने के लिए उपयोग किए गए शब्दों से नहीं, बल्कि कार्यों, लोगों और परिणामों के साथ उनके कनेक्शन से परिभाषित होते हैं।
वे लागत जो किसी डैशबोर्ड पर नहीं दिखतीं
मैं ईमानदारी से उन लोगों के प्रति संशयात्मक हूँ जो इन जैसी अमूर्त लागतों के लिए सटीक संख्याओं का दावा करते हैं ("टीमें प्रति सप्ताह X घंटे बर्बाद करती हैं" की सांख्यिकी की शैली हमेशा ऐसी लगती है जैसे इसे एक वांछित निष्कर्ष से उल्टा निकाला गया हो), लेकिन यहाँ वह है जो हमने अपनी टीम में देखा है।
सबसे स्पष्ट लागत पुनर्विचार है – जब कोई मूल निर्णय नहीं खोज सकता, तो टीमें बस उसे फिर से खोल देती हैं, कभी-कभी इसलिए कि लोग वास्तव में याद नहीं करते और कभी-कभी इसलिए कि नए टीम सदस्य के पास वैध प्रश्न हैं जिनका कोई भी विशेष रूप से जवाब नहीं दे सकता। हमारे पास निर्णयों को उनके स्रोत तक ट्रेस करने का कोई तरीका होने से पहले हम नियमित रूप से सुलझे हुए प्रश्नों को फिर से उठा रहे थे, और प्रत्येक पुनर्विचार अपना स्वयं का ओवरहेड लाता है: मीटिंग का समय, किसी ऐसी चीज पर बहस करने की भावनात्मक थकान जो आपको पक्का लगता है पहले ही हल हो चुकी थी, यह नागवार संदेह कि मूल तर्क जितना कोई याद करता है उससे अधिक सूक्ष्म था।
अधिक सूक्ष्म लागत वह है जो ऑनबोर्डिंग के दौरान होती है। नए टीम सदस्य का हर "यह इस तरह क्यों किया गया?" सवाल किसी ऐसे व्यक्ति को बाधित करता है जो मूल निर्णय में था, और जवाब हर बार जब कोई पूछता है स्मृति से पुनर्निर्मित होता है, प्रत्येक पुनर्कथन के साथ मूल तर्क से थोड़ा और दूर जाता है – टेलीफोन के खेल की तरह, सिवाय इसके कि फोन एंटरप्राइज़ सॉफ़्टवेयर है और संदेश है "आर्किटेक्चर इस तरह क्यों काम करता है।" और एक विश्वसनीयता अंतर है जो समय के साथ बढ़ता है: "हम webhooks के साथ गए" का "हम webhooks के साथ गए क्योंकि पोलिंग हमारी GitHub API रेट लिमिट का 40% खा रही थी और हम पीक घंटों के दौरान थ्रॉटलिंग से टकरा रहे थे" से कम वजन है। तर्क वही है जो भविष्य के इंजीनियरों को यह मूल्यांकन करने में सक्षम बनाता है कि क्या कोई निर्णय बदली हुई परिस्थितियों में अभी भी सही है, और वह तर्क किसी Slack थ्रेड में कहीं बैठा है, पूरी तरह से सुरक्षित और व्यावहारिक रूप से अदृश्य।
Slack स्क्रॉल में निर्णय खोना बंद करें। Sugarbug पूरी निर्णय-सूत्र ट्रेस करता है – Slack थ्रेड से Linear इश्यू तक PR तक – स्वचालित रूप से।
Q: Slack में पुराने निर्णय खोजना इतना कठिन क्यों है? A: Slack संदेशों को कालानुक्रमिक रूप से संग्रहीत करता है, अर्थ के आधार पर नहीं। थ्रेड में दबा हुआ एक निर्णय किसी भी अन्य उत्तर जैसा दिखता है – Slack सर्च कीवर्ड मिला सकती है, लेकिन पूरे बातचीत संदर्भ को पढ़े बिना "हमने Redis का उपयोग करने का निर्णय लिया" और "क्या हमें Redis का उपयोग करना चाहिए?" में अंतर नहीं कर सकती। जितना अधिक समय बीतता है, उतना ही कठिन हो जाता है, क्योंकि आप वे संदर्भगत सुराग खो देते हैं (कौन शामिल था, कौन-सा चैनल, कौन-सा हफ्ता) जो सर्च को पहले स्थान पर व्यवहार्य बनाते हैं।
Q: क्या Sugarbug Slack में किए गए निर्णयों को स्वचालित रूप से ट्रैक करता है? A: हाँ। Sugarbug Slack और अन्य जुड़े टूल्स से आने वाले सिग्नल को वर्गीकृत करता है, निर्णय-जैसे पैटर्न की पहचान करता है – ऐसे थ्रेड जो टास्क को संदर्भित करते हैं, असाइन किए गए लोगों को शामिल करते हैं और स्टेटस बदलाव या PR का परिणाम देते हैं। इन्हें नॉलेज ग्राफ़ में संबंधित टास्क से जोड़ा जाता है, ताकि आप Slack इतिहास खोजने की बजाय टास्क से निर्णय-सूत्र ट्रेस कर सकें।
Q: निर्णय लॉग और निर्णयों के लिए नॉलेज ग्राफ़ में क्या अंतर है? A: निर्णय लॉग के लिए किसी को प्रत्येक निर्णय को मैन्युअल रूप से दर्ज करना होता है जब वह होता है – उसे नोटिस करना, रुकना, सारांश बनाना, टैग करना, लिंक करना। नॉलेज ग्राफ़ आपके टूल्स से प्रवाहित होने वाले सिग्नल से निर्णयों का अनुमान लगाता है और उन्हें स्वचालित रूप से टास्क, लोगों और बातचीत से जोड़ता है। एक हर टीम सदस्य से लगातार अनुशासन पर निर्भर करता है; दूसरा पहले से हो रही गतिविधि से पृष्ठभूमि में चलता है।
Q: क्या Sugarbug Slack के अलावा अन्य टूल्स से निर्णय निकाल सकता है? A: Sugarbug Slack, GitHub, Figma, Linear, Notion, ईमेल और कैलेंडर से जुड़ता है। निर्णय अक्सर कई टूल्स में फैले होते हैं (एक Figma कमेंट एक Slack थ्रेड की ओर जाता है जो एक PR की ओर जाता है), और नॉलेज ग्राफ़ सभी जुड़ी सतहों पर सिग्नल को जोड़ता है। आप पूरी सूत्र देखते हैं चाहे बातचीत किस टूल में शुरू हुई हो।
Q: यह Slack की अंतर्निहित सर्च का उपयोग करने से कैसे अलग है? A: Slack सर्च ऐसे संदेश खोजती है जिनमें विशिष्ट कीवर्ड हैं। नॉलेज ग्राफ़ संदेशों, टास्क और लोगों के बीच संबंध खोजता है। जब आप कोई निर्णय खोज रहे हों, तो आप शायद ही कभी किसी शब्द की तलाश कर रहे होते हैं – आप उस क्षण की तलाश कर रहे होते हैं जब एक टीम ने एक अप्रोच को दूसरे पर चुना, और वह क्षण इसे व्यक्त करने के लिए उपयोग किए गए शब्दों से नहीं बल्कि अन्य सिग्नल के साथ उसके कनेक्शन से परिभाषित होता है।
---
यदि निर्णय आपके Slack इतिहास में गायब होते रहते हैं, तो समस्या Slack नहीं है – समस्या यह है कि कोई सिस्टम उन क्षणों को नहीं देख रहा जो मायने रखते हैं और उन्हें उस कार्य से नहीं जोड़ रहा जो उन्होंने आकार दिया। यही वह अंतर है जिसे हम Sugarbug से भरने के लिए बना रहे हैं।