تطبيق Sales Cloud: عملية صحيحة من Lead إلى Forecast

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

يكمن الفرق بين تنفيذ Sales Cloud الناجح والفاشل دائمًا تقريبًا في سؤال واحد: هل يمكن القول، في جملة واحدة ودون جدال، ما الذي ينقل الصفقة من مرحلة إلى أخرى. عندما تكون الإجابة موجودة، فإن الباقي – الشاشات، الحقول، الأتمتة والتقارير – يُستمد منها. وعندما تكون غائبة، تحصل على نظام مُعرَّف جيدًا ينتج توقعات لا يثق بها أحد.

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

أين تظهر المشكلة فعليًا

في مؤسسة B2B نموذجية، قبل أي تدخل، قد نرى الوضع كالتالي: 40% من الصفقات في مسار المبيعات (Pipeline) قد تجاوزت تاريخ الإغلاق المحدد، ومرحلة "التفاوض" تشمل كلًا من المحادثات الأولية والعقود قيد التوقيع، ومدير المبيعات يدير التوقعات في جدول بيانات منفصل لأنه لا يثق بالنظام. لا تعتبر أي من هذه المشكلات خللاً فنيًا – بل هي جميعًا نتيجة لتعريفات لم يتم حسمها.

مراحل المبيعات: معيار خروج لكل مرحلة

القاعدة البسيطة: يتم تعريف المرحلة بما فعله المشتري، وليس بما يشعر به البائع. "العميل مهتم" ليس معيارًا. "تم تحديد صانع قرار وتم تخصيص ميزانية" هو كذلك.

الاحتمالية (Probability) ليست شعور المندوب بل هي مشتقة من المرحلة. بمجرد السماح للمندوب بتعديلها يدويًا، يصبح التوقع شخصيًا مرة أخرى.

Lead مقابل Opportunity: الحد الذي يحدد جودة مسار المبيعات (Pipeline)

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

تعريف عملي: يبقى Lead Lead حتى تتحقق ثلاثة شروط – جهة اتصال محددة ذات سلطة، حاجة مصاغة بكلمات العميل، وأفق زمني معين. يتم إدارة الاستفسار الذي لا يفي بذلك كـ Lead في مرحلة Nurture، وليس كصفقة. هذا أيضًا ما يسمح بقياس معدل التحويل بين التسويق والمبيعات بشكل حقيقي بدلاً من قياس سخاء التحويل.

سيجد من يقوم ببناء نموذج البيانات وراء ذلك خلفية في تصميم نماذج بيانات Salesforce.

الأنشطة (Activities): إلزام القليل، في الأماكن الحاسمة

يُعد توثيق النشاط هو النقطة التي تفقد فيها عمليات التنفيذ ثقة المندوبين. فإلزام التوثيق لكل تفاعل يُنظر إليه على أنه مراقبة، ويُرد عليه بتوثيق بسيط عديم القيمة، وينتج بيانات أسوأ من عدم التوثيق.

النهج الفعال هو الإلزام بالتوثيق في ثلاث نقاط فقط: الانتقال بين المراحل، تغيير المبلغ فوق حد معين، وتأجيل تاريخ الإغلاق. في كلٍ من هذه النقاط، يخدم التوثيق المندوب نفسه أيضًا – فهو يوضح قرارًا سيُسأل عنه في الاجتماع. مزامنة البريد الإلكتروني والتقويم التلقائية تغطي الباقي دون الحاجة إلى الطباعة.

التوقعات (Forecast): ما يجب أن يكون جاهزًا قبل التشغيل

يتطلب التنبؤ الموثوق به أربعة شروط مسبقة، وكلها تتصرف كسلسلة – الحلقة المفقودة تلغي البقية:

1. تسلسل هرمي للمستخدمين صحيح - Forecast في Salesforce يُحسب وفقًا لـ Role Hierarchy، وليس وفقًا لهيكل تنظيمي في جدول بيانات.
2. تواريخ إغلاق نظيفة - قاعدة تشغيلية لا تسمح للصفقة بالبقاء بتاريخ منتهي لأكثر من أسبوع.
3. فئات توقعات محددة (Forecast Categories) - Pipeline، Best Case، Commit، Closed - مع تعريف متفق عليه لمن ينقل الصفقة إلى Commit ومتى.
4. دورة مراجعة منتظمة - اجتماع أسبوعي لمسار المبيعات (Pipeline) يُدار من داخل النظام وليس من جدول بيانات موازٍ.

النقطة الأخيرة هي الحاسمة. ما دامت هناك جداول بيانات "خفية"، يعلم المندوبون أن النظام ليس مصدر الحقيقة ويقومون بتحديثه متأخرًا.

ما يجب قياسه بعد الانطلاق

تتوفر مقاييس اعتماد (Adoption) أكثر تفصيلاً في مقاييس اعتماد Salesforce.

ما لا يجب فعله في المرحلة الأولى

إدارة الأقاليم (Territory Management) المعقدة، ونماذج التوقعات المتعددة (multiple Forecast models)، وCPQ الكامل، والتسجيل التلقائي (Automatic Scoring) هي كلها قدرات من الصواب إضافتها – بعد أن تستقر العملية الأساسية وتمر دورتين مبيعات. إضافتها في المرحلة الأولى ترسخ افتراضات لم يتم اختبارها بعد، وتزيد تكلفة أي تغيير مستقبلي بشكل كبير.

الخلاصة

إن تنفيذ Sales Cloud هو في الأساس مهمة تحديدات أعمال: متى تنتقل الصفقة إلى المرحلة التالية، متى يصبح الاستفسار صفقة، وما الذي يتطلب التوثيق. تحدد هذه القرارات الثلاثة ما إذا كان التوقع سيكون أداة إدارية أم مجرد تمرين لإعداد التقارير. ستدعم الأداة نفسها أي تعريف تختاره – بما في ذلك التعريف السيئ.