چگونه یک سیستم تیکت پشتیبانی (هلپ‌دسک) بسازیم: تیکت‌ها، وضعیت‌ها، ارجاع و ایمیل

سیستم تیکت هلپ‌دسک درخواست‌های پراکنده — ایمیل‌ها، پیام‌ها، «سؤال‌های سریع» در راهرو — را به تیکت تبدیل می‌کند: یک رکورد برای هر مشکل، با مالک، وضعیت، اولویت و کل گفتگو. برای ساختنش به راهی برای ساختن تیکت، صف مشترک با فیلتر، ارجاع، رشته‌ای که پاسخ‌های عمومی را از یادداشت‌های داخلی جدا کند، و اعلان‌هایی نیاز دارید تا کسی بی‌جواب نماند. یک ابزار ساخت اپ هوش مصنوعی می‌تواند نسخه اول محکمی برای یک میز IT، منابع انسانی یا امکانات داخلی در یک بعدازظهر بسازد. پشتیبانی مشتری‌محور با ردیابی ایمیل، مهلت پاسخ و گزارش‌گیری نیاز به دقت بیشتری دارد — و اینجاست که محصولات هلپ‌دسک جاافتاده ارزش هزینه‌شان را نشان می‌دهند.

سیستم به چه چیزهایی نیاز دارد

داده‌ها

زمان اولین پاسخ و زمان حل را از همان ابتدا ذخیره کنید. همه گزارش‌ها روی آن‌ها ساخته می‌شوند و بعداً نمی‌توانید آن‌ها را بازسازی کنید.

صفحه‌ها

• درخواست‌کننده: فرم «ارسال درخواست» با دسته و پیوست، فهرست «درخواست‌های من»، و رشته گفتگوی هر تیکت.
• کارشناس: صف (تیکت‌های من، بدون ارجاع، همه باز)، فیلتر و جستجو، و نمای تیکت با کنترل‌های پاسخ، یادداشت، وضعیت، اولویت و ارجاع.
• ادمین: دسته‌ها، تیم‌ها، کارشناسان، پاسخ‌های آماده، و یک گزارش ساده.

دسترسی‌ها

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

تصمیم‌ها و مصالحه‌ها

فرم، ایمیل یا هر دو

فرم وب ساده‌ترین است و داده تمیز می‌دهد: دسته، اولویت و فیلدهای اجباری. دریافت ایمیل — مردم به support@ می‌نویسند و یک تیکت ظاهر می‌شود — چیزی است که مشتریان انتظار دارند، اما به یک ارائه‌دهنده ایمیل نیاز دارد که بتواند پیام دریافت کند و به اپ شما بفرستد، به‌علاوه رشته‌بندی تا پاسخ‌ها به تیکت درست بچسبند (معمولاً یک شماره تیکت در موضوع یا یک آدرس پاسخ یکتا). با فرم شروع کنید؛ ایمیل را وقتی گردش کار ثابت شد اضافه کنید. ارسال ایمیل از اپ نیمه خروجی را پوشش می‌دهد.

ارجاع

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

اولویت‌ها و مهلت‌های پاسخ

دو یا سه اولویت با مهلتی برای اولین پاسخ تعریف کنید («فوری: ۱ ساعت، عادی: ۱ روز کاری»). نشان دادن زمان باقی‌مانده روی هر تیکت مفیدتر از یک گزارش ماهانه است که کسی نمی‌خواند. ساعات کاری محاسبات را سخت‌تر می‌کند — زود تصمیم بگیرید آیا مهلت‌ها شب‌ها و آخر هفته‌ها را هم می‌شمارد.

ادغام و تکراری‌ها

یک مشکل که سه بار گزارش شده رایج است. عمل «ادغام در تیکت #» کارشناسان را از پاسخ دادن مکرر به یک چیز نجات می‌دهد؛ ساختنش زود ارزش دارد.

یک پرامپت اولیه که کار می‌کند

یک هلپ‌دسک IT داخلی برای یک شرکت ۶۰ نفره بسازید. کارکنان درخواست‌ها را با فرم ارسال می‌کنند: موضوع، دسته (سخت‌افزار، نرم‌افزار، دسترسی، شبکه، سایر)، اولویت (کم، عادی، فوری)، توضیح و پیوست‌ها. هر تیکت یک شماره و وضعیت‌های جدید، باز، در انتظار درخواست‌کننده، حل‌شده و بسته‌شده می‌گیرد. کارشناسان IT یک صف با تب‌های بدون ارجاع، من و همه باز می‌بینند، با فیلتر بر اساس دسته، اولویت و وضعیت، و جستجو. صفحه تیکت رشته گفتگو را با پاسخ‌های عمومی و یادداشت‌های داخلی کاملاً جدا نشان می‌دهد؛ کارکنان هرگز یادداشت داخلی نمی‌بینند. کارشناسان می‌توانند ارجاع دهند، وضعیت و اولویت را تغییر دهند، از پاسخ‌های آماده استفاده کنند و تکراری‌ها را ادغام کنند. زمان‌های اولین پاسخ و حل را ثبت کنید و زمان از آخرین به‌روزرسانی را روی هر تیکت نشان دهید. کارکنان صفحه «درخواست‌های من» دارند. نقش‌ها: کارمند، کارشناس، ادمین. همه چیز را در یک پایگاه داده ذخیره کنید. رابط ساده، متراکم و سریع — سرعت بر تزئین.

مراحل ساخت

1. مدل تیکت و فرم. ارسال، فهرست، باز کردن تیکت، پاسخ دادن.
2. صف و فیلترها. بدون ارجاع، من، همه باز؛ فیلتر و جستجو؛ مرتب‌سازی بر اساس اولویت و سن.
3. نقش‌ها و ورود. درخواست‌کننده، کارشناس، ادمین — با یادداشت‌هایی که روی سرور از درخواست‌کنندگان پنهان‌اند.
4. کنترل‌های ارجاع، وضعیت و اولویت، با یک گزارش فعالیت از هر تغییر.
5. اعلان‌ها. ایمیل به درخواست‌کننده برای پاسخ‌های عمومی و به کارشناس برای ارجاع‌های جدید، از طریق ارائه‌دهنده ایمیل خودتان.
6. پاسخ‌های آماده و ادغام.
7. مهلت‌های پاسخ و یک گزارش پایه: تیکت‌های باز بر اساس سن، زمان اولین پاسخ، تیکت‌ها در هر دسته.
8. دریافت ایمیل، پس از اینکه بقیه کار کرد، با رشته‌بندی به‌دقت آزموده‌شده.
9. آزمایش با یک تیم به مدت دو هفته پیش از انتقال همه.

اشتباه‌های رایج

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

وقتی یک محصول آماده بهتر است

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

ساخت سفارشی برای میزهای داخلی (IT، منابع انسانی، امکانات، درخواست‌های مالی) مناسب است، برای گردش‌کارهای خاص که در آن یک تیکت در واقع یک کار با مراحل مشخص است، و برای تیم‌هایی که می‌خواهند درخواست‌ها به داده‌های دیگری که از قبل نگه می‌دارند وصل شوند. همچنین از هزینه به‌ازای هر کارشناس جلوگیری می‌کند وقتی افراد زیادی گاهی تیکت‌ها را مدیریت می‌کنند. راهنمای ابزار داخلی این دسته را گسترده‌تر پوشش می‌دهد.

ساخت با Mythex

در Mythex هلپ‌دسک را در گفتگو توصیف می‌کنید، آن را در پیش‌نمایش زنده بررسی می‌کنید و برای تیم‌تان منتشر می‌کنید. تیکت‌ها در یک پایگاه داده Postgres زندگی می‌کنند که عامل وقتی داده نیاز به ذخیره داشته باشد اضافه می‌کند، و پیوست‌ها به فضای ذخیره‌سازی فایل پروژه می‌روند. ورود درخواست‌کنندگان و کارشناسان، و همه ایمیل‌های ورودی و خروجی، از ارائه‌دهندگان خودتان استفاده می‌کنند — Mythex محصول داخلی ورود کاربر نهایی یا ایمیل ندارد؛ دستور ارسال ایمیل رویکرد را نشان می‌دهد. هم‌تیمی‌ها می‌توانند از طریق یک فضای کار مشترک کمک کنند، بدون هزینه هر صندلی در خود Mythex.

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

پرسش‌ها