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