دور فريق دعم العملاء في تحسين المنتج

إنّ إلقاء اللوم على فريق الدّعم بسبب العملاء غير الراضين هو كإلقاء اللوم على الأرصاد الجويّة بسبب المطر. صحيحٌ أنّهم معنيّون في الأمر، إلا أنّهم ليسوا السبب.

إنّ توكيل مهمّة دعم العملاء إلى فريق من خارج شركتك outsource، أو القيام بعزل فريق الدّعم عن بقية الأقسام في الشركة يعني أنّك مقبل على إنتاج مُنتج متوسّط الجودة. كما أنّ فريق الإنتاج الذي لا يُبالي بالتغذية الراجعة feedback لن يتعلم أبدًا من الإطلاق الفاشل، واجهة المستخدم المُربكة، الوسوم المُبهمة، أو الإعدادات الافتراضيّة غير المنطقية للمنتج. لن يعرف فريق الإنتاج الشيء الذي لم يفهمه العملاء ما لم يسترشدوا بالمُعطيات المُتوفّرة لدى فريق الدّعم الفنّي، جنبًا إلى جنب مع المُعطيات المُتوفّرة لديهم.

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

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

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

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

السبب الجذري والمسؤول عنه

جميع المشاكل لها سبب جذريّ، وكل سبب جذريّ له مسؤول.

• العميل لا يستطيع التسجيل؟ - لماذا؟
• يسأل العميل عن طريقة دعوة زمليه؟ - لماذا سأل هذا السؤال؟
• يدّعي العميل أنّه رأى "مجانًا" في الإعلان؟ - من وضعها هناك؟
• تعطّل التطبيق بعد عمل أول مشروع لهم؟ - لماذا حدث ذلك؟
• تم تأشير بريد دعوة العميل كبريد مزعج spam؟ - لماذا تمت إضافتنا إلى القائمة السوداء؟

هنالك مسؤول عن كل مشكلة من هذه المشاكل؛ الأشخاص الذي يمتلكون السلطة والقدرة على تغيير المنتج للتأكّد من أنّ العملاء المستقبليين لن يسألوا هذه الأسئلة مجدّدًا.

المراحل الخمس للإقرار بالمشكلة

من الشائع أن يمر أصحاب المُنتج بخمس مراحل من الإحباط الذي يرافق المشاكل التي تواجههم. إنّ أي إجراء يتّخذه صاحب المنتج سيُسبق بمحاولات لرفض، إنكار، تكذيب، أو تزويق البيانات.

وهذا رد فعل طبيعي. وأفضل طريقة لتجاوز ذلك هي إمّا أن يقوم صاحب المُنتج بعمل بعض اختبارات المستخدم user testing، أو أن يبدأ بقراءة بعض طلبات الدّعم. قامت شركة Amazon بحل هذه المشكلة عن طريق تحويل الرسائل المتعلّقة بكل مشكلة إلى القسم المسؤول عنها حتى يبدؤوا بحلّها. حيث إنّ الوسيلة الأفضل للقضاء على المشاكل الداخلية عندما تفشل كل الطرق الأخرى هو إرسالها مُباشرة إلى صندوق البريد الإلكتروني الخاص بالمسؤول عنها..

كيف تنفذ هذه العملية

إنّ أسهل طريقة للبدء هي تصنيف رسائل العملاء حسب أسبابها الجذرية عن طريق إضافة وسوم tags إليها (يختلف الأمر حسب أداة/خدمة الدّعم الفني التي تستخدمها) سيسهّل هذا التنظيم رؤية المناطق التي تتمحور حولها أغلب أسئلة المستخدمين، كما يسهّل على مصممي ومهندسي المنتج الرؤية السريعة لنتائج عملهم. كما أنّه من المفيد وسم أو تصنيف الرسائل حسب المراحل في دورة حياة العميل لكي تتمكن من معرفة أسئلة "اليوم الأوّل" الشائعة، ثمّ الاستفادة من هذه الأسئلة في تهيئة العملاء الجدد onboarding.

ليس من الحذاقة تجاهل ما يقوله العملاء عند التركيز على تصميم المنتج، وكما يقوم David Cancel، كبير موظفي المنتجات في HubSpot:

"أطلق منتجًا مبكّرًا، لكن لا تطلق مُنتجًا غير قابل للاستخدام".

ترجمة-وبتصرّف-للمقال: How The Support Team Improves The Product لصاحبه: Des Traynor.