مقدمه
تیم پشتیبانی مجله زیبایی و درمانی آذروت نقش کلیدی در اطمینان حاصل می‌کند که کاربران ما در مواقعی که اتفاقات غیرمنتظره رخ می‌دهد یا پرسش‌هایی درباره محصولات و خدمات ما دارند، پشتیبانی لازم را دریافت کنند.
در گذشته، وقتی کاربران نیاز به پشتیبانی در زمان واقعی داشتند، تنها گزینه آنها تماس با خط ویژه ما بود و در صف انتظار برای صحبت با یک نماینده قرار می‌گرفتند. اما پشتیبانی صوتی مشکلات خود را دارد: گاهی اوقات توضیح یک مسئله در برنامه پیچیده است و نیاز به تمام توجه کاربر برای تماس صوتی دارد.
با رشد برنامه‌های چت پیام‌رسان در سال‌های اخیر، چت به عنوان کانال پشتیبانی مورد انتظار و شناخته شده توسط کاربران شده است. این کانال پشتیبانی به همراهی پشتیبانی به صورت واقعی‌زمان و امکان مولتی‌تسکینگ و توضیح آسان مسئله با استفاده از اشتراک تصاویر و اسناد را ارائه می‌دهد. در مقایسه با پشتیبانی صوتی، چت به دسترسی به گفتگوی مورد استفاده برای مرجع آینده ارائه می‌دهد.
با رشد چت، ساخت یک سیستم چت تنظیم شده برای نیازهای پشتیبانی ما و یکپارچه شده با داده‌های داخلی، به نظر می‌رسد گام بعدی طبیعی باشد.
در مقالات قبلی ما، چالش‌های فنی ساختن سکوی چت برای وب و بهبود کارآیی نمایندگان با یادگیری ماشین را پوشش داده‌ایم. در این مقاله، رویکرد و یادگیری‌های کلیدی ما در ساخت چت درون ساختمانی برای پشتیبانی از زاویه محصول و طراحی را توضیح خواهیم داد.
چرا نیاز به تجدید ابتکار است
ما می‌خواستیم یک محصول ارائه دهیم که به طور کامل کاربرانمان را خوشحال کند. به همین دلیل تصمیم گرفتیم یک ابزار چت داخلی بسازیم که بتواند:
- جلوگیری از قطع ارتباط چت و اطمینان حاصل کردن از تجربه چت یکنواخت: ساختن یک تجربه چت داخلی به ما اجازه می‌دهد تا یک جلسه چت پایدار را تضمین کنیم، حتی زمانی که کاربران از برنامه خارج می‌شوند. علاوه بر این، بهره‌گیری از زیرساخت چت مجله زیبایی و درمانی آذروت موجود به ما کمک کرد تا این کار را به سرعت انجام دهیم و تجربه چت در کل برنامه یکنواخت باشد. می‌توانید در مورد معماری چت بیشتر بخوانید.
شکست سریع با MVP
قبل از ساختن یک راه‌حل کامل، ما نیاز به اثبات مفهوم داشتیم، یک MVP که ویژگی‌های کلیدی را داشته باشد و با این حال، اگر شکست خوردید، زیاد زمان واگذار نکند. برای شروع تجربه ما، ما معیارهای موفقیت برای MVP خود را تعیین کردیم؛ چگونه ما موفقیت یا شکست آن را اندازه‌گیری می‌کنیم؟
تعریف آنچه که موفقیت به نظر می‌رسد
هر آزمایشی نیاز به فرضیه دارد - چیزی که سعی در اثبات یا متنافی آن را دارید و باید به محصول نهایی خود ارتباط پیدا کند. برای شخصی‌سازی محصول نهایی در اطراف معیارهای موفقیت، باید بفهمیم که چگونه موفقیت در موقعیت ما اندازه‌گیری می‌شود. در مورد ما، قطع ارتباط در حین پشتیبانی چت یکی از چالش‌های اصلی است که با آن روبرو شدیم، بنابراین فرضیه ما بود:
شروع با طرح طراحی
طرح طراحی ما به هدف حل یک سری اظهارات مشکل پردازی کرد و یک طرح نمونه تولید کرد تا فرضیه ما را تأیید کند. برای القاء ایده‌پردازی، تمرین‌های طراحی متنوعی از جمله Crazy 8، Solution sketch و به اشتراک گذاری و رای گیری انجام دادیم.
تعریف دامنه MVP برای اجرای آزمایش
برای سریع پایه مفهوم خود را آزمودن، ما باید بر روی عملکرد پایه اجازه گرفتن از تبادل پیام چت با یک نماینده تمرکز کنیم.
اینجا جریان اصلی و یک نگاه سریع به طراحی است:
آنچه را از آزمایش یاد گرفتیم
در طول آزمایش، ما باید به طور مداوم خود را به جای کاربران خود قرار دهیم چرا که ‘ما خودمان کاربران نیستیم’. ما تصمیم گرفتیم که نمایندگان پشتیبانی چت ما را تظاهر کنیم و با مشاهده مشکلات بالقوه کاربرانمان، بسیار درباره نحوه استفاده از ابزار آن در چرخه بعدی بیاموزیم. این کار به ما کمک کرد تا بسیاری درباره نحوه استفاده از ابزار یاد بگیریم و چندین مشکل را در نسخه‌های بعدی شناسایی کنیم.
در نهایت، آزمایش فرضیه ما را تأیید کرد که داشتن یک چت درون برنامه‌ی اصلی پایدارتر از چت پیشین است و در نتیجه تجربه کاربری بهتری را ارائه می‌دهد.
شروع با هدف در ذهن
پس از موفقیت آزمایش، ما به مقیاس بزرگتر تمرکز کردیم. ما مهمترین وظایف انجام شده برای کاربران خود را تعریف کردیم تا بتوانیم محصول را به مقیاس بالاتری برسانیم. در طراحی راه‌حل‌ها برای مقابله با هر یک از آنها، اطمینان حاصل کردیم که محصول به اندازه کافی انعطاف پذیر است تا به مشکلات آینده پرداخته شود. آیا این برای کانال‌های بیشتر، کاربران بیشتر، محصولات بیشتر و کشورهای بیشتر کار می‌کند؟
قبل از مقیاس‌پذیری، مسائلی برای حل و فصل وجود داشت:
- پایش عملکرد سیستم به صورت زمان واقعی تا تغییرات عملیاتی سریع بتواند اعمال شود تا مطمئن شویم کاربران پشتیبانی سریعی دریافت می‌کنند؛ مسیریابی هر چت به بهترین نماینده در دسترس، با در نظر گرفتن مهارت‌ها، شغل، و همچنین اولویت بررسی مسئله. می‌توانید در مورد طراحی سیستم مسیریابی ما بیشتر بخوانید؛ ارتباط آسان با کاربران و نشان دادن هم‌دردی، که به ما کمک کرد تا قابلیت‌های به اشتراک گذاری فایل برای هر دو کاربر و نماینده، و همچنین اجازه استفاده از شکلک‌ها را برای هر دو طرف فراهم کنیم که تجربه‌ای شخصی‌تر را به ارمغان می‌آورند.
مقیاس‌پذیری بهره‌ور
ما مسیر پشتیبانی چت را تجزیه‌کردیم تا ببینیم کدام بخشها قابل بهبود هستند.
کاهش زمان انتظار
زمان انتظار میانگین به طور چشمگیری بالا می‌رود. در این موارد، بیشتر کاربران تا زمانی که یک نماینده بالاخره به آنها پاسخ دهد، بی‌پاسخ می‌مانند.
برای حل این مشکل، تیم بر روی یک مفهوم حداکثر صف پویا بر اساس قانون لیتل کار کرد. ایده این است که با در نظر گرفتن تعداد چت‌های ورودی و ظرفیت نماینگی‌ها، می‌توانیم تعداد کاربرانی را که می‌توانیم در زمان معقولی مدیریت کنیم پیش‌بینی کنیم و از بقیه جلوگیری کنیم که چت را شروع کنند. با این کار، مطمئن می‌شویم که یک کانال پشتیبانی فرعی وجود دارد تا هیچ کاربری بی‌پاسخ نماند.
این به ما اجازه داد تا زمان انتظار چت را تا حدود 30٪ و تعداد کاربران بی‌پاسخ را تا حدود 7٪ کاهش دهیم.