پشتیبانی خودکار در مقیاس - وقتی ربات هرگز نباید به پول دست بزند
در پشتیبانی فینتک، همه پرسش‌ها شبیه هم به نظر می‌رسند ولی به دو دسته کاملاً متفاوت تقسیم می‌شوند: پرسش اطلاعاتی و درخواست عملیات. اولی را میشود خودکار کرد؛ دومی نباید حتی نزدیک ربات شود - و این مرز باید در معماری باشد، نه در دستوری که به مدل داده میشود.
محصول آماده کارن تکنولوژی
این را روی داده واقعی کسب‌وکار خودتان ببینید
آنچه در این مقاله می‌خوانید، در محصولات کارن پیاده‌سازی شده است. در جلسه دمو، همان را روی داده و فرآیند خودتان اجرا می‌کنیم.
درخواست دمو رایگان یا تماس بگیرید: ۰۲۱-۸۸۶۱۴۲۸۲در این صفحه
دو دسته پرسش که شبیه هم به نظر می‌رسند
«کارمزد انتقال چقدر است؟» و «کارمزد این انتقال را برگردانید» از نظر زبانی نزدیک‌اند و از نظر ریسک، زمین تا آسمان فرق دارند.
پرسش اطلاعاتی - قابل خودکارسازی
- کارمزدها، سقف‌ها و محدودیت‌ها
- مراحل احراز هویت و مدارک لازم
- ساعات تسویه و زمان‌بندی واریز
- علت رایج خطاهای درگاه
درخواست عملیات - هرگز خودکار نه
- برگشت وجه یا اصلاح تراکنش
- تغییر اطلاعات حساب یا شماره شبا
- رفع مسدودی
- هر چیزی که پول یا دسترسی را جابه‌جا کند
چرا مرز باید در معماری باشد
راه رایج و اشتباه، نوشتن این محدودیت در دستور مدل است: «هرگز تراکنش انجام نده». مشکلش این است که دستور مدل یک ترجیح است نه یک مانع - و در مقابل ورودی‌های غیرمنتظره یا تلاش عمدی، تضمینی ندارد.
راه درست این است که ربات اصلاً دسترسی فنی به عملیات تراکنشی نداشته باشد. اتصالش فقط خواندنی باشد و هیچ API نوشتنی در اختیارش نباشد.
در این حالت، حتی اگر مدل به هر دلیلی تصمیم بگیرد کاری انجام دهد، راهی برای انجامش وجود ندارد. این تفاوت میان «به او گفتیم نکند» و «نمیتواند» است - و در حوزه مالی فقط دومی قابل دفاع است.
اوج بار: اینجا قابل پیش‌بینی است
در مخابرات، اوج بار وقتی می‌آید که سرویس قطع شود - یعنی غیرقابل پیش‌بینی. در فینتک برعکس است: اوجها الگوی تقویمی دارند.
- روزهای پرداخت حقوق
- مهلت‌های پرداخت قبض و مالیات
- مناسبت‌های خرید و فروش‌های فصلی
- ساعات پایانی تسویه روزانه
این یعنی ظرفیت را میشود از قبل برنامهریزی کرد، و مهمتر: میشود پیش از اوج اطلاعرسانی کرد. پیام فعال درباره تأخیر احتمالی تسویه در روز شلوغ، بخشی از تماسها را قبل از وقوع حذف میکند.
ترکیب تماس‌های پشتیبانی شما چیست؟
در جلسه ارزیابی، پرسشهای پرتکرار و اوج بار شما بررسی میشود و می‌گوییم چه سهمی واقعاً قابل خودکارسازی است.
پیگیری تراکنش: حالت خاص
پرتکرارترین پرسش فینتک معمولاً این است: «پول کم شد ولی نرسید». این پرسش اطلاعاتی است - پاسخش در داده هست - ولی حساس‌ترین پرسش هم هست.
دو نکته در طراحی پاسخ:
- احراز هویت پیش از هر اطلاعاتی - وضعیت تراکنش، اطلاعات مالی است و نباید با شماره پیگیری تنها افشا شود
- پاسخ باید مرحله بعدی را بگوید - «در حال بررسی است» کافی نیست؛ «تا فلان زمان به‌صورت خودکار برمی‌گردد و اگر نشد این کار را بکنید» کافی است
و اگر تراکنش واقعاً مشکل دارد، انتقال فوری به کارشناس - چون در این حوزه، تعلل خودش تبدیل به شکایت میشود.
گردش‌کار
۱. تشخیص دسته پرسش
اطلاعاتی یا عملیاتی. عملیاتی بدون تلاش برای پاسخ، به مسیر انسانی یا کانال امن می‌رود.
۲. احراز هویت در صورت نیاز
برای هر پرسشی که پاسخش اطلاعات حساب یا تراکنش را افشا میکند.
۳. استعلام خواندنی
اتصال فقط خواندنی به سامانه، بدون هیچ API نوشتنی.
۴. پاسخ با مرحله بعدی مشخص
نه فقط وضعیت، بلکه اینکه کاربر حالا چه کار کند.
۵. انتقال با تاریخچه کامل
موارد استثنا با تمام گفتوگو و اطلاعات تراکنش به کارشناس منتقل می‌شوند.
انطباق و ثبت
در حوزه پرداخت، گفتوگوی پشتیبانی میتواند در رسیدگی به شکایت مستند شود. سه الزام:
- ثبت کامل گفتوگو با زمان و شناسه کاربر
- ماسک خودکار اطلاعات حساس در لاگ و گزارش
- قابلیت بازیابی گفتوگوی یک تراکنش خاص، ماهها بعد
و استقرار روی زیرساخت خودتان، چون محتوای این گفتوگوها اطلاعات مالی مشتری است.
سنجش و نقطه شروع
معیار اصلی: نرخ حل در همان گفتوگو برای پرسشهای اطلاعاتی. معیار دوم و مهمتر از نظر ریسک: تعداد مواردی که ربات نباید پاسخ میداد ولی داد - این عدد باید صفر باشد و مرتب پایش شود.
پیشنهاد ما شروع با پرتکرارترین دسته اطلاعاتی است - معمولاً پیگیری تراکنش یا کارمزدها. و پیش از شروع، ترکیب تماسها را به تفکیک نوع پرسش بدانید تا معلوم شود چه سهمی واقعاً قابل خودکارسازی است.
جزئیات پلتفرم در صفحه مانوتل است.
احراز هویت در راهنمای KYC و بقیه کاربردها در صفحه راهکارهای فینتک است.
پرسشهای متداول
خیر، و نه فقط به این دلیل که به او گفتهایم نکند. در طراحی ما ربات هیچ دسترسی نوشتنی به سامانه ندارد، پس حتی اگر تصمیم بگیرد، راهی برای انجامش نیست. تفاوت «به او گفتیم نکند» و «نمیتواند» در حوزه مالی تعیینکننده است.
چون دستور مدل یک ترجیح است نه یک مانع، و در برابر ورودی غیرمنتظره یا تلاش عمدی تضمینی ندارد. محدودیتی که با پول سروکار دارد باید در معماری اعمال شود، یعنی با نبودِ دسترسی.
اول احراز هویت، چون وضعیت تراکنش اطلاعات مالی است و با شماره پیگیری تنها نباید افشا شود. بعد پاسخ با مرحله بعدی مشخص: نه «در حال بررسی است»، بلکه اینکه تا چه زمانی خودکار برمی‌گردد و اگر نشد کاربر چه کند. و اگر واقعاً مشکل دارد، انتقال فوری.
در فینتک برخلاف مخابرات، اوجها الگوی تقویمی دارند - روز حقوق، مهلت قبض، پایان تسویه. پس هم ظرفیت را میشود از قبل برنامهریزی کرد و هم مهمتر، پیش از اوج اطلاعرسانی کرد؛ پیام فعال درباره تأخیر احتمالی، بخشی از تماسها را پیش از وقوع حذف میکند.
بله و برای همین طراحی شدهاند: ثبت کامل با زمان و شناسه، ماسک خودکار اطلاعات حساس در لاگ، و امکان بازیابی گفتوگوی یک تراکنش خاص ماهها بعد.
روی زیرساخت خودتان. محتوای این گفتوگوها اطلاعات مالی مشتری است و به سرویس بیرونی نمیرود.
نرخ حل در همان گفتوگو برای پرسشهای اطلاعاتی، و مهمتر از نظر ریسک: تعداد مواردی که ربات نباید پاسخ میداد ولی داد. عدد دوم باید صفر باشد و مرتب پایش شود، نه یک بار در پذیرش اولیه.
