كيفية إنشاء تقرير تذاكر الدعم: خطوة بخطوة

إن تقرير تذاكر الدعم الفني هو في الغالب مشكلة تعريفات. فالتذاكر المنشأة، والتذاكر التي تم حلها، ووقت الرد الأول، ووقت الحل كلها تبدو بديهية وغنية عن التعريف. ومع ذلك، فإن كل واحد منها يحمل أكثر من معنى رسمي واحد داخل مكتب المساعدة نفسه.

حدد قواعد الاحتساب بوضوح وسيكتب التقرير نفسه. تخطَّ هذه الخطوة، وسيقوم شخصان صادقان بسحب نفس ملف التصدير والاختلاف على النتائج بفارق ساعات.

يغطي هذا الدليل العناصر التي يجب تضمينها في التقرير، والمواضع الأربعة التي تتفرع فيها التعريفات، وكيفية إنشائه من ملف تصدير التذاكر.

ما الذي يجب تضمينه في تقرير تذاكر الدعم الفني

حجم التذاكر وحده لا يخبرك بشيء تقريباً. إن طريقة التنسيق والترتيب هي ما يجعل قراءة الأرقام موثوقة وسليمة.

العنصر	سبب وجوده
التذاكر المنشأة خلال الفترة	جانب الطلب
التذاكر التي تم حلها خلال الفترة	جانب العرض، بناءً على قاعدة حالة محددة
التذاكر المتراكمة في نهاية الفترة	كل ما لم يتم حله أو إغلاقه
وقت الرد الأول	بناءً على توقيت محدد وتعريف محدد
وقت الحل	الأول أو الكامل، مع تسميته صراحة
التذاكر المعاد فتحها	مؤشر الجودة الذي تخفيه الأرقام الأخرى
التذاكر التي لم يتم الرد عليها	حيث فشلت العملية تماماً
نطاق وأساس تاريخ محددين	القنوات والعلامات التجارية وقوائم الانتظار المضمنة

يحمل صفان وزناً أكبر بكثير مما يوحي به حجمهما. فالتذاكر المعاد فتحها والتي لم يتم الرد عليها هي الموضع الذي يتوقف فيه التقرير عن كون مجرد لوحة نتائج ليصبح أداة مفيدة فعلاً.

تنشر Zendesk الصيغ الأساسية، مما يجعل التعريفات قابلة للتحقق بدلاً من أن تكون مجرد مسألة وجهات نظر. ويقدم مرجع المقاييس والسمات الخاص بها تفاصيل كل منها.

لنبدأ بالأبسط. التذاكر التي تم حلها هي "عدد التذاكر التي تم حلها أو إغلاقها"، وبالتالي فإن هذا المقياس يشمل حالتين بدلاً من حالة واحدة.

"وقت الرد الأول" له تعريفان رسميان

هذا هو التفرع الذي يسبب أكبر قدر من الخلاف، وتحذر الشركة المزودة للخدمة من ذلك مباشرة.

توضح وثائق SLA documentation الخاصة بـ Zendesk ذلك في سطر واحد: "لا تخلط بين وقت رد SLA ومقياس وقت الرد الأصلي في Zendesk."

المقياس الأصلي صارم بشأن من يقوم بالرد. حيث تشير Zendesk إلى أن "وقت الرد الأول يتم احتسابه حصرياً بناءً على ردود الوكلاء". أما الإجراءات التلقائية وتلك المتعلقة بالبوتات "فلا تؤخذ في الاعتبار عند احتساب وقت الرد الأول".

أما مقياس SLA فليس كذلك. ففيه، وقت الرد الأول هو "الوقت المنقضي بين إنشاء التذكرة وأول تعليق عام من وكيل (أو رد تلقائي)". وتضيف Zendesk أن "مقاييس وقت الرد يتم استيفاؤها إذا قمت بإعداد مشغل للرد التلقائي بتعليق عام".

اقرأ هذين التعريفين معاً وستجد النتيجة صارخة؛ إذ يمكن للرد الآلي التلقائي أن يلبي مستهدف SLA الخاص بك بينما يستمر مقياس وقت الرد الأول الأصلي في الاحتساب والعمل.

لذا، فإن التقرير الذي يظهر تحقيق مستهدفات SLA بنسبة 98% ومتوسط وقت رد أول يبلغ أربع ساعات لا يناقض نفسه. بل إنه يقدم تقريراً عن أمرين مختلفين، وكلاهما صحيح.

هناك استثناءان أصغر يجدر معرفتهما. خذ على سبيل المثال الحالة التي يقوم فيها الوكيل بإنشاء التذكرة ويكون التعليق الأول عاماً. يشير مرجع مقاييس المدة الزمنية إلى أن الطابع الزمني الثاني "ينتقل إلى تعليق الوكيل العام الثاني".

كما أن التذاكر المشتركة لا تُحتسب. تشير Zendesk إلى أنه عندما يعلق وكيل بشكل عام من حساب آخر باستخدام ميزة مشاركة التذاكر، "فإن هذا لا يُحتسب ضمن وقت الرد الأول لحسابك".

"وقت الحل" له تعريفان أيضاً

يسري الانقسام نفسه على مقاييس الحل، وهنا يتوفر كلا الإصدارين بشكل افتراضي.

وقت الحل الأول هو "المدة بين إنشاء التذكرة وحلها لأول مرة"، وينتهي عند "المرة الأولى التي يتم فيها تعيين حالة التذكرة إلى تم الحل".

وقت الحل الكامل هو "المدة بين إنشاء التذكرة وأحدث حل لها". وينتهي عند "المرة الأخيرة التي تم فيها تعيين حالة التذكرة إلى تم الحل".

بالنسبة لتذكرة تم حلها مرة واحدة، يكون المقياسان متطابقين. أما بالنسبة لتذكرة تم حلها، ثم أُعيد فتحها، وحُلّت مرة أخرى، فإنهما يختلفان بمقدار الوقت الذي استغرقته الجولة الثانية.

هذا هو السبب بالضبط في وجوب تضمين التذاكر المعاد فتحها في التقرير. وتعرفها Zendesk بأنها التذاكر التي "أُعيد فتحها بعد حلها"، وتشير إلى أن المقياس "لا يشمل التذاكر التي تم حلها وإعادة فتحها خلال نفس التحديث".

هناك تأثير من الدرجة الثانية يغفل عنه الناس. فالمعدل اليومي للتذاكر المحلولة يحتسبها "فقط إذا كانت محلولة أو مغلقة حالياً". وبالتالي، فإن التذكرة التي أُعيد فتحها اليوم تخرج بهدوء من إجمالي التذاكر المحلولة للشهر الماضي.

وبناءً على ذلك، فإن التقرير الذي قمت بتشغيله في يونيو لن يعطي نفس النتائج في أغسطس. لم يحدث أي خلل؛ بل إن الحالة الأساسية للتذاكر هي التي تغيرت.

هناك مقياسان آخران يفصلان بين وقت الانتظار ووقت العمل. وقت انتظار مقدم الطلب هو الوقت الإجمالي المقضي في حالات "جديد" و"مفتوح" و"قيد الانتظار"، ووقت انتظار الوكيل هو الوقت الإجمالي المقضي في حالة "معلق".

يجيب هذا الثنائي على سؤال لا يمكن لمتوسط وقت الحل الإجابة عليه. فأوقات الحل الطويلة الناتجة عن انتظار رد العميل تمثل مشكلة مختلفة تماماً عن أوقات الحل الطويلة الناتجة عن طول قائمة الانتظار.

ساعات التقويم أم ساعات العمل

تتوفر كل أرقام الرد والحل وفقاً لتوقيتين، واختيار أحدهما ليس أمراً اختيارياً.

تقوم Zendesk بتخزين كليهما. فبعد الرد العام الأول، "يقوم النظام باحتساب وقت الرد الأول بساعات التقويم وساعات العمل". ويتم "تخزين كلا المقياسين مع بيانات التذكرة".

الخيار الافتراضي الذي تراه ليس محايداً. تشير Zendesk إلى أن تقارير Explore الجاهزة "تعرض المعلومات في التقارير الجاهزة بساعات التقويم". أما مقاييس ساعات العمل "فهي متاحة ويمكن استخدامها في تقاريرك الخاصة".

لذلك، فإن الفريق الذي يعمل من التاسعة إلى الخامسة سيبدو بطيئاً في التقرير الافتراضي. فالتذكرة التي تصل في الساعة 6 مساءً يوم الجمعة تحمل تقريباً 63 ساعة تقويم قبل صباح يوم الاثنين، بينما تقترب من الصفر في ساعات العمل.

تضيف قنوات المحادثة المباشرة تعقيداً آخر. فمقياس وقت الرد الأول (بالثواني) للمراسلة والدردشة "يتجاهل إعدادات ساعات عمل المراسلة وساعات تشغيل الدردشة المباشرة".

كما أن اتفاقيات مستوى الخدمة (SLAs) لوقت رد الدردشة اختيارية. تشير Zendesk إلى أن اتفاقيات مستوى الخدمة لوقت الرد للدردشة المباشرة "تكون معطلة افتراضياً"، لذا فإن غيابها يعود لإعدادات التهيئة وليس بالضرورة للأداء المثالي.

كيفية القيام بذلك يدوياً

الخيار 1: علامة تبويب واحدة لكل فئة مقاييس

قم بتصدير قائمة التذاكر مع حقول المقاييس، ثم قسّم الحجم ووقت الرد ووقت الحل إلى علامات تبويب منفصلة قبل تلخيص أي شيء.

احتفظ بأعمدة ساعات التقويم وساعات العمل جنباً إلى جنب بدلاً من اختيار أحدهما وقت التصدير. فمن المؤكد أنه سيُطلب منك المقياس الآخر لاحقاً.

احسب الوسيط الحسابي بدلاً من المتوسط الحسابي لمقاييس الوقت. فبضع تذاكر تُركت مفتوحة خلال العطلة قد تسحب المتوسط إلى رقم لا يمثل واقع أي تذكرة فعلياً.

الحد الأقصى للقدرة هنا هو أن جداول البيانات لا يمكنها رؤية سجل الحالات. ستحصل فقط على الحالة الحالية لكل تذكرة، لذا يجب أن يأتي سلوك إعادة الفتح من عدد مرات إعادة الفتح بدلاً من إعادة بناء السجل يدوياً.

الخيار 2: علامة تبويب للتعريفات، تُكتب أولاً

قم بتسجيل تعريف وقت الرد، والتوقيت المستخدم، ومقياس الحل، وقاعدة الحالة للتذاكر المحلولة، والقنوات المشمولة بالنطاق، وأساس التاريخ.

ثم سجّل ما لا يدّعيه التقرير. إن تدوين أن تحقيق مستهدفات SLA ووقت الرد الأول الأصلي يقيسان أشياء مختلفة يمنع زميلاً حسن النية من الاستشهاد بهما كرقم واحد.

العائق هنا هو العائق المعتاد؛ فتوثيق القاعدة لا يعني تطبيقها تلقائياً، وفي الربع القادم قد يعيد شخص ما بناء الجدول المحوري من الذاكرة.

الخيار 3: التقسيم قبل حساب المتوسط

قسّم التذاكر حسب القناة قبل احتساب أي مقياس زمني. فتذاكر البريد الإلكتروني والدردشة والهاتف لها طبيعة مختلفة تماماً، والوسيط المختلط لا يصف أياً منها بدقة.

ثم استبعد أو ضع علامة على التذاكر التي تشوه البيانات. فالتذاكر التي تنتظر رد العميل لأسابيع يجب أن توضع في بند مستقل بدلاً من إدراجها داخل متوسط وقت الحل.

اعرض ما قمت باستبعاده وعدد هذه الحالات. فالقارئ الذي لا يرى عامل التصفية سيفترض عدم وجود أي تصفية.

العائق هنا هو أن التقسيم يضاعف العمل. فثلاث قنوات مضروبة في توقيتين مضروبة في مقياسي حل تعني اثني عشر رقماً يجب تتبعها بدقة.

الحد الأقصى المشترك. تفترض الخيارات الثلاثة أن ملف التصدير يغطي نطاقاً تاريخياً واحداً على أساس تاريخ واحد لكل قائمة انتظار. وتعد النطاقات المختلطة عبر علامات التبويب الخطأ الصامت الأكثر شيوعاً في هذا التقرير.

أين تتباطأ الطريقة اليدوية

يستغرق إعداد تقرير تذاكر الدعم الأول فترة بعد الظهر. أما التقرير الرابع فيستغرق وقتاً أطول، لأن مكتب المساعدة قد تغيرت تفاصيله في هذه الأثناء.

يتم تفعيل قناة جديدة، فيتغير الوسيط المختلط لأسباب لا علاقة لها بالأداء. ويتم تعديل ساعات العمل لمنطقة جديدة، فتتغير معها كل أرقام ساعات العمل التاريخية.

ثم يظهر تأثير إعادة الفتح. لم تعد أرقام الربع الماضي قابلة للتكرار، ويستغرق شرح السبب وقتاً أطول من إعادة بناء التقرير نفسه.

هناك تكلفة رابعة تظهر فقط تحت الضغط. عندما يسأل شخص ما عما إذا كان الدعم قد أصبح أسرع هذا الربع. تتطلب الإجابة الصادقة تحديد التوقيت والتعريف ومزيج القنوات أولاً.

لمعرفة جانب الرضا من نفس الصورة، راجع دليلنا حول إنشاء تقرير NPS. وإذا كان حجم التذاكر نفسه هو المشكلة، فإن دليلنا الإرشادي حول بناء وكيل ذكاء اصطناعي لدعم العملاء قبل البيع يغطي جانب تحويل التذاكر وتقليلها.

كيفية بنائه باستخدام Powerdrill Bloom

الخطوة 1: تحميل ملف تصدير التذاكر الخاص بك

قم بتحميل ملف تصدير التذاكر، أو ملفات تصدير التذاكر واتفاقيات مستوى الخدمة (SLA) معاً. يقوم Powerdrill Bloom بتحليل الأعمدة فور وصولها، بحيث تظهر الطوابع الزمنية الفارغة، وتنسيقات التاريخ المختلطة، والتذاكر التي تفتقر إلى رد أول قبل احتساب أي وسيط.

الخطوة 2: وصف التقرير بلغة طبيعية

حدد التعريفات بدلاً من إعادة بنائها. حدد تعريف وقت الرد، والتوقيت، ومقياس الحل الذي تريده، وقاعدة الحالة للتذاكر المحلولة، والقنوات المشمولة بالنطاق.

ثم اطرح الأسئلة التي تكشف الأخطاء. اسأل عن عدد التذاكر التي لم تتلقَ أي رد من وكيل على الإطلاق. واسأل عن التذاكر التي أُعيد فتحها. واطلب الحصول على الوسيط لكل قناة بدلاً من رقم واحد مختلط.

الخطوة 3: تصدير المخطط أو التقرير أو العرض التقديمي

استخرج جدول المقاييس لكل قناة، أو مخططاً للتذاكر المنشأة مقابل المحلولة مع التراكمات خلفها. وتخرج الشرائح التي تحمل التعريفات بجانب الأرقام من نفس عملية التشغيل.

أخطاء شائعة

الاستشهاد بتحقيق مستهدفات SLA كوقت رد أول. أحدهما يقبل الرد التلقائي والآخر يستبعد الإجراءات التلقائية تماماً.

مقارنة ساعات التقويم بساعات العمل. يمنحك التقرير الافتراضي الخيار الأول، بينما تم تحديد مستهدفك على الأرجح بناءً على الثاني.

استخدام المتوسط الحسابي لأوقات الرد والحل. فبضع تذاكر مهملة تنقل المتوسط إلى قيمة لا تمثل أي تذكرة حقيقية.

خلط القنوات معاً. يختلف وسيط الدردشة والبريد الإلكتروني بطبيعتهما، والخلط يخفي تفاصيل كليهما.

الإبلاغ عن وقت الحل دون تحديد نوعه. فوقت الحل الأول والكامل هما مقياسان منفصلان ومخزنان، وليسا مجرد اختلافات في التقريب.

التعامل مع عدد التذاكر المحلولة كعدد نهائي. تشمل أعداد التذاكر المحلولة التذاكر المحلولة أو المغلقة حالياً فقط، لذا فإن إعادة الفتح تغير الماضي.

استبعاد التذاكر التي لم يتم الرد عليها. وتُعرف بأنها التذاكر التي تحتوي على أقل من رد واحد من الوكيل، وهي أوضح فشل يمكن للتقرير إظهاره.

خاتمة

حدد تعريف الرد، وحدد التوقيت، واختر الحل الأول أو الكامل، واذكر قاعدة الحالة، وقسّم حسب القناة، واعرض التذاكر المعاد فتحها والتي لم يتم الرد عليها. ينتج عن ذلك تقرير تذاكر دعم يمكن اتخاذ إجراءات بناءً عليه.

ما قد لا يفعله التقرير هو مقارنة أرقامك بأرقام شركة أخرى بشكل دقيق. فالتعريفات قابلة للتخصيص والتهيئة، لذا فإن أي معيار مرجعي تقرأه في مكان ما قد تم قياسه بالتأكيد بطريقة مختلفة.

تتبع أداءك مقارنة بسجلك التاريخي الخاص بدلاً من ذلك، بناءً على مجموعة ثابتة من القواعد. هذا هو الإصدار الذي يخبرك ما إذا كان هناك أي تحسن فعلي قد حدث.

إذا كانت إعادة بناء التقرير كل شهر تستهلك يوماً كاملاً، فجرّب Powerdrill Bloom على ملف تصدير التذاكر الخاص بك. راجع أيضاً صفحة AI report generator وأداة voice of customer summarizer.

الأسئلة الشائعة

لماذا لا يتطابق تحقيق مستهدفات SLA مع وقت الرد الأول لدي؟

إنهما يقيسان أحداثاً مختلفة. فوقت الرد الأول لاتفاقية مستوى الخدمة (SLA) في Zendesk يمكن استيفاؤه من خلال الرد التلقائي، بينما يستبعد مقياس وقت الرد الأول الأصلي إجراءات البوتات والإجراءات التلقائية تماماً.

هل يجب علي الإبلاغ عن وقت الحل الأول أم وقت الحل الكامل؟

أبلغ عن المقياس الذي تحدده وتسميه. ينتهي وقت الحل الأول عند المرة الأولى التي يتم فيها تعيين التذكرة كـ "تم الحل". وينتهي وقت الحل الكامل عند المرة الأخيرة، لذا فإن التذاكر المعاد فتحها هي ما يفصل بين الاثنين.

هل تُقاس مقاييس الدعم بساعات التقويم أم بساعات العمل؟

يتم تخزين كليهما. تعرض تقارير Explore الجاهزة من Zendesk ساعات التقويم، وتتوفر مقاييس ساعات العمل للتقارير التي تبنيها بنفسك.

لماذا تغير عدد التذاكر المحلولة للربع الماضي؟

تشمل أعداد التذاكر المحلولة التذاكر المحلولة أو المغلقة حالياً فقط. والتذكرة التي أُعيد فتحها بعد انتهاء الفترة تخرج من إجمالي تلك الفترة.

هل يمكنني مقارنة وقت الحل لدي بمعيار مرجعي في هذا المجال؟

بشكل تقريبي فقط. فالتعريفات، والتوقيت، ومزيج القنوات كلها قابلة للتخصيص، لذا فإن الرقم المنشور قد تم قياسه على الأرجح وفقاً لقواعد مختلفة عن قواعدك.