درس ۱۳ / ۱۴ · کورس رایگان کاروبار
رشد، علاوه بر عاید، مسئولیت هم اضافه می‌کنه. پیش از زیاد کدنِ ترافیک، ویژگی‌ها یا اندازهٔ تیم، بفهمین کدام بخش کاروبار فعلاً تحویل‌دهی قابل‌اعتماد ره محدود می‌کنه. او محدودیت ره بهبود بدین و نتیجه ره اندازه‌گیری کنین.
تا آخر: گلوگاه فعلی خویش ره شناسایی کنین، یک مجموعه کوچیک از سنجه‌های مفید ره حساب کنین، و یک آزمایش رشد مبتنی بر شواهد انتخاب کنین.
از شماره‌ها همراه با تعریف‌های روشن استفاده کنید
عواید تکرارشوندهٔ ماهانه، یا MRR، عواید فعال اشتراک‌های تکرارشونده ره به اساس ماهانه نشان میته. مصارف یک‌بارهٔ راه‌اندازی و خدمات ره از ای معیار جدا کنین. اشتراک‌های سالانه ره به‌گونهٔ یکسان نرمال‌سازی کنین و مستند بسازین که با تخفیف‌ها، بازپرداخت‌ها و حساب‌های پرداخت‌ناشده چطور برخورد می‌کنین.
میانگین عایدِ تکرارشونده به‌ازای هر حساب، عبارت از MRR تقسیم بر تعداد حساب‌های فعالِ پرداخت‌کننده‌ای است که برای او دوره استفاده شده. ای سود به‌ازای هر مشتری نیسته. ریزش مشتری، مشتری‌هایی ره که از گروه آغازین از دست رفته‌اند پیگیری می‌کنه؛ ریزش عاید، عایدِ تکرارشونده از‌دست‌رفته ره پیگیری می‌کنه و وقتی اندازه پلان‌ها فرق داشته باشه، می‌تانه داستان متفاوتی ره نشان بته.
مصرف به‌دست‌آوردن مشتری باید بیان کنه که کدام مصرفای فروش و بازاریابی ره شامل می‌کنین و کدام مشتریای نو ره حساب می‌کنین. مقایسهٔ یک برآورد صرفاً نقدی با مصرف کاملِ یک چینل دگه، نتیجهٔ گمراه‌کننده میته. فرضیات مربوط به وقت مؤسس، قراردادی‌ها و کمیشنای ارجاعی ره ثبت کنین.
نمونهٔ FitSite ره با دقت انجام بته
مخلوطِ نمونویِ منبع ره در نظر بگیرید: ۳۰ حسابِ Starter با ۴۹ دالر، ۱۵ حسابِ Growth با ۹۹ دالر و پنج حسابِ Pro با ۱۹۹ دالر در ماه. عایدِ پایهٔ اشتراک ماهانهٔ اونا $1,470 + $1,485 + $995 = $3,950 است. ای قیمت‌ها فرضیات آموزشی‌اند، نه قیمت‌های پیشنهادی بازار.
اگر امو مشتری‌های هم‌چنان هر ماه ۵۰۰ دالر اضافات تکراری بپردازن، مجموع MRR برابر ۴٬۴۵۰ دالر و میانگین عاید تکراری به ازای هر حساب ۸۹ دالر می‌شه. اگر او ۵۰۰ دالر در عوض از کارهای یک‌بارهٔ تنظیمات بییه، MRR هم‌چنان ۳٬۹۵۰ دالر می‌مانه و میانگین تکراری ۷۹ دالر می‌شه. دسته‌بندی، معیار ره تغییر می‌ده.
هیچ‌کدام از مجموع‌ها درآمد خالص قابل‌برداشت نییه. وختی سودآوری ره ارزیابی می‌کنی، فیس‌های پرداخت، میزبانی، ارسال ایمیل، پشتیبانی، نرم‌افزار، جذب مشتری، اداره و دیگه مصرف‌های قابل‌اجرا ره کم کو. کاری که خودت انجام می‌دی هم حساب کو تا کاروبار فقط به ای خاطر قابل دوام نباشه که کارِ تو رایگان حساب شده.
اگر دَ یک ماه، دو تا از ۵۰ مشتری آغازین لغو کنه، ریزش مشتری ۴٪ است. میان‌بُرِ تقسیم‌کدنِ یک به او نرخ، ۲۵ ماه پیشنهاد می‌کنه، اما فرض می‌کَنه که ریزش ثابت است و جمعیت مشتری‌ها ساده‌سازی شده. ای از یک ماه مشاهده‌ی کم، پیش‌بینی قابل اعتماد نیَست.
کوهورت‌های مشاهده‌شده ره ترجیح بتی: مشتری‌ها ره بر بنیاد دوره شروع‌شان گروپ کو، بعد ماندگاری، عاید تکراری و مصرف‌های ارائه خدمت‌شان ره در طول زمان پیگیری کو. اگر از مدل ارزش طول عمر استفاده می‌کنی، فرضیاتش ره نشان بتی و ارزش عاید ره از سهم پس از مصرف‌های خدمات جدا کو. از یک رقمِ ظاهراً دقیق استفاده نکو تا مصرف پول نقدی ره توجیه کنی که نمی‌تانی پس بگیری.
محدودیت واقعی زیربنا ره مقیاس‌بندی کو
تجربهٔ مشتری و رفتار سیستم ره باهم ببینین. صفحه‌های کُند ممکنه از یک کوئری خاص، یک API شخصِ ثالث، تصویرهای کلان، کارهای پس‌زمینه یا منابع ناکافی باشه. یک سرور کلان‌تر شاید به یک مشکل کمک کنه، اما مشکل دگه ره بی‌تغییر باقی بمانه.
هیچ قاعدهٔ عمومی‌ای وجود نداره که بگه صد سایت یا هفتاد فیصد CPU یعنی وقت ارتقا رسیده. بار کاری با ترافیک، پلاگین‌ها، داده‌ها و هم‌زمانی فرق می‌کنه. زمان‌های پاسخ‌دهی نماینده، درخواست‌های ناکام، حافظه، ذخیره‌سازی و صف‌های پس‌زمینه ره اندازه‌گیری کنین، بعد گلوگاه ره بررسی کنین.
برای مسیر اختیاری وردپرس، تنها پس از بررسی بار کاری، کش‌کردن مناسب صفحه و آبجکت، رساندن دارایی‌های استاتیک، کار روی دیتابیس و ذخیره‌سازی رسانه را در نظر بگیرین. بررسی کنین که کش کردن صفحه‌های مختص حساب کاربری را افشا نکنه یا با پرداخت تداخل نکنه. تغییرات را در برابر وظیفه‌های نمایندهٔ مشتری آزمایش کنین.
اگر مهاجرت ضروری‌اس، همگام‌سازی دیتا، پشتیبان‌گیری، تأیید، یک راه برگشت و اطلاع‌رسانی به مشتری‌ها ره پلان کنین. پیش از زمان‌بندی، انتقال ره تمرین کنین. ثبت‌نام‌های نو، آپلودها و پرداخت‌ها در جریان انتقال می‌تنه داده‌ها ره تغییر بده؛ تصمیم بگیرین که ای تغییرات چطور مدیریت می‌شه.
یک پروسهٔ پایدار ره خودکار کنین
پیش از خودکارسازی، یک روند دستی ره بنویسین. یک خودکارسازی قابل‌اعتماد به یک محرک، اطلاعات لازم، نتیجهٔ مورد انتظار، یک مسئول برای خرابی‌ها و یک راه برای جلوگیری از کارهای تکراری نیاز داره. پیش از خودکارسازی تغییرات در پرداخت یا دسترسی، از اعلان‌های داخلی کم‌خطر شروع کنین.
یک نمونهٔ مفید اولی ای است که وقتی یک مشتری که تازه پرداخت کده، کار اولیه ره تکمیل نکده، به تیم پشتیبانی خبر بده‌ین. پیغام باید فقط معلوماتی ره شامل باشه که تیم پشتیبانی ضرورت داره. تصمیم بگیرین که ای چند بار می‌تانه فرستاده شوه و چطور بعد از تکمیل‌شدن کار، یادآوری‌ها ره بند کنین.
وب‌هوک‌ها و ابزارهای یکپارچه‌سازی می‌تانن Ultimate Multisite یا یک برنامهٔ SaaS دگه ره به سیستم‌های عملیاتی وصل کنن. رویدادهای پشتیبانی‌شده و تصدیق هویت ره برای نصب خود تأیید کنین. تلاش‌های دوباره و تحویل‌های تکراری ره آزمایش کنین؛ دریافت یک رویداد به‌طور دو بار نباید دو حساب مشتری یا دو پاداش ایجاد کنه.
واسه موردای استثنایی یک راه انسانی نگه دارین. یک ایمیل تأیید می‌تانه به مشتری خاطرجم‌سازی کنه که تیکت رسیده، اما نباید به نادرستی وانمود کنه که کسی او را حل کده. وقتی محصول یا پوشش پشتیبانی تغییر می‌کنه، پیام‌های خودکار ره بازبینی کنین.
ارزش هر مشتری ره به‌گونه مسئولانه افزایش بَتین
وقتی مزایای یک سطح بالاتر با کار مشتری برابر می‌باشه، او ره پیشنهاد کنید. خدمات اضافی قسم تنظیم، آموزش یا دیزاین می‌تانه عاید ایجاد کنه، اما ظرفیت ره هم مصرف می‌کنه. او ره به‌حیث تعهدات واقعی تحویل قیمت‌گذاری و زمان‌بندی کنید، نه این‌که به‌عنوان ارتقاهای بی‌هزینه با او رفتار کنید.
بل‌گیری سالانه ممکن اس زمان‌بندی نقدی‌ره تغییر بته، اما پرداخت سالانه همی روز اول تمامش سود کسب‌شده نیَست. ته هنوزم در طول دورهٔ اشتراک، خدمتِ وعده‌داده‌شده‌ره بدهکار استی. پیش ازی که مشتری‌ه ره تشویق کنی تبدیل شوه، تخفیف‌ها، رفتار تمدید و هزینه‌های ارائه‌ره مدل‌سازی کو.
وقتی قیمت‌ها ره تغییر می‌دین، تصمیم بگیرین که قراردادهای موجود چطور رسیدگی می‌شن و پیش از نافذ شدن تغییر، واضح اطلاع‌رسانی کنین. نگه‌داشتن قیمت‌های موجود برای همیشه یک پالیسی ممکن است، نه یک قاعدهٔ همگانی. از وعده‌دادن شرایط دایمی که ارزیابی نکده‌این، خودداری کنین.
هر جای که کار ایجاب کُنه، نفر اضافه کنین
کاری ره که مشتری‌ها ره تأخیر می‌کَنه یا مانع بهتر کدن محصول می‌شه، پیگیری کنین. بسته به گلوگاه، یک متخصص پشتیبانی، نویسنده یا طراح شاید اولین افزودۀ مفید باشه. پیش از استخدام یا قرارداد بستن، نتیجه، مرزهای دسترسی و واگذاری کار ره مشخص کنین.
کارای معمول ره مستندسازی کده و برای آموزش و بازبینی جا باز کنین. واگذاری بیرونیِ یک روندِ گنگ، خودبه‌خود او ره قابل اعتماد نمی‌سازه. مصرف مجموعی و پوشش مورد ضرورت ره بررسی کنین و مطمئن شین که وقتی قراردادی در دسترس نیَیه، یک نفر هنوز هم مسئولیت‌پذیر می‌مانه.
مرحله‌های ثابتِ شمار مشتری ره با تصمیم‌گیری‌های مبتنی بر شواهد تبدیل کنین. یک خدمت پیچیده شاید در ده مشتری هم کمک لازم داشته باشه؛ یک خدمت ساده‌تر شاید با یک تیم کوچک به مشتری‌های بسیار بیشتری خدمت‌رسانی کنه. ظرفیت، نتیجه‌های مشتری، حاشیه سود و نقدینگی، گام بعدی ره تعیین می‌کنه.
تمرین شما: یک محدودیت ره انتخاب کده بهترش کنین
یه شیت ماهانه جور کو که عاید تکرارشونده، عاید یک‌باره، حساب‌های فعال، مشتری‌های از دست‌رفته از گروپ شروع، مصرف جذب مشتری و مصرف‌های ارائهٔ خدمات ره نشان بده. پهلوی هر معیار، یک تعریف کوتاه اضافه کو.
مثال FitSite ره دَفعه محاسبه کنین: یک‌بار با افزونه‌های تکراری و یک‌بار با کارِ تنظیمات یک‌باره. تشریح کنین که چرا پولِ جمع‌آوری‌شده و عاید ماهوارِ تکراری (MRR) فرق کده می‌تانه، حتی وقتی واریزی بانک یکسان باشه.
یک گلوگاه مشاهده‌شده را انتخاب کو. شواهد، یک مداخلهٔ کوچک، بودجهٔ او و نتیجه‌ای ره که انتظار داری مشاهده کنی، تشریح کو. مثال‌ها شامل کاهش کارهای ناموفقِ تأمین یا کمک به مشتری‌های جدید بیشتر برای تکمیل تنظیمات می‌باشد.
یک تاریخ بازبینی و یک شرط توقف تعیین کنید. هم‌زمان یک سرور کلان‌تر نخرید، نیروی پشتیبانی استخدام نکنید و تبلیغات نو راه نیندازید؛ مگر این‌که شواهد مستقل هر مصرف را توجیه کند. یک آزمایش متمرکز، تفسیر نتیجه را آسان‌تر می‌سازد.
پیش ازی که ادامه بدین
از محدودیت‌های مشاهده‌شده و اقتصادِ واضح تعریف‌شده مقیاس بگیرین. MRR عاید ناخالصِ تکرارشونده‌اس، نه سود؛ تخمین‌های جذب مشتری و ارزش طول عمر وابسته به فرضیات‌شان اس. مشتری بیشتر تنها وقتی مفید اس که بتانین وعده ره به‌گونه پایدار عملی کنین.
منابع و مطالعهٔ بیشتر
اقتباس‌شده از درس اصلی ۱۳: گسترش دادن. فیت‌سایت یک کاروبار نمونه‌وار است که برای یادگیری استفاده می‌شه، نه یک داستان موفقیت مشتری. رقم‌های کارشده، حساب‌وکتاب نمونه‌وار از راهنمای اصلی استه که عواید تکرارشونده و یک‌باره از هم جدا شده. انتخاب‌های زیرساختی باید در برابر بار کاری خودتان و اسناد ارائه‌دهنده تأیید شوه.