درخواست جمع بندی و طبقه بندی (تریاژ بلیط)

سود:

• توانایی تبدیل درخواست های طولانی و پراکنده مشتری به خلاصه های ساختاریافته و قابل اجرا
• امکان طبقه بندی درخواست ها بر اساس دسته بندی، فوریت ها و احساس مشتری با یک طرح ثابت
• امکان تعریف فرمت خروجی سازگار (JSON/table) مناسب برای اتوماسیون برای پردازش بلیط انبوه

صبح یک تیم پشتیبانی را تصور کنید: 220 بلیت (بلیت) جدید یک شبه جمع آوری شده است. برخی از آنها یک خط "رم رمز عبور خود را فراموش کرده ام"، برخی یک شکایت سه پاراگراف عصبانی هستند، و برخی در واقع یک فرصت فروش هستند. خواندن این انبوه، اختصاص دادن هر یک به دسته درست، تعیین فوریت آن و هدایت آن به شخص مناسب (به این می گویند تریاژ؛ همان منطق طبقه بندی بیماران بر اساس اولویت در اورژانس) دو ساعت اول روز را می خورد.

هوش مصنوعی (AI) می تواند این کار را در چند ثانیه و به طور مداوم انجام دهد. اما جادو در این نیست که بگوییم "این درخواست را خلاصه کن". این یک لیست ثابت از دسته ها، سطوح فوریت واضح و یک قالب خروجی تغییرناپذیر را بر مدل تحمیل می کند. در این واحد، ما یک سیستم تریاژ ایجاد خواهیم کرد که از پردازش یک درخواست منفرد به برچسب زدن صدها درخواست به روشی آماده برای اتوماسیون می‌رود.

توجه: برچسب های دسته و فوریت های تولید شده توسط هوش مصنوعی یک ابزار غربالگری اولیه است. به ویژه، درخواست هایی با برچسب "فوری" و "شکایت" باید قبل از رسیدگی توسط یک انسان تایید شود.

چرا خلاصه ساختاری؟

خلاصه رایگان ("مشتری در حمل و نقل خود مشکل دارد") را نمی توان جستجو، مرتب کرد یا خودکار کرد. با این حال، نیاز مدیر پشتیبانی به سؤالات زیر روشن است:

• این درخواست در کدام دسته قرار می گیرد؟ (ارسال، مرجوعی، پرداخت، فنی، اطلاعات محصول، شکایت، فرصت فروش)
• چقدر فوری است؟ (بحرانی / زیاد / متوسط / پایین)
• وضعیت عاطفی مشتری چگونه است؟ (عصبانی / ناامید / خنثی / راضی)
• جوهر تک جمله ای آن چیست؟
• قدم بعدی چه باید باشد؟

هنگامی که این سوالات را از قبل تعریف کردید و آنها را به عنوان یک طرحواره به مدل دادید (فیلدهای ثابت و مقادیر ممکن)، همه 220 درخواست در قالب یکسان قابل مقایسه و فیلتر می شوند.

گام به گام: ایجاد یک طرح تریاژ

1. لیست دسته ها را پین کنید. اجازه ندهید مدل مناسب باشد. یک لیست بسته ارائه کنید.
2. معیار فوریت را تعریف کنید. معنی "بحرانی" را مشخص کنید: خدمات به طور کامل متوقف شده، از دست دادن پرداخت، خطر امنیتی.
3. برچسب های احساسات را شناسایی کنید. از یک مجموعه محدود و واضح استفاده کنید.
4. فرمت خروجی را وارد کنید برای پردازش دسته‌ای، JSON (فرمت داده‌های ماشین‌خوان متشکل از جفت‌های فیلد-مقدار) مناسب است، برای درخواست تک جدول مناسب است.
5. قانون «اگر مطمئن نیستید را علامت بزنید». اگر مدل از مقوله مطمئن نیست، بگذارید بگوید نامشخص و انسان نگاه می کند.
6. تأیید کنید. در دسته اول، به صورت دستی دقت برچسب ها را بررسی کنید و دستور را تنظیم کنید.

درخواست های قابل کپی

اعلان اصلی که یک درخواست واحد را به یک خلاصه ساختار یافته تبدیل می کند:

نقش: شما یک متخصص تریاژ پشتیبانی با تجربه هستید. درخواست مشتری را در زیر تجزیه و تحلیل کنید. افزودن نظر؛ فقط به آنچه در متن است تکیه کنید. فیلدهای زیر را پر کنید: - خلاصه: (حداکثر 1 جمله) - دسته: [حمل و نقل | بازگشت | پرداخت | فنی | اطلاعات محصول | شکایت | فرصت فروش]- فوریت: [بحرانی | بالا | متوسط ​​| کم]- احساس: [عصبانی | ناامیدی | خنثی | رضایت]- مرحله بعدی: (تک جمله، اقدام مشخص)- مطمئن نیستم: ("بله" اگر دسته/فوریت نامشخص است، در غیر این صورت "نه") درخواست:"""{{ request_text }}"""

برای پردازش دسته ای، درخواست چندین درخواست را به صورت همزمان به یک آرایه JSON تبدیل می کند:

درخواست‌های شماره‌دار زیر را پردازش کنید. یک شی JSON برای هر کدام با طرح زیر ایجاد کنید و همه آنها را به عنوان یک آرایه JSON برگردانید. خارج شدن از طرح: { "id": ""، "خلاصه": ""، "رده": ""، "اضطرار": ""، "emotion": ""، "next_step": ""، "من مطمئن نیستم": "" }فقط دسته‌ها: حمل و نقل، مرجوعی، پرداخت، فنی، اطلاعات محصول، شکایت، تخفیف. درخواست ها: {{ numbered_request_list }}

اعلانی که معیار فوریت را روشن می کند و به مدل تعریف «بحرانی» را می آموزد:

اضطرار را طبق قانون زیر تعیین کنید: - بحرانی: سرویس کاملاً در دسترس نیست، از دست دادن پرداخت، خطر امنیت/داده، تهدید قانونی. - زیاد: عملکرد مهم خراب است اما راه حل وجود دارد. مشتری عصبانی.- متوسط: موضوع منحصر به فرد، عدم توقف گردش کار.- کم: درخواست اطلاعات، پیشنهاد، سؤال کلی. دلیل تصمیم خود را در یک جمله در قسمت «دلیل_ فوریت» بنویسید.

درخواستی که فرصت فروش را جلب می کند و یک پل پشتیبانی/فروش ایجاد می کند:

هنگام پردازش درخواست، اگر مشتری به خرید محصول/بسته/مکمل جدید علاقه نشان داد (به عنوان مثال «آیا بسته بزرگ‌تری دارید»، «چند کاربر طول می‌کشد»)، دسته‌بندی «فرصت فروش» را ایجاد کنید و یک نکته یک جمله‌ای برای تیم فروش در قسمت «یادداشت_فروش» اضافه کنید.

اعلان ضعیف / اعلان قوی

اعلان ضعیف

اعلان قدرتمند

"این درخواست را خلاصه و طبقه بندی کنید"

فهرست دسته بندی بسته + تعریف فوریت + طرحواره JSON ثابت

هر بار برچسب های مختلفی تولید می کند

همیشه به همان درخواست یک برچسب می دهد

او طبق میل خود از کلمه «فوری» استفاده می کند.

معیارهای مشخصی را برای "بحرانی" اعمال می کند

مبهم ها را درست می کند

emin_degilim: بله را بگویید و به آن شخص بسپارید

قواعد قانون طلایی در اینجا است: اگر یک شکایت در دو روز مختلف در یک دسته قرار نگیرد، هیچ گزارش و اتوماسیون قابل اعتماد نخواهد بود.

سه کیف کوچک

مورد 1 - منتقد محرمانه. در یک شرکت SaaS (نرم‌افزار اجاره‌ای اینترنتی)، پیام «نمی‌توانم وارد شوم، کل تیم منتظر 40 نفر هستند» معمولی به نظر می‌رسید، زیرا طول آن کوتاه بود. به لطف قانون فوریت (معیارهای "سرویس کاملاً در دسترس نیست") اعلان تریاژ آن را "بحرانی" علامت گذاری کرد. درخواست به جای انتظار 2 ساعت در صف در 6 دقیقه رسیدگی شد. از نقض SLA (توافق سطح خدمات، یعنی زمان پاسخ وعده داده شده) جلوگیری شده است.

مورد 2 - اولویت بندی خشم. یک روز که برچسب های هوش مصنوعی 180 درخواست بررسی شد، مشاهده شد که 14 درخواست با احساس "عصبانی" در یک صف جداگانه قرار داده شده است. این درخواست ها به نمایندگان باتجربه ارسال شد و امتیاز نظرسنجی منفی (CSAT، یعنی امتیاز رضایت مشتری) در آن هفته نسبت به هفته قبل به طور قابل توجهی بهبود یافت.

مورد 3 - از پشتیبانی به فروش پل بزنید. "بسته فعلی من برای 5 کاربر است، باید آن را به 20 نفر برسانم، آیا این امکان وجود دارد؟" هوش مصنوعی پیام را با عنوان "فرصت فروش" برچسب گذاری کرد و یک یادداشت فروش اضافه کرد. درخواست به طور خودکار به تیم فروش افتاد. یک فرصت فروش که اگر در صف پشتیبانی استاندارد از دست می رفت، مورد توجه قرار نمی گرفت، به یک سود تبدیل شده است.

نکته: فهرست دسته بندی خود را تا حد امکان کوتاه و گسسته نگه دارید. 20 دسته مدل (و تیم شما) را گیج می کند. 6-8 دسته بندی واضح به طور مداوم برچسب گذاری شده و در گزارش ها معنادار هستند. دو مقوله اغلب اشتباه گرفته را با هم ترکیب کنید.

اتصال به اتوماسیون

قدرت واقعی خروجی JSON ساختاریافته این است که به‌طور خودکار به مرحله بعدی می‌رود: درخواست با برچسب «بحرانی» بلافاصله به مدیر اطلاع می‌دهد، «فرصت فروش» در CRM (نرم‌افزار مدیریت ارتباط با مشتری) قرار می‌گیرد، «بازگشت» به جریان سلف سرویس می‌رود. اما اولین قانون اتوماسیون: اقدامات پر تاثیر (بازپرداخت، بسته شدن حساب) هرگز بر اساس برچسب هوش مصنوعی انجام نمی شود. گاهی اوقات تایید انسانی وجود دارد.

احتیاط: تحلیل احساسات یک پیش بینی است، نه یک اندازه گیری دقیق. مشتری که مدل او را "خنثی" می نامد ممکن است بی سر و صدا بسیار عصبانی باشد. از برچسب احساس برای اولویت بندی استفاده کنید. اما برای نتیجه گیری قطعی مانند «این مشتری قبلاً راضی است» به تنهایی به آن تکیه نکنید.

اشتباهات رایج

• واگذاری لیست دسته به مدل؛ هر بار برچسب های متفاوت و ناسازگار دریافت می کنید.
• عدم تعریف کلمه نسبی مانند "فوری" درخواست همه فوری است.
• عدم رفع فرمت خروجی؛ گاهی اوقات پاراگراف، گاهی اوقات لیست به جای JSON ظاهر می شود.
• عدم ارائه درب خروجی برای عدم اطمینان (من مطمئن نیستم).
• پیوند دادن تراکنش های پر تاثیر (بازپرداخت، بسته شدن حساب) به برچسب هوش مصنوعی بدون تایید انسان.
• خودکارسازی کل جریان بدون تأیید دستی دسته اول.

به طور خلاصه

• تریاژ به سرعت انبوه درخواست‌های دریافتی را بر اساس دسته‌بندی، فوریت و احساسات مرتب می‌کند.
• کلید سازگاری: فهرست دسته بندی بسته، تعریف فوریت مشخص، و فرمت خروجی ثابت (JSON).
• برچسب‌های فوریت و احساسات اولویت‌بندی را تسریع می‌کنند. خواسته های انتقادی و عصبانی را مطرح می کند.
• خروجی ساختاریافته را می توان مستقیماً به اتوماسیون (اعلان، مسیریابی، CRM) مرتبط کرد.
• اقدامات پر تاثیر و برچسب های مبهم همیشه باید مورد تایید انسانی قرار گیرند.

وظیفه کاربردی

5 درخواست مشتری متفاوتی که دارید (یا نمونه‌ها) را با دستور آرایه JSON در بالا دسته‌ای پردازش می‌کند. سپس به صورت دستی خروجی را بررسی کنید: (1) آیا هر دسته درست است؟ (2) آیا مواردی که "بحرانی" علامت گذاری شده اند در واقع سرویس را متوقف می کنند؟ (3) آیا مطمئناً در جاهای مناسب «بله» گفتم؟ هر برچسبی را که مناسب نیست تصحیح کنید و اعلان (مخصوصاً تعاریف دسته و قانون فوریت) را بر اساس آن به روز کنید. این تمرین عادت کالیبره کردن طرحواره را با واقعیت خود ایجاد می کند.

چک لیست

• [ ] من یک لیست بسته و مجزا از دسته ها تعریف کرده ام.
• [ ] سطوح اضطرار را با اقدامات مشخص شرح دادم.
• [ ] من فرمت خروجی (JSON/table) را اصلاح کردم.
• [ ] برای عدم قطعیت یک درب خروجی اضافه کردم (من_مطمئن نیستم).
• [ ] من به صورت دستی اولین دسته را تأیید کردم و درخواست را کالیبره کردم.
• [ ] من لایه ای از تایید انسانی را روی اقدامات پر تاثیر گذاشتم.