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

> درخواست باید شناسه، مسئول، وضعیت و سابقه داشته باشد. یک مسیر را تا بازگشایی بررسی کن و خواندن و تغییر همان تیکت را با نشست مشتری دیگر بیازما؛ رابط زیبا، اثبات کنترل دسترسی نیست.

- Published: 2026-10-30T10:34:42.615Z
- Updated: 2026-10-30T10:34:42.615Z
- Author: نیکان نورافکن

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

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

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

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

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

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

نسخهٔ اول فقط دو نقش اصلی دارد: **مشتری و کارشناس تخصیص‌یافته**. پاسخگوی خودکار، پیامک، ایمیل، فایل پیوست و گزارش‌های رضایت را فعلاً کنار می‌گذاریم. اگر تازه مسیر ساخت را شروع کرده‌ای، [آموزش وایب کدینگ با کُندا](https://kondaai.com/blog/vibe-coding-tutorial) به آماده کردن درخواست و بررسی نسخهٔ اول کمک می‌کند.

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

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

| نقش | خواندن تیکت مشتری الف | ثبت پاسخ | حل‌شده کردن | بازگشایی |
| --- | --- | --- | --- | --- |
| مشتری الف، مالک درخواست | بله | بله، تا وقتی حل‌شده نیست | خیر | پس از حل‌شدن، با توضیح |
| کارشناس تخصیص‌یافته | بله | بله | پس از ثبت پاسخ | خیر |
| مشتری ب | خیر | خیر | خیر | خیر |
| کارشناس تخصیص‌نیافته | خیر | خیر | خیر | خیر |
| مهمان | خیر؛ ورود لازم است | خیر | خیر | خیر |

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

کنترل دسترسی را برای هر درخواست سرور انجام بده؛ پنهان کردن لینک یا دکمه در رابط کافی نیست. [راهنمای مجوزدهی OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) بر بررسی مجوزها در هر درخواست تأکید دارد. برای برگهٔ بررسی عمومی‌تر هم [چک‌لیست دسترسی وب‌اپ](https://kondaai.com/blog/web-app-access-control-checklist) را نگه دار.

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

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

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

در کُندا می‌توانی این درخواست را با نام خدمت و قواعد تیم خودت آماده کنی یا ابتدا [قالب‌های آماده](https://kondaai.com/templates) را ببینی. قبل از ساخت، یک معیار پذیرش کنار پرامپت بگذار: «همان تیکت پس از پاسخ و بازگشایی، با همان شناسه و سابقه خوانده شود و نشست مشتری ب هیچ داده‌ای از آن دریافت نکند.» اگر نسخهٔ خروجی فقط رابط است، هنوز این معیار را پاس نکرده است.

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

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

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

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

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

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

<figure><img src="/blog/images/build-ticketing-system-with-ai/queue-supplied-v2.webp" width="1920" height="1234" loading="lazy" alt="صف و داشبورد تیکتینگ در طرح HTML سوم ارسالی داخل قاب روشن نمایشی کُندا"><figcaption>داشبورد اصلیِ طرح سوم ارسالی؛ آمار و نمودارها جزئی از طرح نمایشی‌اند و نتیجهٔ آزمون محلی یا آمار کُندا نیستند.</figcaption></figure>

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

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

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

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

| اتفاق | چه کسی انجام می‌دهد؟ | نتیجه در نمونه |
| --- | --- | --- |
| ثبت درخواست | مشتری واردشده | جدید |
| ثبت پاسخ | کارشناس همان تیکت | در انتظار مشتری |
| ثبت نتیجهٔ بررسی پس از پاسخ | کارشناس همان تیکت | حل‌شده |
| اعلام باقی ماندن مشکل با توضیح | مالک تیکت حل‌شده | بازگشایی‌شده |

<figure><img src="/blog/images/build-ticketing-system-with-ai/workflow-supplied-v2.webp" width="1920" height="1234" loading="lazy" alt="بوم جریان کار و تنظیم گره‌ها در طرح HTML دوم ارسالی داخل قاب روشن نمایشی کُندا"><figcaption>بوم جریان کارِ طرح دوم ارسالی؛ تصویر چیدمان پیشنهادی رابط است، نه موتور خودکارسازی یا استقرار فعال کُندا.</figcaption></figure>

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

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

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

<figure><img src="/blog/images/build-ticketing-system-with-ai/conversation-supplied-v2.webp" width="1920" height="1234" loading="lazy" alt="گفتگو و مراحل تیکت همراه کارت دسترسی در طرح HTML اول ارسالی داخل قاب روشن نمایشی کُندا"><figcaption>نمای اصلیِ طرح اول ارسالی؛ پیام‌ها و کارت آزمون دسترسی داخل آن، بخش‌های نمایشی HTML هستند و مدرک پاسخ واقعی سرور نیستند.</figcaption></figure>

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

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

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

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

پاسخ ۴۰۴ انتخاب همین نمونه است؛ معیار پذیرش این است که داده و امکان تغییر به فرد غیرمجاز نرسد. شناسهٔ طولانی یا غیرقابل حدس هم جای بررسی مالکیت را نمی‌گیرد. [راهنمای جلوگیری از دسترسی مستقیم غیرمجاز OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html) این تفاوت را توضیح می‌دهد.

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

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

آزمون این راهنما روی سرور محلی و دادهٔ ساختگی انجام شد. **۱۹ بررسی گذشت**؛ موارد اصلی را می‌توانی برای خروجی خودت تکرار کنی و در [برگهٔ معیار پذیرش](/blog/images/build-ticketing-system-with-ai/acceptance-checklist.csv) ثبت کنی:

| بررسی | نتیجهٔ مشاهده‌شده در نمونهٔ محلی |
| --- | --- |
| ثبت و خواندن درخواست مالک | ثبت موفق؛ مالک از نشست تعیین شد |
| پاسخ کارشناس تخصیص‌یافته | پاسخ ثبت و برای مشتری قابل خواندن شد |
| تغییر به حل‌شده و بازگشایی توسط مالک | همان شناسه با سه پیام و چهار رویداد باقی ماند |
| خواندن و تغییر توسط مشتری ب | دریافت، پاسخ، تغییر وضعیت و بازگشایی رد شدند |
| فهرست مشتری ب | تیکت مشتری الف در آن نبود |
| کارشناس دیگر و مهمان | به‌ترتیب ۴۰۴ و ۴۰۱؛ بدون دادهٔ تیکت |
| ورودی خالی و بازگشایی تکراری | با پیام مشخص رد شدند |

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

از نظر تجربهٔ کاربر هم فرم خالی، خطای ارسال، وضعیت بارگذاری و نمای گوشی را جدا ببین. در نمونه، موضوع و شرح پس از خطای اعتبارسنجی پاک نمی‌شوند. اگر دکمه‌ای فقط ظاهر دارد یا سرویسی متصل نیست، آن را آماده معرفی نکن. [تفاوت پیش‌نمایش با محصول آماده](https://kondaai.com/blog/ai-app-preview-vs-production) کمک می‌کند این مرز را نگه داری.

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

نسخهٔ اول را با یک موضوع خدماتی، دو مشتری ساختگی و یک کارشناس تعریف کن. پرامپت بالا را در [داشبورد کُندا](https://kondaai.com/dashboard) بازبینی کن یا از [قالب‌های آماده](https://kondaai.com/templates) شروع کن. ساخت را پس از بررسی درخواست و شرایط حسابت آغاز کن؛ فعلاً دادهٔ واقعی مشتری وارد نکن.

اول باید بتوانی یک درخواست را تا بازگشایی دنبال کنی و دسترسی غیرمجاز را با دو نشست بررسی کنی. بعد تصمیم بگیر کدام قابلیت واقعاً لازم است: انتقال مسئول، پیوست خصوصی یا اعلان. اگر هر درخواست تازه به فهرست امکانات تبدیل شد، [راهنمای ساخت MVP با هوش مصنوعی](https://kondaai.com/blog/build-mvp-with-ai) به کوچک نگه داشتن مسیر کمک می‌کند.

## پرسش‌های متداول

### برای ساخت سیستم تیکتینگ با هوش مصنوعی از کجا شروع کنیم؟

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

### آیا تیکتینگ بدون کدنویسی یعنی سامانه خودش به مشتری جواب می‌دهد؟

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

### فرق تیکت با فرم تماس چیست؟

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

### از کجا بفهمیم مشتری دیگر به تیکت دسترسی ندارد؟

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

### بازگشایی تیکت باید یک درخواست تازه بسازد؟

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

### آیا نمونهٔ مقاله یک سامانهٔ آمادهٔ استفادهٔ عمومی است؟

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



## منابع

- [OWASP؛ مجوزدهی و بررسی دسترسی در هر درخواست](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)
- [OWASP؛ جلوگیری از دسترسی مستقیم غیرمجاز به داده‌ها](https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html)