تطبيق Service Cloud: الحالات، اتفاقيات مستوى الخدمة، التوجيه، والمعرفة

الإجابة المختصرة

إن Service Cloud لا يقلل من أوقات الاستجابة بمفرده. بل يفرض الإعدادات التي قمت بتكوينها. إذا لم يتم تحديد تعريف Case، ومن يستقبله، ومتى يتم احتساب الوقت – فإن النظام سيقوم بقياس عملية غير محددة بدقة، وستبدو المقاييس أفضل من الواقع أو أسوأ منه، دون علاقة بالخدمة الفعلية.

تحدد أربع قرارات رئيسية النتيجة: تعريف Case، نموذج التخصيص، ساعة SLA، ومكان المعرفة. أما بقية التنفيذ – مثل الشاشات، القنوات، والأتمتة – فتنبثق عنها.

القرار 1: ما الذي يُعتبر Case

تُنشئ العديد من مراكز الاتصال Case لكل تفاعل بحجة "للحصول على بيانات". لكن النتيجة تكون عكسية: آلاف السجلات التي تُغلق في دقيقة تضخم الحجم، تحسن بشكل مصطنع متوسط وقت الحل، وتخفي الاستفسارات التي تواجه بالفعل صعوبات.

التعريف الفعال يميز بين ثلاثة أنواع:

القرار 2: من يستقبل الاستفسار

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

نموذج التخصيص الصحيح يحدد ثلاثة أبعاد: المهارة المطلوبة، السعة الفعلية للموظف (وليس عدد Cases بل الوزن)، وقواعد التصعيد القائمة على الوقت. يدعم Omni-Channel Routing الأبعاد الثلاثة، ولكن فقط إذا تم تعريف المهارات الحقيقية. تعريف "مهارة: دعم" لجميع الموظفين يعادل عدم التعريف.

للحصول على تفاصيل كاملة حول التخصيص متعدد القنوات، يرجى زيارة Omnichannel و-SLA في Service Cloud.

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

هذا هو القرار الذي تتجاهله معظم المؤسسات، وهو الذي يحدد مصداقية المقاييس. يجب الإجابة كتابيًا على الأسئلة التالية:

1. متى يبدأ احتساب الوقت – عند استلام الاستفسار أم عند بداية ساعات العمل التالية؟ يجب تعريف Business Hours لكل منطقة زمنية ذات صلة.
2. متى يتوقف – يجب تجميد عداد Case الذي ينتظر رد العميل، وإلا فإن مركز الاتصال يعاقب على تباطؤ العميل.
3. ما الذي يتم قياسه بالضبط – وقت الاستجابة الأول، وقت الحل، أم كلاهما مع أهداف منفصلة لكل مستوى خطورة.
4. ماذا يحدث قبل التجاوز – Milestone الذي ينشئ تنبيهًا عند 80% من الوقت المخصص أفضل من تقرير التجاوزات الشهري.

تُطبق Entitlements وMilestones هذه النقاط الأربع. تفعيلها دون قرار مكتوب مسبقًا ينتج عنه تنبيهات يتم تجاهلها في غضون أسبوعين.

القرار 4: أين توجد المعرفة

قاعدة المعرفة (Knowledge Base) ليست مشروعًا منفصلاً بل هي شرط لتقليل العبء. الفشل المعتاد: تُكتب المقالات عند الإطلاق، ولا يقوم أحد بتحديثها، وفي غضون ستة أشهر، يعود الموظفون للسؤال عبر الدردشة الداخلية.

ما ينجح: دورة حياة محددة لكل مقال – مالك (Owner)، تاريخ إعادة المراجعة، ومقياس الاستخدام. يُعد Case الذي يُغلق دون مقال مرتبط ويظهر خمس مرات في نفس الربع دافعًا تلقائيًا لإنشاء مقال. تُعرض تفاصيل أعمق حول هذا الموضوع في إدارة المعرفة في Salesforce.

مقاييس التشغيل

معدل إعادة الفتح (Reopen rate) هو المقياس الأكثر أهمية وعادة ما يكون الأكثر إهمالاً: فهو يكشف عن الإغلاقات المبكرة التي تتم لتحقيق هدف الوقت.

ترتيب العمل الموصى به

الموجة الأولى: تعريف Case، قناة أو اثنتين، توجيه أساسي، SLA لمستوى خطورة واحد، وعشرة مقالات Knowledge للاستفسارات الشائعة. الموجة الثانية: قنوات إضافية، مهارات، Entitlements كاملة، Self-Service. تفعيل كل شيء دفعة واحدة ينتج عنه مركز يقوم بمعالجة تغيير العملية، تغيير الأدوات، وتغيير القياس في نفس الأسبوع – وعادة ما يعود إلى العمل بطريقة التفافية.

الخلاصة

يُقاس نجاح تنفيذ Service Cloud بسؤال واحد: هل يستطيع مدير مركز الاتصال أن يظهر، من النظام وبدون جدول مساعد، أين توجد الاستفسارات التي تتجاوز المعايير ولماذا. إذا تم الانتهاء من القرارات الأربعة، فإن الإجابة موجودة. إذا لم يكن كذلك، فهناك نظام جديد ونفس مركز الاتصال.