ریشهٔ تیکتها رو بزن، نه خود تیکتها
هوش مصنوعیخلاصهٔ کاملتر
تو این مقاله اومده که راه کمکردن فشار پشتیبانی، سریعتر جوابدادن به تیکتها نیست؛ پیدا کردن دلیلیه که باعث میشه اون تیکتها اصلاً ساخته بشن. نویسنده اسم این رویکرد رو root-cause support automation میذاره: از AI استفاده میکنی تا بفهمی چرا یه نوع تیکت مدام تکرار میشه و همون ریشه رو درست کنی. تو نمونهای که تعریف میکنه، یه شرکت کوچیک با همین روش حجم تیکت هفتگیش رو از ۵۲ تا به ۱۹ تا رسوند؛ ۶۳٪ کمتر، اونم فقط توی یه هفته.
به گفتهٔ نویسنده، کار با ابزار شروع نشد. اول تیم کل مسیر پشتیبانی رو همونطور که واقعاً اتفاق میافتاد نوشت و زمان هر مرحله رو دستی گرفت. نتیجه غافلگیرکننده بود: نوشتن جواب گرون نبود، جمعکردن اطلاعات قبل از نوشتن گرون بود. برای یه تیکت ساده باید ایمیل، Slack، Stripe، Substack و گفتوگوهای قدیمی چک میشد. وقتی ایجنتها این جستوجوها رو توی یه رکورد جمع کردن، اون مرحله از ۵ تا ۱۰ دقیقه رسید به زیر یه دقیقه و به تخمین تیم حدود ۹۰٪ از بار ذهنی این فرایند از بین رفت.
بزرگترین دستهٔ تیکتها مشکل دسترسی به کامیونیتی Slack بود که خودش چند زیرمشکل داشت: دعوتنامههایی که نمیرسید، لینکهای ورود که قبل از استفاده منقضی میشدن، و حسابهایی که ایمیل پرداختشون با ایمیل عضویت یکی نبود. راهحل نهایی یه چتبات باهوشتر نبود، یه تغییر ساختاری بود: دامنههای ایمیل مجاز که خودشون میتونستن وارد فضای کاری بشن، بهعلاوهٔ یه لینک دعوت بدون انقضا. اون دستهٔ تیکت کوچیک نشد، کلاً از صف غیب شد.
نویسنده یه مرزبندی مفید هم میده: هر چیزی که به پول یا دسترسی حساب ربط داره تأیید نهاییش باید دست آدم بمونه و AI فقط زمینه و کارهای تکراری رو آماده کنه. برای پیدا کردن بقیهٔ ریشهها هم کل تاریخچهٔ تیکتها با کمک AI الگوبندی شد و ۲۶ الگوی تکراری بیرون اومد؛ دوتا مشکل پنهان هم همینجا لو رفت: یه لینک دعوت که از شدت ترافیک هر دو سه روز یه بار منقضی میشد، و یه غلط تایپی توی کد دسترسی یکی از پلنها که آنبوردینگ بخشی از کاربرها رو خراب کرده بود.
آخر مقاله یه نمونهٔ یه پله جلوتر از Gumroad اومده: یه مشتری از یه باگ ظاهری توی نمودار فروش اپ موبایل گفت، ایجنت پشتیبانی باگ رو بازتولید کرد، ردش رو تو کد گرفت، تست نوشت و pull request باز کرد و بعد از انتشار فیکس، به مشتری خبر داد. مشتری جواب داد که هنوز درست نشده، ایجنت نسخهٔ اصلاحشده رو ساخت و این بار تأیید خود مشتری قبل از merge یه مرحلهٔ رسمی شد؛ یعنی کار وقتی تموم میشه که کاربر بگه مشکلش حل شده.
نکات کلیدی:
- تیکت رو نشونه ببین نه بیماری؛ سؤال درست اینه که چرا کاربر اصلاً مجبور شده سؤال کنه.
- قبل از خودکارسازی، کل فرایند رو دستی بنویس و زمان بگیر تا گلوگاه واقعی معلوم شه.
- گلوگاه معمولاً نوشتن جواب نیست، جمعکردن اطلاعات از چند سیستم پراکندهست.
- تصمیمهای مربوط به پول و دسترسی حساب رو دست آدم نگه دار.
- معیار موفقیت، حجم همون دستهٔ تیکت در طول زمانه، نه سرعت اولین پاسخ.
