ساخت سیستم تیکتینگ با هوش مصنوعی؛ هر درخواست، یک مسیر پیگیری

مشتری می‌گوید «همان مشکل قبلی هنوز هست»، اما توضیح اولش در یک پیام است، پاسخ همکارت در گفتگویی دیگر و هیچ‌کس مطمئن نیست آخرین بار چه چیزی بررسی شد. مسئله فقط کمبود یک فرم تماس نیست؛ درخواست باید یک شناسه، مسئول، وضعیت و سابقهٔ قابل دنبال کردن داشته باشد.

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

تصاویر این مقاله مستقیماً از سه طرح HTML ارسالی، در قاب روشن نمایشی کُندا تهیه شده‌اند. چیدمان، رنگ‌ها و اجزای رابط همان طرح‌ها هستند. آمار، خودکارسازی و ادعاهای امنیتی نوشته‌شده داخل طرح‌ها تأیید نشده‌اند و بیانگر قابلیت‌های آمادهٔ کُندا نیستند. آزمون‌های عملکردِ این راهنما جداگانه، روی سرور مستقل محلی و با سناریوی سادهٔ «لینک راهنما» در ۸ آبان ۱۴۰۵ انجام شده‌اند؛ موضوع نمایشی داخل تصاویر با این سناریوی آزمون فرق دارد.

چه زمانی فرم تماس کافی نیست؟

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

مخاطب این نمونه یک تیم خدماتی کوچک است؛ نه مرکز تماس بزرگ و نه تیمی که از روز اول به ده‌ها اتصال نیاز دارد. یک مشتری فرضی می‌خواهد فایل راهنمای نمونه را دریافت کند، اما لینک برایش باز نمی‌شود. همین مسئله برای بررسی ثبت، پاسخ، حل‌شدن و بازگشایی کافی است؛ لازم نیست اطلاعات بانکی، رمز یا فایل خصوصی مشتری را وارد تمرین کنیم.

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

قبل از ساخت سامانه پشتیبانی، نقش‌ها را روشن کن

ورود به حساب به‌تنهایی مجوز دیدن همهٔ تیکت‌ها نیست. مشتری الف باید درخواست خودش را ببیند؛ مشتری ب نباید با عوض کردن شناسه، به همان گفتگو برسد. کارشناس هم در این نمونه فقط تیکتی را می‌بیند که به خودش تخصیص یافته است.

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

کنترل دسترسی را برای هر درخواست سرور انجام بده؛ پنهان کردن لینک یا دکمه در رابط کافی نیست. راهنمای مجوزدهی OWASP بر بررسی مجوزها در هر درخواست تأکید دارد. برای برگهٔ بررسی عمومی‌تر هم چک‌لیست دسترسی وب‌اپ را نگه دار.

پرامپت ساخت تیکتینگ بدون کدنویسی را چطور بنویسیم؟

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

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

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

قدم اول: مشتری چه چیزی ثبت کند؟

برای شروع، موضوع کوتاه و شرح قابل پیگیری کافی است. شرح را با سه راهنما بخواه: چه انتظاری داشتی، چه اتفاقی افتاد و چطور می‌توان مشکل را تکرار کرد؟ نمونهٔ ما می‌گوید: «روی دریافت راهنما می‌زنم، اما فایل باز نمی‌شود؛ انتظار داشتم راهنمای آزمایشی باز شود.»

پس از ارسال، شناسه و وضعیت «جدید» را نشان بده. موفقیت باید بعد از تأیید سرور نمایش داده شود. اگر ارسال شکست خورد، شرح نوشته‌شده را نگه دار و پیام قابل فهم بده؛ کاربر نباید همه‌چیز را از اول بنویسد یا با زدن دوبارهٔ دکمه، بی‌خبر چند درخواست بسازد. برای تکرار امن ارسال در نسخهٔ عمومی، جلوگیری از ثبت تکراری را هم بررسی کن؛ این قابلیت در نمونهٔ محلی ما پیاده نشده است.

در آزمون محلی، درخواست از نشست مشتری الف ثبت شد و در خواندن تازه از سرور، با همان مالک دیده شد. حتی وقتی در درخواست آزمایشی، مالک دیگری فرستادیم، سرور مالک را از نشست مشتری الف تعیین کرد. موضوع و شرح خالی هم با پیام اصلاح ورودی رد شدند.

قدم دوم: کارشناس بداند الان نوبت کیست

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

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

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

قدم سوم: حل‌شده با پایان همیشگی فرق دارد

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

«حل‌شده» در این مثال یعنی کارشناس نتیجهٔ بررسی را ثبت کرده است؛ به معنی تأیید قطعی مشتری نیست. اگر مشتری گفت مشکل باقی است، نباید مجبور شود یک تیکت تازه و بدون سابقه بسازد. با توضیح کوتاه، همان درخواست باز شود و مسئول آن را دوباره در صف پیگیری ببیند.

قدم چهارم: بازگشایی، سابقه را پاک نکند

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

بازگشایی باید وضعیت و شرح معتبر بخواهد. در آزمون، تلاش دوباره برای بازگشایی تیکتی که از قبل باز بود رد شد؛ رویداد تکراری ساخته نشد. این کنترلِ تغییر وضعیت با جلوگیری از ثبت دو تیکت تازه هنگام ارسال دوباره فرق دارد؛ آن بخش هنوز در محدودهٔ نمونه نیست.

چطور نشان بدهیم مشتری دیگر تیکت را نمی‌خواند؟

یک بار به‌عنوان مشتری الف وارد شو و تیکت خودش را باز کن. بعد با نشست جداگانهٔ مشتری ب همان شناسه را مستقیماً درخواست کن؛ فقط نبودن کارت در فهرست را بررسی نکن. دریافت گفتگو، ثبت پاسخ، تغییر وضعیت و بازگشایی را جدا امتحان کن.

در سرور محلی این مقاله، درخواست‌های مشتری ب برای همان تیکت با پاسخ عمومی ۴۰۴ رد شدند. پاسخ، موضوع، متن گفتگو یا مشخصات مالک را برنگرداند. درخواست مشتری الف و کارشناس مجاز با پاسخ موفق خوانده شد؛ یعنی نتیجهٔ منفی، صرفاً به خاطر خراب بودن همهٔ مسیرها نبود. کارشناس تخصیص‌نیافته هم به تیکت دسترسی نداشت.

پاسخ ۴۰۴ انتخاب همین نمونه است؛ معیار پذیرش این است که داده و امکان تغییر به فرد غیرمجاز نرسد. شناسهٔ طولانی یا غیرقابل حدس هم جای بررسی مالکیت را نمی‌گیرد. راهنمای جلوگیری از دسترسی مستقیم غیرمجاز OWASP این تفاوت را توضیح می‌دهد.

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

چه چیزهایی واقعاً بررسی شد و چه چیزهایی باقی است؟

آزمون این راهنما روی سرور محلی و دادهٔ ساختگی انجام شد. ۱۹ بررسی گذشت؛ موارد اصلی را می‌توانی برای خروجی خودت تکرار کنی و در برگهٔ معیار پذیرش ثبت کنی:

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

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

قدم بعدی برای ساخت سیستم تیکتینگ در کُندا

نسخهٔ اول را با یک موضوع خدماتی، دو مشتری ساختگی و یک کارشناس تعریف کن. پرامپت بالا را در داشبورد کُندا بازبینی کن یا از قالب‌های آماده شروع کن. ساخت را پس از بررسی درخواست و شرایط حسابت آغاز کن؛ فعلاً دادهٔ واقعی مشتری وارد نکن.

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