صبح اولین روز کاری ادمین جدید، ورود به صفحه ممکن است؛ اما فایل اصلی ویدیوی امروز پیدا نمی‌شود، مشتری منتظر پاسخ درباره سفارش است و هیچ‌کس نمی‌داند پست تخفیف هنوز باید منتشر شود یا نه. ادمین قبلی هم می‌گوید همه چیز را تحویل داده است. این اختلاف معمولاً از بدقولی شروع نمی‌شود؛ از این شروع می‌شود که «تحویل اکانت شبکه اجتماعی» را فقط تحویل امکان ورود تعریف کرده‌ایم.
تحویل درست یعنی کسب‌وکار بتواند بدون وابستگی به حافظه یا حساب شخصی فرد قبلی، انتشار و پاسخ‌گویی را ادامه دهد. این انتقال چند موضوع مستقل دارد: اختیار مدیریت، راه بازیابی، فایل‌ها، تقویم فعال، تعهدهای باز و مجوزهای متصل. تا وقتی هرکدام قابل بررسی نشده، صرف ورود موفق نشانه پایان کار نیست. راهنمای زیر برای انتقال عملی مسئولیت است، نه فهرست عمومی وظایف روزانه ادمین.
قبل از خروج فرد، تعریف «تحویل کامل» را توافق کنید
از همان ابتدای فرایند، تحویل‌دهنده، تحویل‌گیرنده و نماینده مجاز کسب‌وکار را مشخص کنید. در تیم کوچک ممکن است یک نفر بیش از یک نقش داشته باشد، اما نقش‌ها نباید مبهم بمانند. ادمین قبلی وضعیت موجود را توضیح می‌دهد، فرد جدید اجرای کار را می‌آزماید و نماینده کسب‌وکار درباره اختیارها، ریسک‌های باقی‌مانده و پایان دسترسی تصمیم می‌گیرد.
یک صورت‌جلسه قابل ویرایش بسازید که برای هر مورد، وضعیت، مدرک پذیرش، مسئول اقدام و مانع احتمالی داشته باشد. «فایل‌ها ارسال شد» مدرک کافی نیست؛ «نسخه قابل ویرایش در فضای سازمان قرار دارد و فرد جدید آن را باز کرده است» قابل بررسی است. «دسترسی داده شد» هم باید به نام دارایی، سطح اختیار و آزمون موفق همان اختیار تبدیل شود.
تحویل اکانت با انتقال مالکیت کسب‌وکار یا حل اختلاف قراردادی یکی نیست. ممکن است صفحه در ساختاری ایجاد شده باشد که هنوز زیر مدیریت پیمانکار است. صرف داشتن رمز یا امکان انتشار، اثبات مالکیت نیست. وضعیت را ثبت کنید و از مسیر رسمی پلتفرم و توافق معتبر میان طرف‌ها پیش بروید. راه‌حل این ابهام، استفاده از هویت فرد دیگر یا دور زدن کنترل امنیتی نیست.
یک بازه مشخص برای تغییرات تعیین کنید. نزدیک نقطه تحویل، اصلاح‌های ضروری ادامه پیدا می‌کند اما تغییرهای غیرضروری در نام فایل، پوشه، اتصال سرویس و برنامه انتشار متوقف می‌شود. این توقف کوتاه، رویه پیشنهادی تیم است و ویژگی خاص یک نرم‌افزار نیست. هدف این است که تحویل‌گیرنده چیزی ثابت و قابل آزمون ببیند، نه وضعیتی که هنگام بررسی مرتب عوض می‌شود.
دایرکت هوشمند اینستاگرام
پاسخ خودکار به کامنت‌ها و دایرکت‌های اینستاگرام
با دایرکت هوشمند نوین هاب اتوماتیک به کامنت‌ها و دایرکت‌های اینستاگرام پاسخ دهید و بازدید و تعامل پیج خود را چند برابر کنید
نقشه دارایی‌ها را از روی کار واقعی بسازید
فهرست را با نام شبکه‌های اجتماعی شروع کنید، اما به آن محدود نمانید. برای هر صفحه یا کانال بنویسید چه دارایی‌هایی به آن وابسته‌اند: حساب تبلیغاتی، فضای فایل، ایمیل سازمانی، دامنه لینک کوتاه، صفحه فرود، ابزار انتشار، محل ثبت درخواست‌ها و اشتراک منابع تصویری. چیزی که بیرون از اپلیکیشن شبکه اجتماعی قرار دارد ممکن است برای ادامه فعالیت حیاتی‌تر از خود صفحه باشد.
برای هر دارایی، شناسه یا نشانی غیرمحرمانه، مالک یا مسئول سازمانی، روش دسترسی مجاز و محل ثبت تنظیمات را بنویسید. رمز، کد بازیابی، توکن اتصال و کد یک‌بارمصرف در این فهرست جایی ندارند. دفتر تحویل باید بگوید چه چیزی کجاست و چه کسی اختیارش را دارد؛ نباید به بسته‌ای تبدیل شود که با افشای آن تمام حساب‌ها در معرض خطر قرار بگیرند.
چه چیزی را با چه شاهدی تحویل بگیریم؟
| دارایی | شاهد قابل پذیرش | چیزی که کافی نیست |
|---|---|---|
| صفحه یا کانال | ورود فرد مجاز با هویت خودش و آزمون اختیار مورد نیاز | تصویر صفحه روی گوشی ادمین قبلی |
| فایل محتوایی | باز شدن نسخه اصلی و مشاهده وضعیت تأیید | فقط خروجی فشرده در پیام‌رسان |
| تقویم انتشار | تطبیق برنامه ثبت‌شده با صف واقعی ابزارها | جدول قدیمی بدون زمان آخرین تغییر |
| تعهد مشتری | خلاصه دقیق، ارجاع به سابقه و مسئول پیگیری | عبارت کلی «چند پیام مانده است» |
| اتصال خارجی | شناسایی سرویس، مالک مجوز و وضعیت ادامه استفاده | فرض اینکه تغییر رمز همه اتصال‌ها را قطع می‌کند |
در این مرحله سراغ دستگاه شخصی و پیام‌های خصوصی فرد نروید. از او بخواهید دارایی‌های کاریِ متعلق به سازمان را از مسیر مورد توافق منتقل کند. اگر فایلی با حساب شخصی ساخته شده، باید امکان انتقال یا نگهداری مجاز نسخه سازمانی بررسی شود. مرز دارایی شغلی و داده شخصی را با حدس تعیین نکنید؛ موارد مورد اختلاف را برای تصمیم مسئول مجاز نگه دارید.
اختیار انتشار با اختیار مدیریت دسترسی فرق دارد
ادمین جدید ممکن است بتواند محتوا منتشر کند اما نتواند دسترسی همکار بعدی را مدیریت کند. این لزوماً نقص نیست؛ شاید دقیقاً سطح اختیار مورد نیاز او باشد. کسب‌وکار باید بداند چه فرد مجازی اختیار مدیریتی لازم را نگه می‌دارد تا خروج یا غیبت یک نفر باعث بن‌بست نشود. دادن بیشترین اختیار به همه اعضا جای طراحی این مسئولیت را نمی‌گیرد.
برای نمونه، راهنمای رسمی مدیریت دسترسی صفحه فیس‌بوک توضیح می‌دهد مدیریت دسترسی دیگران به اختیار کنترل کامل صفحه وابسته است. این حکم را نباید به تمام شبکه‌ها یا هر ساختار متصل متا تعمیم داد. نام نقش‌ها و مسیر تنظیمات ممکن است متفاوت باشد؛ آنچه باید در تحویل ثبت شود اختیار واقعی و تأییدشده است، نه عنوانی که افراد به خودشان می‌دهند.
دسترسی را با ترتیب امن جابه‌جا کنید
در خروج عادی و برنامه‌ریزی‌شده، ابتدا دسترسی فرد جدید از مسیر رسمی دعوت یا نقش‌دهی همان سرویس ایجاد می‌شود؛ سپس او با هویت خودش ورود و کار لازم را امتحان می‌کند. پس از اطمینان از وجود مسئول مجاز و مسیر بازیابی سازمانی، دسترسی فرد خارج‌شونده مطابق زمان توافق‌شده لغو می‌شود. این ترتیب برای شرایط عادی است؛ در رخداد امنیتی یا احتمال سوءاستفاده، مهار فوری خطر بر انتقال آرام اولویت دارد.
تحویل رمز حساب شخصی، درخواست کد یک‌بارمصرف از همکار و خاموش کردن احراز هویت چندمرحله‌ای برای آسان شدن کار، روش انتقال نیست. هر فرد باید احراز هویت خودش را انجام دهد. اگر سرویس نقش‌دهی مناسبی ندارد یا ساختار فعلی به حساب شخصی گره خورده، مسئول فناوری یا مالک مجاز باید راه رسمی اصلاح ساختار را بررسی کند؛ نبود راه ساده، مجوز اشتراک‌گذاری رمز نیست.
راهنمای فعالسازی تأیید دومرحله‌ای NCSC استفاده از این لایه حفاظتی را برای حساب‌های مهم توصیه می‌کند؛ از جمله ایمیلی که برای بازیابی حساب‌های دیگر استفاده می‌شود. در تحویل، وجود حفاظت را بررسی کنید، نه اینکه کدها را داخل صورت‌جلسه کپی کنید. انتخاب روش مناسب به قابلیت همان سرویس وابسته است و باید با مسئول امنیت یا فناوری سازمان هماهنگ شود.
راه بازیابی را بدون نمایش رازها بررسی کنید
ممکن است حساب به ایمیلی متصل باشد که پس از خروج کارمند بسته می‌شود، یا اعلان امنیتی فقط برای او ارسال شود. مسئول مجاز باید بررسی کند کانال‌های بازیابی و دریافت هشدار تحت کنترل درست قرار دارند. لازم نیست مشخصات کامل بازیابی در پرونده عمومی پروژه نوشته شود. کافی است نتیجه بررسی، مسئول کنترل و محل نگهداری امن اطلاعات ثبت شود.
برای اثبات بازیابی، حساب را عمداً قفل نکنید و فرایندهای پرریسک را بدون طرح اجرا نکنید. بررسی تنظیمات و کنترل سازمانی، سپس آزمون‌های مجاز و کم‌خطر با نظارت مسئول مربوط کافی‌تر از یک نمایش عجولانه است. اگر مسیر بازیابی هنوز حل نشده، مورد را باز نگه دارید. زدن تیک سبز برای حفظ ظاهر تحویل، مسئله را به روزی منتقل می‌کند که ورود واقعاً از دست رفته است.
اتصال‌ها را جدا از رمز و نقش‌ها ممیزی کنید
ابزار زمان‌بندی، سرویس تبلیغات، فضای ابری و نرم‌افزارهای متصل ممکن است مجوزهای جداگانه داشته باشند. فرض نکنید تغییر رمز الزاماً همه نشست‌ها و اتصال‌ها را لغو می‌کند. وضعیت نشست‌های فعال، کاربران ابزارهای جانبی و مجوز برنامه‌ها را هرجا سرویس امکانش را می‌دهد بررسی کنید. نتیجه هر بررسی باید مستقل ثبت شود، چون اثر یک اقدام در سرویس‌های مختلف یکسان نیست.
اتصال ناشناس را هم بدون شناخت پیامدش حذف نکنید؛ ممکن است به صف انتشار معتبر وابسته باشد. ابتدا مالک و کاربرد اتصال مشخص شود، سپس تصمیم ادامه یا لغو گرفته شود. در صورت مشاهده نشانه خطر، مسئول امنیت باید تصمیم مهار بگیرد. برای اتصال ضروری که به مجوز فرد قبلی وابسته است، بازاتصال رسمی با فرد مجاز جدید و آزمون عملکرد لازم است؛ کپی توکن راه‌حل تحویل محسوب نمی‌شود.
تحویل مسئولیت با هم‌تیمی نوین‌هاب
وقتی چند نفر روی یک پیج کار می‌کنند، لازم نیست برای ورود هر همکار تازه، رمز اصلی حساب را دست‌به‌دست کنید. در بخش هم‌تیمی نوین‌هاب می‌توانید اعضا را به فضای کاری دعوت کنید و متناسب با مسئولیتشان به آن‌ها دسترسی بدهید. به این ترتیب، همکاران انتشار محتوا و پاسخ‌گویی به پیام‌ها و کامنت‌ها را در یک محیط مشترک دنبال می‌کنند و نقش هر نفر روشن‌تر است.
هنگام تغییر ادمین، ابتدا همکار جدید را دعوت کنید و دسترسی‌های لازم برای کارش را مشخص کنید. پیش از پایان دوره تحویل، از او بخواهید کارهای مربوط به نقشش را با حساب خودش بررسی کند؛ مثلاً محتوای در صف انتشار را پیدا کند یا به گفتگوهای مرتبط با مسئولیتش دسترسی داشته باشد. در پایان همکاری نفر قبلی، دسترسی او به فضای کاری و مجوزهایش در خود شبکه اجتماعی و ابزارهای دیگر را جداگانه بازبینی کنید. این کار در کنار تحویل فایل‌ها و تعهدهای باز، کمک می‌کند ادامه فعالیت پیج به حضور یا رمز شخصی یک نفر وابسته نباشد.
حافظه محتوایی را همراه با دلیل تصمیم‌ها منتقل کنید
تحویل فایل تصویر نهایی کافی نیست. نسخه قابل ویرایش، فایل خام مرتبط، کپشن تأییدشده، متن جایگزین آماده، زیرنویس و وضعیت مجوز استفاده را کنار هم مشخص کنید. اگر پروژه به فونت یا افزونه‌ای وابسته است، نام وابستگی و وضعیت مجوز آن را ثبت کنید. فرد جدید نباید روز انتشار بفهمد خروجی قابل اصلاح نیست یا حق استفاده از یک عکس فقط برای کمپین قبلی بوده است.
برای محتواها وضعیت واقعی بنویسید: ایده، در حال تولید، نیازمند اصلاح، تأییدشده، زمان‌بندی‌شده یا متوقف. فایل با نام «نهایی» ممکن است هنوز تأیید نشده باشد. معیار پذیرش، همخوانی فایل با تصمیم ثبت‌شده است، نه نام آن. کنار هر فایل مشخص کنید چه کسی آن را تأیید کرده، کدام بررسی انجام شده و چه کاری هنوز باقی است؛ ادمین جدید نباید این وضعیت را از روی نام پوشه حدس بزند.
بخش مهم‌تر، علت تصمیم‌هایی است که در فایل دیده نمی‌شود. چرا یک طرح کنار گذاشته شد؟ چرا نام محصول در کپشن شکل خاصی دارد؟ چرا استفاده از تصویر یک مشتری ممنوع شده است؟ توضیح کوتاهِ مستند کنار همان دارایی، از بازگشت اشتباه‌های قدیمی جلوگیری می‌کند. سلیقه‌های شخصی را با محدودیت قطعی برند مخلوط نکنید؛ هرکدام باید برچسب و منبع خودش را داشته باشد.
از فرد جدید بخواهید یکی از محتواهای در صف را خودش پیدا کند، فایل اصلی را باز کند و آخرین نسخه کپشن را تشخیص دهد. این تمرین کم‌خطر، کیفیت آرشیو را بهتر از نمایش پوشه‌ها توسط فرد قبلی آشکار می‌کند. اگر موفق نمی‌شود، مشکل ممکن است نام‌گذاری، مجوز فایل یا نبود ارجاع میان تقویم و پوشه باشد؛ همان مانع باید قبل از خروج حل شود.
گزارش‌های عملکرد نیز بخشی از حافظه کاری‌اند. آخرین گزارش، بازه زمانی آن، تعریف شاخص‌ها و منبع داده را تحویل دهید تا ادمین جدید عدد امروز را با عددی از دامنه متفاوت مقایسه نکند. روشن کنید کدام محتوا تبلیغ شده، کدام نتیجه به کمپین موقت مربوط بوده و کدام بخش هنوز داده کامل ندارد. افزایش یا افت ظاهری پس از تغییر ادمین ممکن است ناشی از تفاوت روش گزارش باشد، نه تغییر عملکرد او.
لازم نیست برای این انتقال، همه اطلاعات تحلیلی و مخاطبان را یکجا صادر کنید. آنچه برای ادامه گزارش‌گیری لازم است با دسترسی مجاز فراهم شود و محدودیت‌های مشاهده نوشته شود. اگر نام‌گذاری کمپین‌ها یا لینک‌ها قاعده داشته، همان قاعده و یک نمونه غیرحساس را اضافه کنید. فرد جدید باید بتواند گزارش بعدی را با تعریف قبلی بازتولید کند، یا تغییر تعریف را آشکار و مستند اعلام کند.
تصمیم‌های متوقف‌شده را هم از سابقه پاک نکنید. در یک مثال فرضی، همکاری تبلیغاتی به دلیل نامشخص بودن مجوز تصویر متوقف شده است. نبود این یادداشت می‌تواند باعث شود ادمین تازه، همان فایل آماده را فرصتی برای انتشار سریع ببیند. تحویل خوب فقط می‌گوید چه کاری باید ادامه یابد؛ درباره کاری که نباید دوباره شروع شود و دلیل مستند آن نیز توضیح می‌دهد.
تقویم را با صف واقعی انتشار تطبیق دهید
برنامه ثبت‌شده در جدول را با آنچه واقعاً در ابزارها زمان‌بندی شده مقایسه کنید. ممکن است یک پست از تقویم حذف شده ولی همچنان در صف باشد، یا از دو مسیر برای یک صفحه آماده انتشار باشد. زمان، منطقه زمانی، مقصد و وضعیت تأیید را با هم ببینید. انتقال ادمین نباید باعث شود محتوای پایان‌یافته کمپین دوباره منتشر شود یا محتوای معتبر بی‌دلیل متوقف بماند.
برای تیمی که از ابزار زمان‌بندی و انتشار محتوا استفاده می‌کند، صف همان ابزار یکی از محل‌های بررسی است، نه تنها محل حقیقت. نسخه‌های پیش‌نویس داخل پلتفرم و برنامه‌های خارج از آن هم باید شناسایی شوند. این توصیه به معنای انتقال خودکار مالکیت، حفظ قطعی همه صف‌ها پس از تغییر مجوز یا همگام‌سازی همه ابزارها نیست؛ وضعیت واقعی هر اتصال باید آزموده شود.
کنار هر محتوای نزدیک به انتشار، مسئول آخرین تأیید و شرط توقف را مشخص کنید. در یک سناریوی فرضی، معرفی رویداد فقط پس از تأیید ظرفیت محل مجاز است؛ آماده بودن فایل کافی نیست. هنگام تحویل، فهرست همین تعهدهای موجود و مغایرت‌های واقعی را روشن کنید. بازطراحی تقویم را می‌توان بعداً انجام داد؛ اول باید معلوم باشد کدام انتشار در روزهای پیش رو به تصمیم یا تأیید دیگری نیاز دارد.
مهم‌ترین بسته تحویل: قول‌هایی که هنوز باز مانده‌اند
پیام خوانده‌شده ممکن است هنوز حل نشده باشد. برعکس، پیام نخوانده ممکن است فقط یک تشکر باشد. برای پیدا کردن تعهدهای باز به نشان خواندن تکیه نکنید. مکالمه‌هایی را بررسی کنید که در آن‌ها وعده بررسی سفارش، اعلام نتیجه، ارائه پیش‌فاکتور، اصلاح اشتباه یا هماهنگی با تیم دیگری داده شده است. هر تعهد باید وضعیت و مسئول بعدی داشته باشد.
خلاصه پرونده باید به اندازه‌ای باشد که ادمین بعدی مجبور نشود از مشتری بخواهد تمام ماجرا را دوباره تعریف کند. موضوع، آخرین واقعیت تأییدشده، آخرین قول داده‌شده، اقدام لازم و مرجع سابقه را بنویسید. اطلاعات حساس را در پرونده مجاز خودش نگه دارید؛ برای تحویل معمولاً ارجاع به سابقه بهتر از تکثیر تصویر مدارک یا جزئیات پرداخت در یک گروه عمومی است.
نمونه فرضی یادداشت داخلی: «مشتری درباره تفاوت کالای دریافتی با سفارش پیام داده است. تصویر در پرونده پشتیبانی موجود است. هنوز مغایرت تأیید نشده و وعده تعویض داده نشده است. مسئول بعدی باید نظر انبار را بگیرد و نتیجه بررسی را در همان گفت‌وگو اعلام کند. وضعیت فعلی: منتظر پاسخ انبار.»
این یادداشت عمداً میان ادعای مشتری، واقعیت بررسی‌شده و وعده شرکت فرق می‌گذارد. نوشتن «تعویض انجام شود» بدون تأیید، یک تعهد تازه می‌سازد. همچنین انتقال پرونده به همکار دیگر به معنای انجام بررسی نیست. در پیام مشتری نگویید موضوع بررسی شده یا حل شده است مگر اینکه واقعاً چنین اقدامی انجام و تأیید شده باشد.
اگر زمان پاسخ نزدیک است و بررسی هنوز ادامه دارد، پیام انتقال باید صادقانه باشد. نمونه فرضی: «پیگیری درخواست شما ادامه دارد و لازم نیست اطلاعات قبلی را دوباره بفرستید. نتیجه را پس از دریافت پاسخ بخش مربوط در همین گفت‌وگو اعلام می‌کنیم.» این متن فقط وقتی مناسب است که سابقه واقعاً در دسترس و مسئول پیگیری مشخص باشد؛ متن آماده جای این دو شرط را نمی‌گیرد.
تعهدهای عمومی را هم وارد فهرست کنید: پاسخ به یک کامنت اعتراضی، اعلام نتیجه یک رویداد، اصلاح توضیح محصول در هایلایت یا پیگیری همکاری با تولیدکننده محتوا. بعضی از این موارد در صندوق پیام پیدا نمی‌شوند. آخرین پست‌ها، محتوای سنجاق‌شده و صفحه‌های فرود فعال را مرور کنید تا وعده‌ای که مقابل چشم مخاطب باقی مانده، از پرونده تحویل جا نماند.
تحویل را با اجرای کار بپذیرید، نه با جمله «انجام شد»
جلسه پذیرش باید با اقدام تحویل‌گیرنده پیش برود. او با حساب مجاز خود وارد شود، محتوای تعیین‌شده را پیدا کند، صف مرتبط را ببیند و بتواند پرونده باز نمونه را از روی خلاصه ادامه دهد. برای آزمون انتشار، از پیش‌نویس یا محیط مجاز کم‌خطر استفاده کنید؛ لازم نیست برای اثبات دسترسی، محتوای آزمایشی در صفحه عمومی منتشر شود.
- ورود و اختیارهای لازم با هویت فرد جدید بررسی شده است.
- مسئول سازمانی مدیریت و مسیر بازیابی مشخص است.
- صف‌های انتشار، فایل‌های مرتبط و موارد متوقف تطبیق داده شده‌اند.
- تعهدهای باز به فرد مشخص واگذار شده و سابقه در دسترس اوست.
- لغو دسترسی‌ها و بررسی اتصال‌های باقی‌مانده شاهد ثبت‌شده دارد.
اگر بخشی کامل نشده، پذیرش مشروط بنویسید؛ مثلا دسترسی تبلیغات هنوز در انتظار تأیید مالک مجاز است، اما انتشار محتوای عادی قابل ادامه است. این توصیف از «تحویل ناقص» دقیق‌تر است و اجازه می‌دهد فعالیت کم‌خطر ادامه پیدا کند. در عین حال، مسئول و زمان پیگیری مانع باید روشن باشد تا پذیرش مشروط به فراموش شدن موضوع تبدیل نشود.
بعد از لغو دسترسی فرد قبلی، فقط به ناپدید شدن نام او از یک صفحه اکتفا نکنید. سرویس‌های موجود در نقشه دارایی را دوباره مرور کنید و وضعیت را با شواهد قابل دسترس تطبیق دهید. در سند تحویل، انجام شدن یک اقدام را از تأیید نتیجه آن جدا کنید. ممکن است درخواست تغییر ثبت شده باشد اما هنوز اعمال نشده باشد؛ همین تفاوت باید دیده شود.
در خروج ناگهانی، امنیت را مقدم کنید و سپس انتقال اطلاعات را از منابع سازمانی بازسازی کنید. اگر ادمین قبلی در دسترس نیست، ادعا نکنید همه جزئیات بازیابی شده‌اند. فهرست دانسته‌ها و مجهول‌ها را جدا کنید، انتشارهای حساس را تا روشن شدن وضعیت نگه دارید و تعهدهای نزدیک را اول بررسی کنید. استفاده از حساب فرد غایب یا حدس زدن رمز، میان‌بر مجاز نیست.
پس از خروج، پشتیبانی احتمالی فرد قبلی باید از مسیر توافق‌شده و بدون حفظ دسترسی غیرضروری انجام شود. می‌توان درباره محل فایل یا دلیل تصمیم سؤال کرد، بدون اینکه امکان ورود او به همه سرویس‌ها باز بماند. درباره حذف یا بازگرداندن نسخه‌های کاری نیز سیاست سازمان و تعهدهای مربوط را اجرا کنید؛ از فرد نخواهید برای اثبات همکاری، محتوای خصوصی دستگاهش را ارائه کند.
صفحه تحویل شده است وقتی کار بدون فرد قبلی ادامه پیدا کند
پایان تحویل اکانت شبکه اجتماعی، لحظه دریافت رمز یا ورود موفق نیست. پایان آن زمانی است که اختیارهای لازم، مسیر بازیابی، فایل‌های قابل استفاده، برنامه واقعی انتشار و قول‌های باز مشتری برای افراد مجاز روشن باشد و دسترسی‌های قبلی نیز بررسی شده باشند. صورت‌جلسه خوب فقط فهرست تحویلی‌ها نیست؛ نشان می‌دهد چه چیزی آزموده شده، چه چیزی باقی مانده و مسئول ادامه هر مورد چه کسی است.
