أغلى جملة في الدعم
«هل يمكنك إرسال لقطة شاشة وإخبارنا بالمتصفح الذي كنت تستخدمه؟» سؤال مهذب ومعقول، وهو السبب في أن خللًا يُصلح في دقيقتين يستغرق ثلاثة أيام. العميل مشغول، فيأتي الرد في اليوم التالي. تُظهر لقطة الشاشة رسالة الخطأ لكنها لا تُظهر النقرة التي سبّبته. وإصدار المتصفح خاطئ لأنه تحقّق من هاتفه. وحين يرى فريق الهندسة التذكرة، لا أحد يتذكر بالضبط ما حدث، ولا حتى العميل نفسه.
الحل ليس نموذج بلاغ أفضل. الحل أن تتوقف عن مطالبة العميل بأدلة كان بإمكانك التقاطها بنفسك، في اللحظة التي وقعت فيها المشكلة.
ما الذي يحتويه بلاغ الخطأ المفيد فعلًا
يحتاج المهندسون إلى خمسة أشياء لإعادة إنتاج الخلل:
- ما فعله العميل: النقرات والمدخلات بالترتيب.
- ما كان يتوقعه: النتيجة التي كان يحاول الوصول إليها.
- ما حدث فعلًا: الخطأ، أو الشاشة الفارغة، أو الزر الذي لم يفعل شيئًا.
- البيئة: الصفحة والمتصفح والجهاز وحجم الشاشة ومصدر القدوم.
- الأثر التقني: أخطاء وحدة التحكم وطلبات الشبكة التي فشلت.
يستطيع العميل أن يقدّم لك بدقة البند الثاني وجزءًا من الثالث. أما الثلاثة الأخرى فهي بالضبط ما تسجّله إعادة تشغيل الجلسة: تسلسل الأفعال، والصفحة والمتصفح، وسجل وحدة التحكم، وطلبات الشبكة. ومطالبة الناس بإعادة بناء ذلك من الذاكرة تعني مطالبتهم بالجزء الذي هم أقل قدرة على تقديمه.
أرفق الجلسة بدلًا من طلبها
أبسط نقطة بداية هي البلاغ نفسه. عندما يرسل العميل أداة ملاحظات أو نموذج بلاغ داخل التطبيق، تكون الجلسة حاضرة: الصفحة التي هو فيها، والأخطاء التي ظهرت للتو، والطلبات التي فشلت قبل ثانية. التقطها مع البلاغ، فتصل التذكرة وهي تحمل ما يحتاجه فريق الهندسة.
هذا يغيّر الرد الأول. بدلًا من «هل يمكنك إرسال لقطة شاشة؟»، يفتح الوكيل إعادة التشغيل، فيرى TypeError في وحدة التحكم قبل ثانيتين من ضغط العميل على زر الدفع مرة أخرى، ويستطيع أن يقول في الساعة نفسها «نرى ما الذي تعطّل، وإليك حلًا مؤقتًا».
البريد الإلكتروني أصعب، لأن الرسالة لا ترافقها جلسة. هناك عادتان تساعدان. عرّف المستخدمين المسجّلين في تحليلاتك حتى يمكن ربط تذكرة من عنوان معروف بجلساتهم الأخيرة، وضع رابطًا للملاحظات داخل المنتج حتى يأتي البلاغ التالي من الصفحة التي فيها المشكلة، لا من صندوق بريد بعد يوم.
افرز حسب الخلل، لا حسب التذكرة
عندما تحمل التذاكر الخطأ، يمكنك تجميعها حسبه. وهنا يحقق معظم الفرق أكبر مكسب. خلل في الدفع لا يولّد تذكرة واحدة؛ بل ثلاثين، كل منها مكتوب بطريقة مختلفة: «فشل الدفع»، «لا أستطيع الشراء»، «الزر معطّل». إذا قرأتها واحدة تلو الأخرى بدت ثلاثين مشكلة. وإذا جمّعتها حسب رسالة الخطأ المشتركة صارت خللًا واحدًا بثلاثين عميلًا متأثرًا، وهذا الرقم هو ما يرفع أولويته.
والتجميع يغيّر أيضًا طريقة إغلاق الحلقة. صعّد الخلل مرة واحدة، إلى مشكلة في Linear أو GitHub أو Jira، واربط به كل تذكرة مطابقة. وعند نشر الإصلاح، يمكن لكل هؤلاء العملاء أن يعلموا به، لا الخمسة الذين صادف أنهم كتبوا مجددًا فقط.
ولكي ينجح ذلك، يجب أن يطابق التجميع ما يراه فريق الهندسة أصلًا. إذا كان الدعم يحصي «مشكلات الدفع» والهندسة تحصي Cannot read properties of undefined (reading 'total')، فلن تتطابق القائمتان أبدًا. جمّع التذاكر حسب رسالة الخطأ الموحّدة نفسها التي يستخدمها تتبّع الأخطاء لديك.
عالج الخصوصية قبل أن تعالجك
إرفاق الجلسات بالتذاكر يعني أن وكلاء الدعم يرون المزيد مما فعله العملاء، لذا ضع القواعد أولًا:
- أخفِ حقول النماذج افتراضيًا، ولا تسجّل أبدًا كلمات المرور أو حقول الدفع.
- اذكر في سياسة الخصوصية أن فريق الدعم قد يراجع الجلسة المرتبطة بطلب ما.
- اقصر الوصول إلى إعادة التشغيل على من يعالجون التذاكر، لا على كل من لديه حساب دخول.
- احترم الموافقة: الزائر الذي رفض التحليلات يجب ألا تكون لديه جلسة تُرفق.
بهذه الطريقة يكون سياق الجلسة أقل تدخلًا من البديل، وهو أن تطلب من العملاء مشاركة الشاشة أو إرسال لقطات من حساباتهم بالبريد.
سير عمل يمكنك البدء به هذا الأسبوع
- أضف أداة ملاحظات أو بلاغ أخطاء داخل التطبيق في الصفحات التي تكثر فيها المشكلات: الدفع، والتهيئة، والإعدادات.
- التقط الجلسة مع كل إرسال، حتى تحمل كل تذكرة إعادة التشغيل وسجل وحدة التحكم والطلبات الفاشلة.
- عرّف المستخدمين المسجّلين، حتى يمكن ربط تذاكر البريد من العملاء المعروفين بجلساتهم.
- جمّع التذاكر حسب الخطأ وراجع أكبر المجموعات أسبوعيًا مع فريق الهندسة.
- صعّد كل خلل مرة واحدة وردّ على كل عميل مرتبط عند إصلاحه.
ما الذي يجب قياسه
أربعة أرقام تخبرك إن كان هذا ينجح:
- نسبة تذاكر الأخطاء المرفقة بجلسة. هذا هو المؤشر الاستباقي؛ ارفعه أولًا.
- الوقت حتى أول رد مفيد، أي رد لا يطلب مزيدًا من المعلومات.
- عدد التذاكر لكل خلل. انخفاضه يعني أنك تصلح الأخطاء التي تولّد أكبر عبء على الدعم.
- معدل إعادة الفتح لتذاكر الأخطاء، وهو ينخفض عندما يكون الرد الأول صحيحًا.
بُني مكتب المساعدة في PulsePanda حول هذه الحلقة: تتحول الملاحظات إلى تذاكر مرفقة بإعادة التشغيل والأخطاء، وتُجمّع التذاكر حسب الأخطاء نفسها التي تعرضها صفحة الأخطاء، ويتيح لك التصعيد إلى Linear أو GitHub أو Jira الرد على كل عميل متأثر عند إغلاق المشكلة.