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