تیکتینگ چیست؟ تعریف ساده، کاربردها و نقشه شروع برای تیم‌های پشتیبانی فنی
تیکتینگ روشی برای مدیریت درخواست‌های پشتیبانی است که در آن هر مشکل، سؤال یا درخواست مشتری به‌صورت یک پرونده جداگانه و شماره‌دار به نام «تیکت» ثبت می‌شود. هر تیکت یک مسئول، یک اولویت، یک وضعیت و تاریخچه کامل گفت‌وگوها دارد و تا حل و بسته شدن پرونده در صف کار تیم می‌ماند.
با تیکتینگ هیچ درخواستی گم نمی‌شود و مسئول پیگیری هر کار معلوم است. مشتری می‌داند کارش در چه مرحله‌ای است و مدیر پشتیبانی می‌تواند با عدد و داده ببیند تیم چقدر سریع و درست کار می‌کند.
تیکتینگ به زبان ساده
تیمی را در نظر بگیرید که درخواست‌ها را از ایمیل، تلفن، پیام‌رسان و فرم سایت می‌گیرد. اگر درخواست‌ها در صندوق ایمیل یا گروه پیام‌رسان بمانند، به‌مرور معلوم نیست کدام پاسخ گرفته، کدام فراموش شده و کدام را دو نفر جداگانه پاسخ داده‌اند.
تیکتینگ این آشفتگی را با یک قاعده ساده حل می‌کند: هر درخواست، از هر کانالی که آمده باشد، یک پرونده واحد می‌شود و همه کارهای مربوط به آن در همان پرونده ثبت می‌شود.
سیستم تیکتینگ یا هلپ‌دسک این کار را خودکار می‌کند. درخواست‌ها را از کانال‌های مختلف جمع می‌کند، برای هر کدام تیکت می‌سازد، آن را به فرد یا گروه مناسب می‌سپارد، زمان‌ها را می‌سنجد و گزارش می‌دهد.
البته تیکتینگ پیش از آنکه نرم‌افزار باشد، یک روش کار است. تیمی که قاعده‌های ثبت، اولویت‌بندی و بستن تیکت را تعریف نکرده باشد، با بهترین نرم‌افزار هم همان آشفتگی قبلی را خواهد داشت.
تیکت از چه اجزایی تشکیل می‌شود
هر تیکت مجموعه‌ای از فیلدهای استاندارد دارد که بعضی را مشتری، بعضی را کارشناس و بعضی را خود سیستم پر می‌کند. تکمیل درست این فیلدها هم برای حل سریع مشکل لازم است و هم برای گزارش‌گیری دقیق در آینده.
| فیلد | توضیح | چه کسی پر می‌کند |
|---|---|---|
| شماره تیکت | شناسه یکتا برای پیگیری و ارجاع | سیستم به‌صورت خودکار |
| درخواست‌کننده | نام و اطلاعات مشتری یا کاربر داخلی | سیستم یا مشتری |
| کانال | ایمیل، تلفن، فرم سایت، چت یا پیام‌رسان | سیستم |
| موضوع و شرح | خلاصه مشکل و جزئیات آن، همراه با پیوست مثل تصویر خطا | مشتری |
| نوع تیکت | رخداد، درخواست خدمت، سؤال، شکایت یا موارد دیگر | کارشناس یا قاعده خودکار |
| دسته‌بندی | محصول، ماژول یا حوزه فنی مرتبط | مشتری یا کارشناس |
| اولویت | فوری، بالا، متوسط یا پایین بر اساس اثر و فوریت | کارشناس یا قاعده خودکار |
| مسئول | فرد یا گروهی که باید تیکت را حل کند | سرپرست، کارشناس یا قاعده ارجاع |
| وضعیت | جدید، باز، در انتظار، حل‌شده یا بسته | کارشناس و سیستم |
| زمان‌ها | زمان ثبت، اولین پاسخ، حل و بستن | سیستم |
| یادداشت داخلی | توضیحاتی که فقط تیم می‌بیند | کارشناس |
انواع تیکت در پشتیبانی فنی
همه درخواست‌ها از یک جنس نیستند و رفتار یکسان با آن‌ها اولویت‌ها را به هم می‌ریزد. چارچوب ITIL، که در مدیریت خدمات فناوری اطلاعات رایج است، این مفهوم‌ها را از هم جدا می‌کند:
- رخداد (Incident): قطع شدن یا افت کیفیت خدمتی که پیش‌تر درست کار می‌کرده است، مثل از کار افتادن ورود به حساب کاربری یا خطا در صدور فاکتور. هدف در رخداد، بازگرداندن سریع خدمت به حالت عادی است.
- درخواست خدمت (Service Request): درخواستی که خرابی نیست و از پیش تعریف شده است، مثل ساخت حساب جدید، بازنشانی رمز عبور یا افزودن یک کاربر به سامانه.
- مشکل (Problem): علت ریشه‌ای یک یا چند رخداد. اگر ده مشتری خطای مشابهی گزارش کنند، ده تیکت رخداد ثبت می‌شود، اما یافتن و رفع علت اصلی در قالب یک «مشکل» پیگیری می‌شود.
- سؤال یا راهنمایی: درخواست‌هایی که با توضیح یا ارسال راهنما حل می‌شوند و اغلب بهترین نامزد برای پایگاه دانش‌اند.
- شکایت و بازخورد: نارضایتی از کیفیت خدمت یا رفتار، یا پیشنهاد برای بهبود محصول.
چرخه عمر تیکت
هر تیکت از ثبت تا بسته شدن از چند وضعیت می‌گذرد. نام این وضعیت‌ها در ابزارهای مختلف فرق می‌کند، اما منطقشان تقریباً یکی است:
- جدید: تیکت ثبت شده اما هنوز کسی آن را بررسی نکرده است.
- باز یا ارجاع‌شده: تیکت به یک کارشناس یا گروه سپرده شده و کار روی آن شروع شده است.
- در انتظار: کار متوقف است چون تیم منتظر اطلاعات از مشتری، تأمین‌کننده یا تیم دیگری است. در بسیاری از سیستم‌ها، شمارش زمان SLA در این وضعیت متوقف می‌شود.
- حل‌شده: کارشناس راه‌حل را ارائه کرده و منتظر تأیید یا عدم اعتراض مشتری است.
- بسته: پرونده نهایی شده است. معمولاً اگر مشتری تا مدت معینی پس از حل‌شدن اعتراض نکند، تیکت خودکار بسته می‌شود.
- بازگشایی‌شده: مشتری اعلام کرده مشکل حل نشده یا دوباره رخ داده است و تیکت به صف کار برمی‌گردد.
یک خطای رایج این است که هر نوع انتظاری ساعت SLA را متوقف کند. رویه معمول در ابزارهای مدیریت خدمات، توقف ساعت فقط هنگام انتظار برای مشتری است. انتظار برای تأمین‌کننده یا تیم داخلی دیگر جزو مسئولیت خود شماست و نباید زمان را متوقف کند.
برای وضعیت «در انتظار مشتری» هم یادآوری خودکار و مهلت بستن تعریف کنید تا تیکتی که مشتری دیگر پیگیرش نیست، بی‌نهایت در صف نماند.
تفاوت «حل‌شده» و «بسته» کوچک به نظر می‌رسد، اما مهم است. وضعیت حل‌شده به مشتری فرصت می‌دهد بگوید راه‌حل کار نکرده، و نرخ بازگشایی از همین مرحله به دست می‌آید.
سطوح پشتیبانی و مسیر ارجاع تیکت
در بیشتر تیم‌های پشتیبانی فنی، تیکت‌ها بر اساس پیچیدگی در چند سطح رسیدگی می‌شوند. این تقسیم‌بندی وقت متخصصان را از سؤال‌های تکراری آزاد می‌کند و درخواست‌های ساده هم منتظر متخصص نمی‌مانند.
| سطح | چه کسی | نمونه کار |
|---|---|---|
| سطح صفر (خودیاری) | خود مشتری با پایگاه دانش، پرسش‌های متداول یا ربات پاسخ‌گو | یافتن راهنمای تنظیمات، بازنشانی رمز از طریق سامانه |
| سطح یک | کارشناس پشتیبانی عمومی | ثبت و دسته‌بندی، پاسخ به سؤال‌های رایج، اجرای راه‌حل‌های مستند |
| سطح دو | کارشناس فنی باتجربه‌تر | بررسی لاگ، عیب‌یابی تنظیمات، بازتولید خطا |
| سطح سه | توسعه‌دهنده، مهندس زیرساخت یا تأمین‌کننده | رفع باگ در کد، تغییر در زیرساخت، مشکلات ریشه‌ای |
ارجاع تیکت به سطح بالاتر را «اسکالیشن» می‌گویند و دو نوع رایج دارد:
- ارجاع افقی یا عملکردی: سپردن تیکت به گروهی که تخصص لازم را دارد.
- ارجاع عمودی یا سلسله‌مراتبی: درگیر کردن مدیر وقتی تیکت در آستانه نقض تعهد زمانی است یا مشتری مهمی ناراضی شده است.
قاعده‌های ارجاع باید از پیش نوشته شوند تا کارشناس سطح یک بداند دقیقاً چه زمانی و با چه اطلاعاتی تیکت را بالا بفرستد.
اگر تیکت‌ها مدام بین سطوح پاس داده می‌شوند، مدل Intelligent Swarming را هم بشناسید که Consortium for Service Innovation، سازنده روش KCS، پیشنهاد کرده است. در این مدل، کسی که تیکت را برمی‌دارد تا حل نهایی مالک آن می‌ماند و به جای ارجاع، متخصص لازم را به همکاری فرامی‌خواند.
اولویت‌بندی تیکت با اثر و فوریت
اگر اولویت را مشتری تعیین کند، تقریباً همه تیکت‌ها «فوری» می‌شوند. روش رایج، تعیین اولویت از ترکیب دو معیار است که در ITIL و استاندارد ISO/IEC 20000 هم توصیه شده است.
«اثر» نشان می‌دهد مشکل چند کاربر، سرویس یا فرایند کسب‌وکار را درگیر کرده است. «فوریت» نشان می‌دهد چقدر زمان دارید تا مشکل به زیان جدی برسد. جدول زیر نمونه‌ای رایج است که هر تیم باید با شرایط خودش تنظیم کند:
| اثر در برابر فوریت | فوریت بالا | فوریت متوسط | فوریت پایین |
|---|---|---|---|
| اثر زیاد (همه کاربران یا یک سرویس حیاتی) | اولویت ۱: بحرانی | اولویت ۲: بالا | اولویت ۳: متوسط |
| اثر متوسط (یک بخش یا گروهی از کاربران) | اولویت ۲: بالا | اولویت ۳: متوسط | اولویت ۴: پایین |
| اثر کم (یک کاربر، با راه جایگزین) | اولویت ۳: متوسط | اولویت ۴: پایین | اولویت ۴: پایین |
برای هر سطح اولویت یک تعریف عملیاتی با مثال بنویسید؛ برای نمونه، «اولویت ۱ یعنی هیچ مشتری‌ای نمی‌تواند وارد سامانه شود یا پرداخت‌ها انجام نمی‌شود». این تعریف‌ها جلوی برداشت سلیقه‌ای را می‌گیرند و پایه تعهدهای زمانی یا SLA می‌شوند.
کاربردهای تیکتینگ
تیکتینگ بیشتر با پشتیبانی فنی نرم‌افزار شناخته می‌شود، اما هر جا درخواستی باید ثبت، پیگیری و پاسخ داده شود، به کار می‌آید:
- پشتیبانی محصولات نرم‌افزاری و سرویس‌های آنلاین: گزارش خطا، سؤال درباره قابلیت‌ها، درخواست تغییر تنظیمات و مشکلات حساب کاربری.
- هلپ‌دسک فناوری اطلاعات داخل سازمان: خرابی رایانه و چاپگر، دسترسی به پوشه‌ها و سامانه‌ها، نصب نرم‌افزار و مشکلات شبکه.
- خدمات پس از فروش و گارانتی: ثبت درخواست تعمیر، پیگیری قطعه، هماهنگی بازدید تکنسین و ثبت نتیجه. در ایران، قانون حمایت از حقوق مصرف‌کننده عرضه‌کنندگان کالا و خدمات را به رعایت تعهدات ضمانت و پاسخ‌گویی به شکایت‌ها ملزم می‌کند و ثبت منظم تیکت، سابقه‌ای مستند از تعهدات انجام‌شده می‌سازد. جزئیات این الزامات را از متن قانون و مقررات جاری یا با مشورت متخصص حقوقی بررسی کنید.
- پشتیبانی فروشگاه‌های اینترنتی: پیگیری سفارش، درخواست مرجوعی و شکایت از کیفیت کالا.
شاخص‌های اصلی سنجش عملکرد تیکتینگ
تیکتینگ عملکرد پشتیبانی را قابل اندازه‌گیری می‌کند، اما شاخص‌ها فقط وقتی مفیدند که تعریفی یکسان و دقیق داشته باشند و همه تیم آن را بدانند. رایج‌ترین شاخص‌ها این‌هاست:
| شاخص | تعریف | روش محاسبه | نکته |
|---|---|---|---|
| FCR (حل در اولین تماس) | درصد درخواست‌هایی که در همان اولین تماس یا اولین پاسخ، بدون نیاز به پیگیری بعدی حل می‌شوند | تعداد تیکت‌های حل‌شده در اولین تماس تقسیم بر کل تیکت‌ها، ضرب در ۱۰۰ | تیکت‌هایی که بعداً بازگشایی می‌شوند نباید جزو حل در اولین تماس شمرده شوند |
| AHT (میانگین زمان رسیدگی) | میانگین زمانی که کارشناس به‌طور فعال صرف یک درخواست می‌کند | مجموع زمان گفت‌وگو، انتظار روی خط و کارهای پس از تماس، تقسیم بر تعداد درخواست‌ها | کاهش بی‌رویه آن به قیمت حل نشدن مشکل، FCR را پایین می‌آورد |
| CSAT (رضایت مشتری) | درصد مشتریانی که پس از بسته شدن تیکت از خدمت رضایت داده‌اند | تعداد پاسخ‌های راضی (مثلاً امتیاز ۴ و ۵ از ۵) تقسیم بر کل پاسخ‌ها، ضرب در ۱۰۰ | نرخ پاسخ پایین به نظرسنجی، دقت این عدد را کم می‌کند |
| SLA (توافق سطح خدمت) | تعهد مکتوب درباره زمان اولین پاسخ و زمان حل برای هر سطح اولویت | درصد تیکت‌هایی که در محدوده زمانی تعهدشده پاسخ یا حل شده‌اند | باید مشخص شود زمان بر اساس ساعت کاری سنجیده می‌شود یا شبانه‌روزی |
| زمان اولین پاسخ | فاصله ثبت تیکت تا اولین پاسخ انسانی به مشتری | میانگین یا میانه این فاصله در یک دوره | پاسخ خودکار «درخواست شما ثبت شد» نباید اولین پاسخ حساب شود |
| زمان حل | فاصله ثبت تیکت تا وضعیت حل‌شده | میانگین یا میانه، به تفکیک اولویت | میانه در برابر چند تیکت بسیار طولانی تصویر واقعی‌تری می‌دهد |
| نرخ بازگشایی | درصد تیکت‌هایی که پس از حل‌شدن دوباره باز می‌شوند | تعداد تیکت‌های بازگشایی‌شده تقسیم بر تیکت‌های حل‌شده، ضرب در ۱۰۰ | نشانه کیفیت راه‌حل‌ها و بستن زودهنگام تیکت |
| تیکت‌های معوق (Backlog) | تعداد تیکت‌های باز در یک لحظه مشخص | شمارش تیکت‌های باز، به تفکیک عمر تیکت | روند افزایشی آن نشان می‌دهد ظرفیت تیم کمتر از حجم درخواست‌هاست |
این شاخص‌ها را باید کنار هم دید. تیمی که AHT بسیار پایین اما نرخ بازگشایی بالا دارد، احتمالاً تیکت‌ها را زود می‌بندد.
هیچ عدد جهانی ثابتی برای «خوب بودن» این شاخص‌ها وجود ندارد. مقدار مناسب به نوع محصول، پیچیدگی فنی و کانال پشتیبانی بستگی دارد و بهترین مرجع مقایسه، روند عملکرد خود تیم در طول زمان است.
انواع ابزار برای پیاده‌سازی تیکتینگ
می‌توان با ابزار ساده شروع کرد و به‌مرور به ابزار تخصصی رسید. انتخاب باید بر اساس حجم درخواست‌ها، تعداد کارشناسان و نیاز به گزارش‌گیری باشد.
| نوع ابزار | مناسب برای | محدودیت‌ها |
|---|---|---|
| صندوق ایمیل مشترک با برچسب | تیم یک یا دو نفره با حجم کم | نبود شماره تیکت، SLA و گزارش؛ احتمال پاسخ تکراری |
| صفحه‌گسترده یا ابزار مدیریت پروژه | تیم کوچک در مرحله آزمایش فرایند | ثبت دستی، اتصال نداشتن به کانال‌ها، خطای انسانی زیاد |
| نرم‌افزار هلپ‌دسک ابری | بیشتر تیم‌های پشتیبانی مشتری | وابستگی به اینترنت و سرویس‌دهنده؛ در ایران باید دسترسی پایدار، روش پرداخت و محل نگهداری داده بررسی شود |
| نرم‌افزار هلپ‌دسک روی سرور سازمان | سازمان‌هایی که کنترل کامل بر داده می‌خواهند | نیاز به نگهداری، به‌روزرسانی و نیروی فنی داخلی |
| سامانه مدیریت خدمات فناوری اطلاعات (ITSM) | هلپ‌دسک داخلی سازمان‌های بزرگ با فرایندهای رخداد، مشکل و تغییر | پیچیدگی راه‌اندازی و هزینه بیشتر |
هنگام انتخاب نرم‌افزار، این قابلیت‌ها را بررسی کنید:
- پشتیبانی کامل از زبان فارسی و نمایش راست‌به‌چپ
- تبدیل خودکار ایمیل و فرم سایت به تیکت
- قاعده‌های ارجاع خودکار
- تعریف SLA بر اساس ساعت کاری و تعطیلات رسمی ایران
- پایگاه دانش، پاسخ‌های آماده و نظرسنجی رضایت
- گزارش‌های قابل خروجی
دو نکته محلی را هم پیش از خرید آزمایش کنید. ایران از شهریور ۱۴۰۱ ساعت تابستانی را کنار گذاشته است و اگر سرور یا نرم‌افزار هنوز قاعده قدیمی منطقه زمانی Asia/Tehran را داشته باشد، زمان ثبت تیکت‌ها و محاسبه SLA در نیمه اول سال یک ساعت جابه‌جا می‌شود.
نکته دوم تعطیلات مذهبی است که از تقویم قمری پیروی می‌کنند و هر سال حدود ده تا یازده روز زودتر می‌آیند. پس تقویم تعطیلات نرم‌افزار را هر سال از روی تقویم رسمی به‌روز کنید، وگرنه تیکت‌های روز تعطیل به اشتباه نقض SLA ثبت می‌شوند.
نقشه شروع: راه‌اندازی تیکتینگ در تیم پشتیبانی فنی
راه‌اندازی تیکتینگ را از تعریف فرایند شروع کنید و انتخاب ابزار را به مرحله بعد بسپارید. مراحل زیر برای یک تیم پشتیبانی فنی کوچک تا متوسط قابل اجراست:
- وضعیت فعلی را ثبت کنید. دو تا چهار هفته همه درخواست‌ها را، حتی در یک صفحه‌گسترده ساده، یادداشت کنید: کانال، موضوع، پاسخ‌دهنده و مدت رسیدگی. این داده پایه همه تصمیم‌های بعدی است.
- کانال‌های ورودی را مشخص کنید. تصمیم بگیرید درخواست‌ها از چه مسیرهایی پذیرفته می‌شوند و همه را به یک صف واحد هدایت کنید. درخواستی که در پیام خصوصی کارشناس بماند، از دید سیستم پنهان است.
- انواع و دسته‌بندی تیکت را تعریف کنید. با داده مرحله اول، فهرست کوتاهی از انواع تیکت و دسته‌های اصلی بسازید. فهرست بیش از حد بلند به انتخاب‌های تصادفی و گزارش‌های بی‌اعتبار می‌انجامد.
- ماتریس اولویت و تعهدهای زمانی را بنویسید. برای هر سطح اولویت، تعریف، مثال، زمان هدف اولین پاسخ و زمان هدف حل را مشخص کنید. اعداد را بر اساس ظرفیت واقعی تیم بگذارید، نه بر اساس آرزو.
- سطوح پشتیبانی و قاعده ارجاع را تعیین کنید. مشخص کنید کدام کارها در سطح یک انجام می‌شود، چه زمانی تیکت به سطح دو یا سه می‌رود و چه اطلاعاتی باید همراهش ارسال شود.
- ابزار را انتخاب و تنظیم کنید. ابزار متناسب با حجم کار را انتخاب و فیلدها، وضعیت‌ها، قاعده‌های ارجاع و SLA را در آن پیاده کنید.
- پاسخ‌های آماده و پایگاه دانش اولیه بسازید. برای ده تا بیست درخواست پرتکرار، پاسخ استاندارد و راهنمای مرحله‌به‌مرحله بنویسید تا زمان رسیدگی کم و پاسخ‌ها یکدست شوند. در روش KCS، مقاله دانش همان لحظه حل تیکت و با کلمات خود مشتری نوشته می‌شود، نه هفته‌ها بعد، تا جست‌وجوی بعدی همان عبارت را پیدا کند.
- تیم را آموزش دهید و دوره آزمایشی بگذارید. قاعده‌ها را با مثال واقعی آموزش دهید و چند هفته سیستم را با یک کانال یا یک گروه از مشتریان آزمایش کنید. در این دوره، اشکال‌های تعریف وضعیت‌ها و دسته‌ها آشکار می‌شود.
- به مشتریان اطلاع دهید. توضیح دهید درخواست را از چه مسیری ثبت کنند و در چه زمانی منتظر پاسخ باشند.
- گزارش‌ها را به‌صورت دوره‌ای مرور کنید. هر هفته شاخص‌های اصلی و هر ماه پرتکرارترین دسته‌ها را بررسی کنید. تیکت‌های تکراری را به تیم محصول یا فنی ارجاع دهید تا علت ریشه‌ای رفع شود.
اشتباهات رایج در راه‌اندازی تیکتینگ
این اشتباهات از دلایل رایج ناکامی تیکتینگ در تیم‌های پشتیبانی‌اند:
- شروع از ابزار به جای فرایند: نرم‌افزاری که پیش از تعریف انواع تیکت، اولویت‌ها و مسئولیت‌ها خریده شود، شکل عادت‌های قبلی را می‌گیرد.
- دسته‌بندی بیش از حد پیچیده: وقتی کارشناس باید از میان ده‌ها دسته انتخاب کند، اغلب «سایر» را برمی‌گزیند و گزارش‌ها بی‌استفاده می‌شوند. قاعده ساده: اگر «سایر» در گزارش ماهانه جزو پرتکرارترین دسته‌ها باشد، فهرست دسته‌ها باید بازنگری شود.
- واگذاری اولویت به مشتری: اولویت باید از روی اثر و فوریت تعیین شود. نظر مشتری درباره فوریت مهم است، اما تنها معیار نیست.
- پاسخ دادن خارج از سیستم: حل مشکل در تماس تلفنی یا پیام‌رسان بدون ثبت در تیکت، سابقه را ناقص و شاخص‌ها را نادرست می‌کند.
- بستن زودهنگام تیکت: فشار برای کاهش زمان حل، کارشناسان را به بستن تیکت پیش از اطمینان از حل مشکل وامی‌دارد و نرخ بازگشایی و نارضایتی را بالا می‌برد.
- تعهدهای زمانی غیرواقعی: SLAای که تیم در عمل نمی‌تواند رعایت کند، اعتماد مشتری و انگیزه کارشناسان را با هم از بین می‌برد.
- بی‌توجهی به تیکت‌های تکراری: اگر یک خطا هر هفته ده‌ها تیکت بسازد و فقط تک‌تک آن‌ها پاسخ بگیرند، تیم پشتیبانی همیشه پرکار و محصول همیشه معیوب می‌ماند.
سوالات متداول
فرق تیکتینگ با پاسخ دادن از طریق ایمیل چیست؟
در ایمیل معمولی، پیام‌ها مالک، وضعیت و اولویت مشخصی ندارند و پیگیری‌شان به حافظه افراد بستگی دارد. در تیکتینگ، هر درخواست شماره، مسئول و وضعیت دارد، زمان‌ها خودکار سنجیده می‌شوند و کل سابقه در یک پرونده جمع است.
بسیاری از سیستم‌های تیکتینگ ایمیل را به‌عنوان یکی از کانال‌های ورودی می‌پذیرند و آن را به تیکت تبدیل می‌کنند.
تیم کوچک هم به سیستم تیکتینگ نیاز دارد؟
روش تیکتینگ از همان روزهای اول لازم است، چون حتی در تیم دو نفره هم درخواست‌ها گم می‌شوند یا دو بار پاسخ می‌گیرند. اما نرم‌افزار تخصصی را می‌توان وقتی تهیه کرد که حجم درخواست‌ها یا تعداد کانال‌ها بالا رفت. شروع با یک صفحه‌گسترده منظم و قاعده‌های روشن، تمرین خوبی برای مرحله بعد است.
SLA با زمان هدف داخلی چه فرقی دارد؟
SLA تعهدی است که به مشتری داده می‌شود و معمولاً در قرارداد یا شرایط خدمت ثبت است. زمان هدف داخلی، که گاهی OLA یا توافق سطح عملیاتی میان تیم‌های داخلی نامیده می‌شود، معمولاً سخت‌گیرانه‌تر از SLA است تا تیم پیش از رسیدن به مرز تعهد فرصت جبران داشته باشد.
FCR در پشتیبانی ایمیلی چطور سنجیده می‌شود؟
در کانال‌های نوشتاری، حل در اولین تماس معمولاً یعنی مشکل با اولین پاسخ کارشناس حل شده و مشتری نیازی به پیام دوباره نداشته است.
روش دقیق شمارش باید در تیم تعریف و ثابت نگه داشته شود. برای مثال، پیام تشکر مشتری پیگیری حساب نشود و تیکت‌های بازگشایی‌شده از این شاخص کنار گذاشته شوند.
چه زمانی باید تیکت را به سطح بالاتر ارجاع داد؟
وقتی راه‌حل مستندی در سطح فعلی وجود ندارد، دسترسی یا تخصص لازم در اختیار کارشناس نیست، یا تیکت در آستانه عبور از زمان تعهدشده است.
قاعده ارجاع باید از پیش نوشته شده باشد. کارشناس هنگام ارجاع، خلاصه مشکل، اقدامات انجام‌شده و نتیجه آن‌ها را در یادداشت داخلی ثبت می‌کند تا سطح بعدی کار را از صفر شروع نکند.
جمع‌بندی
تیکتینگ هر درخواست پشتیبانی را به پرونده‌ای شماره‌دار با مسئول، اولویت، وضعیت و تاریخچه تبدیل می‌کند. این روش جلوی گم شدن درخواست‌ها را می‌گیرد، کار را بین سطوح پشتیبانی تقسیم می‌کند و با شاخص‌هایی مانند FCR، AHT، CSAT و رعایت SLA، عملکرد را قابل اندازه‌گیری می‌کند.
برای شروع، اول فرایند را بنویسید و بعد ابزاری متناسب با حجم کار انتخاب کنید. مرور منظم گزارش‌ها و رفع علت ریشه‌ای تیکت‌های تکراری، تیکتینگ را از یک صف پاسخ‌گویی به ابزاری برای بهبود محصول و خدمت تبدیل می‌کند.
