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