میز کمک & تیکت
ضبط به‌صورت یادداشت داخلی در تیکت باز کارشناس می‌نشیند؛ بدون ساخت مورد تازه‌ای که کسی نخواسته است.
1. پرسشی که این قابلیت ابتدا باید پاسخ می‌داد
کدام تیکت؟
ساخت تیکت برای هر نشست شناسایی‌شده هرزنامه می‌شود: تیم مواردی می‌یابد که کسی باز نکرده است. افزودن یادداشت به همهٔ تیکت‌های قبلی آن فرد هم هرزنامه است، فقط کندتر.
پس: یادداشت داخلی روی تازه‌ترین تیکت باز فرستنده. اگر تیکت بازی نباشد اصلاً اتفاقی نمی‌افتد. هرگز موردی را که مشتری شروع نکرده نمی‌سازیم و کارشناس ضبط را درست در محل توجه فعلی‌اش می‌یابد.
داخلی، هرگز عمومی. پیوند به MousePlayer می‌رود. مشتری نباید آن را ببیند و در هر حال نمی‌تواند دنبال کند.
2. Zendesk Support و Freshdesk
هر دو پشتیبانی می‌شوند و کار یکسان را متفاوت حل می‌کنند. نیازی به درگیری شما نیست، اما توضیح می‌دهد چرا فیلدهای فرم کمی فرق دارند.
| Zendesk Support | Freshdesk | |
|---|---|---|
| زیردامنه | acme از acme.zendesk.com | acme از acme.freshdesk.com |
| ایمیل کارشناس | لازم است؛ ورود Zendesk با این قالب است: email/token | لازم نیست، خالی بگذارید |
| توکن API | مرکز مدیریت → برنامه‌ها و یکپارچه‌سازی‌ها → APIها | تنظیمات نمایهٔ شما |
| نتیجهٔ یادداشت | نظر داخلی روی تیکت | یادداشت خصوصی روی تیکت |
اگر راحت‌تر است کل نشانی را در فیلد زیردامنه بچسبانید؛ بخش لازم را جدا می‌کنیم، پس https://acme.zendesk.com/agent/tickets/1 تبدیل می‌شود به acme.
3. زمان اجرا
هنگام شناسایی نشست؛ وقتی سایت این را فراخوانی می‌کند: MousePlayer.setUserId()، وقتی پل تحلیل شناسهٔ متمایز را بازمی‌خواند یا سرورتان نقطهٔ پایانی identify را فراخوانی می‌کند.
فقط با ایمیل
تیکت به فرستنده تعلق دارد و میز کمک او را با ایمیل می‌شناسد. شمارهٔ قرارداد آنجا راه به جایی نمی‌برد و چیزی فرستاده نمی‌شود.
فقط برای تیکت باز
تیکت حل‌شده و بسته کنار گذاشته می‌شود. یادداشت در موردی که دیگر کسی نمی‌بیند کمکی نمی‌کند و بی‌دلیل تیکت بسته را دوباره به دید کارشناس می‌آورد.
اگر فرستنده تیکت باز نداشته باشد انجام‌شده محسوب می‌شود، نه شکست؛ طبیعی است و تلاش دوباره تغییری نمی‌دهد.
4. آنچه کارشناس می‌بیند
یک یادداشت داخلی: MousePlayer: ضبط نشست از <email> سپس پیوند. یک کلیک تا تماشای کار واقعی شخص، درست کنار چیزی که درباره‌اش نوشته است.
کاربرد ارزشمند آن
- تیکت «کار نمی‌کند». ضبط معمولاً در بیست ثانیه چیزی را نشان می‌دهد که سه دور ایمیل نمی‌گوید.
- مراحل بازتولیدی که کسی نمی‌تواند بازتولید کند. دیگر لازمشان ندارید؛ نشست را دارید.
- کلیک خشمگینانه و بی‌اثر که مشتری هرگز نمی‌گوید، چون فکر می‌کند محصول همین‌طور کار می‌کند.
توکن هرگز از سرور ما خارج نمی‌شود
با AES-256-GCM رمزگذاری، پس از ذخیره هرگز دوباره نشان داده نمی‌شود و عمداً از صف داخلی حامل کار بیرون نگه داشته می‌شود.
5. Help Scout، Front و Gorgias
سه میز کمک دیگر. هر سه یادداشت داخلی روی گفتگوی باز می‌گذارند و هر سه راه متفاوتی دارند.
| اطلاعات شما | زیردامنه | |
|---|---|---|
| Help Scout | شناسه و رمز کارخواه برنامهٔ داخلی | لازم نیست |
| Front | توکن API و شناسهٔ هم‌تیمی | لازم نیست |
| Gorgias | ایمیل کارشناس و کلید API | لازم است |
Help Scout پیش از گفتگو مبادله می‌کند
رمز کارخواه را مستقیم نمی‌پذیرد. پل ابتدا آن را با توکن کوتاه‌عمر دسترسی مبادله می‌کند؛ جریان client credentials برای یکپارچه‌سازی‌ای که برای خودش کار می‌کند، نه یک کاربر. توکن در طول عمرش در حافظه می‌ماند و رمز در پایگاه داده.
نظر Front نویسنده می‌خواهد
نظر در Front به نام هم‌تیمی ظاهر می‌شود و API او را لازم دارد. فیلد با برچسب کارشناس اینجا همین را دارد؛ ورود نیست، فقط شناسه‌ای است که یادداشت نام او را می‌گیرد.
Gorgias دو پرسش می‌خواهد، نه یکی
فهرست تیکتش فقط با این مورد فیلتر می‌شود: customer_id و نه چیز دیگر؛ فیلتر ایمیل ندارد. پس پل ابتدا مشتری را می‌یابد و سپس تیکت او را می‌پرسد. فیلتر وضعیت هم ندارد، پس تیکت باز در سمت ما انتخاب می‌شود؛ درست مانند Freshdesk.
همهٔ علائم تجاری نام‌برده متعلق به مالکانشان‌اند. MousePlayer با این ارائه‌دهندگان رابطهٔ تجاری ندارد.