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

