خانه محصولات اشتراک ها مقاله ها راهکارها درباره ما ورود به حساب درخواست مشاوره
MODIRAM / JOURNAL

پنل مشتریان متصل به CRM؛ هر مشتری چه اطلاعاتی را باید ببیند؟

پنل مشتریان فقط صفحه ورود نیست. با مثال یک چاپخانه بررسی می‌کنیم رابطه مشتری با سفارش، مجوز دریافت فایل و جزئیات قابل نمایش چگونه به CRM وصل می‌شوند.

تاریخ انتشار1405/07/19 05:38
پنل مشتریان متصل به CRM؛ هر مشتری چه اطلاعاتی را باید ببیند؟
MODIRAM EDITORIALسی آر ام

صفحه‌ای با عنوان «سفارش‌های من» ظاهراً ساده است: مشتری وارد سایت می‌شود، سفارش را می‌بیند و فایل مربوط به آن را دریافت می‌کند. اما کلمه «من» در این عنوان، بخش مهم طراحی است. سیستم از کجا می‌داند یک سفارش به همین فرد مربوط است؟ اگر او نماینده یک شرکت باشد، آیا باید سفارش همکارش را هم ببیند؟ پاسخ این پرسش‌ها را نمی‌توان به رنگ دکمه و شکل صفحه واگذار کرد.

پنل مشتریان متصل به CRM، بخشی از اطلاعات کسب‌وکار را در اختیار مشتری می‌گذارد. برای طراحی آن باید روشن کنیم چه کسی، کدام سابقه را، با چه جزئیاتی و برای چه کاری می‌بیند. در ادامه، لایه‌های همین صفحه ساده را باز می‌کنیم؛ از نامی که بالای صفحه ظاهر می‌شود تا فایلی که مشتری دریافت می‌کند. این توضیح برای تصمیم مشترک مدیر و تیم طراحی است، نه دستور پیکربندی یک محصول مشخص.

پشت نام کاربر، یک رابطه کاری قرار دارد

یک چاپخانه فرضی را در نظر بگیریم که برای چند شرکت بسته‌بندی تولید می‌کند. مسئول خرید هر شرکت می‌خواهد طرح تأییدشده و وضعیت سفارش‌های خودش را در سایت چاپخانه ببیند. تمام جزئیات این مثال تألیفی‌اند. قرار نیست از آن نتیجه بگیریم که یک نرم‌افزار خاص این امکانات را دارد یا چنین پنلی حتماً تماس‌های پشتیبانی را به میزان معینی کم می‌کند.

ورود موفق فقط هویت حساب کاربری را روشن می‌کند. تصمیم بعدی این است که آن حساب چه اجازه‌ای دارد. مسئول خرید شرکت اول و مسئول خرید شرکت دوم هر دو مشتری‌اند، ولی نباید به سفارش‌های یکدیگر دسترسی داشته باشند. حتی داخل یک شرکت نیز ممکن است نماینده شعبه فقط سفارش‌های همان شعبه را ببیند. بنابراین عنوان کلی «مشتری» برای توصیف همه مجوزها کافی نیست.

در مستند مجوزهای داده در Power Pages، به‌روزشده در ۷ ژوئیه ۲۰۲۶، دامنه‌های دسترسی متفاوتی معرفی شده‌اند؛ از دسترسی به سوابق مرتبط با شخص واردشده تا سوابق مرتبط با شرکت او. این مستند نشان می‌دهد رابطه میان کاربر و پرونده در تنظیم دسترسی اهمیت دارد. نام و رفتار دقیق این تنظیمات متعلق به همان محصول است؛ در پروژه دیگر باید معادل مناسب آن بررسی شود.

برای چاپخانه، تصمیم قابل فهم این است: نماینده معرفی‌شده شرکت چه مسئولیتی دارد و کدام سفارش‌ها در محدوده آن مسئولیت قرار می‌گیرند؟ پاسخ باید در سیستم ثبت شود؛ مثلاً مشخص باشد هر نماینده به کدام شرکت و شعبه مربوط است. اگر رابطه فرد با شرکت فقط در یادداشت‌های پراکنده آمده باشد، طراح نمی‌تواند فقط از روی شباهت نام‌ها یا حدس خودش دسترسی درست را بسازد.

همین‌جا نظم اطلاعات مشتری به طراحی سایت گره می‌خورد. پرونده شخص، شرکت و ارتباط میان آن‌ها باید قابل تشخیص باشد؛ پیش از آنکه صفحه‌ای برای نمایش سفارش‌ها بسازیم. مقاله مرتبط زیر این پیش‌نیاز را از زاویه نگهداری اطلاعات مشتری توضیح می‌دهد.

مطالعه مرتبط

اطلاعات مشتریان را چگونه منظم و قابل پیگیری نگه داریم؟

فهرست سفارش‌ها، مرز دسترسی نیست

در ظاهر صفحه ممکن است فقط سفارش‌های شرکت اول دیده شوند. این ظاهر به‌تنهایی ثابت نمی‌کند سیستم از اطلاعات شرکت دوم محافظت کرده است. دو روش ظاهراً مشابه می‌توانند پشت صفحه وجود داشته باشند: سرور فقط اطلاعات مجاز را تحویل بدهد، یا اطلاعات بیشتری به مرورگر برسد و بخشی از آن صرفاً در صفحه نمایش داده نشود. برای مدیر، نتیجه مهم این است که اطلاعات غیرمجاز اصلاً به حساب مشتری تحویل داده نشود.

راهنمای امنیت Power Pages، به‌روزشده در ۹ سپتامبر ۲۰۲۶ تصریح می‌کند که پنهان کردن صفحه از فهرست سایت یا فیلتر کردن ظاهر آن، جای کنترل دسترسی در سرور را نمی‌گیرد. این راهنما همچنین بررسی مسیر دریافت فایل را ضروری می‌داند. بنابراین حفاظت از صفحه و حفاظت از فایل پیوست، دو بخش مرتبط از یک طراحی‌اند.

در مثال چاپخانه، مشتری ممکن است نشانی دریافت طرح بسته‌بندی را برای همکارش بفرستد. اینکه یک دکمه در پنل اولیه درست نمایش داده شده، هنوز پاسخ نمی‌دهد گیرنده آن نشانی چه اجازه‌ای دارد. تیم فنی باید قواعد دسترسی را برای خود فایل نیز اجرا کند. روش دقیق می‌تواند با معماری سامانه فرق کند؛ مدیر باید درباره نتیجه مورد انتظار توافق کند، نه اینکه نام یک فناوری را به‌جای نتیجه بپذیرد.

راهنمای کنترل دسترسی OWASP دو اصل را توصیه می‌کند: دسترسی بدون مجوز روشن به‌طور پیش‌فرض رد شود و مجوز در هر درخواست بررسی شود. از این اصول برای مثال ما چنین نتیجه می‌گیریم که نبود رابطه معتبر میان فرد و سفارش، نباید با نمایش همه سفارش‌ها جبران شود. بررسی باید هنگام درخواست اطلاعات انجام شود، نه فقط هنگام ورود اولیه.

داخل هر پرونده هم همه چیز برای نمایش نیست

فرض کنیم رابطه مشتری و سفارش درست تعیین شده است. اکنون پرسش تازه‌ای داریم: چه جزئیاتی از آن سفارش باید در پنل بیاید؟ چاپخانه ممکن است کنار فایل تأییدشده، پیش‌نویس قدیمی، توضیح داخلی کارشناس و یادداشت برنامه‌ریزی تولید را هم نگه دارد. تعلق پرونده به مشتری، به این معنی نیست که تمام اطلاعات داخلی آن برای نمایش بیرونی آماده‌اند.

تصویرسازی مفهومی انتخاب بخشی از اطلاعات یک پرونده برای نمایش در پنل مشتری
تصویرسازی مفهومی: بخش قابل نمایش به مشتری می‌تواند از کل پرونده کوچک‌تر باشد.

پیشنهاد طراحی برای این مثال، تعریف یک مجموعه مشخص از اطلاعات قابل نمایش است: نام سفارش، وضعیت قابل فهم، زمان آخرین به‌روزرسانی و فایل تأییدشده. این مجموعه باید بر اساس نیاز واقعی مشتری تعیین شود. افزودن هر جزئیات تازه، یک تصمیم محتوایی و دسترسی جدید است؛ صرف وجود یک ستون در CRM، دلیل کافی برای آوردن آن در پنل نیست.

همان راهنمای امنیت مایکروسافت توصیه می‌کند در رابط برنامه‌نویسی، جدول‌ها و ستون‌های لازم به‌صورت مشخص مجاز شوند و مسیرهای دیگر نمایش، از جمله جست‌وجو و فرم‌ها، جداگانه بررسی شوند. این توصیه فنی یادآور آن است که محدود کردن یک مسیر، خودبه‌خود همه مسیرهای دریافت داده را محدود نمی‌کند. منبع، راهنمای اجرایی است؛ از آن درباره میزان رضایت مشتریان یا بازده اقتصادی پنل نتیجه‌گیری نمی‌کنیم.

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

وقتی نماینده مشتری عوض می‌شود

پنل با روز راه‌اندازی تمام نمی‌شود. ممکن است مسئول خرید شرکت تغییر کند، شعبه‌ای مستقل شود یا سفارش از یک واحد به واحد دیگر منتقل شود. در طراحی چاپخانه باید مشخص باشد چه کسی این تغییر رابطه را اعلام و چه کسی آن را در سیستم ثبت می‌کند. باقی ماندن سابقه سفارش با باقی ماندن دسترسی نماینده قبلی یک تصمیم واحد نیست؛ اولی برای ادامه کار لازم است، دومی به مسئولیت فعلی فرد بستگی دارد.

برای این بخش از کار، یک تصمیم سازمانی ساده اما مشخص لازم داریم: درخواست تغییر نماینده از چه مسیر معتبری دریافت می‌شود و چه کسی مسئول رسیدگی به آن است؟ فرستادن رمز مشترک به نفر بعدی، جای ثبت رابطه فرد جدید با شرکت را نمی‌گیرد. بهتر است مدیر بتواند توضیح دهد هر حساب متعلق به چه کسی است و دلیل دسترسی فعلی او چیست.

حالا دوباره به عنوان «سفارش‌های من» برگردیم. در یک طراحی روشن، «من» به هویت مشخص وصل است، سفارش‌ها از رابطه کاری معتبر انتخاب می‌شوند، جزئیات قابل نمایش از اطلاعات داخلی جدا هستند و تغییر مسئولیت نیز مسیر معینی دارد. ارزش پنل فقط در این نیست که مشتری چیزی را بدون تماس ببیند؛ در این است که اطلاعات درست را با معنای روشن و در محدوده مسئولیت خودش دریافت کند.

هر دو تصویر با هوش مصنوعی ساخته شده‌اند و تصویرسازی مفهومی هستند؛ نمای واقعی پنل مشتریان یا یک محصول مشخص نیستند.

M
درباره نویسنده

تیم تحریریه مدیرم

تجربه‌های واقعی تیم مدیرم از طراحی محصول، معماری سیستم و ساخت نرم‌افزارهای قابل اتکا برای کسب‌وکارها.

همه مقاله‌ها ↗
گفتگو درباره این مطلب

نظر شما چیست؟

نظر شما برای ما ارزشمند استدیدگاه شما پس از بررسی نمایش داده می‌شود.
امتیاز شما
NEXT STEP / YOUR PROJECT

این مسئله در کسب‌وکار
شما هم واقعی است؟

برای تبدیل آن به یک سیستم روشن، سریع و قابل توسعه با ما گفتگو کنید.

شروع گفتگو ↗