HubSpot أم Salesforce: الاختيار الذي يسبق الاختيار

HubSpot أنسب حين تكون الصفقة قمعًا واحدًا يحركه التسويق والمبيعات معًا، ويستطيع مستخدم أعمال متمكن إدارة الأداة بنفسه. وSalesforce أنسب حين تختلف العملية بحسب المنتج أو الشريحة أو الفرع، ويكون هناك من يتقاضى أجرًا مقابل ملكية المنصة. ولأغلب الفرق الصغيرة عندنا ليس أي منهما السؤال الأول، بل هل توجد عملية تستحق الضبط؟ وحين توجد، يبدأ هذا الاختيار.

ماذا يفترض كل منهما عن عملية البيع؟

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

وSalesforce يفترض مواصفة. الكائنات القياسية موجودة — العملاء المحتملون، والحسابات، وجهات الاتصال، والفرص — ولا شيء يُفرض منها حتى يقرر أحد أنه يجب: أنواع السجلات، وتخطيطات الصفحات، وقواعد التحقق، ومجموعات الصلاحيات، والمسارات الآلية. هي منصة بنموذج بيانات تكتبونه.

ثم يسأل كل منهما سؤاله: HubSpot يسأل «هل تناسب صفقتنا هذا الشكل؟»، وSalesforce يسأل «ما هي صفقتنا، ومن يكتبها؟». والثاني سؤال أفضل، وجوابه أغلى.

من يديره في الشهر السادس؟

في HubSpot المدير عادةً من يدير التسويق أو عمليات البيع: إضافة خاصية، وبناء مسار عمل، وقراءة تقرير، كلها في الإعدادات وبمتناول من يفكر بلغة العمل.

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

السؤال ليس أيهما أصعب، بل هل يوجد الدور. وحين لا يُسمى أحد، تُضبط المنصة مرة وتتجمد: مخصصة، مكلفة، لا يقرأها أحد.

أين يسكن التخصيص؟

تخصيص HubSpot يسكن الخصائص والمسارات وقوالب الرسائل: سطحي، وهذا مقصود. تغيّرون ما يُسجَّل، لا النموذج الذي تحته.

وتخصيص Salesforce يسكن المخطط والأتمتة فوقه، ويتراكم: الكائن الخامس، والمسار الذي يعمل عند تغير المرحلة، وقاعدة التحقق التي تجعل الموافقة شرطًا — كل واحد قرار يحتاج صيانة وتوثيقًا بعد اليوم. والطبقة السطحية سريعة التعلم ورخيصة التغيير، والعميقة تعبّر عن العملية بدقة وتصبح سبب صعوبة الخروج منها.

كيف يبدو الخروج؟

من HubSpot تخرج الكائنات القياسية وخصائصها عبر الواجهة وتصدير CSV في شكل يعرفه نظام آخر. وما ينتقل بصعوبة هو الخط الزمني: الرسائل والمكالمات والملاحظات. والمسارات لا تنتقل، لكنها كانت سطحية.

ومن Salesforce تخرج الكائنات القياسية عبر التقارير وخدمة تصدير البيانات، وتحتاج الكائنات المخصصة عملًا خاصًا، ولا ينتقل المخطط ولا المسارات ولا الشيفرة. والجزء الذي فيه أكثر تفكير هو الجزء الذي يبقى.

النظام الأرخص خروجًا هو الذي يحمل أقل من عمليتكم. وحين يكون الخروج مهمًا — لشركة قد تُباع أو تُعاد هيكلتها — فالعمق عبء بقدر ما هو ميزة.

الاختيار الذي يسبق الاختيار

بالنسبة لفريق صغير في الجزائر، السؤال الأول ليس HubSpot أو Salesforce. بل هذه الخمسة:

1. هل توجد عملية مكتوبة: مراحل مسمّاة، ومالك واحد لكل صفقة، وتعريف للفوز يدافع عنه أحد؟
2. من يملك سجل العميل، ومن يحق له تعديله؟
3. أين يعيش المال الآن؟ إن كانت الفواتير في برنامج محاسبة، فلا يجوز أن يصبح CRM دفترًا ثانيًا.
4. هل سيدير الأداة أحد في الشهر السادس، باسمه؟
5. هل يبيع الفريق من الهاتف ومن واتساب؟ إذن المطلوب سجل سريع على الهاتف، لا قائمة ميزات أطول.

شركة في قسنطينة تستورد قطع غيار، وتسعّر على واتساب، وتسلّم بالأجل وتحصّل لاحقًا، ليست أمام مشكلة HubSpot ولا مشكلة Salesforce. فعندها عملية تسكن رأس شخص واحد، ودفتر مال يسكن برنامج محاسبة. وشراء أي CRM أولًا ينتج مكانًا منظمًا لحفظ ما لم يكتبه أحد.

المقارنة التي تحسم القرار

البعد	HubSpot	Salesforce
ما يفترضه	قمع واحد وسجل جاهز الصياغة	العملية لكم لتكتبوها
من يديره	مستخدم أعمال يعمل في الإعدادات	مدير مسمّى أو شريك
أين يسكن التخصيص	خصائص ومسارات وقوالب	كائنات وأنواع سجلات ومسارات وقواعد
الخروج	الكائنات والخصائص تخرج بسهولة	الكائنات القياسية تخرج، والمخطط يبقى
ما يحد التصميم	الطبقة التي تشترونها	الإصدار والتراخيص التي تشترونها
ما تتحققون منه على صفحة المورّد	أي كائنات وأتمتة وبيئة اختبار تشملها طبقتكم	أي إصدار يحمل حدود الأتمتة والواجهة التي تحتاجونها

كيف تقررون بالترتيب؟

1. ارسموا الصفقة وهي تتحرك، ومعها السهم الذي يعود إلى الوراء. غيابه يعني قمعًا، ووجود عدة أسهم يعني مواصفة.
2. عدّوا المديرين: مستخدم أعمال واحد يرجّح الأداة السطحية، وشريك بعقد يرجّح العميقة.
3. اكتبوا ما لا يجوز أن يفعله CRM — عرض سعر، مخزون، فاتورة — قبل أي إعداد.
4. استوردوا قائمة جهات اتصال حقيقية في تجربة، واقرأوا تقرير التكرارات.
5. ابنوا التقرير الذي سيفتحه صاحب الشركة، من حقولكم، قبل التوقيع.

أين يخطئ الفريق؟

• التخصيص قبل التبني. خمسة كائنات وأربعون حقلًا في اليوم الأول، فيبقي البائعون مسارهم في دفتر.
• CRM كدفتر مال. تدخل عروض الأسعار والدفعات والتسليمات إلى CRM، ويحمل برنامج المحاسبة المال نفسه، فيختلف الاثنان قبل نهاية الربع.
• لا أحد يملك البيانات. تتراكم التكرارات، ويفرغ حقل المالك، ويصبح التقرير جدالًا حول القائمة.
• العرض التجريبي كأنه مواصفة. بيانات المورّد النظيفة تجعل كل منتج يبدو منتهيًا، وقائمتكم بثلاث كتابات لشركة واحدة هي الاختبار الحقيقي.

متى لا يصلح أي منهما

حين تكون الصفقة مشروعًا — عرض بجدول مواد، ودفعة مقدمة، وتسليم، وضمان — يحمل CRM المحادثة ويحمل نظام التشغيل المعاملة. وحين يكون السجل محادثة إنستغرام، فالـCRM ثالث ما يُشترى بعد الكتالوج ومسار الطلب. ومع بائع واحد وصاحب الشركة، يتفوق صندوق بريد مشترك وجدول منظم على منصة مضبوطة لسنة كاملة.

ما لا يغطيه هذا الرأي

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

ولا يغطي هذا الرأي مكان حفظ البيانات، ولا ترحيل نظام CRM له سنوات من التاريخ، ولا الربط بين CRM ونظام تخطيط موارد المؤسسة (ERP). نحن نبني أنظمة ونربطها حول أدوات كهذه؛ لا نعيد بيع أي منهما ولا نتقاضى عمولة، فالتوصية أعلاه بلا مصلحة تجارية.

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