دو فهرست مشتری را کنار هم بگذارید که امروز دقیقاً نام‌های یکسانی دارند. یکی قرار است افراد واجد شرایطِ همین لحظه را نشان دهد؛ دیگری باید یادآوری کند چه کسانی در یک تاریخ مشخص انتخاب شده بودند. ظاهرشان یکی است، اما مأموریتشان فرق دارد. اگر این تفاوت در طراحی CRM روشن نباشد، ممکن است فردی که دیگر شرایط لازم را ندارد همچنان در صف اقدام بماند، یا سابقه یک انتخاب گذشته با تغییر اطلاعات امروز عوض شود.
بخش‌بندی مشتریان یعنی گروه‌کردن پرونده‌ها بر اساس معیارهایی که به یک تصمیم یا اقدام مشخص کمک می‌کنند. ارزش گروه به نام جذاب آن نیست؛ باید بتوان توضیح داد چرا هر عضو داخل آن است و چه زمانی باید خارج شود. در این مقاله، دو نسخه از یک فهرست فرضی را دنبال می‌کنیم و بعد به سراغ منطق شرایط می‌رویم. مثال‌ها تألیفی‌اند؛ رفتار فنی نمونه محصول از مستندات رسمی آمده و به معنی تأیید همان قابلیت‌ها در تمام CRMها نیست.
یک انتخاب مشترک، دو سرنوشت متفاوت
یک فروشنده فرضی تجهیزات قهوه می‌خواهد با کافه‌هایی که دستگاه خریده‌اند و هنوز جلسه آشنایی با نگهداری آن را نگذرانده‌اند، برای هماهنگی تماس بگیرد. امروز نام سه کافه در هر دو فهرست دیده می‌شود. فردا یکی از آنها جلسه را می‌گذراند و کافه دیگری دستگاه می‌خرد. اکنون پرسش اصلی این است: فهرست باید وضعیت تازه را نشان دهد یا انتخاب امروز را نگه دارد؟ تعداد سه فقط برای ساده‌کردن مثال است و آمار واقعی نیست.
در راهنمای ساخت گروه در HubSpot، به‌روزشده در ۲۹ سپتامبر ۲۰۲۶، گروه فعال یا پویا اعضا را بر اساس شرایط به‌روز می‌کند: پرونده واجد شرایط وارد می‌شود و با از دست دادن شرایط خارج می‌شود. فهرست ثابت، اعضای منطبق در زمان ذخیره را نگه می‌دارد و بر اساس تغییر شرایط خودکار به‌روز نمی‌شود؛ افزودن یا برداشتن دستی اعضا همچنان ممکن است.
برای کار روزانه فروشنده فرضی، گروه پویا می‌تواند پاسخ «امروز با چه کسانی هماهنگ کنیم؟» را بدهد. وقتی گذراندن جلسه به‌درستی ثبت شود و گروه به‌روز شود، آن کافه دیگر نباید در همین گروهِ منتظران باشد. در مقابل، فهرست ثابت برای نگه‌داشتن مجموعه‌ای که روز آغاز برنامه انتخاب شده بود کاربرد دارد. این دو خروجی رقیب هم نیستند؛ هرکدام به پرسشی متفاوت پاسخ می‌دهد و ممکن است هر دو لازم باشند.
فهرست ثابت را هم نباید بایگانی کامل گذشته دانست. ثابت‌ماندن عضویت، به‌تنهایی ثابت‌ماندن شماره تماس، نام مسئول یا دیگر اطلاعات پرونده را تضمین نمی‌کند. اگر برای بررسی بعدی لازم است بدانیم هنگام انتخاب چه وضعیتی وجود داشت، پیشنهاد طراحی ما ثبت تاریخ انتخاب، نسخه معیار و اطلاعات ضروری همان تصمیم است. فقط ذخیره نام گروه با عنوان «مشتریان منتخب» این نیاز را روشن نمی‌کند.
جمله‌ای که باید پیش از فیلتر نوشته شود
پیش از انتخاب گزینه‌ها در نرم‌افزار، هدف گروه را با زبان معمولی بنویسید: «کافه‌هایی که خرید دستگاهشان تأیید شده و جلسه آشنایی با نگهداری را هنوز نگذرانده‌اند.» این جمله از عنوان مبهم «مشتریان مهم» قابل استفاده‌تر است. همکار فروش و همکار خدمات می‌توانند درباره معنای خرید تأییدشده و پایان جلسه توافق کنند، سپس فیلدهای مناسب را به آن وصل کنند.
واحد عضویت نیز باید مشخص باشد. در این مثال، قرار است یک کافه یک بار برای هماهنگی بررسی شود، نه هر شخصی که شماره‌اش در پرونده کافه وجود دارد. ممکن است صاحب کافه و مسئول شیفت هر دو مخاطب ثبت‌شده باشند. اگر گروه را بر پایه افراد بسازیم، باید جداگانه روشن کنیم تماس با کدام فرد انجام می‌شود. انتخاب واحد نامناسب می‌تواند چند کار مشابه برای یک مجموعه ایجاد کند، حتی وقتی همه نام‌ها درست ثبت شده‌اند.
این بخش به نظم اطلاعات پایه وابسته است. اگر یک کافه با دو پرونده جدا شناخته شود، یا وضعیت جلسه در یادداشت آزاد بماند و در فیلد مورد استفاده گروه ثبت نشود، فیلتر نمی‌تواند منظور تیم را از روی ظاهر پرونده حدس بزند. مقاله مرتبط زیر درباره یکتایی، تازگی و کامل بودن داده‌ها توضیح می‌دهد؛ پیش‌نیازهایی که کیفیت هر بخش‌بندی به آنها وابسته است.
یک «یا» به جای «و»، گروه دیگری می‌سازد
قاعده مثال ما دو شرط دارد: خرید تأیید شده باشد و جلسه انجام نشده باشد. کافه‌ای که فقط درخواست قیمت داده، شرط اول را ندارد؛ کافه‌ای که خرید کرده و جلسه را گذرانده، شرط دوم را ندارد. هیچ‌کدام نباید با همین تعریف در گروه منتظران جلسه قرار گیرد. این دو نمونه مرزی، معنای قاعده را بهتر از نگاه‌کردن صرف به تعداد اعضا روشن می‌کنند.
راهنمای معیارهای فیلتر HubSpot، به‌روزشده در ۱۵ سپتامبر ۲۰۲۶، منطق AND یا «و» را برای برقرار بودن همه شرایط و OR یا «یا» را برای برقرار بودن دست‌کم یکی از شرایط توضیح می‌دهد. در مثال ما، جایگزینی «و» با «یا» می‌تواند هم خریدارِ دارای جلسه تکمیل‌شده و هم متقاضیِ بدون خرید را وارد گروه کند. این تفاوت، اشکال ظاهری فرم نیست؛ تعریف مخاطب اقدام را عوض می‌کند.
برای بررسی، از همکار تنظیم‌کننده بخواهید دلیل ورود یا خروج چند پرونده مشخص را با زبان ساده بیان کند. لازم نیست فهرست طولانی‌ای از آزمون‌های بی‌هدف بسازیم. پرونده‌ای که هر دو شرط را دارد، پرونده‌ای که فقط یکی را دارد و پرونده‌ای که هیچ‌کدام را ندارد، باید مطابق تعریف رفتار کنند. اگر پاسخ نرم‌افزار با انتظار فرق دارد، ابتدا تنظیم شرط و داده مبنا را بررسی کنیم، نه اینکه برای رسیدن به عدد دلخواه اعضا را دستی کم‌وزیاد کنیم.
«نمی‌دانیم» با «انجام نشده» یکی نیست
در پرونده یک کافه، وضعیت جلسه خالی است. آیا این یعنی جلسه برگزار نشده؟ ممکن است برگزار شده باشد اما همکار مربوط هنوز آن را ثبت نکرده باشد. ممکن هم هست داده از فایل قدیمی آمده باشد و اصلاً این موضوع در آن ثبت نشده باشد. پیشنهاد عملی برای مثال ما، جدا نگه‌داشتن وضعیت نامعلوم از وضعیت تأییدشده «انجام نشده» است تا ابهام به اقدام قطعی تبدیل نشود.
همان مستند معیارهای فیلتر، «نامعلوم» را برای نبود مقدار توضیح می‌دهد و یادآور می‌شود که صفر در فیلد عددی یک مقدار معلوم است. بنابراین نبود داده را نباید خودکار به صفر یا پاسخ منفی تعبیر کرد. در طراحی پیشنهادی شرکت، پرونده‌های نامعلوم می‌توانند وارد صف بررسی جداگانه شوند؛ مسئول خدمات وضعیت را روشن کند و پس از ثبت نتیجه، گروه اصلی بر اساس داده معتبر تصمیم بگیرد.
همچنین خروج از یک گروه الزاماً به معنی لغو کاری نیست که قبلاً برای یک همکار ساخته شده است. گروه، عضویت را توصیف می‌کند؛ رفتار وظیفه یا پیام به قواعد همان سامانه وابسته است. برای نمونه فرضی ما، پیش از تماس باید روشن باشد اگر جلسه در فاصله ساخت وظیفه تا زمان تماس برگزار شد، همکار از کجا این تغییر را می‌بیند. این پرسش را باید در طراحی اقدام پاسخ داد و نمی‌توان فقط از نام «گروه پویا» نتیجه گرفت که همه کارهای قبلی خودبه‌خود اصلاح می‌شوند.
تعریف نهایی گروه را با یک یادداشت کوتاه همراه کنید: چه موجودیتی عضو می‌شود، شرط ورود و خروج چیست، اطلاعات نامعلوم کجا بررسی می‌شوند و چه اقدامی از عضویت نتیجه می‌شود. مسئول نگهداری تعریف و تاریخ آخرین بازبینی هم مشخص باشد. وقتی برنامه جلسه‌ها تغییر کرد، همین یادداشت نشان می‌دهد کدام بخش باید دوباره بررسی شود. هدف، زیادشدن تعداد گروه‌ها نیست؛ هر گروه باید تصمیمی روشن را پشتیبانی کند که همکار بعدی نیز بتواند دلیلش را بفهمد.
هر دو تصویر با هوش مصنوعی تولید شده‌اند و تصویرسازی مفهومی‌اند؛ شخصیت تصویر شاخص فرد واقعی معرفی‌شده در مقاله نیست و شکل هم‌پوشانی گروه‌ها نمودار آماری نیست.
نظر شما چیست؟