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

