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

