قد يُغلِق فريق الدعم الطلب، بينما يشعر العميل أن المشكلة ما زالت موجودة. وإذا اكتفينا بسؤاله عن رِضاه، فقد نحصل على درجة مرتفعة لأنه يُقدِّر تعامل الموظف، وهذا سيؤدي إلى أننا نفهمها خطأً باعتبارها دليلًا على نجاح الحَلّ.
استبيان رِضا العملاء يساعدك على فهم تقييم العميل لتجربة مُحدَّدة، مثل شراء مُنتَج أو التواصل مع الدعم. لكن السؤال عن الرِضا وحده قد يتركك أمام رقم لا تعرف كيف تستفيد منه. في حالة الدعم، نحتاج أيضًا إلى معرفة ما إذا كانت المشكلة قد حُلَّت، ثم قراءة السبب الذي يذكره العميل لتقييمه، أي أننا نحتاج لتقييم الرضا بطريقة مختلفة.
ابدأ بالقرار قبل الأسئلة
لنفترض أن عميلًا تواصل مع الدعم لأنه لا يستطيع الدخول إلى حسابه. عدَّل الموظف إعدادات الحساب، ثم أغلق طلب الدعم وأرسل رسالة تقول: «تمّت معالجة طلبك». لكن الرسالة لم تُوضِّح للعميل ما الذي تغيَّر، وهل عليه محاولة الدخول مجددًا، وكيف يطلب المساعدة إذا استمرّت المشكلة.
يريد الفريق معرفة ما إذا كانت هذه التجربة قد ساعدت العميل فعلًا. لذلك يُرسِل استبيانًا قصيرًا يسأله عن رِضاه عن التعامل مع الدعم، وهل أصبح يستطيع الدخول إلى حسابه، وما السبب الرئيسي لتقييمه. قد يكون العميل راضيًا عن تعاون الموظف، رغم أن مشكلة الدخول لم تُحَلّ. وقد تكون المشكلة انتهت، لكن رسالة الإغلاق تركته غير متأكد مما يجب فعله بعدها.
قبل كتابة الأسئلة، حدِّد كيف ستستفيد من الإجابات. في مثالنا، يمكن للفريق تحسين رسالة الإغلاق لتشرح الخطوة التالية، أو مراجعة طريقة التأكّد من حَلّ المشكلة قبل إغلاق الطلب. أما السؤال عن سهولة شراء الاشتراك، فلا يساعد على فهم تجربة الدعم التي نراجعها هنا.
سنستخدم هذه الحالة الافتراضية لبناء الاستبيان وتحليل ردوده. وستساعدنا الإجابات على فهم تجربة العميل من وجهة نظره. وإذا ذكر أنه لم يعرف كيف يُكمِل الخطوات، فقد نحتاج أيضًا إلى ملاحظة محاولته لمعرفة موضع الصعوبة. يشرح مقال قابلية الاستخدام كيف نستفيد من هذه الملاحظة في تحسين التصميم.
متى ترسله ولمن؟
نُرسِل الدعوة بعد إبلاغ العميل بنتيجة معالجة طلبه، حتى يكون قد اطّلع على الرد الذي نريد تقييمه. ولهذا نسأله عن الحَلّ أيضًا؛ فقد يُغلِق الفريق الطلب في نظامه بينما يبقى جزء من المشكلة لدى العميل.
حدِّد الفئة قبل الإرسال: عملاء عُولِجت طلباتهم خلال الفترة المختارة، عبر قناة الدعم التي تراجعها. استبعد الرسائل الآلية والطلبات المكررة، وقرِّر مسبقًا كيف تتعامل مع عميل لديه عدة طلبات، حتى لا تزعج العميل دون قصد.
يمكن أن تكون الدعوة: «نَوَدّ معرفة رأيك في معالجة طلب الدعم الأخير، سواء حُلَّت المشكلة أم بقي جزء منها. المشاركة اختيارية، وإجابتك تساعدنا على مراجعة الخدمة». اجعل رابط العودة إلى الدعم واضحًا؛ فالاستبيان لا ينبغي أن يكون الطريق الوحيد لطلب المساعدة.
لا تُرسِل الدعوة فقط لمن شكر الموظف، ولا تختَر العملاء الأسهل وصولًا ثم تَصِفهم بأنهم جميع العملاء. قد تختلف تجربة الذين استجابوا عن الذين تجاهلوا الرسالة، لذلك احتفظ بعدد العملاء المدعوين وقناة الإرسال ومدة جمع الردود عند عرض النتيجة.
نموذج أسئلة جاهز للإستخدام
تَظهر الأسئلة الثلاثة الأولى للجميع، وتبقى الإجابة عنها اختيارية. لا يحتاج هذا النموذج إلى اسم العميل أو هاتفه؛ وإذا أردت التواصل معه بشأن تعليقه، فاطلب إذنًا مستقلًا لذلك.
السؤال الأول: درجة الرِضا
ما مدى رِضاك عن تجربة معالجة طلب الدعم الأخير؟
1: غير راضٍ إطلاقًا.
2: غير راضٍ.
3: لا راضٍ ولا غير راضٍ.
4: راضٍ.
5: راضٍ جدًا.
اِعرِض الكلمات بجوار الأرقام؛ فالدرجة الثالثة، مثلًا، تعني موقفًا محايدًا في هذا المقياس، وليست رِضا متوسطًا نَضُمّه تلقائيًا إلى الإجابات الإيجابية. راجِع أيضًا ترتيب الخيارات على الهاتف، حتى يعرف الشخص معنى اختياره دون تخمين.
السؤال الثاني: نتيجة المعالجة
هل حُلَّت المشكلة التي تواصلت بشأنها؟
نعم.
جزئيًا.
لا.
غير متأكد.
نُحلِّل هذا السؤال منفصلًا عن الرِضا. فقد يختار العميل «راضٍ» عن التواصل، لكنه يجيب «جزئيًا» عن الحَلّ. لو جمعنا الأمرين في سؤال «هل أنت راضٍ عن سرعة الدعم وحَلّ المشكلة؟»، فلن نعرف أي جزء قيَّمه.
السؤال الثالث: تفسير التقييم
ما السبب الرئيسي لتقييمك؟
حقل نَصِّي اختياري، يساعد على فهم ما كان مهمًا للعميل دون اقتراح سبب مسبق. لا تضع داخله أمثلة مثل «سرعة الموظف أو لطفه»، لأنها قد تُوجِّه الإجابة نحو أمور اختارها الفريق بدل ما يريد العميل قوله.
السؤال الرابع: ما بقي دون حَلّ؟
ما الذي بقي دون حَلّ؟
يَظهر هذا الحقل الاختياري فقط لمن اختار «جزئيًا» أو «لا». غرضه تحديد الجزء المتبقي، لا إعادة سؤال الرِضا. لا تعرضه لمن ترك سؤال التقييم فارغًا، ولا تُفسِّر الفراغ باعتباره حلًا كاملًا.
تنسجم هذه الصياغة مع إرشادات Pew Research Center لكتابة الأسئلة: سؤال واضح لكل مفهوم، وخيارات مفهومة، وتجنّب الصياغة الموجِّهة.

كيف تحسب نسبة الرِضا؟
نفترض إرسال دعوات بالبريد إلى 200 عميل مُؤهَّل بين 1 و 7 سبتمبر 2026، وإغلاق جمع الردود في 10 سبتمبر. وصل 90 نموذجًا، وأجاب 80 شخصًا عن سؤال الرِضا، بينما تركه عشرة أشخاص فارغًا.
جدول من 6 صفوف
درجة الرِضا | عدد الإجابات |
|---|---|
غير راضٍ إطلاقًا | 4 |
غير راضٍ | 6 |
لا راضٍ ولا غير راضٍ | 10 |
راضٍ | 35 |
راضٍ جدًا | 25 |
مجموع الإجابات الصالحة | 80 |
لحساب مُؤشِّر رِضا العملاء (CSAT)، نبدأ بمن اختاروا «راضٍ» أو «راضٍ جدًا». في مثالنا، اختار 35 شخصًا «راضٍ»، واختار 25 شخصًا «راضٍ جدًا». أي أن 60 شخصًا من أصل 80 أجابوا عن سؤال الرِضا كانت إجاباتهم إيجابية.
نسبة الرِضا = 60 ÷ 80 × 100 = 75%.
هذه النسبة تعني أن ثلاثة من كل أربعة أشخاص أجابوا عن السؤال كانوا راضين عن تجربة الدعم. ويمكن مراجعة دليل Qualtrics لحساب CSAT للتعرّف إلى طريقة الحساب.
لماذا قسمنا على 80؟ لأن هذا هو عدد الذين أجابوا عن سؤال الرِضا. أرسلنا الاستبيان إلى 200 عميل، ووصلنا 90 نموذجًا، لكن عشرة أشخاص تركوا هذا السؤال فارغًا. لا نعرف تقييمهم، لذلك لا نحسبهم ضمن الراضين أو غير الراضين.
هل الرِضا يعني أن المشكلة حُلَّت؟
لننظر إلى إجابات السؤال الآخر: «هل حُلَّت المشكلة التي تواصلت بشأنها؟». أجاب عنه 88 شخصًا:
60 شخصًا: نعم.
12 شخصًا: جزئيًا.
8 أشخاص: لا.
8 أشخاص: غير متأكد.
هذه الإجابات تُوضِّح لماذا لا تكفي نسبة الرِضا وحدها. فقد يكون العميل راضيًا عن تعاون الموظف، بينما بقي جزء من مشكلته دون حَلّ. ولا نفترض أن الأشخاص الستين الذين حُلَّت مشكلاتهم هم أنفسهم الستون الذين عبَّروا عن رِضاهم؛ لمعرفة ذلك، نراجع إجابة كل شخص عن السؤالين معًا.
كذلك، لا يجيب الجميع عن الأسئلة الاختيارية. كتب 35 شخصًا تعليقًا عامًا، وأجاب 12 من أصل 20 شخصًا عن سؤال «ما الذي بقي دون حَلّ؟». نستفيد مما كتبوه لفهم التفاصيل، لكن ترك السؤال فارغًا لا يعني أن التجربة كانت جيدة أو أن المشكلة انتهت.
كيف نستفيد من النتيجة؟
نسبة 75% تصف إجابات هذه المجموعة في هذه الفترة. لكنها لا تخبرنا وحدها بسبب عدم رِضا الآخرين، ولا تُثبِت أن الخدمة تحسَّنت.
لمعرفة ما يحتاج إلى تحسين، نقرأ التعليقات وإجابات سؤال حَلّ المشكلة. وإذا أردنا مقارنة الرِضا بفترة لاحقة، نحافظ قدر الإمكان على السؤال وخيارات الإجابة وموعد إرسال الاستبيان بالنسبة إلى تجربة الدعم. ونراجع أيضًا ما إذا كان نوع الطلبات أو قناة الدعم قد تغيَّر، لأن ذلك قد يؤثر في المقارنة.

اقرأ التعليقات دون اختصار معناها
اقرأ التعليقات قبل عَدّ موضوعاتها. عبارة «انتظرت طويلًا ولم أفهم الرد» تتناول أمرين: الانتظار ووضوح الإجابة. احتفظ بالأمرين عند تصنيفها، واكتب تعريفًا قصيرًا لكل موضوع يستخدمه الفريق، حتى لا تُجمَع مشكلة الرد المتأخر مع مشكلة الرد غير المفهوم.
هذه أربعة تعليقات من البيانات التي وصلتنا في مثالنا:
01: الخطوة التالية غير واضحة
التقييم: كتب العميل: «أغلقتم الطلب ولم أعرف ماذا أفعل بعدها». عبارة «لم أعرف ماذا أفعل» تشير إلى صعوبة في معرفة الخطوة التالية، وقد تعني أن رسالة الإغلاق غير كافية.
ما نراجعه: هل تضمَّنت الرسالة إجراءً واضحًا؟ يراجع مسؤول المحتوى صياغتها، ثم نتابع فهم العميل للخطوة التالية.
02: تعامل جيد، لكن الحَلّ غير مكتمل
التقييم: كتب العميل: «الموظف متعاون، لكن المشكلة ما زالت موجودة». الدليل هنا هو «المشكلة ما زالت موجودة»؛ فقد يخصّ الرِضا تعامل الموظف، دون أن يعني اكتمال الحَلّ.
ما نراجعه: إجابة سؤال الحَلّ وسِجلّ الطلب المسموح بمراجعته. يراجع قائد الدعم إجراء الإغلاق، ونتابع إعادة فتح الطلبات للسبب نفسه.
03: تعليق لا يكفي لتفسير التقييم
التقييم: كتب العميل: «مقبول». هذه الكلمة وحدها لا تُوضِّح سبب التقييم أو موضوعه، ولا تكفي لاختيار تحسين.
ما نراجعه: هل تُتاح متابعة مع العميل بموافقة مستقلة؟ لا نُقرِّر تعديلًا اعتمادًا على العبارة وحدها.
04: طلب المعلومات نفسها مرة أخرى
التقييم: كتب العميل: «انتظرت ردًا ثم طُلِبت مني المعلومات نفسها». عبارة «المعلومات نفسها» تشير إلى التكرار. قد تكون البيانات لا تنتقل بين الموظفين، لكننا نحتاج إلى فحص انتقال الطلب قبل الجزم بالسبب.
ما نراجعه: يراجع مسؤول التشغيل تسليم الطلب بين الموظفين، ونتابع تكرار طلب البيانات التي سبق إرسالها.
احتفظ بالنَصّ الذي يدعم تفسيرك. عبارة 02 لا تعني أن العميل أخطأ في التقييم، ولا يجوز تحويل درجته إلى درجة أقل لتناسب التعليق. هذا الاختلاف نفسه معلومة تستحق الفحص.
ترك خانة التعليق فارغة لا يعني أن العميل لم يواجه مشكلة؛ فقد يحتاج السؤال إلى وقت أو جُهد لا يرغب في بذله. تناقش دراسة Pew كيف يؤثر ذلك في الإجابة عن الأسئلة المفتوحة.
من الملاحظة إلى تحسين واحد
لنأخذ التعليق «أغلقتم الطلب ولم أعرف ماذا أفعل بعدها». الخطوة الأولى هي الرجوع إلى الرسالة التي وصلت إلى العميل. إذا كانت تكتفي بعبارة «تمت معالجة طلبك»، فمن الطبيعي أن نحتاج إلى تفاصيل أكثر عمّا تعنيه المعالجة في حالته.
يمكن أن تكون الصياغة المُقترَحة لحالة افتراضية: «حدَّثنا إعدادات حسابك. جرِّب تسجيل الدخول الآن، وإذا استمرت المشكلة فرُدّ على هذه الرسالة لنُتابع الطلب نفسه». تَذكر الرسالة ما أُنجِز، وما يحتاج العميل إلى فعله، وكيف يعود إلى الدعم. يجب أن يطابق هذا الوصف ما حدث فعلًا، وأن يكون الرد على الرسالة متاحًا.
يراجع مسؤول المحتوى الصياغة مع قائد الدعم، ثم يَعرِضها على أشخاص مناسبين ويسألهم عمّا فهموه وما سيفعلونه بعدها. وعند اعتمادها، يُتابِع الفريق الردود وإعادة فتح الطلبات في سياق متقارب. الهدف التحقّق من وضوحها، لا افتراض نجاحها لمجرد أنها أصبحت أطول.
وإذا كشف الفحص أن الموظف يُغلِق الطلب قبل إنجاز المعالجة، فلن يكفي تحسين الرسالة. عندها ينتقل القرار إلى إجراء الدعم نفسه. قيمة الاستبيان أنه دلّنا على سؤال مُحدَّد، ثم احتجنا إلى دليل آخر لمعرفة السبب.
قبل إرسال الاستبيان
جرِّبه أولًا مع أشخاص يشبهون جمهورك، واطلب منهم شرح ما فهموه من كل سؤال. راجِع أيضًا ظهوره على الهاتف، وسهولة تخطي السؤال الاختياري، وشرط ظهور المتابعة، قبل إطلاقه على الفئة المستهدفة.
عندما تصلك الردود، اختر منها مشكلة يستطيع فريقك متابعتها، وحدِّد من سيراجعها ومتى ستعودون إليها. بهذه الطريقة يبقى الاستبيان مرتبطًا بالخدمة التي يعيشها العميل، ولا ينتهي العمل عند مشاركة نسبة الرِضا في تقرير.
المصادر
تاريخ النشر
9 أكتوبر 2026
آخر تعديل
9 أكتوبر 2026



