مقالات

ویترین های MSP یک مشکل جلویی نیستند. آنها Backend One هستند.


هر MSP آن لحظه را داشته است. مشتری برای اجاره جدید به لپ تاپ نیاز دارد و دو گزینه دارد:

کسب‌وکارهای بیشتری گزینه دو را انتخاب می‌کنند، و هر بار که این کار را انجام می‌دهند، این درآمد به خرده‌فروشی می‌رسد که هرگز سعی نکرده یک MSP باشد، یا به رقیبی که قبلاً ویترینی ساخته است که شما این کار را نکرده‌اید.

اکثر MSP ها سعی می کنند به PSA های خود تکیه کنند، اما آنها هرگز به عنوان یک سیستم تجاری ساخته نشدند. می تواند یک سفارش فروش ایجاد کند، اما سیستم مدیریت سفارش ندارد و با حمل و نقل یکپارچه نمی شود، دو چیزی که واقعاً برای فروش آنلاین به آن نیاز دارید.

برای پیاده‌سازی ویترین فروشگاه MSP، دفتر فروش شما باید یک کاتالوگ دیجیتال، منطق قیمت‌گذاری که توسط مشتریان پشتیبانی می‌شود، و یک سیستم مدیریت سفارش داشته باشد که سفارش را به حمل و نقل و بازگشت همراه با رهگیری انتقال دهد.

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

در اینجا راهنمایی در مورد چگونگی ایجاد یک استراتژی فروشگاهی موفق است که تجربه ای شبیه آمازون را برای مشتریان شما ارائه می دهد.

مشتریان شما انتظار یک ورود دارند، نه شش

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

این شکاف بیش از یک ناراحتی است. به همین دلیل است که پذیرش سلف سرویس حتی زمانی که ویترین فروشگاهی از نظر فنی وجود دارد کم می ماند. اگر سفارش یک دستگاه از شما مراحل بیشتری نسبت به سفارش آن از یک خرده فروش داشته باشد، مشتریان شما را دور خواهند زد.

و حتی در جایی که ویترین فروشگاه یا سایت تجارت الکترونیکی وجود دارد، اغلب اشتباه است. برخی از MSP ها تصمیم می گیرند با ارسال یک خوراک خام به یک توزیع کننده و اعلام انجام آن، “یک کاتالوگ به مشتری بدهند”. یک توزیع کننده بزرگ مانند CDW کاتالوگ سرپرستی چند صد هزار مورد را نگهداری می کند. توزیع‌کننده‌ای مانند Ingram Micro بیش از یک میلیون نفر را وارد بازار می‌کند. دادن یک فید کامل و بدون فیلتر به یک مشتری مفید نیست، این گزینه‌ها را به او می‌دهد تا در آن گم شوند.

Curation به هر مشتری یک تجربه خرید می دهد که در واقع برای چیزی که آنها می خواهند یا برای خرید تأیید شده است ساخته شده است.

مشتریان به دو روش خرید می‌کنند، اما اکثر بک‌اندها فقط یکی را پشتیبانی می‌کنند

کسب‌وکارها در دو حالت مختلف خرید می‌کنند، اما بیشتر پشته‌ها و گردش‌های کاری فناوری MSP فقط برای یک مورد ساخته شده‌اند.

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

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

این دو جنبش نیازهای زیرساختی جداگانه ای دارند، اما MSP مدرن و مشتریان آنها اکنون به آنها نیاز دارند تا در یک سیستم پشتیبان اجرا شوند.

چرا MSP ها به طور پیش فرض موقعیت متوسط شکسته را دارند

بدون سیستمی که برای هر دو حرکت خرید ساخته شده است، MSP ها با یکی از دو راه حل مواجه می شوند و هیچ یک راه حل واقعی نیست.

اولین بار: همه چیز را از طریق CPQ اجرا کنید.

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

بار دوم: از ویترین فروشگاه به یک باطن غیرمرتبط بپیوندید.

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

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

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

دلیل واقعی شکست ویترین ها

ویترین یا فروشگاه تجارت الکترونیکی خود بخش آسانی برای ساخت است. ساختن فروشگاهی با ظاهری تمیز با ابزار مناسب یک آخر هفته طول می کشد. قسمت سخت این است که تمام لوله کشی زیر آن را بسازیم.

چهار نقطه شکست به ترتیب نمایش داده می شود:

کاتالوگ هایی که عادی نیستند. کشیدن خوراک خام توزیع‌کننده به‌جای کاتالوگ سفارشی و ویژه مشتری به این معنی است که مشتریان در میلیون‌ها SKU جستجو می‌کنند در حالی که آنچه واقعاً به آن نیاز دارند 5 لپ‌تاپ است که قرار است به آنها بفروشید، نه همه چیزهایی که توزیع‌کننده حمل می‌کند.

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

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

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

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

قیمت گذاری با قرارداد هر مشتری مرتبط است

سفارش هایی که هرگز به سفارش نمی رسند مدیریت سفارش داخلی، نه راه حل
ردیابی باید دو بار وارد شود یک سیستم متصل یک بار وارد شد

به همین دلیل است که تعداد کمی از MSP ها یک ویترین کارآمد را راه اندازی کرده اند، حتی اگر سال ها تقاضا وجود داشته باشد. چیزی که گم شده است یک Backend است که برای پشتیبانی از آن ساخته شده است.

یک لایه تجاری یکپارچه به چه چیزی نیاز دارد؟

بنابراین پشتیبان برای پشتیبانی از CPQ و تجارت الکترونیک به چه چیزی نیاز دارد؟ مجموعه خاصی از اجزا که با هم کار می کنند:

یک لایه تجاری دو راه برای خرید را تامین می کند

  • کاتالوگ دیجیتال: سخت افزار، نرم افزار و خدمات در یک مکان، از طریق اتصالات توزیع کننده زنده به جای به روز رسانی دستی، به روز نگه داشته می شوند. هر مشتری نمای فیلتر شده خود را در ارتباط با قیمت توافقی خود دریافت می کند، زیرا هیچ دو مشتری نباید به کاتالوگ 300000 کالای مشابه نگاه کنند.
  • موتور CPQ: نقل قول منطق و گردش کار منسجم که به ایجاد مشخصات، پیکربندی، قیمت گذاری و ارزش گذاری، میز معاملات، پیشنهادات و تاییدیه ها می پردازد.
  • پشتیبانی از بسته: هم بسته‌های چند خطی سنتی و هم راه‌حل‌های همراه SKU.
  • منطق قیمت: قوانینی که با انواع محصول و شرایط خاص مشتری سازگار است
  • مدیریت سفارش، تحویل، پیگیری و تهیه و صدور صورتحساب: با هم به عنوان یک زنجیره متصل از خرید تا تحویل کار کنید.

آمازون محصولات می فروشد. AWS نتایج را می فروشد. مشتریان شما هر دو را می خواهند.

آمازون و AWS در دو حرکت کاملا متفاوت به فروش می رسند. آمازون محصولات را می فروشد: جستجو، کلیک، خرید، ارسال. AWS نتایج را به فروش می‌رساند: یک راه‌حل پیکربندی شده که بر اساس آنچه یک کسب‌وکار خاص در تلاش است انجام دهد.

مشتریان شما هر دو را می خواهند. گاهی اوقات آنها به یک لپ تاپ نیاز دارند، سریع، بدون نیاز به صحبت کردن. در مواقع دیگر، آنها به یک راه حل کامل نیاز دارند: امنیت مدیریت شده، به روز رسانی شبکه، چیزی که بر اساس تنظیمات خاص آنها ساخته شده است که هیچ کس دیگری در آن ترکیب دقیق نمی فروشد. این نوع دوم خرید بیشتر شبیه AWS است تا آمازون.

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

با Backend شروع کنید، نه خود Storefront

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

این دقیقاً چگونه ساختار پلت فرم معاملاتی TechGrid است: یک باطن، دو حرکت فروش. اگر می خواهید گردش کار پیشنهادی به پول خود را به روز کنید، یک نسخه نمایشی را برنامه ریزی کنید.


Source link

نوشته های مشابه

دیدگاهتان را بنویسید

همچنین ببینید
بستن
دکمه بازگشت به بالا