چرا این فاز مهم شد؟

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

این یافته یک سؤال مهم ایجاد کرد:

اگر مشتری در هفته‌ها و ماه‌های اول نتواند به استفاده واقعی از محصول برسد، آیا می‌توان با آموزش بهتر و محتوای بیشتر از ریزش او جلوگیری کرد؟

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

فرضیه

اگر مشتری در شروع کار:

• سریع‌تر محصول را راه‌اندازی کند؛

• مسیر یادگیری مشخصی داشته باشد؛

• برای قابلیت‌های اصلی محتوای قابل‌دسترسی دریافت کند؛

• و برای حل مسائل ساده مجبور به تماس با پشتیبانی نباشد؛

می‌توانیم:

1. زمان رسیدن مشتری به استفاده واقعی را کاهش دهیم؛

2. تعداد تیکت‌های آموزشی را کم کنیم؛

3. وابستگی مشتری به پشتیبانی را کاهش دهیم؛

4. و در نهایت، ریسک ریزش ناشی از «ارزش پایین» یا «عدم استفاده» را کاهش دهیم.

به همین دلیل، راه‌حل را فقط «تولید چند ویدئو» ندیدیم؛ بلکه کل مسیر مشتری از نصب تا یادگیری و دریافت کمک را بررسی کردیم.

چه چیزی را تغییر دادیم؟

۱. ساده‌سازی شروع کار و نصب

در ابتدای مسیر، بخشی از زمان و انرژی مشتری و پشتیبانی صرف نصب و آماده‌سازی سیستم می‌شد. بنابراین فرایند نصب با یک Installer ساده‌تر شد تا مشتری بتواند مراحل اولیه را با وابستگی کمتری به نیروی فنی طی کند.

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

۲. طراحی آموزش اولیه

برای مشتریانی که تازه وارد محصول می‌شدند، آموزش اولیه طراحی شد تا مسیر یادگیری از حالت پراکنده و وابسته به توضیحات کارشناس خارج شود.

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

• آشنایی با محیط محصول؛

• انجام اقدامات پایه؛

• راه‌اندازی قابلیت‌های ضروری؛

• شناخت مسیرهای پرتکرار؛

• و درک اینکه محصول دقیقاً کدام مسئله کسب‌وکار او را حل می‌کند.

این تغییر مهم بود، چون متوجه شدیم «آموزش دادن قابلیت» با «کمک به مشتری برای رسیدن به ارزش» یکسان نیست.

۳. پیگیری بعد از شروع استفاده

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

در این مرحله، تلاش کردیم بین سه وضعیت تفاوت بگذاریم:

• مشتری محصول را نصب کرده اما استفاده نمی‌کند؛

• مشتری استفاده می‌کند اما در یک قابلیت مشخص گیر کرده است؛

• مشتری به ارزش محصول نرسیده و هنوز دلیل استفاده مستمر را درک نکرده است.

این تفکیک کمک کرد بفهمیم مشکل هر مشتری الزاماً با یک محتوای آموزشی عمومی حل نمی‌شود.

۴. تولید محتوای آموزشی برای قابلیت‌های مختلف

برای قابلیت‌های پرتکرار و موضوعاتی که بیشترین سؤال را ایجاد می‌کردند، ویدئوهای آموزشی تولید شد. هدف این بود که مشتری برای هر سؤال ساده مجبور به تماس با پشتیبانی نباشد و بتواند در زمان نیاز، پاسخ مرتبط را پیدا کند.

برای کاهش وابستگی به مدرس و قابل‌استفاده‌تر شدن محتوا:

• ویدئوها کوتاه و موضوعی شدند؛

• برای قابلیت‌های مشخص محتوای جداگانه تولید شد؛

• زیرنویس به ویدئوها اضافه شد؛

• و محتوا در نقاطی قرار گرفت که مشتری احتمالاً هنگام مواجهه با مسئله به آن نیاز دارد.

۵. مشخص‌تر کردن راه‌اندازی چاپگر

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

• چه پیش‌نیازهایی لازم است؛

• مراحل راه‌اندازی چیست؛

• در هر مرحله چه خطاهایی ممکن است رخ دهد؛

• و در صورت بروز مشکل، باید از چه مسیری کمک بگیرد.

۶. آزمایش Chatbot و هدایت به محتوای مرتبط

برای بررسی امکان خودکارسازی پاسخ‌گویی، Chatbot آزمایش شد. هدف صرفاً پاسخ دادن به سؤال‌ها نبود؛ می‌خواستیم ببینیم آیا می‌توان مشتری را از سؤال اولیه به محتوای درست، آموزش مرتبط یا مسیر حل مسئله هدایت کرد.

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

۷. هم‌راستا کردن پشتیبانی و مرکز تماس

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

هدف این نبود که مشتری را از دریافت کمک محروم کنیم؛ هدف این بود که:

• مسائل ساده با محتوای مناسب حل شوند؛

• مشتری برای هر سؤال کوچک وارد فرایند طولانی نشود؛

• و پشتیبانی به‌جای تکرار یک توضیح، به ساختن عادت استفاده از منابع خودخدمتی کمک کند.

نتیجه

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

این موضوع باعث شد نتیجه را فقط با تعداد بازدید ویدئو یا کاهش کوتاه‌مدت تیکت نسنجیم. سؤال مهم‌تر این بود:

آیا مشتری بعد از دریافت آموزش، واقعاً رفتار خود را تغییر داده و مستقل‌تر شده است؟

پاسخ در بازه ۴ تا ۶ ماهه، عمدتاً منفی بود.

مهم‌ترین یادگیری

مشکل صرفاً «آموزش ندیدن» نبود.

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

مشتری ممکن بود یک ویدئو را ببیند، اما این به معنی آن نبود که:

• قابلیت را در کار روزمره خود استفاده می‌کند؛

• در مواجهه بعدی می‌تواند پاسخ را خودش پیدا کند؛

• یا ارزش محصول را بهتر درک کرده است.

در واقع، ما بین سه مفهوم تفاوت مهمی پیدا کردیم:

دریافت آموزش ≠ استفاده از قابلیت ≠ تجربه ارزش محصول

این تفکیک، مسیر تحلیل را تغییر داد. متوجه شدیم اگر مشتری برای پیدا کردن قابلیت‌ها، فهمیدن مراحل کار یا حل یک مسئله ساده همچنان به پشتیبانی وابسته است، مشکل فقط کمبود محتوا نیست؛ ممکن است مشکل از:

• پیدا نبودن قابلیت‌ها؛

• پیچیدگی فرایندها؛

• نامفهوم بودن متن‌ها و راهنماها؛

• فاصله بین آموزش و سناریوی واقعی مشتری؛

• یا پایین بودن ارزش ادراک‌شده محصول باشد.

بنابراین به‌جای اینکه صرفاً تولید محتوای بیشتری را ادامه دهیم، مسئله را در سطح تجربه محصول بررسی کردیم:

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

ارتباط این فاز با فاز بعدی

این فاز دو نتیجه مهم برای ادامه مسیر داشت.

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

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

در نتیجه، تمرکز از:

جلوگیری از همه ریزش‌ها با آموزش و پیگیری بیشتر

به سمت:

شناسایی مشتریان ارزشمند، پیشگیری از ریزش آن‌ها و طراحی پشتیبانی مقیاس‌پذیر

تغییر کرد.

این تغییر، نقطه اتصال این فاز با فاز بعدی بود: در فاز بعد دیگر فقط نمی‌پرسیدیم «چطور به مشتری کمک کنیم؟»؛ بلکه می‌پرسیدیم:

کدام مسئله باید با آموزش حل شود، کدام مسئله باید در محصول حذف شود، کدام مورد باید خودکار شود و کدام مشتری واقعاً ارزش مداخله دارد؟

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

۰۳ — آماده‌سازی پشتیبانی برای رشد بدون افزایش متناسب نیرو

با تغییر راهبرد کسب‌وکار، مسئله جدیدی شکل گرفت:

اگر تعداد فروشگاه‌ها ۴ برابر شود، آیا پشتیبانی هم باید ۴ برابر بزرگ شود؟

هدف کسب‌وکار

تحلیل فرایندهای پشتیبانی نشان داد گلوگاه‌ها فقط «تعداد تیکت» نیستند:

نصب · آموزش · به‌روزرسانی · تمدید · فعال‌سازی خدمات آنلاین

نصب: از ساده‌سازی Installer تا بازطراحی کل فرایند

در ابتدا یک Installer ساخته شده بود که با چند مرحله ساده، فرایند نصب را جلو می‌برد.

اما یک سؤال مهم مطرح شد:

اگر فرایند نصب ساده‌تر شده، چرا ظرفیت نصب پشتیبانی تقریباً افزایش پیدا نکرده است؟

بررسی وضعیت موجود

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

در سیستم‌های آماده، نصب به‌طور میانگین حدود ۱.۵ ساعت و در سیستم‌های مشکل‌دار حدود ۴ ساعت طول می‌کشید.

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

راه‌حل: پیش‌نصب + نصب + مدیریت موارد استثنا

به‌جای اینکه فقط Installer را سریع‌تر کنیم، فرایند را به چند مرحله تقسیم کردیم.

۰۱ — بررسی آمادگی سیستم

قبل از شروع نصب، وضعیت سیستم بررسی می‌شد:

• نسخه ویندوز

• فضای خالی دیسک

• وضعیت پارتیشن

• شرایط لازم برای نصب

۰۲ — نصب بدون نیاز به پشتیبانی تخصصی

اگر سیستم آماده بود:

دانلود → نصب → فعال‌سازی

و نیازی به اتصال از راه دور کارشناس نبود.

۰۳ — تشخیص و ثبت مشکل

اگر مشکلی وجود داشت، Installer مشخص می‌کرد مشکل چیست و گزارش آن را برای تیم پشتیبانی ثبت می‌کرد.

برای مثال:

• مشکل ویندوز

• کمبود فضای دیسک

• مشکل پارتیشن

• شکست نصب

• خطای ناشناخته

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

از نمایش خطا به سمت حل مسئله

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

در نتیجه مسیر از:

خطا → تماس با پشتیبانی

به سمت:

تشخیص → راهنمایی → حل توسط مشتری → ثبت مشکل → ارجاع

حرکت کرد.

داشبورد مدیریت فرایند نصب

بعد از مشخص شدن خطاها، یک داشبورد برای مدیریت فرایند نصب طراحی شد.

مدیر پشتیبانی می‌توانست وضعیت همه موارد را ببیند و هر کارشناس فقط موارد مرتبط با خودش را مشاهده می‌کرد.

به این ترتیب، همه درخواست‌ها وارد یک صف یکسان نمی‌شدند.

تشخیص مشکل → تعیین مسئول → پیگیری

حل یک گلوگاه، گلوگاه بعدی را آشکار کرد

یکی از مهم‌ترین یادگیری‌های این مرحله این بود:

ساده‌تر کردن یک مرحله، الزاماً ظرفیت کل فرایند را افزایش نمی‌دهد.

Installer قبلی فرایند نصب را ساده کرده بود، اما ظرفیت نصب به اندازه مورد انتظار افزایش پیدا نکرد.

بررسی فرایند نشان داد دو گلوگاه اصلی باقی مانده‌اند:

1. زمان پیدا کردن و هماهنگی با مشتری

2. سیستم‌هایی که قبل از شروع نصب آماده نبودند

بنابراین مسئله از «نصب نرم‌افزار» به «آماده بودن سیستم برای نصب» تغییر کرد.

کاهش وابستگی به نیروی تخصصی

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

فرایند جدید:

فروش → پیامک و اطلاع‌رسانی → پیش‌نصب → نصب → فعال‌سازی

فقط موارد مشکل‌دار وارد تیم تخصصی می‌شدند.

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

در نتیجه، نقش پشتیبانی از:

انجام‌دهنده تمام مراحل نصب

به:

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

تغییر کرد.

یک نمونه از تحلیل داده

در تحلیل فرایند نصب، حدود ۲۹٪ از نصب‌ها در گروه نصب‌های مشکل‌دار قرار گرفتند.

بنابراین هدف فقط کم کردن زمان نصب نبود؛ هدف اصلی این بود که موارد مشکل‌دار قبل از مصرف ظرفیت نیروی تخصصی شناسایی شوند.

آموزش؛ گلوگاه بعدی

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

به‌جای اینکه برای همه آن‌ها یک راه‌حل در نظر بگیریم، درخواست‌ها را بر اساس نوع مسئله دسته‌بندی کردیم:

این رویکرد باعث شد بخشی از مشکلاتی که قبلاً به‌عنوان «تیکت پشتیبانی» دیده می‌شدند، به‌عنوان «مسئله محصول» شناسایی شوند.

نتیجه کلی