پشتیبانی مشتری نرم‌افزار SaaS: سطح‌ها و زمان پاسخ
پشتیبانی مشتری نرم‌افزار SaaS چطور سازمان میگیرد: سطح‌های کمک از مستندات تا تیکت، سؤال‌های شروع کار، باگ یا آموزش، تحویل به مهندسی و زمان پاسخ هر پلن.
در این مطلب
مشتری SaaS یک بار نرم‌افزار نمی‌خرد و برود. دوشنبه وارد می‌شود، سه‌شنبه گیر میکند و روز تمدید تصمیم میگیرد ارزشش را داشت یا نه. پشتیبانی مشتری نرم‌افزار SaaS کاری است که میان این لحظه‌ها انجام می‌شود، و با پشتیبانی یک فروشگاه فرق دارد: سؤال‌ها دربارهٔ رفتار نرم‌افزارند، یک نفر بارها می‌پرسد و بخشی از گزارش‌ها باگ واقعی‌اند که فقط مهندسی می‌تواند درستشان کند.
این مطلب می‌گوید کمک‌هایی که می‌دهید چطور لایه‌بندی شود، باگ را چطور از سؤال آموزشی جدا کنید، مسئله را چطور به مهندس‌ها بسپارید و روی هر پلن چه قولی بدهید.
سه سطح کمک
بیشتر تیم‌های SaaS، برنامه‌ریزی کرده باشند یا نه، به سه لایه می‌رسند. برنامه‌ریزی یعنی هر لایه کار مشخصی داشته باشد.
| سطح | مناسب برای | چه کسی پاسخ می‌دهد | انتظار معمول |
|---|---|---|---|
| خودخدمتی (مستندات، راهنمای داخل محصول) | مراحل راه‌اندازی، «فلان تنظیم کجاست» | خود مشتری | هیچ |
| چت زنده | سؤال سریع وقتی کاربر داخل محصول است | اپراتورهای پشتیبانی | چند دقیقه |
| تیکت | هر چیزی که بررسی یا چند روز زمان می‌خواهد | پشتیبانی، بعد بقیه | چند ساعت تا چند روز |
قاعدهٔ سرانگشتی: سؤالی که یک پاسخ درست دارد جایش مستندات است، سؤالی که یک نگاه سریع انسانی می‌خواهد جایش چت است، و سؤالی که باید حساب یا لاگ را دید جایش تیکت. هدهد پایگاه دانش ندارد؛ مستندات را هر جا که منتشر می‌کنید نگه دارید و در پاسخ‌های آماده لینکشان کنید. برای نوشتنشان پایگاه دانش و مرکز راهنما را ببینید.
چت و تیکت می‌توانند در یک صندوق باشند. چتی که معلوم می‌شود یک ساعت بررسی می‌خواهد، با تاریخچه‌اش تیکت می‌شود؛ تیکتینگ و چت زنده را ببینید، و اگر نمی‌دانید با کدام شروع کنید تیکتینگ یا چت زنده را.
سؤال‌های شروع کار دستهٔ جدا هستند
دو هفتهٔ اول، آدم‌ها چیز دیگری می‌پرسند تا کاربران قدیمی. به‌ندرت باگ گزارش می‌دهند؛ می‌خواهند بدانند اول چه کنند.
سؤال‌های بیست‌سی حساب جدید اول را جمع کنید و دسته‌بندی کنید. معمولاً همان پنج‌شش تا تکرار می‌شود: اتصال داده، دعوت هم‌تیمی‌ها، وارد کردن فایل، مبانی صورتحساب، یک تنظیم گیج‌کننده. بعد:
- برای هرکدام یک پاسخ آماده بنویسید، با لینک مستند یا جواب دو خطی.
- یک منوی کوتاه چت‌بات یا یک سؤال پیش از چت جلوی چت بگذارید تا این پرسش‌ها همان‌جا جواب بگیرند.
- برچسب «شروع-کار» بزنید تا ماهانه بشمارید.
اگر یک سؤال شروع کار مدام می‌رسد، احتمالاً خود محصول یا صفحهٔ اول ورود نامفهوم است. این یافته‌ای برای تیم محصول است، نه دلیلی برای استخدام یک اپراتور دیگر. پاسخ‌های آماده و قالب‌ها را ببینید.
باگ است یا سؤال آموزشی؟
اولین کار روی هر پیام تشخیص همین است. پاسخ و صاحب این دو فرق دارد.
| نشانه | سؤال آموزشی | باگ |
|---|---|---|
| مشتری می‌گوید | «چطور این را خروجی بگیرم؟» | «خروجی خطا می‌دهد» |
| برای شما کار میکند؟ | بله، با همان مراحل | نه، همان خطا را می‌بینید |
| راه‌حل | یک جواب، شاید یک مستند | تغییر در کد |
| صاحب | پشتیبانی | مهندسی |
وقتی مطمئن نیستید، با همان پلن و نقش مشتری خودتان بازتولید کنید. اگر نشد، جزئیات را در یک پیام بخواهید، نه در پنج پیام. نمونه‌ای برای کپی:
ممنون از گزارشتان. برای بررسی از سمت ما لطفاً این‌ها را بفرستید: ۱. صفحه یا بخشی که مشکل در آن رخ می‌دهد و آنچه انتظار داشتید ببینید ۲. آنچه به‌جایش دیدید (اسکرین‌شات کمک میکند) ۳. زمان رخ دادن، با منطقهٔ زمانی ۴. نسخهٔ مرورگر یا اپلیکیشن ۵. هر بار رخ می‌دهد یا گاهی
اولویت تصمیمی جدا از نوع است. باگی که همهٔ کاربران یک حساب را متوقف کند فوری است، و سؤال آموزشی یک کاربر آزمایشی یک روز قبل از پایان دوره‌اش هم شاید فوری باشد. اولویت‌بندی و تریاژ تیکت را ببینید.
تحویل باگ به مهندسی
پشتیبانی معمولاً همین‌جا می‌لنگد؛ نه چون مهندس‌ها در دسترس نیستند، بلکه چون گزارش بدون اطلاعات لازم می‌رسد یا یازده بار می‌رسد.
یادداشت تحویل، چه در ابزار پیگیری بفرستید چه دستی، این‌ها را داشته باشد:
- خلاصهٔ یک‌جمله‌ای مشکل
- مراحل بازتولید و آنچه دیده‌اید
- حساب، پلن و زمان اولین گزارش
- تا الان چند مشتری گزارش داده‌اند
- راه‌حل موقت، اگر هست، و آنچه به مشتری گفته‌اید
در هدهد می‌توانید گفت‌وگوها و تیکت‌ها را به یک ایشو (Issue) وصل کنید: یک رکورد برای یک مشکل، تا مهندسی به‌جای انبوه پیام یک مورد با شمارش ببیند. ایشو وقتی مشکل برمی‌گردد رخدادهایش را هم نگه می‌دارد و می‌شود آن را بهصورت تیکت مهندسی به Jira فرستاد؛ پیگیری ایشو و اتصال پشتیبانی به Jira را ببینید. به مشتری بگویید بعدش چه می‌شود («به مهندس‌ها سپرده‌ایم و وقتی درست شد خبر می‌دهم») و روی تیکت سررسید بگذارید تا واقعاً خبر بدهید.
وقتی مشکلی هم‌زمان چند حساب را میگیرد، حادثه است نه تیکت. اینکه چه کسی و کِی خبر شود در نمونهٔ سیاست ارجاع و تشدید آمده.
پشتیبانی داخل اپلیکیشن
مشتری همان لحظه‌ای که گیج می‌شود می‌پرسد، یعنی داخل محصول شما. دکمهٔ کمکی که چت را باز کند و کاربر از قبل شناسایی شده باشد، رفت‌وبرگشت «ایمیلتان چیست؟» را حذف میکند و به اپراتور زمینه می‌دهد. برای موبایل، SDK اندروید چت و تیکت را به اپ بومی می‌آورد؛ آموزش SDK اندروید را ببینید. در وب همین کار را ویجت سایت میکند.
انتظار پاسخ بر اساس پلن
لازم نیست همهٔ پلن‌ها یک سرعت بگیرند، ولی هرکدام باید قولی بگیرد که بتوانید نگهش دارید. ساختاری ساده، با عددهای نمونه بر حسب ساعت کاری:
| پلن | کانال‌ها | اولین پاسخ | هدف حل باگی که کار را متوقف میکند |
|---|---|---|---|
| رایگان | مستندات، تیکت | ۲ روز کاری | بدون تعهد |
| استاندارد | مستندات، چت، تیکت | ۸ ساعت کاری | ۳ روز کاری |
| بیزنس | همه، به‌علاوهٔ یک مخاطب مشخص | ۱ ساعت کاری | ۱ روز کاری |
این‌ها عدد نمونه‌اند. از آنچه تیمتان امروز تحویل می‌دهد شروع کنید و حساب را چک کنید: اگر سه اپراتور هرکدام حدود ۳۰ تیکت در روز جواب بدهند و پلن بیزنس ۴۰ حساب داشته باشد که هرکدام هفته‌ای یک تیکت می‌فرستند، صف بیزنس به سقف نزدیک هم نیست. اگر پلن رایگان ۴٬۰۰۰ کاربر داشته باشد، شاید باشد. پیش از چاپ عددها روی صفحهٔ قیمت‌ها، حساب خودتان را بکنید.
برای اجرا در هدهد، گفتوگو را با پلن برچسب بزنید (مثلاً «پلن-بیزنس») و یک قانون خودکارسازی بسازید که سیاست SLA متناسب را به گفت‌وگوهای آن برچسب اضافه کند. جزئیات در SLA در پشتیبانی مشتری.
چک‌لیست هفتگی
- تیکت‌های جدید را با برچسب بشمارید: آموزشی، باگ، صورتحساب، شروع کار
- پنج تیکت باز قدیمی‌تر را بخوانید
- باگ‌هایی را که بیش از یک گزارش دارند فهرست کنید و وضعیتشان را از مهندسی بپرسید
- سؤال‌های آموزشی را که سه بار یا بیشتر آمده‌اند پیدا کنید و مستند بنویسید یا اصلاح کنید
- مهلت‌های ازدست‌رفته را با قول‌های هر پلن مقایسه کنید
اگر می‌خواهید این را با پلن‌ها و برچسب‌های خودتان در یک صندوق مشترک ببینید، دموی رایگان بگیرید.
سؤالات متداول
آیا کاربران رایگان هم باید پشتیبانی بگیرند؟
تصمیم با شماست، ولی چیزی بدهید: مستندات و فرم تیکت با قول کندتر، یا یک انجمن. سکوت پیش از اولین پرداخت به ریزش تبدیل می‌شود.
گزارش باگ با پشتیبانی است یا مهندسی؟
گفتوگو با مشتری تا آخر با پشتیبانی است و درست کردن با مهندسی. مشتری نباید ماجرایش را برای مهندسی تکرار کند؛ یادداشت تحویل برای همین است.
چطور جلوی تکرار یک سؤال آموزشی را بگیرم؟
بشمارید. وقتی سؤالی در یک ماه سه بار آمد، جوابش را در مستند و پاسخ آماده بنویسید. اگر باز هم آمد، صفحه‌ای را که سؤال از آن میآید بازبینی کنید.
چت زنده برای محصول SaaS ضروری است؟
نه. بسیاری از تیمها با مستندات و تیکت کار میکنند. چت وقتی کمک میکند که کاربر وسط کار گیر کرده یا دارد برای خرید تصمیم میگیرد، و باید در ساعتهای اعلامشده کسی پایش باشد.
اطلاعات پلن مشتری از کجا میآید؟
از خود شما. هدهد به سیستم صورتحساب شما وصل نمیشود، پس پلن را باید دستی یا با قانون خودکارسازی بر اساس شرطهای دیگر بهصورت برچسب اضافه کنید.
