درس ۱۲ از ۱۴ · کورس رایگان تجارت
اشتراک تکراری، مسئولیت‌های تکراری هم می‌سازه. مشتری‌ها ضرورت دارن که خدمات هفته آینده هم به خوبی روز ثبت‌نام کار کنه. یک روال کوتاه و قابل‌اعتماد، پیش از ای که درخواست‌های عاجل تمام وقت‌تان ره بگیره، ای مسئولیت‌ها ره آشکار می‌سازه.
تا پایان: یک روال عملیاتی قابل‌مدیریت برای پشتیبانی، بلینگ، نگهداری و حفظ مشتری طراحی کنین.
با چهار نشانه روزانه شروع کنین
دسترس‌پذیری، فعال‌سازی مشتری‌های نو، استثناهای پرداخت و درخواست‌های پشتیبانی بی‌جواب ره بررسی کنین. تصمیم بگیرین کدام رویدادها به هشدار فوری ضرورت داره و کدام‌ها باید در بازبینی زمان‌بندی‌شده بیایه. یک ثبت‌نام ناموفق شاید زودتر از یک تغییر کوچک در ترافیک هفتگی نیاز به توجه داشته باشه.
به هشدارها یک مسئول و یک اقدام تعیین کنین. مانیتوری که صدها پیام نادیده‌گرفته‌شده می‌فرسته، بی‌از ای که قابلیت اطمینان ره بهتر کنه، سر و صدا ایجاد می‌کنه. مشخص کنین چطور یک حادثه ره تشخیص می‌دین، تأیید می‌کنین کی‌ها متأثر شدن و هنگام بررسی، مشتری‌ها ره آگاه نگه می‌دارین.
برای FitSite، یک بررسی صبحگاهی می‌تانه تأیید کنه که سایت‌های موجود پاسخ می‌دن، سایت‌های تازه‌ساخته‌شده قالب درست دارن، رویدادهای بلینگ پردازش شدن و پیام‌های پشتیبانی مسئول دارن. یک SaaS گزارش‌دهی، واردسازی موفق داده‌ها و تحویل گزارش ره جایگزین آماده‌سازی سایت می‌کنه. کار مشتری ره در سراسر سیستم دنبال کنین.
پشتیبانی‌ای ره وعده بدین که می‌تانین ارائه کنین
کانال‌های روشن پشتیبانی، ساعت‌های پوشش و هدف‌های زمان پاسخ ره تعیین کنین. هدف زمان پاسخ یعنی تأیید دریافت و ارزیابی یک درخواست؛ ای وعده حل هر مشکل در همان مدت نیس. میان یک پرسش عمومی و قطعی‌ای که دسترسی یا پرداخت‌ها ره متأثر می‌کنه تفاوت بگذارین.
راهنمای اصلی، سطح‌های مختلف پشتیبانی ره بر اساس پلان نشان می‌ده. تنها وقتی از ای فکر استفاده کنین که توانایی عمل کردن به او ره دارین. اگر تنها کار می‌کنین و چنین پوششی ندارین، وعده چهار ساعت گمراه‌کننده اس. به‌جای ای که مشتری‌ها دسترس‌پذیری همیشگی فرض کنن، ساعت کاری و منطقه زمانی ره صریح بیان کنین.
یک چک‌لیست کوتاه برای دریافت درخواست بسازین: حساب متأثر، کاری که تلاش شده، نتیجه مشاهده‌شده و زمان خرابی. فقط معلوماتی ره بخواین که برای بررسی لازم اس. هیچ‌وقت از مشتری نخواهین رمز عبور یا جزئیات کامل کارت ره ایمیل کنه. به کارکنان پشتیبانی دسترسی متناسب با مسئولیت‌های‌شان بدین.
درخواست‌های تکراری ره به بهبودهای محصول تبدیل کنین
پرسش‌های تکراری ره برچسب‌گذاری کنین و دنبال علت اساسی بگردین. چند مشتری که می‌پرسن چطور برنامه زمانی ره تغییر بدن، شاید نشان‌دهنده یک مقاله راهنمای گم‌شده، یک صفحه گیج‌کننده یا کاری باشه که محصول به‌خوبی پشتیبانی نمی‌کنه. نوشتن مستندات یک پاسخ اس، نه جواب هر مشکل کاربردپذیری.
یک مقاله راهنمای مؤثر، کار ره نام می‌بره، مرحله‌های فعلی ره نشان می‌ده، توضیح می‌ده چطور موفقیت ره تشخیص بدین و اگر ناکام شد، قدم بعدی ره پیشنهاد می‌کنه. پس از تغییر محصول دوباره او ره بررسی کنین. برای موردهایی که با مقاله جور نمیایه، یک راه دسترسی به شخص واقعی نگه دارین.
فرض کنین یک بررسی پشتیبانی فرضی FitSite شش پرسش در مورد افزودن یک مربی پیدا می‌کنه. تیم می‌تانه دستورالعمل‌های قالب مربوطه ره بهتر کنه، تماشای تلاش یک نفر برای انجام کار ره بکنه و درخواست‌های بعدی ره مقایسه کنه. تا وقتی ای نتیجه ره اندازه‌گیری نکردین، ادعا نکنین که یک مقاله راهنما پشتیبانی ره کاهش داده.
بلینگ و دسترسی ره تطبیق کنین
بلینگ تکراری به درگاه پیکربندی‌شده، تنظیمات اشتراک و رسیدن رویدادهای پرداخت به برنامه شما وابسته اس. خودکارسازی نیاز به بررسی استثناها ره از میان نمی‌بره. پیش از تغییر دستی دسترسی یا صادر کردن بازپرداخت، وضعیت عضویت ره با سابقه پرداخت مقایسه کنین.
یک پرداخت ناموفق می‌تانه چندین علت داشته باشه. به‌جای فرض کردن ای که کارت منقضی شده یا لغو عمدی بوده، معلومات واقعی ردشدن یا رویداد ارائه‌دهنده ره بررسی کنین. از تنظیمات پشتیبانی‌شده ارائه‌دهنده برای تلاش مجدد و اطلاع‌رسانی به مشتری استفاده کنین و توضیح بدین مشتری چطور از راه امن جزئیات پرداخت ره به‌روزرسانی کرده می‌تانه.
برای بخش وردپرس، عضویت‌ها و پرداخت‌های Ultimate Multisite ره در کنار سوابق درگاه‌تان بررسی کنین. ارتقاها، تنزل‌ها، پایان دوره‌های آزمایشی و فاکتورها ره در نسخه پیکربندی‌شده‌تان تأیید کنین. به‌جای وعده ای که هر تغییر پلان یکسان رفتار می‌کنه، زمان‌بندی تغییرها و هرگونه محاسبه نسبتی ره بررسی کنین.
لغو کردن ره ساده نگه دارین. تاریخ مؤثر پایان، وضعیت بلینگ آینده و هر ترتیب صادرات یا نگهداری داده ره تأیید کنین. یک پرسش اختیاری برای بازخورد می‌تانه کمک کنه یاد بگیرین، اما لغو نباید وابسته به پاسخ دادن به او باشه. بازپرداخت‌ها ره مطابق شرایطی که واقعاً ارائه کردین، یکسان تطبیق کنین.
خدمتی ره نگهداری کنین که قابل بازیابی باشه
نگهداری معمول ره زمان‌بندی کنین و برای به‌روزرسانی‌های عاجل امنیتی یک مسیر داشته باشین. هر به‌روزرسانی ره تا جلسه ماهانه به تأخیر نندازین. بر بنیاد مشکل و میزان در معرض بودن اولویت‌بندی کنین، تا حد ممکن مصون آزمایش کنین و اگر تغییر مشکل ساخت، یک پلان بازیابی نگه دارین.
برای WordPress Multisite، تغییر یک افزونه یا قالب مشترک شاید بر بسیاری سایت‌های مشتری تأثیر بگذاره. پلان‌های نمونه، قالب‌ها، پرداخت و دسترسی ره در محیط آزمایشی امتحان کنین. از محافظت داده و کنترل‌های دسترسی متناسب با نسخه آزمایشی استفاده کنین؛ محیط آزمایشی نباید معلومات مشتری ره آشکار کنه.
از محتوای پایگاه داده و فایل‌های لازم نسخه پشتیبان نگه دارین و بازیابی ره آزمایش کنین. بازیابی‌های موفق اخیر ره ثبت کنین، نه فقط کارهای موفق پشتیبان‌گیری ره. علاوه بر ای که صفحه اصلی باز می‌شه یا نه، برای تمام‌شدن منابع، کارهای پس‌زمینه ناموفق و خطاهای تحویل هم نظارت داشته باشین.
بیاموزین چرا مشتری‌ها می‌مانن یا می‌رن
برای یک دوره مشخص، ریزش مشتری ره تعریف کنین: مشتری‌های از دست‌رفته در جریان دوره تقسیم بر مشتری‌های فعال در آغاز او. قواعد شمارش‌تان ره ثبت کنین، از جمله ای که توقف‌ها و حساب‌های پرداخت‌نشده ره چطور حساب می‌کنین. ریزش درآمد یک معیار متفاوت اس و باید جداگانه برچسب بخوره.
اگر یک تجارت فرضی ماه ره با ۵۰ مشتری شروع کنه و دو نفرشان ره از دست بده، ریزش مشتری برای او گروه ۴٪ اس. مشتری‌های نوی که در جریان ماه به‌دست میایه، آن مخرج ابتدایی ره تغییر نمی‌ده. با تعدادهای کم، یک لغو می‌تانه درصد ره به‌شدت تغییر بده، پس دلیل‌های فردی ره هم بررسی کنین.
مشکل‌های محصول، تغییرهای بودجه، بسته‌شدن تجارت‌ها و مشتری‌هایی که هیچ‌وقت به نخستین نتیجه مفیدشان نرسیدن ره جدا کنین. هرجا مناسب بود کمک یا یک پلان مناسب ارائه کنین. فرض نکنین تخفیف یک ویژگی گم‌شده ره حل می‌کنه، و پیش از فرستادن پیشنهادهای بازگشت، به ترجیح‌های ارتباطی احترام بگذارین.
وقتی مشتری نیاز مرتبط داره و هزینه اضافی ره می‌فهمه، ارتقا پیشنهاد کنین. رسیدن به یک محدودیت می‌تانه فرصتی برای روشن کردن پلان درست باشه، اما پیام نباید گزینه کاهش استفاده یا ماندن در سطح فعلی ره پنهان کنه.
برای روال یک تقویم بسازین
بررسی‌های روزانه دسترس‌پذیری، پشتیبانی عاجل و استثناهای بلینگ ره پوشش می‌ده. بازبینی‌های هفتگی دنبال تیکت‌های حل‌نشده، ناکامی‌های فعال‌سازی و مشکل‌های تکراری می‌گرده. بازبینی‌های ماهانه درآمد تکراری، هزینه‌ها، حفظ مشتری و مستندات ره بررسی می‌کنه. بازبینی‌های سه‌ماهه قیمت‌گذاری، ظرفیت و ای که پیشنهاد هنوز با مخاطبان سازگار اس یا نه ره دوباره می‌بینه.
از ای تناوب به‌عنوان نقطه شروع استفاده کنین، بعد او ره با خطر و حجم کار خدمات سازگار کنین. تجارتی که رزروهای حساس به زمان ره پردازش می‌کنه، نسبت به یک اشتراک پژوهشی ماهانه به نظارت متفاوت نیاز داره. هدف ای اس که کار میان مسئولیت‌ها گم نشه، نه ای که برای خود جلسه‌ها جلسه بسازین.
تمرین شما: یک برگه عملیاتی بنویسین
چهار بخش بسازین: نظارت، پشتیبانی، بلینگ و نگهداری. برای هر کدام، مسئول، تناوب، مدرکی که باید بررسی شوه و اقدام برای یک استثنا ره نام ببرین. برای کارهای مهم یک مسئول جایگزین هم شامل کنین.
وعده پشتیبانی‌تان ره با زبان ساده بنویسین، شامل ساعت‌ها و تفاوت میان پاسخ نخست و حل مشکل. بعد بررسی کنین که برنامه فعلی‌تان در زمان بیماری یا رخصتی از او پشتیبانی کرده می‌تانه یا نه.
یک کار تکراری مشتری ره انتخاب کنین و یک مقاله راهنما بنویسین. او ره با کسی که با محصول آشنا نیس آزمایش کنین. ثبت کنین که آیا او کار ره بدون توضیح اضافی کامل می‌کنه یا نه.
در آخر، یک حادثه ره روی کاغذ تمرین کنین: مشتری پرداخت کرده اما دسترسی نداره. فهرست کنین کدام سوابق ره مقایسه می‌کنین، چطور ارتباط برقرار می‌کنین و چطور بدون صادر کردن پرداخت دوم، بازیابی ره تأیید می‌کنین.
پیش از ای که ادامه بدین
عملیات پایدار، مسئولیت‌پذیری، وعده‌های روشن و بازیابی ره باهم ترکیب می‌کنه. گام‌های قابل‌اعتماد ره خودکار کنین، استثناها ره بررسی کنین و از پرسش‌های مشتری برای بهتر ساختن تجربه استفاده کنین. حفظ مشتری ره با تعریف‌های صریح دنبال کنین، نه ای که تنها به برچسب یک داشبورد تکیه کنین.
منابع و مطالعه بیشتر
برگرفته از درس اصلی ۱۲: اداره تجارت. FitSite یک تجارت فرضی برای آموزش اس، نه یک داستان موفقیت مشتری. راهنمای پشتیبان‌گیری وردپرس اجزای یک نصب قابل‌بازیابی ره توضیح می‌ده.