شناخت درخواست‌ها
کانال‌های فعلی، تیم‌ها و مشکلات رسیدگی.
سامانه تیکتینگ چیست؟
سامانه تیکتینگ یا Ticketing System، ابزار ثبت و مدیریت درخواست‌هاست. هر درخواست به یک رکورد قابل پیگیری تبدیل می‌شود و اطلاعات، پاسخ‌ها و وضعیت آن در یک محل نگهداری می‌شوند. این ساختار به تیم کمک می‌کند بداند چه کاری باقی مانده، چه کسی مسئول است و چه نتیجه‌ای به کاربر اعلام شده است.
تیکتینگ میتواند برای پشتیبانی فناوری اطلاعات، رسیدگی به مشتری یا درخواست‌های داخلی به کار برود. امکانات این راهنما معیار طراحی و انتخاب سامانه‌اند؛ همهٔ آن‌ها الزاماً در هر نرم‌افزار یا فرم پشتیبانی فعال نیستند و باید در محدودهٔ پروژه مشخص شوند.
طراحی روند
فرم، مسئولیت‌ها، وضعیت‌ها و دسترسی‌ها.
اجرای آزمایشی
تست با کاربران واقعی و چند درخواست نمونه.
تحویل و بهبود
آموزش، بکاپ، پایش و اصلاح روند رسیدگی.
تیکتینگ چه مشکلی را در پشتیبانی حل می‌کند؟
وقتی درخواست‌ها بین تماس تلفنی، پیامرسان و گفتوگوی حضوری پخش باشند، ممکن است چند نفر یک کار را دنبال کنند یا همه تصور کنند دیگری مسئول است. سابقهٔ پاسخ نیز به حافظهٔ افراد وابسته می‌شود. سامانهٔ تیکتینگ یک مرجع مشترک برای ثبت، ارجاع و پیگیری ایجاد می‌کند.
- شفاف‌شدن مسئولیت: هر درخواست در صف مشخص و نزد مسئول معین قرار می‌گیرد.
- حفظ سابقه: شرح مشکل، اقدام‌ها و نتیجه کنار همان درخواست نگهداری می‌شوند.
- دیدن کارهای معطل: درخواست‌های بدون مسئول یا منتظر رسیدگی قابل شناسایی می‌شوند.
- یادگیری از تکرارها: مشکلات مشابه برای اصلاح زیرساخت یا تهیهٔ راهنما بررسی می‌شوند.
خود نرم‌افزار تضمین پاسخ‌گویی نیست. اگر تیم، مسئول رسیدگی و زمان بازبینی صف را مشخص نکند، درخواست ثبت می‌شود ولی همچنان معطل می‌ماند. طراحی روند کاری به اندازهٔ نصب سامانه اهمیت دارد.
پیش‌نیازهای راه‌اندازی تیکتینگ سازمانی
قبل از انتخاب ابزار، مشخص کنید چه کسانی درخواست می‌دهند، چه تیم‌هایی رسیدگی میکنند و اطلاعات چقدر حساس‌اند. پشتیبانی مشتریان بیرونی با درخواست‌های داخلی کارکنان، الزام‌های یکسانی برای ورود و دسترسی ندارد.
- تعداد کاربران، کارشناسان و حجم تقریبی درخواست‌ها
- کانال ثبت درخواست و روش شناسایی یا تماس با متقاضی
- تیم‌ها، مسئول ارجاع و مسیر رسیدگی به موارد فوری
- نیاز میزبانی، نگهداری اطلاعات، خروجی و انتقال داده
- اتصال‌های لازم، برنامهٔ بکاپ و مسئول نگهداری سامانه
ابزارهایی مانند GLPI و Jira Service Management نمونه‌هایی با امکانات متفاوت‌اند، نه انتخاب قطعی برای همهٔ سازمانها. قابلیت‌ها، مجوز، شرایط دسترسی و توان نگهداری باید بررسی شوند. توسعهٔ اختصاصی نیز زمانی معنا دارد که نیاز روشن و برنامهٔ نگهداری قابل اتکا وجود داشته باشد.
فرم ثبت تیکت را کوتاه و قابل فهم طراحی کنید
کاربر نباید برای گزارش خرابی، دسته‌بندی‌های تخصصی تیم فناوری اطلاعات را حدس بزند. اطلاعات لازم برای شناخت درخواست و ارتباط با متقاضی را بگیرید و هر فیلد اضافی را با یک نیاز واقعی توجیه کنید. دستهبندی، اولویت و مسئول میتوانند در سمت تیم پشتیبانی تکمیل شوند.
عنوان و شرح واضح، معمولاً ارزش بیشتری از فرم طولانی دارند. در راهنمای شرح درخواست، از کاربر بخواهید بگوید چه اتفاقی افتاده، از چه زمانی شروع شده و چه کاری متوقف شده است. اگر هویت از ورود سازمانی مشخص است، گرفتن دوبارهٔ همان اطلاعات باید دلیل داشته باشد.
نمونهٔ شرح مفید: «از صبح امروز، دو نفر از واحد مالی نمی‌توانند پوشهٔ مشترک را باز کنند؛ پیام Access denied نمایش داده می‌شود.» این توضیح برای شروع بررسی، از «شبکه خراب است» اطلاعات بیشتری دارد. رمز یا اطلاعات محرمانه نباید در متن یا تصویر ارسالی باشد.
گردش کار؛ از ثبت درخواست تا بستن تیکت
وضعیت‌ها باید معنای روشن داشته باشند. زیادکردن تعداد آن‌ها، بدون تفاوت عملی، فقط کار را پیچیده می‌کند. یک روند سادهٔ نمونه میتواند این مراحل را داشته باشد؛ نام و جزئیات آن باید با سامانه و تیم انتخابشده تطبیق داده شوند:
- جدید: درخواست دریافت شده و هنوز نیازمند بررسی و تعیین مسئول است.
- در حال رسیدگی: مسئول مشخص شده و اقدام روی درخواست شروع شده است.
- منتظر اطلاعات: برای ادامه، اطلاعات یا تأیید مشخصی لازم است؛ علت انتظار ثبت می‌شود.
- حل‌شده: راه‌حل یا نتیجه ثبت و به متقاضی اعلام شده است.
- بسته: طبق روند توافق‌شده، نتیجه تأیید یا دورهٔ پیگیری پایان یافته است.
خرابی یک سرویس را از درخواست دریافت یک خدمت تفکیک کنید. «قطع دسترسی فایل‌سرور» با «ایجاد دسترسی برای همکار جدید» نیاز یکسانی ندارد؛ دومی ممکن است تأیید مالک اطلاعات لازم داشته باشد. ارجاع بین تیم‌ها نیز باید همراه با توضیح و حفظ مسئولیت پیگیری باشد.
برای پاسخ قابل مشاهدهٔ کاربر و یادداشت داخلی تیم، سطح نمایش جدا تعریف کنید. راه‌حل باید قابل فهم و قابل استفاده باشد، اما اطلاعات داخلی یا محرمانه نباید ناخواسته در پاسخ عمومی قرار گیرد. مسیر بازکردن مجدد درخواست حل‌نشده هم روشن باشد.
تعیین اولویت و تفاوت زمان پاسخ با زمان حل
اولویت بهتر است با اثر مشکل بر کار و فوریت آن تعیین شود، نه فقط ترتیب ثبت یا انتخاب کاربر. توقف یک سرویس برای کل سازمان با مشکل یک دستگاه دارای راه‌حل موقت تفاوت دارد. ماتریس اولویت باید ساده، قابل توضیح و قابل بازبینی باشد.
زمان پاسخ اولیه نشان می‌دهد تیم چه زمانی ارتباط و رسیدگی را شروع کرده است؛ زمان حل به رفع مشکل یا انجام درخواست مربوط می‌شود. پیام خودکار «درخواست دریافت شد» را بدون تعریف روشن، معادل پاسخ کارشناس حساب نکنید.
در توافق سطح خدمت یا SLA، ساعت کاری، منطقهٔ زمانی، تعطیلات و شرایط شروع، توقف و پایان اندازه‌گیری مشخص شوند. انتظار برای کاربر یا تأمین‌کننده فقط مطابق قاعدهٔ توافق‌شده بر زمان اثر بگذارد؛ تغییر وضعیت نباید راهی برای پنهان‌کردن تأخیر باشد. زمان‌های هدف باید با ظرفیت واقعی تیم هماهنگ باشند.
اعلان‌ها و اتصال به ایمیل یا پیامرسان
اعلان برای رویدادهای مهم مانند ثبت، ارجاع یا پاسخ تازه مفید است؛ ارسال پیام برای هر تغییر کوچک میتواند هشدارها را کم‌اثر کند. برای هر رویداد، گیرنده و محتوای مجاز را مشخص کنید و نتیجه را با حساب‌های آزمایشی بررسی کنید.
اگر اتصال تلگرام یا پیامرسان دیگری در بستر انتخابشده پیش‌بینی شود، اعلان کوتاه میتواند کارشناس را به پنل هدایت کند. متن کامل تیکت و پیوست حساس نباید بی‌برنامه به کانال بیرونی منتقل شوند. لینک اعلان هم نباید جای ورود و بررسی مجوز دسترسی را بگیرد.
ثبت موفق درخواست باید از تحویل اعلان تفکیک شود. قطع ارتباط سرویس اعلان نباید تیکت را گم کند؛ خطا، تلاش مجدد و امکان بررسی صف باید در طراحی اتصال دیده شوند. برای دریافت درخواست از ایمیل، روش اتصال پاسخ به تیکت قبلی و جلوگیری از ایجاد موارد تکراری یا حلقهٔ پاسخ خودکار نیز آزمایش شود.
اتصال‌های ایمیلی را با تنظیمات ایمیل سازمانی و ورود یکپارچه را، در صورت نیاز و پشتیبانی بستر، با مدیریت هویت سازمان هماهنگ کنید.
امنیت تیکت‌ها، پیوست‌ها و پنل کارشناسان
درخواست ممکن است شامل اطلاعات مشتری، تصویر نرم‌افزار یا جزئیات زیرساخت باشد. کاربر باید فقط به موارد مجاز خود دسترسی داشته باشد و کارشناس هم بر اساس نقش و تیم، مجوز بگیرد. پنهان‌کردن یک دکمه کافی نیست؛ مجوز مشاهده، تغییر و دریافت پیوست باید در سمت سرور برای هر درخواست بررسی شود.
برای پیوست، نوع‌های مجاز، تعداد و اندازه تعیین شوند و اعتبارسنجی سمت سرور انجام شود. پسوند یا Content-Type اعلام‌شدهٔ مرورگر به‌تنهایی قابل اعتماد نیست. فایل با نام کنترل‌شده و بدون مجوز اجرا نگهداری شود و دانلود نیز نیازمند بررسی دسترسی باشد؛ در طراحی مناسب، ذخیره خارج از مسیر عمومی وب انجام می‌شود.
ارتباط امن، حفاظت نشست، محدودیت تلاش‌های ناموفق و حفاظت متناسب از حساب‌های مدیریتی در طرح امنیت دیده شوند. رمزها و کلیدهای اتصال نباید در فایل عمومی یا کد مرورگر قرار گیرند. گزارش رخدادها نیز باید با هدف پیگیری تغییرات ثبت شود، بدون ذخیرهٔ بی‌دلیل اطلاعات حساس.
بکاپ تیکتینگ فقط نسخهٔ دیتابیس نیست
دیتابیس، پیوست‌ها و تنظیمات موردنیاز باید با یک برنامهٔ هماهنگ پشتیبان‌گیری شوند. بازیابی دیتابیس بدون فایل‌های مربوط، میتواند درخواست‌ها را با پیوست‌های گمشده برگرداند. زمان نگهداری و حذف داده نیز باید بر اساس نیاز سازمان مشخص شود.
بازیابی یک تیکت نمونه همراه با پاسخ‌ها و پیوست را در محیط کنترل‌شده آزمایش کنید. صحت دسترسی‌ها و ارتباط فایل با درخواست بررسی شود. بکاپ روی همان سرور، به‌تنهایی خرابی کامل یا از دست رفتن آن میزبان را پوشش نمی‌دهد؛ برنامه را با پشتیبان‌گیری و بازیابی هماهنگ کنید.
مراحل اجرا و راه‌اندازی آزمایشی
- شناخت روند فعلی: بررسی کانال‌های درخواست، تأخیرها و نیاز کاربران و تیم.
- طراحی: تعیین فرم، وضعیت‌ها، صف‌ها، دسترسی‌ها و اقلام تحویل.
- پیکربندی: آماده‌سازی بستر، حساب‌ها و اتصال‌های موردنیاز در محدودهٔ توافق‌شده.
- آزمون محدود: ثبت و ارجاع چند درخواست واقعیِ مجاز و بررسی تجربهٔ کاربر و کارشناس.
- آموزش و شروع استفاده: معرفی مسیر اصلی ثبت، مسئولیت بازبینی صف و شیوهٔ پاسخ‌گویی.
- بازبینی: بررسی دادهٔ دورهٔ شروع و اصلاح فیلدها و قواعدی که واقعاً مشکل ایجاد کرده‌اند.
اگر اطلاعات قبلی منتقل می‌شوند، کاربران، وضعیت‌ها، تاریخ‌ها و ارتباط پیوست‌ها باید تطبیق داده شوند. انتقال همهٔ گفت‌وگوهای پراکنده بدون بررسی مالکیت و محرمانگی، الزام پروژه نیست. محدودهٔ انتقال و موارد نگهداری‌شده در منبع قبلی باید روشن باشند.
گزارش‌گیری برای بهبود، نه فقط شمارش تیکت
تعداد درخواست‌های باز، موارد بدون مسئول، عمر صف، بازشدن مجدد و زمان پاسخ و حل را با تعریف یکسان دنبال کنید. نوع درخواست و اولویت هم در تفسیر مهم‌اند؛ حل ده درخواست ساده با رسیدگی به یک اختلال گسترده قابل مقایسهٔ مستقیم نیست.
برای موارد پرتکرار، راهنمای کوتاه یا اصلاح ریشهٔ مشکل تهیه کنید. پایگاه دانش باید پاسخ قابل استفاده بدهد و از اطلاعات حساس پاک شده باشد. هدف گزارش، پیدا کردن گلوگاه و بهترشدن خدمت است، نه صرفاً افزایش تعداد تیکت‌های بسته‌شده.
هزینه راه‌اندازی سامانه تیکتینگ
تعداد کارشناسان و کاربران، مجوز یا اشتراک، میزبانی، پیچیدگی گردش کار، اتصال‌ها، انتقال داده و نیاز امنیت و بکاپ بر هزینه اثر دارند. تعداد فیلدها یا ظاهر فرم به‌تنهایی اندازهٔ پروژه را تعیین نمی‌کند. نگهداری، به‌روزرسانی و پشتیبانی باید جداگانه در برآورد دیده شوند.
برای شروع، حجم تقریبی درخواست‌ها، تیم‌های پاسخ‌گو، روش ورود کاربران و اتصال‌های ضروری را آماده کنید. امکانات نسخهٔ اول را از توسعهٔ بعدی جدا کنید تا سامانهٔ اولیه با پیچیدگی غیرضروری شروع نشود.
چک‌لیست تحویل سامانه تیکتینگ
- ثبت درخواست و تأیید دریافت برای کاربر، در موبایل و دسکتاپ درست کار می‌کند.
- درخواست به صف و مسئول صحیح می‌رسد و تغییر وضعیت قابل پیگیری است.
- کاربر غیرمجاز نمی‌تواند تیکت، یادداشت داخلی یا پیوست دیگران را ببیند.
- فایل نامعتبر یا بزرگ رد می‌شود و پیوست مجاز فقط از مسیر کنترل‌شده دریافت می‌شود.
- اعلان به گیرندهٔ درست می‌رسد و خطای اتصال، ثبت درخواست را مختل نمی‌کند.
- اگر SLA در محدودهٔ پروژه است، تقویم و شرایط اندازه‌گیری آزمایش شده‌اند.
- بازیابی نمونه و مسئول نگهداری، آموزش و مستندات تأیید شده‌اند.
راه‌اندازی تیکتینگ سازمانی با ویوان نت
نیاز و روند فعلی پشتیبانی را در بخش پشتیبانی ویوان نت ثبت کنید تا مسیر انتخاب و اجرای سامانه بررسی شود. تیکتینگ باید با سایر سرویس‌های تحت شبکه، هویت کاربران و سیاست امنیت سازمان هماهنگ باشد؛ هدف، ثبت راحت درخواست و رسیدگی منظم و قابل پیگیری است.
سناریوی آموزشی: درخواست‌ها بین تماس و پیام گم می‌شوند
فرض کنید تیم پشتیبانی درخواست‌ها را در تماس تلفنی و چند گفتوگوی پراکنده دریافت می‌کند. نقطهٔ شروع میتواند یک فرم کوتاه، صف مشخص و مسئول پیگیری باشد؛ لازم نیست کاربر تمام دسته‌بندی‌های فنی را هنگام ثبت بداند.
برای آزمون، یک درخواست غیرحساس ثبت کنید و مسیر دریافت شناسه، ارجاع، پاسخ و اعلام نتیجه را دنبال کنید. اگر اعلان در محدودهٔ پروژه است، تحویل آن را جدا از ثبت درخواست بررسی کنید؛ خطای اعلان نباید به معنی گم‌شدن تیکت باشد.
تعداد تیکت بسته‌شده به‌تنهایی نتیجهٔ کیفیت خدمت نیست. درخواست‌های بی‌مسئول، موارد بازشدهٔ مجدد و زمان پاسخ با تعریف روشن بررسی شوند. این مثال آموزشی است و درصد بهبود یا تجربهٔ مشتری واقعی را ادعا نمی‌کند.
این راهنما از مجموعهٔ سرویس‌های شبکه سازمانی ویوان نت است. برای شناخت مجموعه، معرفی ویوان نت و برای بررسی نیاز پروژه، ثبت درخواست مشاوره را ببینید.
پرسش‌های متداول درباره سامانه تیکتینگ
تیکتینگ با پیامرسان چه تفاوتی دارد؟
پیامرسان برای گفتوگوی سریع کاربرد دارد؛ تیکتینگ برای هر درخواست شناسه، مسئول، وضعیت و سابقهٔ قابل پیگیری نگه میدارد. اعلان در پیامرسان میتواند مکمل باشد، اما مرجع رسیدگی بهتر است خود سامانه باشد.
برای شروع چند فیلد در فرم لازم است؟
تعداد ثابتی برای همهٔ سازمانها وجود ندارد. اطلاعات لازم برای شناخت درخواست و ارتباط با متقاضی کافی است؛ دستهبندی فنی، مسئول و اولویت میتوانند در سمت تیم پشتیبانی تعیین شوند. فیلدهای اضافی باید دلیل مشخص داشته باشند.
زمان پاسخ اولیه با زمان حل تیکت یکی است؟
خیر. پاسخ اولیه شروع ارتباط و رسیدگی است، اما زمان حل به رفع مسئله یا انجام درخواست مربوط می‌شود. ساعت کاری، اولویت و شرایط شروع، توقف و پایان هر معیار باید جداگانه تعریف شوند.
آیا تیکتینگ به اکتیو دایرکتوری نیاز دارد؟
الزام همیشگی نیست. بعضی سامانهها حساب مستقل دارند و برخی امکان اتصال به هویت سازمانی را فراهم میکنند. سازگاری، مجوزها و روش ورود باید برای بستر انتخابشده بررسی و آزمایش شوند.
می‌توان برای تیکت جدید اعلان تلگرام یا ایمیل داشت؟
در بستر دارای امکان اتصال، بله. گیرندگان و محتوای اعلان باید محدود و مشخص باشند؛ اطلاعات حساس و پیوست‌ها نباید بی‌برنامه به کانال دیگر ارسال شوند. خرابی اعلان هم نباید باعث از دست رفتن ثبت درخواست شود.
هزینه راه‌اندازی سامانه تیکتینگ چگونه تعیین می‌شود؟
تعداد کارشناسان و کاربران، بستر میزبانی و مجوز، پیچیدگی گردش کار، اتصال‌ها، انتقال اطلاعات و نیاز پشتیبانی و بکاپ در هزینه اثر دارند. محدودهٔ اجرای اولیه و هزینهٔ نگهداری باید جدا مشخص شوند.
منابع فنی و مطالعهٔ بیشتر
مفاهیم گردش کار، SLA و حفاظت داده را در منابع اصلی زیر مطالعه کنید. امکانات محصول و روش پیاده‌سازی باید با نسخه و محدودهٔ پروژه تطبیق داده شوند: