اغلب کمتر از آنچه لیست درخواست نشان می دهد. قبل از اینکه کسی یک شی جدید طراحی کند یا یک پروژه سفارشی سازی CRM را ارزیابی کند، هر درخواست را به یکی از شش قضاوت مرتب کنید زیرا فقط یکی از آنها یک ساخت واقعی است.
در یک تمرین الزامات مستند، این مرحله نشان داد که 11 مورد از تقریباً 44 درخواست ویژگی هایی هستند که مشتری قبلاً مجوز آنها را صادر کرده و آنها را خاموش کرده است. این یک جلسه مدیریت بود، نه یک پروژه توسعه.
چرا درخواست تغییر CRM اینقدر گران می شود؟
در تمرین زیر، هیچ پرس و جوی مشکلی را توصیف نمی کند. هر کدام به عنوان یک راه حل آماده وارد شدند: “ما به یک کاشی داشبورد نیاز داریم”، “ما به یک ماژول مجوز جدید نیاز داریم”.
در مواجهه با این لیست، هر دو طرف تمایل دارند که طراحی را به یکباره شروع کنند. قبل از اینکه کسی بررسی کند که پلتفرم قبلاً چه کاری انجام می‌داد، تجزیه و تحلیل به یک نقل قول توسعه تبدیل شده بود.
دو برابر هزینه دارد. بودجه در نظر گرفته شده برای شکاف های واقعی صرف ساختن چیزهایی می شود که فقط باید گنجانده شوند. سپس مشتری متوجه می شود که این ویژگی در تمام مدت وجود داشته است، و هرکسی که ساخت را نقل قول کرده اعتماد خود را از دست می دهد که به سختی می توان آن را بازگرداند.
چگونه تصمیم می گیرید که در واقع چه چیزی نیاز به ساخت دارد؟
Coevera (قبلا Pipeliner CRM) روش را در یک پروژه پیاده سازی مستند می کند. تا زمانی که هر درخواست دقیقاً یکی از شش حکم را دریافت نکند، هیچ کس چیزی را رتبه بندی نمی کند:
- زنده: این ویژگی در حال حاضر فعال است و مردم آن را نمی دانند. این باعث می شود که یک کار آموزشی باشد، نه ساخت.
- تغییر وضعیت: همراه محصول است اما خاموش است. متعلق به یک مدیر است.
- پیکربندی: با اتوماسیون، فیلدهای سفارشی، گزارش ها یا چک لیست ها قابل دستیابی است.
- ساخت و ساز: یک طرح واره جدید، یک رابطه یا یکپارچگی جدید. فقط این یک کار نمونه است.
- حد: پلت فرم نمی تواند آن را انجام دهد. پرس و جو را در مورد چیزی که واقعاً وجود دارد، دوباره قالب بندی کنید.
- غیر محصولی: یک سوال خط مشی، تجاری یا ابزارهای داخلی که به لیست CRM راه یافت.
هر جمله همچنین مالکی را مشخص می کند که یک لیست مرتب شده را به یک برنامه کاری تبدیل می کند.
بررسی سوئیچ ها چند دقیقه طول می کشد. هر سیستم مشتری Coevera دارای یک تغییر ویژگی است: لیستی از ویژگی‌ها و ادغام‌های آن، که هر کدام بررسی یا خاموش می‌شوند. در سیستم مورد مطالعه، تقریباً 107 رکورد دارد. هر کوئری را با یک خط مرتبط کنید و فقط زمانی آن را ساختنی بنامید که هیچ خطی آن را پوشش ندهد.
وقتی راه‌حل ساخت است، چهار مکان وجود دارد که داده‌ها می‌توانند از ارزان‌ترین به گران‌ترین مکان بروند: یک فیلد از یک رکورد موجود، یک زیرنوع از یک رکورد موجود، یک رکورد فرزند مرتبط یا یک شی کاربر جدید. سوال تعیین کننده کوتاه است. آیا این چیز فقط فهرست، فیلتر و گزارش می دهد و آیا عمر خودش را دارد؟ نگاهی به مکان می کند. یک تاریخ، یک بازرس و یک نتیجه وجود دارد و کسی لیستی از معوقات می خواهد. سطح توزیع کننده ندارد. یک حساب کاربری را توصیف می کند.
چگونه در یک تمرین واقعی به نظر می رسید
با شش بخش جداگانه مصاحبه شد. بین آنها حدود 44 درخواست مختلف، از بازرسی در محل گرفته تا گزارش منطقه ای، تهیه کردند.
مرتب کردن آنها ابتدا تصویر را تغییر داد:
- 11 درخواست سوئیچ بود. ویژگی‌ها در سیستم خود مشتری وجود داشتند و مجوز داشتند و به سادگی خاموش می‌شدند. 9 نفر از آنها با چیزی در یادداشت های جلسه مطابقت داشتند.
- 16 عملکرد قبلاً فعال بودند و هرگز به مشتری نشان داده نشد.
- سه درخواست یک دلیل داشت. شمارش افرادی که به این رویداد دعوت شده‌اند، شمارش افرادی که واقعاً با آنها ملاقات کرده‌اند و پیشنهادات مبتنی بر حضور سه مجموعه به نظر می‌رسد. همه آنها به یک دیوار برخورد کردند: رویدادها هیچ ارتباط مستقیمی با مخاطبین نداشتند. ایجاد آن یک اتصال، هر سه را متمایز کرد.
- چهار مورد را نمی توان پوشش داد زیرا یادداشت های جلسه برای تفسیر آنقدر مبهم بود. اینها به جای حدس و گمان به عنوان سؤالات باز بیان شد.
سپس دستور تحویل از قضاوت ها تبعیت می کند. هر کسی که امروز مسدود شده است را رفع انسداد کنید. به مشتری آنچه را که قبلاً دارند نشان دهید. هر چیزی که آماده است را روشن و پیکربندی کنید. فقط پس از آن استناد به مجموعه های باقی مانده به عنوان یک لیست بسیار کوتاه تر. اقلام غیرمحصولی را به هر کسی که واقعاً آنها را دارد بدهید.
چه زمانی این رویکرد ناکافی است؟
رایگان همیشه به معنای رایگان نیست. پرچم فعال/غیرفعال نمی‌تواند به شما بگوید که آیا مدیر امروز می‌تواند یک ویژگی را فعال کند یا مجوز آن را متوقف می‌کند. قبل از اینکه به کسی قول برنده شدن سریع بدهید، با تیم محصول فروشنده چک کنید.
بعضی چیزها را نمی توان به هر قیمتی ساخت. برخی از اشیاء پلتفرم شکل ثابتی دارند و فیلدهای اضافی را نمی پذیرند. در این تمرین، هیچ آزمون یا قابلیت مدیریت یادگیری در پلتفرم وجود نداشت، بنابراین ارزیابی‌های ورود باید به‌عنوان راهنمای ارائه خدمات یا ابزار شخص ثالث مجدداً فرموله می‌شد.
داشتن اشیاء سفارشی گران است و هر نسخه Coevera شامل آنها نمی شود. هر کدام فرم دیگری برای نگهداری، مجموعه دیگری از مجوزها برای درست کردن، و ورودی منوی دیگری برای ایجاد است. این هزینه معمولاً از پیش بینی خارج می شود.
یافته های کلیدی
- هر پرس و جوی CRM را به یکی از شش قضاوت مرتب کنید قبل از اینکه کسی به چیزی امتیاز دهد.
- ابتدا، مواردی را که قبلاً دارای مجوز و مستثنی شده اند، بررسی کنید. در یک تمرین، 11 مورد از تقریباً 44 درخواست بود.
- به دنبال خوشه ها باشید. درخواست های متعدد اغلب یک پیوند گمشده را به اشتراک می گذارند.
- قبل از اینکه سوئیچ را یک برد سریع رایگان نامید، مجوز را تأیید کنید.
- یک شی سفارشی را فقط زمانی انتخاب کنید که آن چیز برای خودش عمر داشته باشد.
طرح کامل، با جزئیات پیکربندی، رهگیری های میدان جستجو، و چک لیست تأیید، در Coevera Blueprints است: چگونه چیزی را مدل سازی می کنید که CRM شما آن را هدف قرار نمی دهد؟
