الإجابة المختصرة
يدير Sales Cloud صفقة تتقدم – وهي وحدة عمل تستمر لأسابيع أو أشهر، وتُقاس باحتمالية الإغلاق، وتنجح عند إغلاقها. ويدير Service Cloud طلبًا يتم حله – وهي وحدة عمل تستمر لساعات أو أيام، وتُقاس بوقت الاستجابة والحل، وتنجح عندما تُغلق بسرعة ودون تكرار.
هذا الاختلاف، وليس قائمة الميزات، هو ما يحدد الاختيار. إذا كنت تدير مسار مبيعات (Pipeline) – فSales Cloud هو المناسب. إذا كنت تدير قائمة انتظار مع اتفاقية مستوى خدمة (SLA) – فService Cloud هو المناسب. إذا كنت تدير عميلاً يشتري ويقدم شكاوى أيضًا – فكلاهما، على نفس حساب العميل (Account).
الاختلاف في المصطلحات التشغيلية
| البعد | Sales Cloud | Service Cloud |
|---|---|---|
| الكائن المركزي | الفرصة (Opportunity) | الحالة (Case) |
| دورة الحياة | أسابيع إلى أشهر | ساعات إلى أيام |
| المؤشر الرئيسي | معدل الفوز، دقة التنبؤ | الاستجابة الأولى، الحل عند الاتصال الأول (FCR)، رضا العملاء (CSAT) |
| آلية التخصيص | ملكية شخصية على المدى الطويل | توجيه ديناميكي حسب التوافر |
| مصدر العبء | عدد الصفقات النشطة | ذروات غير متوقعة عبر القنوات |
| مكون المعرفة | أدلة العمل والتسعير (Playbooks) | قاعدة معرفة مدمجة (Knowledge Base) |
السطر الأكثر أهمية هو آلية التخصيص. في المبيعات، الملكية الشخصية هي قيمة – فالعميل يريد نقطة اتصال ثابتة. في الخدمة، الملكية الشخصية هي عيب – فهي تخلق قوائم انتظار شخصية تتعطل عندما يكون الممثل في إجازة.
متى يكون الاختيار واضحًا
Sales Cloud فقط يناسب المؤسسة التي تبيع في عملية مستمرة ويكون الدعم بعد البيع فيها ضئيلاً أو يتم التعامل معه من قبل شريك – على سبيل المثال، مورد معدات يبيع من خلال موزعين ولا يدير مركز اتصال.
Service Cloud فقط يناسب المؤسسة التي يكون جميع تفاعلاتها مع العميل عبارة عن معالجة طلبات – مثل شركة خدمات تشغيلية، أو هيئة عامة، أو مورد بنية تحتية بعقود قائمة.
كلاهما مطلوب عندما يكون هناك تجديد، أو بيع إضافي (Upsell)، أو احتفاظ بالعملاء: بمجرد أن يحتاج ممثل الخدمة إلى معرفة أن العميل يمر بعملية تجديد، ويحتاج ممثل المبيعات إلى معرفة أن العميل قد فتح ثلاث حالات خطيرة هذا الشهر – يصبح الفصل عائقًا.
كيفية الربط دون تكرار البيانات
هذه هي النقطة التي تفشل فيها عمليات التنفيذ المتكاملة. القاعدة هي: Account وContact هما طبقة مشتركة واحدة. لا يوجد "عميل مبيعات" و"عميل خدمة" منفصلان.
ومن هنا تنبثق ثلاثة قرارات:
- ملكية سجل العميل – من يقوم بتحديث معلومات الاتصال، العنوان، والهيكل التنظيمي. عادةً ما يكون قسم الخدمة، لأنه يتحدث مع العميل بتواتر أكبر.
- الرؤية المتبادلة – يرى ممثل الخدمة الصفقات المفتوحة بمستوى قراءة فقط؛ ويرى ممثل المبيعات الحالات المفتوحة ومؤشر رضا العملاء. يتم تحديد كلا الاتجاهين في نموذج المشاركة (Sharing Model)، وليس عن طريق نسخ الحقول.
- المحفزات الشاملة (Cross-domain triggers) – حالة حرجة لدى عميل يمر بعملية تجديد تولد تنبيهًا لمدير الحساب. هذه الآلية أكثر قيمة من أي لوحة تحكم متكاملة.
يتوفر تفصيل حول موضوع الأذونات والرؤية في نموذج المشاركة والرؤية في Salesforce.
الترخيص: ما يجب معرفته قبل مقارنة الأسعار
ترخيص Service Cloud شامل للمجموعات – فهو يتضمن القدرات الأساسية لـ Sales Cloud، وبالتالي فإن المستخدم الذي يحتاج إلى كليهما لا يحتاج إلى ترخيصين. الاتجاه المعاكس غير موجود: ترخيص Sales لا يتضمن إدارة الحالات (Case management)، أو المؤهلات (Entitlements)، أو قاعدة المعرفة (Knowledge).
المعنى العملي: يبدأ حساب التكلفة الصحيح بتصنيف المستخدمين بناءً على ما يقومون به بالفعل، وليس بناءً على القسم الذي ينتمون إليه. الممثل الذي يتفاعل مع الصفقة مرتين في السنة ليس مستخدم مبيعات.
ترتيب التنفيذ عند الحاجة إلى كليهما
يبدو التنفيذ المتوازي فعالاً ولكنه في الواقع يضاعف المخاطر: عمليتان تتغيران في وقت واحد، مجموعتان من المستخدمين في التدريب، وعدم القدرة على إرجاع التحسين أو الفشل إلى مصدره.
الترتيب الموصى به هو البدء بالجانب الذي يعاني من الألم الأكثر قابلية للقياس – عادةً الخدمة، لأن وقت الاستجابة ومعدل التوقف يتم قياسهما بالفعل – وإضافة الجانب الآخر بعد شهرين من التشغيل المستقر. يتم بناء الطبقة المشتركة (Account، Contact، الأذونات) في المرحلة الأولى حتى لو تم إطلاق جانب واحد فقط، وإلا فإن المرحلة الثانية ستتطلب إعادة الهيكلة.
الملخص
السؤال ليس أي منتج أفضل، بل ما هي وحدة العمل التي تديرها المؤسسة: صفقة تتقدم أم طلب يتم حله. معظم المؤسسات الناضجة تدير كليهما، وعندئذٍ لا يكون القرار الحقيقي هو ماذا تشتري، بل كيف تحافظ على طبقة عميل واحدة تحت كليهما.
