العميل مش محتاج يسمع «هنرد عليك قريب» كل يوم
لو شكوى العميل اتسجلت واترد عليها بسرعة، لكن فضلت مفتوحة من غير مسؤول أو موعد تحديث، فمؤشر سرعة أول رد هيبان ممتاز بينما تجربة العميل سيئة. لازم تفرق بين موعد الرد الأول، وموعد التحديث التالي، والموعد المستهدف لحل المشكلة.
اتفاق مستوى الخدمة، أو SLA، هو تعريف داخلي واضح لما يلتزم به الفريق حسب نوع الحالة. مش لازم تبدأ بوعد معلن لكل العملاء. ابدأ أولًا بتحديد مسؤول ومواعيد قابلة للتنفيذ، ثم راقب الالتزام قبل ما تحولها لتعهد خارجي.
ليه الشكوى الواحدة محتاجة أكثر من ساعة؟
تخيل متجرًا عنده عميل دفع لطلب ولم يستلمه، وعميلًا ثانيًا يسأل عن لون منتج. الاتنين وصلوا على واتساب في نفس الوقت، لكن الضرر المحتمل مش واحد.
قسّم الحالات إلى عاجلة لو فيها موعد قريب أو أثر مالي أو أمني، ومهمة لو فيها خدمة متأخرة أو شكوى تحتاج تنسيقًا، وعادية للاستفسارات التي يمكن جدولتها. ده تصنيف تشغيلي مقترح، مش معيارًا قانونيًا ولا SLA مفروضًا على كل شركة.
لكل فئة حدد أربع خانات: صاحب الحالة، وقت الرد الأول، موعد التحديث القادم، ومتى تنتقل إلى مسؤول أعلى. لا تكتب «تم الحل» لمجرد إن الموظف أرسل رسالة.
نموذج بسيط لسجل التصعيد
| الحقل | معناه |
|---|---|
| رقم الحالة | مرجع ثابت لا يتغير بتغير الموظف |
| الأولوية | عاجلة أو مهمة أو عادية مع سبب |
| المسؤول | شخص واحد يتابع الخطوة التالية |
| آخر تحديث | آخر معلومة مؤكدة وصلت للعميل |
| موعد المراجعة | وقت التحقق التالي، وليس وعدًا آليًا بالحل |
| سبب التأخير | انتظار شركة شحن أو قسم مالي أو قرار إداري |
| مسار التصعيد | من يتدخل لو فات الموعد |
| إثبات الإغلاق | ما الذي يؤكد انتهاء المشكلة فعلًا |
اكتب تعريفًا لساعة العمل: هل تحسب مواعيد الرد خلال ساعات الدوام أم على مدار اليوم؟ لو ما وضحتش ده، هتطلع تقارير غير عادلة وتوقعات متضاربة.
إزاي تعمل Escalation بدون زحمة رسائل؟
في نهاية كل وردية، راجع الحالات اللي موعدها قرب أو فات. لو الحالة متأخرة، انقلها لمسؤول محدد مع آخر إجراء تم، بدل رسالة جماعية تقول «حد يتابع». لو الحل مع قسم آخر، خليه يملك خطوة داخلية واضحة، لكن مسؤول التواصل مع العميل يفضل معروفًا.
الرسالة المفيدة للعميل تقول: إيه اللي اتأكدنا منه، إيه اللي لسه قيد المراجعة، ومتى هنبعت تحديثًا جديدًا. ما توعدش بموعد حل نهائي إلا لو عندك أساس حقيقي.
مثال افتراضي: عميل يسأل عن استرجاع مبلغ. موظف الدعم يثبت رقم الطلب وحالة الطلب، ثم يحيل الموضوع للفريق المالي. موعد التحديث التالي يفضل واضحًا حتى لو تاريخ رد المبلغ نفسه لسه مش مؤكد. المثال ده طريقة تنظيم، مش وصف لعميل Mr. AI.
ثلاثة مقاييس أفضل من سرعة الرد وحدها
راقب نسبة الحالات التي لها مسؤول واضح، ونسبة التحديثات التي وصلت في موعدها، ومدة حل الشكاوى المغلقة. اعرض أيضًا عدد الحالات المفتوحة حسب عمرها، حتى لا تختفي الحالات الصعبة وراء متوسط جميل.
ISO 10002:2018 يقدم إرشادات عالمية لإدارة شكاوى العملاء والتحسين المستمر، لكنه لا يفرض أوقات رد محددة لكل شركة. لا تنقل أرقام SLA من نشاط آخر وتقدمها كمعيار لمصر.
أين يساعد Mr. AI وأين يحتاج الفريق يتدخل؟
توضح الأسئلة الشائعة أن Mr. AI يساعد في الرد بمعرفة الشركة، وعرض المحادثات وملخصاتها، والمتابعة والتسليم لموظف بشري عند الحاجة. لكن ده لا يثبت وجود محرك SLA أو تنبيه تصعيد زمني مخصص في المنتج. لو محتاج الوظيفة دي، اختبرها صراحة أو استخدم سجلًا تشغيليًا خارجيًا قبل الاعتماد عليها.
لو لسه بتبني خطوات استقبال الشكوى نفسها، ابدأ بـدليل معالجة الشكاوى على واتساب. ولو عندك ورديات، اقرأ دليل تسليم الشيفت.
خطوة عملية هذا الأسبوع: اختَر عشر شكاوى مفتوحة، وحدد لكل واحدة المسؤول وموعد التحديث والتصعيد. بعد أسبوع راجع الحالات اللي اتأخرت، واسأل هل السبب عدم وضوح المسؤولية ولا انتظار معلومة ولا وعد غير واقعي. بعدها جرّب Mr. AI في جزء الرد والمتابعة، واحتفظ بقرار التصعيد البشري مع فريقك.
المصدر: ISO 10002:2018، إصدار يوليو 2018 ومؤكد استمراره في مراجعة 2023. إرشاد عالمي لا يقدم متوسطات أداء مصرية.
