آموزش گام‌به‌گاممیز خدمت
سیستم تیکتینگ داخلی سازمان: راه‌اندازی برای IT، منابع انسانی، ساختمان و حقوقی
راه‌اندازی موفق سیستم تیکتینگ داخلی به دستهبندی با زبان کاربر، صف و سرپرست مشخص، SLA واقع‌بینانه، فرم ساده و پایگاه دانش اولیه بستگی دارد. این راهنما هشت گام اجرا و چهار سناریوی آماده برای IT، منابع انسانی، ساختمان و حقوقی ارائه می‌دهد.
خلاصه در چند نکته
- با یک واحد شروع کنید و برای سیستم تیکتینگ یک راهبر داخلی مالک تعیین کنید.
- دستهها را با زبان درخواستدهنده و حداکثر در دو سطح طراحی کنید.
- هر صف سرپرست، کارشناس، سطح دو و جانشین مشخص داشته باشد.
- اولویت پیش‌فرض را دسته تعیین کند و سرپرست صف آن را تأیید یا اصلاح کند.
- فرم ثبت تیکت ساده باشد و اطلاعات کاربر خودکار پر شود.
- پیش از راه‌اندازی ده پرسش پرتکرار هر واحد را با پاسخ استاندارد بنویسید.
- مدیران باید خودشان از سیستم استفاده کنند تا کانال‌های قدیمی بسته شوند.
فهرست مطالب
در بیشتر سازمان‌ها، سیستم تیکتینگ داخلی با یک جمله شروع می‌شود: «دیگر درخواست‌ها را در گروه پیامرسان نفرستید.» و در بسیاری از همان سازمان‌ها، سه ماه بعد همه دوباره به پیامرسان برگشته‌اند. علت معمولاً خود نرم‌افزار نیست؛ این است که دسته‌بندی‌ها گیج‌کننده بودند، درخواست به صف اشتباه می‌رفت، کسی مسئول صف نبود و درخواستدهنده نمی‌دانست چه زمانی جواب می‌گیرد. این راهنما گام‌به‌گام نشان می‌دهد سیستم تیکتینگ داخلی را برای فناوری اطلاعات، منابع انسانی، خدمات ساختمان و حقوقی چطور راه بیندازید که واقعاً جا بیفتد، و برای هر واحد یک سناریوی آماده پیشنهاد می‌دهد.
اگر هنوز تفاوت تیکتینگ، میز خدمت و پرتال کارکنان برایتان روشن نیست، ابتدا میز خدمت الکترونیک چیست را بخوانید. اینجا تمرکز ما روی اجرای عملی است.
پیش از شروع: سه تصمیم کلیدی
- کدام واحد اول؟ همه واحدها را هم‌زمان راه نیندازید. واحدی را انتخاب کنید که بیشترین درخواست تکراری و مدیری علاقه‌مند دارد؛ معمولاً فناوری اطلاعات.
- چه کسی مالک سیستم است؟ یک راهبر داخلی که دستهها، صف‌ها و گزارش‌ها را نگهداری کند. بدون مالک، ساختار به‌سرعت به هم می‌ریزد.
- کانال رسمی کدام است؟ تصمیم بگیرید از چه تاریخی درخواست فقط از پرتال یا سامانه پذیرفته می‌شود و استثناها، مثل تماس تلفنی در شرایط بحرانی، چیست.
گام ۱: دستهبندی درخواست‌ها را طراحی کنید
دستهبندی ستون فقرات تیکتینگ است. درخواستدهنده با انتخاب دسته، درخواست را به صف درست میفرستد و گزارش‌ها هم بر اساس همین دستهها ساخته می‌شوند.
اصول دستهبندی خوب:
- از زبان درخواستدهنده استفاده کنید، نه زبان فنی. «اینترنت یا شبکه کار نمی‌کند» بهتر از «اختلال لایه دسترسی» است.
- حداکثر دو سطح. دسته اصلی و زیردسته کافی است. سه یا چهار سطح، کاربر را در انتخاب سرگردان می‌کند.
- دسته «سایر» محدود. اگر بیش از ده درصد تیکتها در «سایر» ثبت می‌شوند، دسته‌ای جا افتاده است.
- هر دسته یک صف مقصد. کاربر نباید بداند درخواستش به کدام تیم می‌رود؛ دسته باید خودش آن را مسیریابی کند.
گام ۲: صف هر واحد و نقش‌ها را تعریف کنید
هر واحد ارائه‌دهنده خدمت یک یا چند صف دارد. برای هر صف این نقش‌ها را مشخص کنید:
| نقش | مسئولیت |
|---|---|
| سرپرست صف | تخصیص تیکتها، پایش مهلت‌ها، دریافت تشدیدها |
| کارشناس | رسیدگی و پاسخ به تیکت‌های تخصیص‌یافته |
| کارشناس سطح دو | موارد پیچیده یا تخصصی که از سطح یک ارجاع می‌شود |
| جانشین سرپرست | دریافت تشدیدها در غیبت سرپرست |
صف‌ها باید از هم جدا باشند تا تیکت تأسیسات با تیکت فناوری اطلاعات قاطی نشود و هر واحد فقط صف خودش را ببیند؛ اما همه از یک هویت کاربری و یک پرتال درخواست استفاده کنند تا کارمند مجبور نباشد برای هر واحد سامانه جداگانه یاد بگیرد.
گام ۳: اولویت و SLA را مشخص کنید
برای هر دسته، اولویت پیش‌فرض و مهلت پاسخ اولیه و حل را تعیین کنید. اولویت را بهتر است کارشناس یا سرپرست صف تأیید یا اصلاح کند، چون اگر انتخاب آن کاملاً با درخواستدهنده باشد، به‌زودی همه درخواست‌ها «فوری» می‌شوند. اجزای SLA، محاسبه ساعات کاری و الگوی تشدید چندسطحی را در SLA در گردش‌کار و تیکتینگ با جزئیات توضیح داده‌ایم.
گام ۴: فرم ثبت تیکت را ساده نگه دارید
هر فیلد اضافه، احتمال برگشت کاربر به پیامرسان را بیشتر می‌کند. فرم پایه:
- دسته و زیردسته
- عنوان کوتاه
- شرح
- پیوست (عکس صفحه خطا، تصویر خرابی)
- محل یا شماره اموال، فقط برای دسته‌هایی که لازم دارند
اطلاعاتی مثل نام، واحد و شماره تماس باید خودکار از حساب کاربری پر شوند. برای دسته‌های خاص، فیلدهای ویژه همان دسته را اضافه کنید؛ مثلاً «شماره قرارداد» برای تیکت حقوقی.
گام ۵: پایگاه دانش اولیه بسازید
قبل از راه‌اندازی، ده پرسش پرتکرار هر واحد را با پاسخ استاندارد بنویسید. این کار دو فایده دارد: کارشناس به جای تایپ دوباره، پاسخ آماده را میفرستد، و کاربر گاهی پیش از ثبت تیکت پاسخش را خودش پیدا می‌کند. اصول ساخت پایگاه دانشی که واقعاً استفاده شود را در دانشنامه سازمانی چیست آورده‌ایم.
گام ۶: آزمایشی راه بیندازید
دو هفته با یک واحد و گروه کوچکی از کاربران آزمایش کنید. در این مدت به سه چیز دقت کنید: درخواست‌ها به صف درست می‌روند؟ کدام دسته مبهم است؟ کارشناسان مهلت‌ها را رعایت می‌کنند یا مهلت‌ها غیرواقعی‌اند؟ اصلاحات را قبل از گسترش انجام دهید.
گام ۷: کانال‌های قدیمی را مؤدبانه ببندید
پس از راه‌اندازی رسمی، به درخواست‌هایی که هنوز از پیامرسان یا تلفن می‌رسند با یک پاسخ ثابت و مؤدبانه جواب دهید: «لطفاً درخواستتان را از این مسیر ثبت کنید تا پیگیری و مهلت آن مشخص باشد.» مهم‌ترین نکته این است که مدیران خودشان از سیستم استفاده کنند. اگر مدیرعامل درخواستش را تلفنی بدهد و فوراً رسیدگی شود، پیام روشنی به همه سازمان ارسال شده است.
گام ۸: گزارش و رضایت را بسنجید
از ماه اول این گزارش‌ها را برای هر صف ببینید: تعداد تیکت ورودی و بسته‌شده، درصد رعایت مهلت پاسخ و حل، تیکت‌های باز قدیمی و پرتکرارترین دستهها. اگر ابزار شما امکان نظرسنجی پس از بستن تیکت دارد، یک پرسش کوتاه رضایت با یک فیلد توضیح اختیاری کافی است؛ اگر ندارد، هر ماه با چند درخواستدهنده تماس کوتاه بگیرید. پرتکرارترین دستهها هم نامزد نوشتن مقاله دانش یا خودکارسازی‌اند.
یک تیکت از ثبت تا بستن
برای اینکه تصویر کامل شود، مسیر یک تیکت واقعی را دنبال کنیم. کارشناس فروش ساعت ده صبح از پرتال، دسته «شبکه و اینترنت» و زیردسته «قطعی» را انتخاب می‌کند و می‌نویسد اینترنت طبقه دوم قطع است. چون دسته اولویت پیش‌فرض بالا دارد، تیکت مستقیم در صف فناوری اطلاعات قرار می‌گیرد و ساعت SLA شروع می‌شود. سرپرست صف می‌بیند سه تیکت مشابه از همان طبقه رسیده، آن‌ها را به هم مرتبط می‌کند و اولویت را به بحرانی تغییر می‌دهد، چون اثر آن کل طبقه است. کارشناس شبکه در پانزده دقیقه پاسخ اولیه می‌دهد که مشکل از سوئیچ طبقه است. پس از تعویض، تیکتها بسته می‌شوند و درخواست‌دهندگان پیام بسته شدن را می‌گیرند. در گزارش ماهانه، این رخداد یک‌بار در دسته «قطعی شبکه» ثبت شده و سرپرست صف می‌تواند ببیند سوئیچ‌های کدام طبقه‌ها بیشترین خرابی را داشته‌اند. هیچ‌کدام از این‌ها در گروه پیامرسان ممکن نبود.
چهار سناریوی آماده
سناریوی ۱: فناوری اطلاعات
| دسته | زیردسته‌ها | اولویت پیش‌فرض |
|---|---|---|
| رایانه و تجهیزات | خرابی سخت‌افزار، کندی، چاپگر | متوسط |
| شبکه و اینترنت | قطعی، کندی، Wi-Fi | بالا |
| حساب و دسترسی | بازنشانی رمز، دسترسی به پوشه یا سامانه | متوسط |
| نرم‌افزار | نصب، خطا، به‌روزرسانی | پایین تا متوسط |
دسترسی به سامانه‌های حساس معمولاً پیش از اجرا تأیید مدیر واحد را لازم دارد؛ این بخش را با فرم و مسیر تأیید پشت تیکت پیاده کنید.
سناریوی ۲: منابع انسانی
| دسته | زیردسته‌ها |
|---|---|
| گواهی و نامه | گواهی اشتغال، معرفی‌نامه |
| اطلاعات پرسنلی | اصلاح مشخصات، مدارک |
| پرسش و راهنمایی | آیین‌نامه‌ها، مزایا، مرخصی |
| آموزش | درخواست دوره، گواهی آموزش |
بسیاری از پرسش‌های منابع انسانی با پایگاه دانش پاسخ داده می‌شوند. محرمانگی هم مهم است: تیکت‌های مربوط به اطلاعات شخصی فقط برای کارشناسان مجاز قابل مشاهده باشند.
سناریوی ۳: خدمات ساختمان و تأسیسات
| دسته | زیردسته‌ها | اولویت پیش‌فرض |
|---|---|---|
| تأسیسات | برق، آب، سرمایش و گرمایش | بسته به اثر |
| تعمیرات | در و پنجره، مبلمان | پایین |
| نظافت و پذیرایی | درخواست ویژه جلسه | پایین |
| خودرو و حمل‌ونقل | رزرو خودرو، جابه‌جایی اثاثیه | متوسط |
فیلد «محل دقیق» (ساختمان، طبقه، اتاق) برای این صف حیاتی است. برای کارهای چندروزه مثل بازسازی یک طبقه، تیکت را به وظیفه یا کارت کانبان تیم تأسیسات تبدیل کنید؛ ستون‌های پیشنهادی را در کانبان چیست ببینید.
سناریوی ۴: حقوقی
| دسته | زیردسته‌ها |
|---|---|
| بازبینی قرارداد | قرارداد خرید، فروش، همکاری |
| استعلام حقوقی | پرسش درباره مقررات یا تعهدات |
| دعاوی و اختلافات | اطلاع از اختلاف یا اخطار |
| تنظیم سند | وکالت‌نامه، صورتجلسه مجمع |
تیکت‌های حقوقی معمولاً محرمانه‌اند و مهلت حل آن‌ها بیشتر به کامل بودن اطلاعات وابسته است. وضعیت «منتظر اطلاعات واحد درخواست‌کننده» برای این صف ضروری است.
اشتباهات رایج
- دستهبندی بر اساس ساختار داخلی تیم پشتیبانی به جای زبان کاربر.
- صف بدون سرپرست: تیکت‌هایی که «مال همه» است، در عمل مال هیچ‌کس نیست.
- مهلت‌های رؤیایی: که از هفته اول نقض می‌شوند.
- گسترش هم‌زمان به همه واحدها پیش از تثبیت واحد اول.
- تبدیل تیکتینگ به نامه‌نگاری: درخواست خدمت جای نامه رسمی نیست و برعکس.
تیکتینگ داخلی در آریا آی‌تی
نرم‌افزار تیکتینگ سازمانی آریا آی‌تی تیکت، دسته، اولویت، صف، کارشناس، تشدید، مهلت خدمت، خودکارسازی و پرتال درخواستدهنده را دارد و صف‌های نمونه فناوری اطلاعات، منابع انسانی، ساختمان و حقوقی روی همان محصول‌اند. پاسخ تکراری از دانش سازمانی پیشنهاد می‌شود و درخواست عملیاتی می‌تواند به کارت کار تیم در بخش وظایف تبدیل شود. صف خدمات ساختمان از فناوری اطلاعات جداست، اما از همان هویت، مهلت خدمت و اعلان استفاده می‌کند. محصول خدمات کارکنان مستقل هم عرضه می‌شود؛ یعنی سازمانی که هنوز اتوماسیون کامل نمی‌خواهد، می‌تواند فقط صف تیکت و پرتال داخلی را راه بیندازد. تمرکز فعلی میز خدمت داخلی کارکنان و واحدهاست.
جمع‌بندی
راه‌اندازی موفق سیستم تیکتینگ داخلی بیشتر به طراحی بستگی دارد تا نرم‌افزار: دستهبندی با زبان کاربر، صف و سرپرست مشخص برای هر واحد، اولویت و SLA واقع‌بینانه، فرم ساده، پایگاه دانش اولیه، آزمایش با یک واحد، بستن مؤدبانه کانال‌های قدیمی و سنجش ماهانه. با یک واحد شروع کنید و وقتی صف اول پایدار شد، سناریوهای بعدی را اضافه کنید.
درخواست‌ها را از پیامرسان بیرون بیاورید: تیکتینگ آریا آی‌تی در پلن حرفه‌ای نسخه ابری در دسترس است. ۷ روز رایگان امتحان کنید یا تعرفه‌ها را ببینید.
مراحل انجام کار
سه تصمیم کلیدی بگیرید
واحد اول، مالک سیستم و تاریخ رسمی شدن کانال تیکتینگ را مشخص کنید.
دستهبندی را طراحی کنید
دستهها و زیردسته‌ها را با زبان کاربر و حداکثر در دو سطح بنویسید و به صف مقصد وصل کنید.
صف و نقش‌ها را تعریف کنید
برای هر صف سرپرست، کارشناس، سطح دو و جانشین تعیین کنید.
اولویت و SLA را مشخص کنید
اولویت پیش‌فرض و مهلت پاسخ و حل هر دسته را تعیین کنید.
فرم ساده بسازید
فقط فیلدهای ضروری را در فرم بگذارید و اطلاعات کاربر را خودکار پر کنید.
پایگاه دانش اولیه بسازید
ده پرسش پرتکرار هر واحد را با پاسخ استاندارد آماده کنید.
آزمایشی راه بیندازید
دو هفته با یک واحد و گروه کوچک آزمایش کنید و دستهها و مهلت‌ها را اصلاح کنید.
کانال‌های قدیمی را ببندید و بسنجید
درخواستهای پیامرسان را به سامانه هدایت کنید و گزارش مهلت و رضایت را ماهانه مرور کنید.
پرسش‌های متداول
سیستم تیکتینگ داخلی چیست؟
+
سامانهای برای ثبت، مسیریابی، پیگیری و پاسخ به درخواستهای خدمت کارکنان است که هر درخواست را بهصورت یک تیکت با دسته، اولویت، مسئول و مهلت به صف واحد مربوط میفرستد.
تیکتینگ را از کدام واحد شروع کنیم؟
+
معمولاً از فناوری اطلاعات، چون درخواست تکراری زیاد و نیاز روشن به صف و مهلت دارد. واحدی را انتخاب کنید که مدیرش به راه‌اندازی علاقه‌مند است.
دستهبندی تیکتها چند سطح داشته باشد؟
+
حداکثر دو سطح: دسته اصلی و زیردسته. دستهها را با زبان درخواستدهنده بنویسید و هر دسته را به یک صف مقصد وصل کنید.
چطور کارکنان را از پیامرسان به تیکتینگ منتقل کنیم؟
+
تاریخ مشخصی برای کانال رسمی اعلام کنید، به درخواستهای پیامرسان با پاسخ ثابت و مؤدبانه هدایت به سامانه جواب دهید و مهمتر از همه، مدیران خودشان از سیستم استفاده کنند.
آیا تیکتینگ فقط برای واحد فناوری اطلاعات است؟
+
خیر. منابع انسانی، خدمات ساختمان، حقوقی و هر واحدی که به بقیه سازمان خدمت می‌دهد می‌تواند صف تیکت جداگانه با دستهها و مهلت‌های خودش داشته باشد.