टीम · अप्रूवल
हर साइन-ऑफ़, एक ही इनबॉक्स में
लाइब्रेरी रिव्यू, कैंपेन प्लान, लॉन्च रिक्वेस्ट और छुट्टी, सब एक ही जगह इंतज़ार करते हैं, और हर एक का फ़ैसला उसी टूल के नियमों से होता है जिसका वह हिस्सा है। देखें कि यह कैसे काम करता है, या वर्कस्पेस बनाकर अपना पहला प्लान अप्रूवल के लिए भेजें।
क्या आपके पास पहले से वर्कस्पेस है? साइन इन करें
- प्लान $99 प्रति माह से
- मल्टी-क्लाइंट एजेंसियों के लिए बना
- पूरे कंसोल में आपका ब्रांड
टीम · अप्रूवल
एजेंसियों के लिए अप्रूवल वर्कफ़्लो सॉफ़्टवेयर, हर फ़ैसले के लिए एक इनबॉक्स के साथ
ज़्यादातर एजेंसियों में साइन-ऑफ़ का मतलब है चैट का एक मैसेज: “अच्छा लग रहा है, भेज दीजिए।” वह किसी वर्शन से जुड़ा नहीं होता, एक महीने बाद उसे कोई ढूंढ नहीं पाता, और जिस साथी ने बाद में फ़ाइल एडिट की, उसने उसे कभी देखा ही नहीं। AI Marketing Dashboard का अप्रूवल इसकी जगह एक ऐसा अप्रूवल वर्कफ़्लो सॉफ़्टवेयर देता है जो एक इनबॉक्स के आसपास बना है। रिव्यू के लिए भेजे गए लाइब्रेरी एसेट, अप्रूवल के लिए सबमिट किए गए कैंपेन प्लान, किसी के मांगे गए लॉन्च और छुट्टी की रिक्वेस्ट, सब वहीं इंतज़ार करते हैं, और हर एक का फ़ैसला वही व्यक्ति करता है जिसे इसकी अनुमति है, उस टूल के नियमों से जिसका वह हिस्सा है। अप्रूवल मिलने के बाद एडिट किया गया प्लान खुद बता देता है कि वह बदल गया है, और कोई लॉन्च किसी पुरानी हामी के भरोसे आगे नहीं जा सकता।
चैट या इनबॉक्स
हां कहां दर्ज रहती है, इसी से तय होता है कि उस पर भरोसा किया जा सकता है या नहीं
साइन-ऑफ़ उतना ही भरोसेमंद होता है जितना वह रिकॉर्ड, जो वह पीछे छोड़ता है। थ्रेड में दिए गए एक थंब्स-अप को ऐसे फ़ैसले के बगल में रखकर देखें जो वहां लिया गया हो जहां नियम उसे देख सकते हैं।
मैसेज से साइन-ऑफ़
- चैट थ्रेड में दी गई एक हां, जो किसी वर्शन से जुड़ी नहीं है
- ईमेल में दिया गया ऐसा अप्रूवल जिसे अगला व्यक्ति कभी नहीं देखता
- ओके मिलने के बाद एडिट हुआ प्लान, और किसी को खबर नहीं
- ज़ुबानी मांगा गया लॉन्च
- जिस मैसेज में बात पहले आई, उसी में तय हुई छुट्टी
हर हां सच्ची थी, और बाद में उनमें से किसी की भी जांच नहीं की जा सकती।
एक इनबॉक्स में साइन-ऑफ़
- ज़्यादा से ज़्यादा पांच टैब में वह सब जमा होता है जो किसी व्यक्ति पर रुका है
- प्लान का अप्रूवल उसी रूप में प्लान को कवर करता है जिस रूप में वह अप्रूव हुआ था
- जो प्लान वापस भेजा जाए, या जो लॉन्च या छुट्टी की रिक्वेस्ट ठुकराई जाए, उसके साथ लिखित कारण रहता है
- लॉन्च रिक्वेस्ट “Publish” अनुमति वाले किसी व्यक्ति का इंतज़ार करती हैं
- प्लान, लॉन्च और लाइब्रेरी वाली रो उसी रिकॉर्ड को खोलती हैं जिसके बारे में वे हैं
हर फ़ैसला उस टूल के नियम जस के तस रखता है जिसका वह है, इसलिए इनबॉक्स कोई शॉर्टकट नहीं जोड़ता।
इनबॉक्स
सुबह के फ़ैसले एक ही राउंड में निपटाएं
जो कुछ किसी व्यक्ति पर रुका है, वह इस हिसाब से सूचीबद्ध होता है कि वह क्या है और अगला कदम किसे उठाना है, इसलिए दिन के पहले दस मिनट एक ही पेज पर एक राउंड में निकल जाते हैं।
बिना टैब-दर-टैब भटके लाइब्रेरी, लॉन्च और छुट्टी के फ़ैसले
- “All”, “Library”, “Plans”, “Launches” और “Time off” के टैब, जिनमें “Time off” सिर्फ़ एडमिन के लिए
- अप्रूव हुए प्लान 14 दिन तक सूची में रहते हैं
- क्लाइंट फ़िल्टर, जो हेडर के स्विचर वाले क्लाइंट से शुरू होता है
एक प्लान का सफ़र
सबमिट हुए प्लान से उस लॉन्च तक, जिसे चलने की इजाज़त मिल चुकी है
चार कदम एक प्लान को उसे बनाने वाले व्यक्ति से उसे पब्लिश करने वाले व्यक्ति तक पहुंचाते हैं, और हर कदम अपने पीछे एक रिकॉर्ड छोड़ जाता है।
रिव्यूअर के साथ सबमिट करें
जो भी प्लान बनाता है, वह उसे अप्रूवल के लिए भेजता है और चाहे तो रिव्यूअर का नाम दे सकता है। क्लाइंट के “Marketing Plans” प्रोजेक्ट में एक रिव्यू टास्क आ जाता है, जिसकी तारीख तीन दिन बाद की होती है, और रिव्यूअर का नाम दिया गया हो तो वह टास्क उसी को असाइन हो जाता है। सूचनाओं की घंटी और एक ईमेल उसे बता देते हैं जिसे फ़ैसला करना है।प्लान जैसा है, उसी पर फ़ैसला करें
अप्रूवर उसे अप्रूव करता है, या नोट के साथ वापस भेज देता है। सबमिट करने वाला अपना प्लान अप्रूव नहीं कर सकता। एजेंसी एडमिन कर सकता है, और इतिहास में दर्ज हो जाता है कि उसने ऐसा किया।इसे लॉन्च में खोलें
अप्रूव हुआ प्लान अपने चैनल के लॉन्च पेज पर “Ready to launch” (लॉन्च के लिए तैयार) के नीचे दिखता है। पहले प्लान को एडिट कर दें, तो उस पर बदले जाने का निशान लग जाता है, और जब तक वह दोबारा अप्रूव नहीं होता, लॉन्च ठुकरा दिया जाता है।खुद न कर सकें, तो पब्लिशर से कहें
“Publish” अनुमति के बिना टीममेट इसकी जगह लॉन्च रिक्वेस्ट भेजता है। पब्लिशर जांच पढ़ता है, अप्रूव करता है या कारण के साथ ठुकराता है, और अप्रूव करते समय जांच दोबारा चलती है।
वॉकथ्रू देखें
देखें कि लाइब्रेरी एसेट, प्लान और लॉन्च रिक्वेस्ट पर फ़ैसला कैसे होता है
वॉकथ्रू इंतज़ार कर रही चीज़ों से शुरू होता है, एक एसेट को वैसे खोलता है जैसे क्लाइंट उसे देखेगा, उसे कारण के साथ वापस भेजता है, एक प्लान अप्रूव करता है, और इस पर खत्म होता है कि लॉन्च रिक्वेस्ट एक अलग फ़ैसला क्यों है।
- 0:00वह सब देखें जो आप पर रुका है
- 0:06एसेट को वैसे खोलें जैसे क्लाइंट देखेगा
- 0:11साफ़ कारण के साथ वापस भेजें
- 0:20प्लान को जैसा है वैसा ही अप्रूव करें
- 0:29लॉन्च रिक्वेस्ट अलग होती हैं
42 सेकंड
ट्रांसक्रिप्ट पढ़ें
0:00 वह सब देखें जो आप पर रुका है। लाइब्रेरी एसेट, प्लान, लॉन्च और छुट्टी एक ही इनबॉक्स में आते हैं। उसे क्लाइंट के हिसाब से फ़िल्टर करें।
0:06 एसेट को वैसे खोलें जैसे क्लाइंट देखेगा। लाइब्रेरी रिव्यू फ़ुल स्क्रीन में खुलते हैं और एसेट को ठीक वैसा दिखाते हैं जैसा क्लाइंट उसे देखता है।
0:11 साफ़ कारण के साथ वापस भेजें। “Request changes” (बदलाव मांगें) के लिए नोट ज़रूरी है। बताएं कि क्या ठीक करना है, ताकि एसेट बनाने वाला उस पर कदम उठा सके।
0:20 प्लान को जैसा है वैसा ही अप्रूव करें। एजेंसी एडमिन Alex Morgan, Jordan Lee के प्लान को ठीक वैसा ही अप्रूव करते हैं जैसा वह लिखा गया है।
0:29 लॉन्च रिक्वेस्ट अलग होती हैं। लॉन्च “Publish” वाले किसी व्यक्ति का इंतज़ार करता है। हाथ से होने वाले लॉन्च को अप्रूव करने से सिर्फ़ एक टास्क बनता है।
हर फ़ैसला ऐसी जगह रखें जहां नियम उसे देख सकें
अपनी टीम और अपने क्लाइंट को एक नए वर्कस्पेस में जोड़ें, फिर पहला प्लान अप्रूवल के लिए भेजें और उसे इनबॉक्स में पहुंचते देखें।
प्लान $99 प्रति माह से शुरू होते हैं।
इस पेज पर
लाइब्रेरी रिव्यू, प्लान, लॉन्च और छुट्टी के लिए अप्रूवल वर्कफ़्लो सॉफ़्टवेयर का एक ही इनबॉक्स
पांच तक टैब, हर टैब पर एक गिनती, और स्विचर के साथ चलने वाला क्लाइंट फ़िल्टर
“टीम > अप्रूवल” एक ही पेज खोलता है, जिसमें पांच तक टैब होते हैं: “All”, “Library”, “Plans”, “Launches” और “Time off”। “Time off” टैब सिर्फ़ एजेंसी एडमिन को दिखता है। हर टैब पर वह गिनती रहती है कि कितने आइटम किसी व्यक्ति के फ़ैसले का इंतज़ार कर रहे हैं; “All” हर स्रोत से इंतज़ार कर रहे पहले पांच आइटम दिखाता है, साथ में “View all” लिंक भी, और क्लाइंट फ़िल्टर क्लाइंट के काम को एक अकाउंट तक सीमित कर देता है। फ़िल्टर उसी क्लाइंट पर शुरू होता है जिस पर हेडर का स्विचर सेट है, बशर्ते उस क्लाइंट का कोई आइटम इनबॉक्स में हो, और एक क्लिक में वह हर क्लाइंट तक फैल जाता है। छुट्टी क्लाइंट का काम नहीं है, इसलिए “Time off” टैब फ़िल्टर को अनदेखा करता है और “Workspace-wide” लेबल से यह साफ़ बता देता है।
कुछ भी किसी दूसरे सिस्टम में कॉपी नहीं होता। लाइब्रेरी रिव्यू का फ़ैसला अब भी उसकी रिव्यू स्क्रीन पर होता है, प्लान का उसके अप्रूवल से, लॉन्च का उसके रिकॉर्ड से और छुट्टी का टाइम-ऑफ़ रिक्वेस्ट से, इसलिए इनबॉक्स अपना कोई नियम नहीं जोड़ता, और न कोई चोर-दरवाज़ा। यह तब रीफ़्रेश होता है जब आप टैब पर लौटते हैं, और खुला रहने पर हर मिनट। प्लान या लॉन्च की सूचना से, या आपके इंतज़ार में बैठी लाइब्रेरी की किसी सूचना से आने वाला लिंक सीधे सही टैब में उसी आइटम पर खुलता है, इसलिए अप्रूवर को ढूंढने के लिए कोई सूची नहीं मिलती, वह सीधे उसी चीज़ पर पहुंचता है जिसके बारे में उससे पूछा गया था।
अप्रूवल उसी प्लान को कवर करता है जैसा वह अप्रूव हुआ था
प्लान बाद में बदलें तो वह “Changed since approval” पढ़ता है
साइन-ऑफ़ की कीमत तभी है जब वह अब भी उसी चीज़ का ब्योरा हो जो भेजी जा रही है। कैंपेन प्लान अप्रूव होते ही सर्वर उसके कंटेंट का एक फ़िंगरप्रिंट दर्ज कर लेता है: नाम, चैनल, थीम, प्लेटफ़ॉर्म, ऑडियंस और सेटिंग्स, ईमेल प्लान जो लाइब्रेरी टेम्पलेट भेजता है, और वह सेव की हुई ऑडियंस जिसे ईमेल, SMS या पेड प्लान टारगेट करता है, यानी उसकी परिभाषा और, फ़िक्स्ड लिस्ट हो तो, उसके सदस्य। नियमों पर आधारित सेगमेंट उस दिन किसे मैच करता है, यह उसमें शामिल नहीं है। इनमें से कुछ भी बाद में बदलें तो फ़िंगरप्रिंट मेल नहीं खाता। तब प्लान जहां भी उसका अप्रूवल दिखता है, वहां “Changed since approval” पढ़ता है, और उसे दोबारा सबमिट करके अप्रूव कराए बिना वह लॉन्च नहीं हो सकता।
यह तुलना सर्वर प्लान की मौजूदा हालत से करता है, स्क्रीन से कभी नहीं, और जहां इसका सबसे ज़्यादा मतलब है वहां इसे दोहराता है: जब लॉन्च बनाया जाता है, जब लॉन्च रिक्वेस्ट अप्रूव होती है, और शेड्यूल किया गया लॉन्च चलने से ठीक पहले। कतार में इंतज़ार करते हुए एडिट हुआ प्लान भी अप्रूव नहीं हो सकता; इनबॉक्स बताता है कि उसे दोबारा सबमिट करना होगा। लाइब्रेरी एसेट का रिव्यू अलग तरह से होता है: उन पर एक स्टेटस रहता है, और अप्रूव हो चुके एसेट को एडिट करने से वह रीसेट नहीं होता, इसलिए काम बदलने पर रिव्यूअर रिव्यू को दोबारा खोलता है।
काम को ऐसी वजह के साथ वापस भेजें जिस पर सबमिट करने वाला कुछ कर सके
प्लान वापस भेजने, या लॉन्च या छुट्टी ठुकराने के लिए लिखित कारण ज़रूरी है
प्लान, लॉन्च या छुट्टी की रिक्वेस्ट अप्रूव करने के लिए एक क्लिक और एक पुष्टि चाहिए, साथ में चाहें तो एक नोट। बदलाव मांगने के लिए एक क्लिक और एक वाक्य चाहिए, और वह वाक्य ज़रूरी है: जब तक नोट में न लिखा हो कि क्या बदलना है, प्लान वापस नहीं भेजा जा सकता; बिना कारण के लॉन्च ठुकराया नहीं जा सकता, और छुट्टी की रिक्वेस्ट भी नहीं। लाइब्रेरी रिव्यू स्क्रीन भी बदलाव मांगते समय नोट मांगती है। प्लान सबमिट करने वाले के पास “Changes requested” के साथ लौट जाता है, रिव्यू टास्क नोट के साथ उसकी सूची में वापस चला जाता है, और आइटम अप्रूवर की इंतज़ार वाली गिनती से हट जाता है।
इससे बार-बार सुधारने का काम चैट से बाहर रहता है। सबमिट करने वाला कारण वहीं पढ़ता है जहां उसने काम सबमिट किया था, एडिट करता है और फिर सबमिट करता है, और अप्रूवर को वह एक नए सबमिशन की तरह मिलता है, जांचने के लिए नए फ़िंगरप्रिंट के साथ। लाइब्रेरी में रिव्यू स्क्रीन एसेट को वैसे दिखाती है जैसे क्लाइंट उसे देखेगा, और कमेंट प्रीव्यू पर किसी जगह पिन किए जा सकते हैं, इंटरनल रखे जा सकते हैं, या “Publish” अनुमति वाला कोई व्यक्ति उन्हें क्लाइंट से शेयर कर सकता है, ताकि फ़ीडबैक चीज़ की तरफ़ इशारा करे, उसे याद के भरोसे बयान न करे।
क्लाइंट का अप्रूवल पोर्टल में होता है, एसेट पर ही
अप्रूवल रिक्वेस्ट, पिन की गई बदलाव की रिक्वेस्ट और क्रिएटिव के लिए वर्शन की पट्टी
क्लाइंट का रिव्यू तभी शुरू होता है जब आपकी टीम एसेट को अप्रूव कर चुकी हो या स्किप दर्ज कर चुकी हो। “Publish” अनुमति वाला कोई व्यक्ति उसे क्लाइंट के पोर्टल में शेयर करता है और जवाब मांगता है, साथ में एक वैकल्पिक नोट जोड़ सकता है जो क्लाइंट पढ़ता है। रिव्यू पैनल में एक हेडिंग आपकी एजेंसी का नाम लेकर बताती है कि वह अप्रूवल मांग रही है। “Approve” सिर्फ़ पोर्टल एडमिन को दिखता है। कोई भी पोर्टल सदस्य “Request changes” चुन सकता है, जो लिखित नोट मांगता है और ठीक उसी जगह पर एक पिन भी लगा सकता है। रिव्यू के दौरान किसी क्रिएटिव का आर्टवर्क बदला गया हो, तो उसके पुराने वर्शन एक पट्टी में दिखते हैं, और हर पिन याद रखता है कि वह किस वर्शन पर लगाया गया था।
आपकी टीम को जवाब “Client approved” या “Client requested changes” के रूप में दिखता है, और जिसने रिव्यू मांगा था और जिसने एसेट सबमिट किया था, उन्हें उसी समय अलर्ट मिल जाता है, उनकी सूचना सेटिंग्स के हिसाब से। पोर्टल एडमिन एक घंटे तक अपना अप्रूवल वापस ले सकता है, जिससे एसेट “Awaiting client review” में लौट जाता है। बदलाव वापस आएं तो आप एसेट एडिट करते हैं और फिर से पूछते हैं। इंटरनल कमेंट और रिव्यू का इतिहास आपकी तरफ़ ही रहते हैं: पोर्टल को रिक्वेस्ट का नोट, क्लाइंट का अपना फ़ैसला और “shared” मार्क किए गए कमेंट मिलते हैं। क्लाइंट पोर्टल Scale और Enterprise प्लान का हिस्सा हैं, जबकि इंटरनल अप्रूवल हर प्लान पर काम करता है।
अपना प्लान कोई खुद अप्रूव नहीं करता, और इकलौता अपवाद दर्ज होता है
एजेंसी एडमिन अपना काम अप्रूव कर सकता है, और रिकॉर्ड यह बताता है
एक व्यक्ति का सबमिट किया प्लान कोई दूसरा अप्रूव करता है। सबमिट करने वाला कोशिश करे तो सर्वर सीधे शब्दों में मना कर देता है, और इनबॉक्स में जहां “Approve” बटन होता, वहां बटन की जगह एक संकेत दिखता है। सबमिशन पर नामित रिव्यूअर एक संकेतक है, ताला नहीं: उस क्लाइंट की अप्रूव अनुमति रखने वाला कोई भी साथी फ़ैसला कर सकता है, इसलिए जब तक कोई दूसरा अप्रूवर मौजूद है, एक व्यक्ति की गैरहाज़िरी से कैंपेन अटकना नहीं चाहिए, और जिस सबमिशन में किसी का नाम न हो, उसे कोई भी अप्रूवर उठा सकता है।
एक अपवाद है, और वह निशान छोड़ता है। एजेंसी एडमिन अपना ही सबमिशन, या ऐसा प्लान जिसे किसी ने सबमिट नहीं किया, अप्रूव कर सकता है, और वह अप्रूवल “self-approved” (खुद अप्रूव किया) के रूप में सेव होता है और इनबॉक्स में उसी लेबल के साथ दिखता है; प्लान सबमिट हुआ था तो उसका रिव्यू टास्क भी इसे दर्ज करता है। जिस छोटी एजेंसी में मालिक ही स्ट्रैटेजिस्ट भी है, उसके लिए यह जुगाड़ नहीं, ईमानदार हिसाब-किताब है: इतिहास दिखाता है कि फ़ैसला किसने किया और यह भी कि किसी दूसरे व्यक्ति ने नहीं किया।
लॉन्च रिक्वेस्ट उस व्यक्ति का इंतज़ार करती हैं जिसे पब्लिश करने की अनुमति है
सर्वर की प्रीफ़्लाइट जांच अप्रूवल के क्षण पर दोबारा चलती है
कैंपेन बनाने वाले हर व्यक्ति को उसे लाइव करने की इजाज़त नहीं होती। लॉन्च के लिए उस क्लाइंट की “Publish” अनुमति चाहिए, और ईमेल या SMS लॉन्च के लिए क्लाइंट के CRM का ऐक्सेस भी, चाहे आप उसे लॉन्च करें, अप्रूव करें या मांगें। “Publish” के बिना भी कोई साथी रिक्वेस्ट कर सकता है। रिक्वेस्ट “Launches” के तहत “Waiting for launch approval” के रूप में दिखती है। रो में दिखता है कि किसने मांगा, उसका नोट, और रिक्वेस्ट के समय जांचें किस हाल में थीं, चेतावनियों समेत: जैसे लाइब्रेरी का कोई टेम्पलेट जो अभी अप्रूव नहीं हुआ। जो रिक्वेस्ट किसी जांच में फ़ेल हो, वह दर्ज होते समय ही ठुकरा दी जाती है, इसलिए इंतज़ार करती रिक्वेस्ट रोकने वाली जांचें पार कर चुकी होती है। पब्लिशर रिक्वेस्ट को अप्रूव करता है या ठुकराता है, और ठुकराने के लिए ऐसा कारण चाहिए जिसे रिक्वेस्ट करने वाला पढ़ सके।
अप्रूव करने से पहले पब्लिशर एक छोटी लाइन पढ़ता है कि आगे क्या होगा: ईमेल किन तक पहुंचेगा और वह तुरंत शुरू होगा या शेड्यूल पर, या यह कि मैन्युअल लॉन्च सिर्फ़ उस व्यक्ति के लिए एक टास्क बनाता है जो हाथ से पब्लिश करता है। फिर जांचें दोबारा चलती हैं, क्योंकि रिक्वेस्ट और उसके अप्रूवल के बीच चीज़ें बदल जाती हैं, और फ़ेल होती जांच को डायलॉग में गिनाया जाता है, पास नहीं कर दिया जाता। ईमेल लॉन्च भेजे जाते हैं; पेड, सोशल और SMS लॉन्च हाथ से किए गए काम के रूप में दर्ज होते हैं, और इनबॉक्स साफ़ बताता है कि कौन-सा कौन-सा है।
छुट्टी के फ़ैसले क्लाइंट के काम के बगल में हैं, पर उससे अलग
अप्रूव या ठुकराएं, और हर इनकार अपनी वजह खुद बताता है
छुट्टी की रिक्वेस्ट क्लाइंट का काम नहीं हैं, इसलिए उनका अपना एक टैब है, जो सिर्फ़ एजेंसी एडमिन को दिखता है और जिस पर “Workspace-wide” लिखा रहता है। हर रो में व्यक्ति का नाम, छुट्टी का प्रकार, तारीखें, गिने गए कामकाजी दिन और उनका छोड़ा कोई नोट होता है, और “Approve” या “Decline” वही डायलॉग खोलता है जो बाकी टैब इस्तेमाल करते हैं। ठुकराने के लिए ऐसा कारण चाहिए जिसे रिक्वेस्ट करने वाला पढ़ेगा, इसलिए इनकार कभी चुप्पी बनकर नहीं आता।
ये वही नियम हैं जिन पर HR का ज़ोर रहता है। आपकी अपनी रिक्वेस्ट आपके इनबॉक्स में कभी नहीं आतीं, और जब तक कोई दूसरा सक्रिय एजेंसी एडमिन मौजूद है, कोई अपनी छुट्टी का फ़ैसला खुद नहीं करता। सिर्फ़ ऐसे वर्कस्पेस में जहां एक ही एडमिन है, कोई अपनी रिक्वेस्ट पर खुद फ़ैसला कर सकता है, और रिकॉर्ड तब दिखाता है कि वह खुद का फ़ैसला था। रिक्वेस्ट करने वाले को नतीजा ईमेल से मिलता है, दिनों की गिनती सर्वर ने एक ही बार निकाली थी ताकि अप्रूव हुआ आंकड़ा वही रहे जो उन्होंने देखा था, और संदर्भ के लिए सदस्य की प्रोफ़ाइल एक क्लिक दूर है। यह अनुमति किसी टीम इंचार्ज को सौंपी नहीं जा सकती: यह एडमिन के पास ही रहती है।
“Also waiting”: जिनका फ़ैसला कहीं और होता है, उनकी गिनती
टाइमशीट और बुकिंग स्क्रिप्ट यहां गिने जाते हैं और अपने टूल में रिव्यू होते हैं
कुछ अप्रूवल को एक रो से ज़्यादा जगह चाहिए। टाइमशीट की एंट्री टाइमशीट में पूरे हफ़्ते को सामने रखकर रिव्यू होती हैं, और बुकिंग-स्क्रिप्ट के रिवीज़न स्क्रिप्ट के बगल में। इनबॉक्स उन्हें वहीं रहने देता है जहां उनका रिव्यू सबसे अच्छी तरह हो पाता है, और एक कार्ड जोड़ता है, “Also waiting”, जिसमें हर एक के लिए एक गिनती और “Open” लिंक है, ताकि जो एडमिन दिन की शुरुआत यहां से करता है, उसे यह जानने के लिए दूसरा टूल नहीं खोलना पड़ता कि कितनी एंट्री इंतज़ार में हैं।
गिनतियां या तो ईमानदार होती हैं या होती ही नहीं। हर स्रोत अपनी हालत खुद बताता है, और जो लोड नहीं हो पाता वह शून्य की जगह रीट्राई के साथ एक एरर कार्ड दिखाता है; जो गिनती पढ़ी नहीं जा सकी, वह छोड़ दी जाती है, कभी “कोई नहीं” बनाकर नहीं छापी जाती। यही नियम पूरे पेज पर लागू है: लाइब्रेरी की कोई टूटी हुई रीड “Plans” टैब को खाली नहीं कर सकती, और लंबी कतार बताती है कि वह सबसे नए आइटम पर काटी गई है, यह जताती नहीं कि बस इतना ही है।
अप्रूवल मैट्रिक्स: कौन-सा फ़ैसला कौन करेगा, और किस अनुमति से
पहला लॉन्च करने से पहले इसे एक बार तय कर लें, तो किसे अप्रूव करना चाहिए था, इस पर आगे की हर बहस छोटी हो जाती है। अप्रूवल वर्कफ़्लो सॉफ़्टवेयर के रूप में कंसोल आज क्या लागू करता है, यह टेबल एक-एक रो में बताती है।
| क्या इंतज़ार में है | कौन सबमिट करता है | कौन फ़ैसला करता है | दूसरे व्यक्ति की ज़रूरत | फ़ैसले का असर |
|---|---|---|---|---|
| लाइब्रेरी एसेट: थीम, कीवर्ड लिस्ट, कॉपी, क्रिएटिव, लैंडिंग पेज, बुकिंग पेज, फ़ॉर्म या ईमेल | लाइब्रेरी एडिट कर सकने वाला कोई भी व्यक्ति | उस क्लाइंट के लिए “Approve” अनुमति रखने वाला कोई भी व्यक्ति | कंसोल यह लागू नहीं करता: अप्रूवर अपना सबमिट किया हुआ भी अप्रूव कर सकता है | अप्रूव हो चुके एसेट को, या जिसका अप्रूवल स्किप किया गया हो उसे, क्लाइंट के साथ शेयर किया जा सकता है |
| शेयर किए गए एसेट पर क्लाइंट का रिव्यू | एजेंसी रिव्यू मांगती है, “Publish” अनुमति रखने वाले व्यक्ति के ज़रिए | क्लाइंट: पोर्टल एडमिन अप्रूव करता है, पोर्टल का कोई भी सदस्य बदलाव मांग सकता है | दूसरा पक्ष क्लाइंट खुद है | जवाब रिव्यू पर दर्ज होता है, और अप्रूवल को एक घंटे के भीतर पलटा जा सकता है |
| कैंपेन प्लान | लाइब्रेरी एडिट कर सकने वाला कोई भी व्यक्ति | उस क्लाइंट के लिए “Approve” अनुमति रखने वाला कोई भी व्यक्ति | हां, एजेंसी एडमिन को छोड़कर, और वह अपवाद दर्ज किया जाता है | प्लान लॉन्च हो सकता है, बशर्ते बाद में कोई उसे एडिट न करे |
| लॉन्च रिक्वेस्ट | लाइब्रेरी एडिट कर सकने वाला कोई भी व्यक्ति; ईमेल और SMS के लिए CRM ऐक्सेस भी चाहिए | उस क्लाइंट के लिए “Publish” अनुमति रखने वाला कोई भी व्यक्ति; ईमेल और SMS के लिए CRM ऐक्सेस भी चाहिए | हमेशा: “Publish” के बिना आप लॉन्च नहीं कर सकते, इसलिए फ़ैसला पब्लिशर करता है | ईमेल लॉन्च शुरू हो जाता है या शेड्यूल हो जाता है, और हाथ से होने वाला लॉन्च एक टास्क बना देता है |
| छुट्टी की रिक्वेस्ट | टीम का कोई भी सदस्य, अपनी छुट्टी के लिए | सिर्फ़ एजेंसी एडमिन | हां, जब तक कोई दूसरा सक्रिय एजेंसी एडमिन मौजूद है | अप्रूव या ठुकराए जाने का फ़ैसला कारण के साथ दर्ज होता है, और रिक्वेस्ट करने वाले को ईमेल जाता है |
डिफ़ॉल्ट रूप से एजेंसी टीम का सदस्य लाइब्रेरी के एसेट और प्लान देख सकता है, बना सकता है और एडिट कर सकता है। इसका मतलब है कि वह प्लान को अप्रूवल के लिए सबमिट कर सकता है, पर अप्रूव या पब्लिश नहीं कर सकता। ईमेल या SMS कैंपेन को लॉन्च करने की रिक्वेस्ट के लिए यह भी ज़रूरी है कि रिक्वेस्ट करने वाले के पास CRM का ऐक्सेस हो, जो टीम के सदस्यों के पास डिफ़ॉल्ट रूप से नहीं होता। एजेंसी एडमिन के पास हर अनुमति रहती है। कोई एडमिन किसी टीम इंचार्ज को “Approve” या “Publish” अनुमति दे सकता है, एक-एक व्यक्ति को अलग से या किसी अनुमति टेम्पलेट के ज़रिए, और टीममेट सिर्फ़ उन्हीं क्लाइंट पर काम करता है जिन पर उसे असाइन किया गया है। छुट्टी के फ़ैसले किसी और को सौंपे ही नहीं जा सकते।
टिप
पहला लॉन्च करने से पहले मैट्रिक्स लिख लें
हर क्लाइंट के लिए तय करें कि प्लान कौन अप्रूव करेगा और पब्लिश कौन करेगा, और जहां हो सके, ये दोनों अलग-अलग लोग रखें। जहां दोनों काम एक ही व्यक्ति को करने पड़ें, वहां कंसोल इसे दर्ज कर लेता है, और यह ऐसा दिखावा करने से ज़्यादा ईमानदार रास्ता है कि किसी दूसरे की नज़र भी पड़ चुकी है।
सबमिट करने वाला, रिव्यूअर, अप्रूवर, पब्लिशर और रिक्वेस्ट करने वाला: हर भूमिका सीधे शब्दों में
यही पांच शब्द हर टैब पर आते हैं। हर शब्द का मतलब एक ही है।
- सबमिट करने वाला
- वह व्यक्ति जो प्लान को अप्रूवल के लिए भेजता है। वह प्लान एडिट और सबमिट करता है, और अपना प्लान अप्रूव नहीं कर सकता, जब तक वह एजेंसी एडमिन न हो।
- रिव्यूअर
- वह व्यक्ति जिसका नाम सबमिट करने वाला प्लान पर लिखता है। यह नाम बंदिश नहीं, सिर्फ़ सलाह है: इससे तय होता है कि किसे खबर मिले और रिव्यू टास्क का ओनर कौन बने, फिर भी कोई भी अप्रूवर फ़ैसला कर सकता है।
- अप्रूवर
- क्लाइंट के लिए “Approve” अनुमति रखने वाला कोई भी व्यक्ति। अप्रूवर लाइब्रेरी रिव्यू और प्लान अप्रूवल पर फ़ैसला करते हैं।
- पब्लिशर
- क्लाइंट के लिए “Publish” अनुमति रखने वाला कोई भी व्यक्ति। पब्लिशर अप्रूव हो चुके प्लान लॉन्च करते हैं, लॉन्च रिक्वेस्ट पर फ़ैसला करते हैं और क्लाइंट से लाइब्रेरी एसेट का रिव्यू मांगते हैं।
- रिक्वेस्ट करने वाला
- वह व्यक्ति जिसने “Publish” अनुमति के बिना लॉन्च मांगा। जब तक रिक्वेस्ट इंतज़ार में रहे, वह उसे खुद रद्द कर सकता है।
साइन-ऑफ़ को चैट और ईमेल से निकालकर इनबॉक्स में लाने के चार स्टेप
लोग अप्रूवल उसी जगह देते रहते हैं जहां वे पहले से बात कर रहे होते हैं। रोलआउट तब काम करता है जब इनबॉक्स मैसेज से ज़्यादा आसान पड़े, इसलिए एक क्लाइंट और एक तरह के फ़ैसले से शुरू करें।
आज आप जिन बातों पर हां कहते हैं, उनकी सूची बनाएं
एक हफ़्ते तक चैट या ईमेल में होने वाले हर साइन-ऑफ़ को नोट करें: कोई क्रिएटिव, लैंडिंग पेज, कैंपेन, लॉन्च या एक दिन की छुट्टी। इन्हें उन चार चीज़ों में बांट दें जो इनबॉक्स में आती हैं, और बाकी को वहीं रहने दें जहां वे हैं।
हर क्लाइंट के लिए अप्रूवर तय करें
हर क्लाइंट के लिए चुनें कि प्लान कौन अप्रूव करेगा और पब्लिश कौन करेगा, उन्हें ये अनुमतियां दें और उस क्लाइंट पर असाइन करें। जिस टीममेट को किसी क्लाइंट पर असाइन नहीं किया गया है, उसे उस क्लाइंट का काम इनबॉक्स में नहीं दिखेगा।
एक क्लाइंट पर दो हफ़्ते चलाकर देखें
सबमिट करने वालों से कहें कि वे रिव्यूअर का नाम दें और कारण नोट में लिखें। जब कोई चैट में हां मांगे, तो जवाब दें कि वह इनबॉक्स में है, और फ़ैसला वहीं करें। रिव्यू टास्क, सूचनाओं की घंटी और एक ईमेल रिव्यूअर को पहले ही बता देते हैं, इसलिए ज़्यादातर रिव्यूअर को बिना टोके खबर मिल जाती है।
इनबॉक्स को ही हां कहने की इकलौती जगह बनाएं
दो हफ़्ते बाद अगले क्लाइंट को भी इसी पर ले आएं। टीम को बता दें कि जिस लॉन्च का प्लान अप्रूव नहीं हुआ है, उसे कंसोल वैसे भी नामंज़ूर कर देता है। हर दिन की शुरुआत “All” (सभी) टैब से करें, और शून्य से ऊपर की किसी भी गिनती को सबसे पहला काम मानें।
“Changed since approval” आपको किस चीज़ से बचाता है
यह चेतावनी आपको बार-बार टोकने के लिए नहीं है। यह उस पल को चिह्नित करती है जब प्लान वह नहीं रह जाता जिस पर किसी ने सहमति दी थी।
| स्टेटस | इसका मतलब | आगे क्या होता है |
|---|---|---|
| “Pending” (इंतज़ार में) | सबमिट हो चुका है और अप्रूवर का इंतज़ार कर रहा है | रिव्यूअर फ़ैसला करता है: उसे अप्रूव करता है, या नोट के साथ लौटा देता है |
| “Changes requested” (बदलाव मांगे गए) | उस व्यक्ति के पास वापस भेज दिया गया जिसने उसे सबमिट किया था | वह प्लान को एडिट करता है और दोबारा सबमिट करता है |
| “Approved” (अप्रूव्ड) | अप्रूवर ने प्लान को वैसा ही स्वीकार किया जैसा वह उस समय था | उसे उसके चैनल के लॉन्च पेज से लॉन्च किया जा सकता है |
| “Changed since approval” (अप्रूवल के बाद बदला गया) | अप्रूव होने के बाद प्लान एडिट किया गया | लॉन्च होने से पहले उसे नया अप्रूवल चाहिए |
तुलना तीन चीज़ों को पढ़ती है: खुद प्लान; वे लाइब्रेरी ईमेल टेम्पलेट, जिन्हें ईमेल प्लान भेजता है; और ईमेल, SMS या पेड प्लान के पीछे की कोई भी सेव की हुई ऑडियंस, यानी ऑडियंस की परिभाषा और, स्टैटिक लिस्ट के मामले में, उसमें शामिल लोग। इनमें से किसी में भी हुआ एडिट गिना जाता है, उस टेम्पलेट का एडिट भी जिसे दूसरे कैंपेन साझा करते हैं। नियमों से तय होने वाला सेगमेंट भेजने के दिन तक अलग-अलग लोगों से मेल खा सकता है, फिर भी इससे अप्रूवल पुराना नहीं पड़ता। जो सबमिशन इंतज़ार के दौरान एडिट हो गया, उसे अप्रूव नहीं किया जा सकता, और उसकी रो पर लिखा होता है कि उसे दोबारा सबमिट करना होगा।
दो सीमाएं जान लेना काम आएगा। अगर लॉन्च शेड्यूल होने के बाद प्लान एडिट हो जाए, तो डिस्पैचर अपना काम करने से ठीक पहले दोबारा तुलना करता है, और तब लॉन्च साफ़ शब्दों में वजह बताते हुए फ़ेल हो जाता है, और कुछ भी नहीं भेजा जाता। और लाइब्रेरी एसेट अलग तरह से काम करते हैं: एसेट के साथ कंटेंट का फ़िंगरप्रिंट नहीं, रिव्यू स्टेटस रहता है, इसलिए अप्रूव हो चुके एसेट को एडिट करने से उसका रिव्यू जैसा था वैसा ही रहता है। काम बदले, तो रिव्यू को दोबारा खोलें।
अप्रूवर के लिए इनबॉक्स में दस मिनट का एक राउंड
इनबॉक्स ऊपर से खाली करने के लिए बना है। यह क्रम उन फ़ैसलों को पहले रखता है जो दूसरे लोगों को रोक रहे हैं।
“All” टैब से शुरू करें
टैब पर लिखी गिनतियां पढ़ें। अगर हेडर के क्लाइंट स्विचर ने क्लाइंट फ़िल्टर को एक ही अकाउंट तक सीमित कर रखा है, तो पहले उसका दायरा बढ़ाएं, ताकि कोई चीज़ उस फ़िल्टर के पीछे न अटकी रहे जिसे आप लगाकर भूल गए हैं।
लॉन्च रिक्वेस्ट सबसे पहले लें
कोई पब्लिश करने के इंतज़ार में है। जांच और एक लाइन में लिखा असर पढ़ें, फिर अप्रूव करें, या कारण लिखकर ठुकराएं। कोई जांच फ़ेल हो, तो वह डायलॉग में दिखती है और अप्रूवल को रोक देती है।
फिर प्लान
हर प्लान को उसकी रो से खोलें। जिस रो पर सबमिशन के बाद एडिट होने का निशान है, उसे अप्रूव नहीं किया जा सकता, इसलिए इंतज़ार करने के बजाय दोबारा सबमिट करने को कहें। “Request changes” (बदलाव मांगें) में ऐसा नोट लिखें जो बताए कि क्या बदलना है।
फिर लाइब्रेरी
हर रिव्यू को वैसे खोलें जैसे क्लाइंट उसे देखेगा। अप्रूव करें, बदलाव मांगें, या अप्रूवल स्किप करें, जिससे दर्ज होता है कि एसेट का रिव्यू किसी ने नहीं किया, और उसे अप्रूव्ड के रूप में नहीं दिखाया जाता। कमेंट को ठीक उसी जगह पिन करें जिसकी आप बात कर रहे हैं।
छुट्टी और “Also waiting” पर खत्म करें
एडमिन छुट्टी का फ़ैसला सबसे आखिर में करते हैं, और हर ठुकराई गई रिक्वेस्ट के साथ एक कारण देते हैं। अगर “Also waiting” (और भी इंतज़ार में) कार्ड में टाइमशीट एंट्री या बुकिंग स्क्रिप्ट रिवीज़न की गिनती दिखे, तो उसके लिंक से टाइमशीट या बुकिंग स्क्रिप्ट खोलें।
तीन आदतें इस राउंड को छोटा रखती हैं: नोट के साथ सबमिट करें, रिव्यूअर का नाम दें, और चैट के बजाय इनबॉक्स में फ़ैसला करें। इनबॉक्स आपके टैब पर लौटते ही रीफ़्रेश हो जाता है और खुला रहने पर हर मिनट एक बार भी, इसलिए आप उसे खुला छोड़ सकते हैं और लौटने पर ताज़ा गिनती पा सकते हैं।
इनबॉक्स क्या नहीं करता, ताकि कोई यह न मान ले कि करता है
फ़ैसलों की कतार पर तभी भरोसा किया जा सकता है जब उसकी सीमाएं साफ़ हों।
- इनबॉक्स कोई रिमाइंडर नहीं भेजता और एस्केलेट भी नहीं करता। प्लान सबमिट होने पर सूचनाओं की घंटी बजती है और रिव्यूअर को ईमेल जाता है, या रिव्यूअर का नाम न होने पर क्लाइंट के हर अप्रूवर को, और तीन दिन बाद की तारीख वाला एक रिव्यू टास्क बन जाता है। इसलिए प्रोजेक्ट में उस टास्क की तारीख ही याद दिलाने का काम करती है। सुबह का सारांश, जो डिफ़ॉल्ट रूप से कामकाजी दिनों में भेजा जाता है, आप पर रुके लाइब्रेरी रिव्यू, टाइमशीट एंट्री और छुट्टी की रिक्वेस्ट भी गिनाता है, पर प्लान या लॉन्च रिक्वेस्ट नहीं। लाइब्रेरी सबमिशन अप्रूवर को सूचना देता है और कोई टास्क नहीं बनाता। कोई आइटम तब तक रुका रहता है जब तक कोई व्यक्ति उस पर फ़ैसला न कर दे।
- ईमेल के अलावा यह फ़िलहाल आपकी तरफ़ से न कुछ पोस्ट करता है, न कुछ भेजता है। पेड, सोशल या SMS लॉन्च हाथ से पूरा हुआ दर्ज किया जाता है: अप्रूवल एक टास्क और फ़्रीज़ किए गए स्पेसिफ़िकेशन का एक्सपोर्ट बना देता है, और कोई व्यक्ति उसे लॉन्च हुआ, पब्लिश हुआ या भेजा गया मार्क करता है। ईमेल लॉन्च इसका अपवाद है, और वह भेजता है।
- टाइमशीट और बुकिंग स्क्रिप्ट पर यहां फ़ैसला नहीं होता। उनकी गिनती “Also waiting” में आती है और फ़ैसला उनके अपने टूल में लिया जाता है।
- यह क्लाइंट को प्लान, लॉन्च या इनबॉक्स नहीं दिखाता। क्लाइंट को पोर्टल में वे लाइब्रेरी एसेट दिखते हैं जो आप उसके साथ शेयर करते हैं, और वह उन एसेट का रिव्यू करता है जिनका रिव्यू आप उससे मांगते हैं।
- यह हर व्यक्ति को वही क्लाइंट दिखाता है जिन्हें वह देख सकता है। “Approve” (अप्रूव करें) और “Decline” (ठुकराएं) सिर्फ़ वहीं दिखते हैं जहां उस व्यक्ति के पास अनुमति है। इंतज़ार करती जिस प्लान या लॉन्च रो पर वह फ़ैसला नहीं कर सकता, उस पर लिखा होता है कि कौन कर सकता है, और “Time off” (छुट्टी) टैब सिर्फ़ एडमिन को दिखता है।
- जिस प्लान का लॉन्च पूरा हो चुका है, उसे यह दोबारा लॉन्च नहीं करता। उसे फिर भेजना हो, तो प्लान की डुप्लिकेट कॉपी बनाएं और उस कॉपी को अप्रूव करें। फ़ेल, रद्द या ठुकराए गए लॉन्च को दोबारा आज़माया जा सकता है।
इस पूरे सिलसिले में क्लाइंट का अपना अप्रूवल कहां आता है
प्लान और लॉन्च अंदरूनी फ़ैसले हैं। क्लाइंट का साइन-ऑफ़ उन लाइब्रेरी एसेट पर लागू होता है जो आप उसके साथ शेयर करते हैं।
पहले इंटरनल अप्रूवल लें
किसी एसेट को क्लाइंट के साथ तभी शेयर किया जा सकता है जब एजेंसी का कोई अप्रूवर उसे अप्रूव कर दे या अप्रूवल स्किप कर दे। अप्रूवल की सुविधा आने से पहले जो एसेट शेयर हो चुके थे, उन्हें शेयर किया हुआ चिह्नित किया जाता है और कभी रोका नहीं जाता।
शेयर करें, फिर रिव्यू मांगें
“Publish” अनुमति वाला कोई व्यक्ति एसेट शेयर करता है और क्लाइंट से रिव्यू मांगता है, चाहे तो एक नोट के साथ, जो क्लाइंट को रिक्वेस्ट के साथ दिखता है। शेयर के लिए मार्क किए गए कमेंट भी क्लाइंट को दिखते हैं।
क्लाइंट पोर्टल में जवाब देता है
पोर्टल एडमिन अप्रूव करता है, और पोर्टल का कोई भी सदस्य बदलाव मांग सकता है। दोनों काम एसेट पर उसी रूप में होते हैं जिसमें क्लाइंट उसे देखता है, और कमेंट को वे ठीक उस जगह पिन कर सकते हैं जिसकी वे बात कर रहे हैं।
पलटें, फिर से खोलें या दोबारा मांगें
क्लाइंट अपना अप्रूवल एक घंटे के भीतर पलट सकता है। बदलाव मांगे जाने के बाद आप एसेट एडिट करते हैं और दोबारा रिव्यू मांगते हैं। रिक्वेस्ट जब तक क्लाइंट के पास है, आप उसे वापस ले सकते हैं, और रिव्यू के अप्रूव या स्किप हो जाने के बाद उसे दोबारा खोल सकते हैं।
इनबॉक्स में ये एसेट “Library” टैब पर “With the client” (क्लाइंट के पास) के नीचे रहते हैं, जब तक क्लाइंट उन्हें अप्रूव नहीं कर देता, और उसके बाद “Decided” (फ़ैसला हो चुके) के नीचे। अगर क्लाइंट बदलाव मांगता है, तो वे “With the client” में तब तक रहते हैं जब तक आप दोबारा रिव्यू नहीं मांगते या रिक्वेस्ट वापस नहीं ले लेते। क्लाइंट रिव्यू के लिए क्लाइंट पोर्टल चाहिए, जो Scale और Enterprise प्लान पर मिलता है। आर्टवर्क इसका एक आम मामला है, और क्रिएटिव मैनेजमेंट दिखाता है कि वर्शन और रिव्यू क्रिएटिव पर ही कैसे बैठते हैं।
अक्सर पूछे जाने वाले सवाल
एजेंसी के अप्रूवल वर्कफ़्लो में क्या-क्या कवर होना चाहिए?
आमतौर पर चार चीज़ों के लिए किसी के नाम दर्ज फ़ैसले की ज़रूरत पड़ती है: क्लाइंट तक पहुंचने से पहले क्रिएटिव और कॉपी, पैसा लगाने से पहले कैंपेन प्लान, कुछ भी लाइव होने से पहले लॉन्च, और छुट्टी, उसका वादा किए जाने से पहले। यह इनबॉक्स इन चारों को एक जगह रखता है और हर टूल के नियम जस के तस बने रहते हैं, इसलिए एजेंसियों के लिए यह अप्रूवल सिस्टम अनुमतियों और रिकॉर्ड का एक सेट है, किसी ऐसे दस्तावेज़ जैसा नहीं जिसे कोई खोलता ही नहीं।
अप्रूवल इनबॉक्स किन प्लान में शामिल है?
इनबॉक्स हर प्लान पर मिलता है। उसमें क्या आता है, यह प्लान पर निर्भर करता है: पेड और सोशल प्लानर और लॉन्च के लिए Agency या उससे ऊपर का प्लान चाहिए, ईमेल और SMS प्लानर हर प्लान के साथ आते हैं, और लाइब्रेरी एसेट पर क्लाइंट के अपने रिव्यू के लिए Scale या Enterprise प्लान का क्लाइंट पोर्टल चाहिए। छुट्टी के फ़ैसले किसी भी प्लान पर एजेंसी एडमिन के लिए उपलब्ध हैं।
प्लान या लाइब्रेरी एसेट को अप्रूव करने की इजाज़त किसे है?
उस क्लाइंट के लिए “Approve” अनुमति रखने वाला कोई भी व्यक्ति। एजेंसी एडमिन के पास यह अपने-आप रहती है, और कोई एडमिन इसे किसी टीम इंचार्ज को दे सकता है। डिफ़ॉल्ट रूप से टीम का सदस्य एडिट और सबमिट कर सकता है, पर अप्रूव या पब्लिश नहीं। इसके अलावा टीम के सदस्य सिर्फ़ उन्हीं क्लाइंट पर काम करते हैं जिन पर उन्हें असाइन किया गया है, इसलिए अप्रूवर को इनबॉक्स उसके अपने अकाउंट के हिसाब से छना हुआ दिखता है।
क्या अप्रूवल इनबॉक्स में अपना ही काम अप्रूव किया जा सकता है?
यह आइटम के प्रकार पर निर्भर करता है। जिस व्यक्ति ने प्लान सबमिट किया है, वह उसे अप्रूव नहीं कर सकता, जब तक वह एजेंसी एडमिन न हो, और तब अप्रूवल को सेल्फ़-अप्रूव्ड के रूप में दर्ज किया जाता है। लाइब्रेरी रिव्यू में दूसरे व्यक्ति की ज़रूरत नहीं होती, इसलिए अप्रूवर अपना सबमिट किया हुआ भी अप्रूव कर सकता है। जब तक कोई दूसरा एडमिन फ़ैसला कर सकता है, कोई भी अपनी छुट्टी का फ़ैसला खुद नहीं करता।
अप्रूव होने के बाद प्लान एडिट हो जाए, तो क्या होता है?
उस पर “Changed since approval” लिखा दिखता है — इनबॉक्स में पिछले 14 दिनों के अप्रूवल के लिए, और प्लान व लॉन्च पेज पर — और जब तक उसे दोबारा सबमिट और अप्रूव नहीं किया जाता, उसे लॉन्च नहीं किया जा सकता। सर्वर अप्रूव हुए कंटेंट की तुलना प्लान की मौजूदा हालत से तब करता है जब लॉन्च बनाया या अप्रूव किया जाता है, और शेड्यूल किए गए लॉन्च के कोई कदम उठाने से ठीक पहले एक बार फिर, इसलिए जो कंटेंट अप्रूव हुआ था, वह किसी बदले हुए कंटेंट के रूप में बाहर नहीं जा सकता।
क्या लॉन्च अप्रूव करते ही वह अपने-आप पोस्ट या सेंड हो जाता है?
ईमेल लॉन्च भेजे जाते हैं। फ़िलहाल पेड, सोशल या SMS लॉन्च को अप्रूव करने से एक टास्क और एक्सपोर्ट किया हुआ स्पेसिफ़िकेशन बनता है, जिसे कोई व्यक्ति पूरा करता है, और फिर पब्लिशर लॉन्च को लॉन्च हुआ, पब्लिश हुआ या भेजा गया मार्क करता है, चाहे तो एक लिंक के साथ। कंसोल सोशल नेटवर्क पर पोस्ट नहीं करता और SMS नहीं भेजता।
क्या क्लाइंट अप्रूवल इनबॉक्स या अपने प्लान देख पाते हैं?
नहीं। इनबॉक्स अंदरूनी है, और प्लान व लॉन्च पोर्टल में कभी नहीं दिखाए जाते। क्लाइंट को अपने ही ब्रांडेड पोर्टल में वे लाइब्रेरी एसेट दिखते हैं जो आप उसके साथ शेयर करते हैं, और वह उन एसेट का रिव्यू करता है जिनका रिव्यू आप उससे मांगते हैं: पोर्टल एडमिन अप्रूव कर सकता है, और पोर्टल का कोई भी सदस्य बदलाव मांग सकता है। पोर्टल Scale और Enterprise प्लान के साथ आता है।
क्या इनबॉक्स अप्रूवर को याद दिलाता है या पुराने पड़ चुके आइटम को एस्केलेट करता है?
इनबॉक्स कोई रिमाइंडर ईमेल नहीं भेजता और एस्केलेट भी नहीं करता। प्लान सबमिट होने पर सूचनाओं की घंटी बजती है और रिव्यूअर को ईमेल जाता है, या रिव्यूअर का नाम न होने पर क्लाइंट के हर अप्रूवर को, और तीन दिन बाद की तारीख वाला एक रिव्यू टास्क बन जाता है। लाइब्रेरी सबमिशन अप्रूवर को सूचना देता है और कोई टास्क नहीं बनाता। कामकाजी दिनों की सुबह का सारांश आप पर रुके लाइब्रेरी रिव्यू, टाइमशीट एंट्री और छुट्टी की रिक्वेस्ट गिनाता है। कोई आइटम तब तक रुका रहता है जब तक कोई उस पर फ़ैसला न कर दे, इसलिए पीछा करने के लिए गिनतियों और टास्क की तारीखों का सहारा लें।
इनबॉक्स का एक हिस्सा लोड न हो पाए, तो क्या होता है?
हर स्रोत अपनी स्थिति खुद बताता है। जो रीड फ़ेल होता है, वह रीट्राई वाला एरर कार्ड सिर्फ़ अपने ही टैब पर दिखाता है, और बाकी टैब काम करते रहते हैं। जिस गिनती को सर्वर पढ़ नहीं सका, उसे शून्य दिखाने के बजाय छोड़ दिया जाता है, और अपनी सीमा पर कटी हुई सूची खुद बता देती है कि वह कटी है, इसलिए कोई खाली टैब ऐसे काम को नहीं छिपाता जो आपने अभी पढ़ा ही नहीं।
अप्रूवल इनबॉक्स एक्टिविटी सेंटर से कैसे अलग है?
एक्टिविटी सेंटर कंसोल भर में जो कुछ हुआ उसकी फ़ीड है, जिसमें फ़िल्टर और पढ़ा या अनपढ़ा होने का स्टेटस है। अप्रूवल इनबॉक्स वह जगह है जहां फ़ैसले होते हैं, अपने नियमों के साथ: कौन अप्रूव कर सकता है, अप्रूवल किस चीज़ को कवर करता है और आगे क्या होता है। कई आइटम दोनों में दिखते हैं, और किसी अप्रूवल की सूचना यहां उसकी रो खोल देती है।