چت آنلاین
نحوه برخورد با تقاضاهای خاص مشتریان
هنگام برخورد با مشتری، به یاد داشته باشید که بین اهداف ذینفعان و نیازهای کاربر اصلی تفاوت هایی وجود دارد. بیشتر اولویت های تصمیم گیرندگان، زمان و بودجه است، در حالی که کاربران اصلی بیشتر ویژگی های خاص را درخواست می کنند. از آنجا که این اهداف با یکدیگر در تضاد هستند، باید تصمیم بگیرید که کدام طرف را می خواهید خشنود کنید.
شما همیشه باید کاری را انجام دهید که به نظرتان بهترین کار برای پروژه می باشد. این به معنای به چالش کشیدن درخواست های کاربران کلیدی است، اگر فکر می کنید که این کار برای پروژه ارزشی ندارد تا حدی از انجام آن امتناع بورزید. برای رسیدگی به درخواستهای سفارشی سازی توسعه از روشهای زیر استفاده کنید:
1. آیا واقعاً لازم است؟
2. آیا ارزش هزینه توسعه و نگهداری را دارد؟
3. آیا سود حاصل از آن به اندازه کافی قابل توجه است؟
4. آیا می توانیم با رویکردی متفاوت در خدمت همان هدف باشیم؟
اگر به این نتیجه رسیدید که توسعه یک ویژگی خاص ارزش ندارد، باید بیشتر تلاش کنید تا مشتری را قانع کنید. تاکتیکهای مختلفی برای این کار وجود دارد: "چرا" را توضیح دهید، بعد از تاریخ "عملیاتی سازی" آن را مرحله بندی کنید، به یک مدیر تبدیل شوید (اگرچه ایده آل نیست، اما گاهی اوقات لازم است).
تاکتیک 1: آیا واقعا لازم است؟
فرض کنید برای توسعه سفارشی زیر درخواستی دارید:
مشتری وب سایتی دارد که با فروشگاه اینترنتی مجنتو توسعه یافته و نمی خواهد آن را تغییر دهد، زیرا قبلاً در آن سرمایه گذاری زیادی کرده است. اما آنها دوست دارند اودوو به طور کامل با وب سایت مجنتو یکپارچه شود (شامل محصولات، کوپن ها، پیگیری سبدهای رها شده و غیره).
بهترین روش برای ارزیابی این است که آیا ضرورتی دارد که بررسی شود که مشتری قبلاً این ویژگی را در نرم افزار قدیمی خود داشته است یا خیر . اگر مشتری تمام سفارشات را به صورت دستی در نرم افزار قدیمی خود ثبت کرده باشد، می تواند این کار را با همان روش اودوو نیز انجام دهد. پس از آن، توصیه می شود که بدون ایجاد یکپارچه سازی با مجنتو، پروژه را اجرا کنید، چند ماه از اودوو استفاده کنید و سپس ارزش آن را تعیین کنید. به یاد داشته باشید، اولویت های مشتری وقتی وارد مرحله اجرا می شود، تغییر می کند.
از نظر مدیریت تغییر، شروع فرآیند کسب و کار به صورت تدریجی تغییر می کند نه یکباره. به خاطر وجود افزونه ها در اودوو، استقرار در چند مرحله منطقی است. مرحله اول، آنچه که مشتری برای فعالیت در این کسب و کار نیاز دارد و تنها پس از انتقال به مرحله دوم، سایر ویژگی ها برای بهبود کارایی اجرا می شوند.
"یک کاربر کلیدی از من خواست گزارش پیچیده ای را که هر هفته در اکسل تهیه می کنند، تهیه کنم. به گفته کاربر، این گزارش برای مدیر عامل بسیار مهم بود. با این حال، من کاربر را به چالش کشیدم تا بداند کدام یک از شاخص های کلیدی عملکرد مربوط به مدیر عامل است.
به نظر می رسید که مدیر عامل فقط چند مبلغ را بررسی می کرد و آن، موجودی برخی از حساب های تحلیلی بود. من به جای اینکه با توسعه به جلو بروم، به مدیرعامل نشان دادم که چگونه این موجودی را مستقیماً در اودوو بررسی کند و آنها از این موضوع خوشحال شدند.
به چالش کشیدن مشتری نه تنها توسعه سفارشی و خطرات تأخیر را کاهش می دهد، بلکه ارزش کسب و کار را افزایش می دهد."
- سدریک، رهبر پروژه ، BE اودوو
تاکتیک 2: آیا پشتیبانی از هزینه ها ارزش دارد؟
شما باید مزایای آن را ارزیابی کنید. مشتری به خاطر این ویژگی، چند روز در ماه صرفه جویی می کند؟ اغلب اوقات، مشتری فقط حساب می کند که در حال حاضر چه مدت زمانی را برای انجام این کار صرف می کند و چقدر در هزینه های آینده می تواند صرفه جویی کند. در حقیقت، او هنوز هم مجبور به ثبت تمام داده های لازم برای محاسبه، سر و کار داشتن با موارد استثنایی به صورت دستی و غیره است. به عنوان مثال، حتی اگر مشتری رابط مجنتو را توسعه دهد، باز هم باید همه مغایرت ها را حل کند، تخفیف قیمت در هر دو راه حل نرم افزاری را ثبت کند و چون همگام سازی آنی نیست، با مغایرت های موجودی مواجه شود و غیره.
شما باید هزینه های جاری را نیز ارزیابی کنید. غالباً مشتری فقط "هزینه توسعه یک باره" را می بیند. ولی در واقع، شما می توانید برای تعمیر و نگهداری و ارتقاء در آینده و تا 5 سال بعد، این هزینه ها را در 2 یا 3 ضرب کنید.
توجه داشته باشید که استفاده از افزونه کامیونیتی (نسخه کم هزینه تر) به شما امکان می دهد تا در زمان توسعه اولیه صرفه جویی کنید، ولی همچنان آزمایش، تعمیر و نگهداری، تاخیر پروژه و ارتقاء را در هزینه ها لحاظ کنید. افزونه کامیونیتی (نسخه کم هزینه تر) نیز بدهی فنی است.
تاکتیک 3: آیا سود مورد نظر به اندازه کافی مهم است؟
فرض کنید شما درخواستی برای توسعه سفارشی زیر دارید:
وقتی یک سفارش فروش را برای یک پروژه ساخت و ساز تأیید می کنیم، می خواهیم یک سری وظایف را براساس مجموعه قوانینی ایجاد کنیم که به محصولات، مشتریان و مکانها بستگی دارد. هنگامی که درخواستی برای سفارشی سازی دارید، ابتدا باید در مورد حجم، سوال کنید: "در هر ماه، چند پروژه ساختمانی انجام می دهید؟" فرض کنید، مشتری ماهانه 10 مورد از این پروژه ها را انجام می دهد. ایجاد و به روزرسانی کارها با تکثیر و به روزرسانی قالب های پروژه، می تواند 10 دقیقه طول بکشد.
آیا راه اندازی توسعه پیچیده، برای صرفه جویی در کمتر از 2 ساعت در ماه، ارزش دارد؟ مطمئنا نه، نه تنها هزینه این ویژگی حدود 10 روز خواهد بود، 25 در صد نیز در سال افزایش خواهد یافت.
تاکتیک 4: آیا می توانیم با رویکردی متفاوت در خدمت همان هدف باشیم؟
فرض کنید درخواست مشتری شما به صورت زیر است:
من می خواهم تقویم Outlook خود را با CRM اودوو هماهنگ کنم.
اودوو به طور استاندارد دارای رابطی با تقویم گوگل است، اما با Outlook این گونه نیست. توسعه و نگهداری یک رابط ممکن است هزینه زیادی صرف کند. با این حال، سرویس های زیادی وجود دارد که تقویم گوگل را با Outlook همگام می کنند (مانند IFTTT). بنابراین، راه حل می تواند اشتراک گذاری و راه اندازی چنین خدماتی برای هر کارمند باشد.
اینکار، بهترین راه حل نیست زیرا شما مجبورید هر بار که یک کارمند جدید استخدام می کنید، تنظیمات را تغییر دهید. اما این راه حل در مدت 2 ساعت آماده است و برای هر کارمند جدید، 10 دقیقه طول می کشد. اگر شرکتی کمتر از 100 کارمند داشته باشد، بسیار کمتر از یک توسعه جدید زمان می برد.
"چند سال پیش من برای Bioulvax، یک تولید کننده محصولات آشامیدنی بلژیکی، پروژه استقرار را انجام دادم. نماینده مشتری برای این پروژه بسیار پرشور بود، او متقاعد شده بود که روش کار او کارآمدترین روش است و همه افراد شرکت باید مانند او کار کنند.
ما کار خوبی انجام ندادیم زیرا با او مصالحه کردیم و برخی از درخواست های ایشان را پذیرفتیم. فیلدهای تاریخ داشتیم که هرگز استفاده نشده بودند، فیلدهای انتخابی که صفحه نمایش را بدون دلیل پر می کردند، آیتم های منو که کاربر پسند نبودند و غیره. بعد از چند ماه کار با سیستم، متوجه شدیم که بسیاری از کارمندان از آن استفاده نکرده اند و بدون اینکه مدیر را مطلع کنند، دوباره از نرم افزار قدیمی خود استفاده می کنند.
وقتی این موضوع را فهمیدیم، موارد زیر را پیشنهاد کردیم: "بیایید به نحوه عملکرد سیستم در استاندارد کامل برگردیم و با تیم صحبت کنیم تا بفهمیم چه چیزی می خواهند از سیستم خروجی بگیرند". به عبارت دیگر، به جای اینکه یک روش خاص کاری را به عنوان راه و روش اصلی تعیین کنیم، از افراد پرسیدیم که چه چیزی می خواهند. ما دموها را کاملاً مطابق با استاندارد و با در نظر گرفتن اهداف تیم سازماندهی کردیم.
آنها نمی توانستند باور کنند که استفاده از این سیستم آسان است، ولی وقتی به مرحله اجرا رساندیم، کل تیم، اودوو را پذیرفتند و عادت های قدیمی خود را کنار گذاشتند. من یاد گرفتم که همیشه نیازمندی های نماینده مشتری را به چالش بکشم و همچنان بر اهداف کسب و کار تمرکز کنم. اغلب اوقات، مشتریان کسب و کار خود را میشناسند، اما نحوه اجرای آن را نمی دانند.
- سدریک، رهبر پروژه،BE & SF اودوو