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