ایجنت کِی باید دست نگه دارد؟ طراحی مرزهای ارجاع به انسان

ارزشمندترین کاری که ایجنت شما تمام هفته انجام می‌دهد، سپردن یک پرونده به یک انسان است.

در اغلب پروژه‌ها ارجاع به انسان به‌عنوان مسیر شکست طراحی می‌شود: وقتی ایجنت نتوانست، به پشتیبانی وصل کن. این نگاه، ارجاع را به یک عیب تبدیل می‌کند که باید کمینه شود.

ارجاع یک قابلیت است، نه یک نقص. و مثل هر قابلیت دیگری، باید طراحی شود.

ارجاع را چطور تعریف کنیم

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

سه بخش این تعریف هرکدام یک خطای رایج را می‌بندند. «تشخیص می‌دهد» یعنی ارجاع نتیجهٔ یک خطای فنی نیست. «انسان مشخص» یعنی پرونده به یک صف بی‌مالک نمی‌رود. «زمینهٔ کامل» یعنی انسان مجبور نیست از صفر شروع کند.

سه محرک ارجاع

هر مورد ارجاع در یکی از این سه دسته می‌افتد، و هر دسته منطق متفاوتی دارد:

خلط این سه، رایج‌ترین خطای طراحی است. یک بازگشت وجه ۵۰ میلیون تومانی نباید به اطمینان مدل وابسته باشد؛ باید همیشه ارجاع شود، حتی وقتی ایجنت کاملاً مطمئن است. اطمینان و مجوز دو محور مستقل‌اند.

شعاع آسیب را تعریف کنید

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

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

یک راه عملی برای رتبه‌بندی، پرسیدن سه سؤال دربارهٔ هر ابزار است:

• آیا برگشت‌پذیر است؟ اگر نه، شعاع بالاست، صرف‌نظر از مبلغ.
• آیا بیرون از سازمان دیده می‌شود؟ کنش‌های داخلی را می‌شود اصلاح کرد؛ کنش‌های بیرونی را نه.
• چند نفر را همزمان تحت تأثیر قرار می‌دهد؟ یک کنش گروهی، شعاعش را در تعداد ضرب می‌کند.

قرارداد ارجاع: انسان دقیقاً چه چیزی تحویل می‌گیرد

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

یک ارجاع مفید حداقل شامل این‌هاست:

1. آنچه ایجنت فهمید — خلاصهٔ درخواست به زبان خودش.
2. آنچه بررسی کرد — کدام پرونده‌ها را خواند، چه چیزی پیدا کرد.
3. چرا متوقف شد — کدام‌یک از سه محرک، و با چه عددی.
4. پیشنهادش اگر مجبور بود تصمیم بگیرد — همراه با درجهٔ اطمینان.
5. تصمیم برگشتی چطور ثبت شود، تا به ارزیابی برگردد.

بند پنجم همان چیزی است که ارجاع را از یک بن‌بست به یک حلقهٔ یادگیری تبدیل می‌کند.

ارجاع به چه کسی؟ مسئلهٔ مسیریابی

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

مسیریابی باید از همان محرکی بیاید که ارجاع را ساخته است. سه محرک، سه مقصد متفاوت دارند:

• اطمینان پایین به کسی می‌رود که دانش موضوعی دارد — معمولاً کارشناس همان حوزه.
• شعاع آسیب بالا به کسی می‌رود که اختیار تأیید دارد — یک نقش، نه یک فرد، وگرنه مرخصی آن فرد کل جریان را متوقف می‌کند.
• نبود اختیار به مالک همان سیاست می‌رود، که اغلب کسی خارج از تیم عملیات است.

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

در عمل، تعریف همین دو چیز — مقصد و مهلت — تفاوت بین ارجاعی که کار می‌کند و ارجاعی که فقط مسئولیت را جابه‌جا می‌کند، می‌سازد.

نرخ ارجاع را به‌عنوان معیار سلامت بخوانید، نه شمارش شکست

اگر نرخ ارجاع را به‌عنوان معیار شکست تعریف کنید، تیم آن را پایین می‌آورد. راه پایین‌آوردنش هم ساده است: آستانه را شل کنید. نتیجه یک عدد بهتر و یک سیستم بدتر است.

معیار درست، نرخ ارجاع در کنار دقتِ ارجاع است: از موارد ارجاع‌شده، چند درصد واقعاً نیاز به انسان داشتند؟ اگر انسان در هشتاد درصد موارد همان کاری را می‌کند که ایجنت پیشنهاد داده بود، آستانه‌ها بیش از حد محتاط‌اند.

یک نمونهٔ واقعی: ایجنتی که هرگز نه نمی‌گفت

یک تیم عملیات ایجنتی برای پاسخ به سؤالات قراردادی مشتریان راه‌اندازی کرد. سه ماه اول، نرخ ارجاع ۳ درصد بود و همه راضی بودند.

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

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

تغییری که همه چیز را عوض کرد یک قانون ساده بود: اگر پاسخ به بندی متکی است که در پروندهٔ همین مشتری پیدا نشد، ارجاع بده. نرخ ارجاع به ۱۱ درصد رفت. تعداد شکایات به صفر رسید.

دو ضد‌الگو

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

ایجنتی که هیچ‌وقت ارجاع نمی‌دهد. خطرناک‌تر، چون شبیه موفقیت به‌نظر می‌رسد. نرخ ارجاع نزدیک صفر روی یک دامنهٔ واقعاً پیچیده، تقریباً همیشه یعنی مسیر ارجاع وجود ندارد یا آستانه بی‌معنی است.

آستانهٔ اطمینان را چطور تعیین کنم؟

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

آیا ارجاع باید برای کاربر قابل مشاهده باشد؟

بله. «این را به همکارم ارجاع دادم، تا فردا ظهر پاسخ می‌گیرید» اعتماد می‌سازد. سکوت و تأخیر، اعتماد را از بین می‌برد.

اگر تیم انسانی ظرفیت ندارد چه؟

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

جمع‌بندی

یک ایجنت خوب با تعداد کارهایی که انجام می‌دهد سنجیده نمی‌شود. با درستیِ خطی سنجیده می‌شود که میان کارهایی که انجام می‌دهد و کارهایی که نمی‌دهد کشیده است.

آن خط را طراحی می‌کنند. کشف نمی‌شود. این صفحه نشان می‌دهد در عمل کجا کشیده می‌شود.