وقتی اپ ساخته‌شده با هوش مصنوعی‌تان به تیم پشتیبانی خودش نیاز دارد (و به جایش چه کنید)

همان‌طور که اپ ساخته‌شده با هوش مصنوعی‌تان رشد می‌کند، پرسش‌های پشتیبانی روی هم تلنبار می‌شوند. این‌جا می‌گوییم چطور پیش از آنکه مجبور به استخدام کسی شوید آن‌ها را مدیریت کنید.

اپتان را در یک آخر هفته با Proyecta ساختید. کار می‌کند. کاربرها واقعاً دارند برایش پول می‌دهند. و حالا زیر انبوه ایمیل‌های پشتیبانی دفن شده‌اید.

این همان نقطه‌ای است که خیلی از سازندگان مستقل فکر می‌کنند: «باید کسی را برای پشتیبانی مشتری استخدام کنم.» شاید سرانجام درست باشد. اما معمولاً سه چهار حرکت هست که می‌توانید اول انجام دهید که خیلی ارزان‌تر و اغلب بهتر است.

سه مرحلهٔ «نمی‌توانم به همهٔ این ایمیل‌ها جواب بدهم»

مرحلهٔ ۱: هنوز به هر ایمیل جواب می‌دهید، اما روزی شش ساعت طول می‌کشد. خسته‌اید.

مرحلهٔ ۲: فقط به فوری‌ترین‌ها جواب می‌دهید. بعضی‌ها سه روز منتظر پاسخ می‌مانند. حس بدی دارید، اما در عین حال دارید قابلیت منتشر می‌کنید.

مرحلهٔ ۳: یک صندوق ورودی با ۵۰ ایمیل عقب‌مانده دارید و دیگر بازش نمی‌کنید. عذاب وجدان شروع می‌شود.

بیشتر سازندگان مستقیم از مرحلهٔ ۲ به «بیایید یک نفر را برای پشتیبانی استخدام کنیم» می‌پرند، بدون اینکه راه‌های میانی را بررسی کنند.

حرکت‌های ارزان (که واقعاً جواب می‌دهند)

۱. سه پرسشی را که بیش از همه به آن‌ها جواب می‌دهید پیدا کنید

یک هفته را صرف خواندن هر ایمیل کنید. پرسش‌هایی را که بیش از یک بار ظاهر می‌شوند یادداشت کنید. شرط می‌بندم چیزی شبیه این پیدا می‌کنید:

  • «چطور این را به Stripe وصل کنم؟»
  • «می‌توانم از این برای تیمم استفاده کنم؟»
  • «اگر شما تعطیل کنید چه می‌شود؟»

سه پرسش برترتان را بردارید و در یک جای ثابت به آن‌ها جواب دهید — نه در ایمیل. یک صفحهٔ پرسش‌های متداول در وب‌سایتتان. یک ویدئو. یک سند راهنما در اپتان. هدف این است که پرسش را پیش از رسیدن به صندوق ورودی‌تان دستگیر کنید.

به نرم‌افزار مستندسازی پرزرق‌وبرق نیاز ندارید. یک Google Doc با سرتیترهای روشن کار می‌کند. یا یک صفحهٔ ساده در وب‌سایتتان. معیار این است: کسی وقتی جست‌وجو می‌کند آن را پیدا کند، پاسخش را بگیرد، و به شما ایمیل نزند.

بیشتر سازندگان مستقل از این کار می‌گذرند چون مسئله‌ای حل‌شده به نظر می‌رسد. همه یک صفحهٔ پرسش‌های متداول دارند. اما بیشتر این صفحه‌ها پس از آنکه بنیان‌گذار فراموش کرده چه چیزی گیجش کرده بود نوشته می‌شوند. شما این را وقتی می‌نویسید که هنوز از همان سه پرسش به‌طور فعال کلافه‌اید. همین حالا بنویسیدش.

۲. از یک پاسخ‌گوی خودکارِ ساده استفاده کنید

وقتی کسی ایمیل می‌زند، در واقع منتظر شش روز نیست. منتظر است بداند کِی جواب می‌دهید.

یک پاسخ‌گوی خودکار راه بیندازید (Gmail این را از پیش دارد، یا از Mailchimp، Zapier، هر چیزی استفاده کنید) که چیزی راست بگوید:

«من هر ایمیل را می‌خوانم. معمولاً می‌توانم ظرف ۴۸ ساعت جواب بدهم. اگر فوری است، در موضوع پیام کلمهٔ URGENT را بنویسید تا در اولویت قرارش بدهم.»

این دو کار می‌کند:

  • به آن‌ها اطمینان می‌دهد که نادیده‌شان نگرفته‌اید.
  • برایتان وقت می‌خرد تا فکر کنید به‌جای اینکه از سر دستپاچگی جواب بدهید.

سیگنال URGENT می‌گذارد سریع اولویت‌بندی کنید. بعضی‌ها از آن سوءاستفاده می‌کنند، اما بیشترشان نمی‌کنند — فقط مضطرب‌اند، و دانستنِ اینکه کِی جواب می‌گیرند این را درست می‌کند.

۳. یک صفحهٔ وضعیتِ عمومی بسازید (حتی اگر فقط یک توییت باشد)

اگر چیزی خراب شود، کاربرها پیش از آنکه وضعیتتان را چک کنند دربارهٔ آن به شما ایمیل می‌زنند.

یک صفحهٔ ساده بسازید (Statuspage.io ماهی ۲۹ دلار است، اما حتی یک GitHub gist یا وضعیت Slack هم کار می‌کند) که بگوید:

  • «همهٔ سیستم‌ها در حال کارند»
  • یا، اگر چیزی از کار افتاده: «داشبورد همین حالا کند است (در حال بررسی)»

در فوتر یا امضای ایمیلتان به آن لینک بدهید. وقتی ایمیلِ «آیا اپ شما خراب است؟» را گرفتید، به‌جای نوشتن یک پاسخ، با یک لینک جواب بدهید: «صفحهٔ وضعیت ما را ببینید.»

این کوچک به نظر می‌رسد. اما اگر اپتان ۱۰۰ کاربر داشته باشد و چیزی خراب شود، صفحهٔ وضعیت جلوی نوشتن بیش از ۱۵ ایمیل دربارهٔ همان مشکل را می‌گیرد.

۴. فرهنگِ «اول تغییرات را اعلام کن» را بسازید

هر بار که باگی را درست می‌کنید یا قابلیتی منتشر می‌کنید، پیش از آنکه کاربرها متوجه شوند به آن‌ها بگویید. این جلوی یک دستهٔ کامل از ایمیل‌های پشتیبانی را می‌گیرد.

از Loom برای ضبط یک ویدئوی ۶۰ ثانیه‌ای استفاده کنید، آن را در یک Slack یا Discordِ «چه خبر تازه» منتشر کنید (اگر دارید)، یا به‌عنوان ایمیل به کاربرهای فعال بفرستید. هدف پرزرق‌وبرق بودن نیست — هدف سریع و صادق بودن است.

«باگی که گاهی واردات را معلق می‌کرد درست شد. شرمنده‌ام. ضمناً این هفته حالت تیره هم اضافه شد.»

این دو کار می‌کند:

  • به کاربرها زمینهٔ آنچه تغییر کرده می‌دهد، تا گیج نشوند.
  • این حس را به آن‌ها می‌دهد که شما فعالانه روی محصول کار می‌کنید.

وقتی واقعاً به کمک نیاز دارید

اگر بعد از این چهار حرکت هنوز در حال غرق شدنید، آن وقت بله، احتمالاً به یک آدم نیاز دارید.

در آن نقطه، کسی را پاره‌وقت استخدام کنید تا:

  • به پرسش‌های روزمره جواب دهد (با استفاده از صفحهٔ پرسش‌های متداول و قالب‌هایتان).
  • پرسش‌های دشوار را خلاصه کند و برای تصمیم‌گیری به شما بفرستد.
  • الگوها را در آنچه گیج‌کننده است تشخیص دهد و به شما بگوید چه چیزی به مستندات بهتر نیاز دارد.

بخش دوم بسیار مهم است: یک نیروی پشتیبانی فقط رباتِ پاسخ به ایمیل نیست. او سیستم هشدار زودهنگام شماست برای اینکه چه چیزی در محصول، قیمت‌گذاری یا مستنداتتان خراب است.

اما بیشتر اپ‌های مستقل مدتی به آن نقطه نمی‌رسند. در این میان، آن چهار حرکت می‌تواند شما را از «دارم غرق می‌شوم» به «دارم مدیریتش می‌کنم» برساند.

نکتهٔ اصلی: پشتیبانی یک قابلیتِ محصول است، نه یک کار اداری. روی شفاف‌تر کردنِ محصول سرمایه‌گذاری کنید، نه روی استخدام آدم‌ها برای توضیح آن. یک صفحهٔ پرسش‌های متداول خوب به ۵۰٪ ایمیل‌ها پاسخ می‌دهد. یک آنبوردینگ خوب از ۳۰٪ دیگر جلوگیری می‌کند. آن ۲۰٪ که واقعاً به تفکر انسانی نیاز دارد برایتان می‌ماند.

این یک مسئلهٔ حل‌شدنی است. هنوز به استخدام نیازی نیست.