مرجع الترحيل
الترحيل من Freshdesk إلى HubSpot
ما الذي ينتقل فعلاً، وما الذي لا ينتقل دون أن تلاحظوا، وما الذي يجب إعادة بنائه يدوياً.
قارنّا Freshdesk بـ HubSpot ميزةً بميزة: 59 ميزة، و3 كائنات تُزامَن، و9 فخاخ موثّقة، و33 عنصراً يجب إعادة بنائه. الخريطة كاملة في هذه الصفحة ومتاحة دون تسجيل.
ملف PDF هو المرجع نفسه بتنسيق يناسب ملف المشتريات.
احصلوا على المرجع والحاسبة
المرجع الكامل للانتقال من Freshdesk إلى HubSpot بصيغة PDF، مع حاسبة Excel التي نحدد بها نطاق هذه العمليات: كل ميزة من الميزات الـ59 في صف مستقل، تدخلون أعدادكم فتحصلون على الساعات.
ثلاثة ملفات: المرجع بصيغة PDF، والمرجع نفسه بصيغة Markdown لأداة الذكاء الاصطناعي لديكم، وحاسبة الجهد الكاملة بصيغة Excel.
الانتقال من Freshdesk إلى HubSpot ترحيل متوسط إلى مرتفع التعقيد، وعادةً خططوا لنطاق 2-6 أسابيع، مع أن المسار الذي تختارونه يغيّر هذا الرقم أكثر مما يغيّره الحجم وحده. يستغرق التصدير عبر CSV أياماً؛ وتغطي أداة ترحيل SaaS ما بين 1K-50K تذكرة في 2-4 أسابيع؛ وتستغرق السكربتات المنفذة ذاتياً (DIY) لما يزيد على 50K تذكرة 4-8 أسابيع؛ أما الخدمة الاحترافية فتعود إلى 2-4 أسابيع أياً كان الحجم. من بين 59 ميزة وثّقناها، تنتقل 26 كما هي، وتنتقل 30 مع فقدان جزء منها. أما العناصر الـ33 التي لا ينقلها شيء نيابةً عنكم فهي ما سيحدد جدولكم الزمني فعلاً، وليس المزامنة.
بطاقة تقييم الترحيل
- درجة تعقيد الترحيل
- متوسط إلى مرتفع
- المدة المعتادة
- خططوا لنطاق 2-6 أسابيع، مع أن المسار الذي تختارونه يغيّر هذا الرقم أكثر مما يغيّره الحجم وحده. يستغرق التصدير عبر CSV أياماً؛ وتغطي أداة ترحيل SaaS ما بين 1K-50K تذكرة في 2-4 أسابيع؛ وتستغرق السكربتات المنفذة ذاتياً (DIY) لما يزيد على 50K تذكرة 4-8 أسابيع؛ أما الخدمة الاحترافية فتعود إلى 2-4 أسابيع أياً كان الحجم.
- الطريقة الموصى بها
- الحفاظ الكامل على البيانات يعني ترحيلاً مخصصاً عبر API؛ اعتبروه الخيار الافتراضي وليس الخيار الاحتياطي. فالمزامنة الأصلية بُنيت للتعايش المستمر بين النظامين وليس لترحيل كامل، فلا تحدّدوا نطاقها على هذا الأساس، ولا يصلح التصدير عبر CSV إلا لما دون 500 تذكرة وحيث لا تحتاجون إلى الاحتفاظ بسجل المحادثات نفسه.
- المزامنة الأصلية
- مزامنة بيانات ثنائية الاتجاه
- النقل الذكي (Smart transfer)
- مدعوم
- اشتراك HubSpot
- مجاني للمزامنة الأساسية. وData Hub Starter فما فوق لربط الحقول المخصصة.
تكافؤ الميزات عبر 59 قدرة
- يقابله مباشرة: 26 (44%)
- يقابله جزئياً: 30 (51%)
- لا مقابل له: 3 (5%)
3
كائنات تُزامَن أصلياً
9
القيود والفخاخ
33
عناصر إعادة البناء اليدوي
4
إصدارات المصدر المشمولة
مصدر هذه الأرقام: مدونة أبحاثنا الخاصة، تم التحقق منها بتاريخ 2026-07-31، وهي مصدر كل رقم في هذه الصفحة.
الكائنات الثلاثة التي تُزامَن أصلياً
ما ينقله الموصّل نيابةً عنكم، وفي أي اتجاه يتدفق كل كائن.
Contacts
في الاتجاهينيصبح Contacts
جهات الاتصال هي الكائن الذي بُنيت عليه هذه المزامنة فعلاً، وتعمل باتجاهين وفي الوقت الفعلي، لكن إزالة التكرار تعتمد على عنوان البريد الإلكتروني الأساسي وحده، وهي قاعدة محفوفة بالمخاطر لأي حساب جرى دمجه في مرحلة ما وصار يحمل أكثر من عنوان مسجَّل.
Companies
في الاتجاهينيصبح Companies
الترتيب مهم هنا: أنشئوا سجلات الشركات قبل وصول جهات الاتصال، ثم اربطوا الاثنين عبر Associations API، لأن العكس يترك جهات الاتصال دون ما ترتبط به. وتتوفر المزامنة ثنائية الاتجاه متى احتُرم هذا الترتيب.
Tickets
في الاتجاهينيصبح Tickets
التذاكر هي أضعف نقطة في هذه المزامنة لا أقواها. فهي لا ترجع إلا 120 يوماً إلى الوراء، ولا تنقل سوى عنوان التذكرة وبيانات وصفية أساسية، وتُسقط الملاحظات الخاصة والعامة معاً، وتفقد من تولّى الحالة ومتى. أما تبادل البريد المتسلسل، بالعربية أحياناً وبالإنجليزية أحياناً وبكلتيهما في التذكرة نفسها أحياناً، فيصل رسائل متفرقة منفصلة بدلاً من المحادثة التي كان عليها.
تسعة أمور لا تخبركم بها المزامنة
كل واحد منها موثّق، وكل واحد منها أفسد عملية ترحيل في أسبوع سيئ.
حد سجل التذاكر البالغ 120 يوماً
كل ما فُتح قبل أكثر من 120 يوماً يبقى خلفكم نهائياً: فمزامنة التذاكر في التكامل الأصلي ترجع هذا القدر بالضبط ولا تتجاوزه. وقد يكون نزاع بدأ في أسبوعه الأول قد خرج من نطاق المزامنة قبل أن يشرع مشروع الترحيل في تحديد نطاق بقية العملية.
الحل البديل: استعادة السجل الكامل تعني الالتفاف على المزامنة تماماً: سكربت مخصص مبني على Freshdesk REST API لاستخراج سجل التذاكر الكامل واستيراده، وهو عمل يجب التكليف به عن قصد وليس افتراض حدوثه مع الاتصال الأصلي.
لا تُنقل المحادثات ولا الردود
ما يضيع هنا فعلاً هو المحادثة نفسها وليس سجل التذكرة. فالتكامل الأصلي ينقل عنواناً وبضعة حقول وصفية ولا شيء غيرها: لا سلسلة بريد، ولا رد من موظف الدعم، ولا إجابة من العميل. والتذكرة التي تُزامَن تصل مع ذلك قوقعة فارغة مما قيل داخلها.
الحل البديل: نقل المحادثة يتطلب سكربت API مخصصاً: يسحب كل رسالة من Freshdesk ويكتبها في HubSpot كملاحظة تفاعل (engagement note) مرتبطة بتذكرتها، إذ لا شيء مضمَّناً في الموصّل ينفذ هذه الخطوة نيابةً عنكم.
الملاحظات الخاصة والعامة مستبعدة
لا الملاحظة الخاصة ولا العامة المرتبطة بتذكرة تنتقل: فالمزامنة الأصلية تستبعد الفئتين كلتيهما. وكل توثيق داخلي كتبه موظفو الدعم إلى جانب التذكرة، من سبب التصعيد إلى تعليمات المدير إلى خطر جرى التنبيه إليه، لا وجود له في HubSpot بعد ذلك.
الحل البديل: اسحبوا الملاحظات عبر Freshdesk API وأعيدوها إلى HubSpot كملاحظات (notes)، ووسموا ما كان خاصاً على أنه داخلي كي يبقى التمييز الذي اعتمد عليه موظفو الدعم قائماً بدلاً من أن يذوب في سجل مفتوح واحد.
ضياع هوية المنفذ والطوابع الزمنية
من عالج التذكرة فعلاً يختفي من سجلها: فالتكامل الأصلي لا يحتفظ بموظف الدعم الأصلي ولا بالطابع الزمني الأصلي، فتبدو كل تذكرة منقولة كأن مستخدم التكامل أنشأها لحظة المزامنة، لا الموظف الذي حلّها قبل أسابيع أو أشهر، وهذا بالضبط التفصيل الذي يحتاجه أي تدقيق أو مراجعة امتثال لاحقة لإعادة بناء من فعل ماذا ومتى.
الحل البديل: احفظوا معرّف موظف Freshdesk (agent ID) والطابع الزمني الأصلي في خصائص مخصصة في HubSpot قبل أن يفقدهما السجل نهائياً، واربطوا كل agent ID بمعرّف مالك (owner ID) في HubSpot كي تبقى هوية المنفذ بصيغة يستطيع النظام نسبتها فعلاً، لا ملاحظة لا يفكر أحد في مراجعتها.
الصور المضمّنة تتحول إلى روابط معطلة
الصورة المضمّنة داخل وصف التذكرة أو ملاحظة لا تُخزَّن مع التذكرة فعلاً: فهي مستضافة على شبكة Freshdesk CDN ومرتبطة بها برابط فقط. وفور إيقاف Freshdesk ينكسر كل رابط من هذه الروابط نهائياً وليس مؤقتاً.
الحل البديل: نزّلوا كل صورة مضمّنة وأعيدوا رفعها إلى File Manager في HubSpot وعدّلوا روابط src في شيفرة HTML الأصلية قبل إلغاء Freshdesk وليس بعده: فبمجرد انتهاء الاشتراك لا يبقى ما يمكن تنزيله.
حدود معدل طلبات Freshdesk API وسقف ترقيم الصفحات
ثلاثة سقوف منفصلة تحدد ما يمكن سحبه من Freshdesk دفعة واحدة: حد لمعدل طلبات API يتراوح بين 50 و700 طلب في الدقيقة بحسب الباقة، وسقف لترقيم الصفحات قدره 30,000 تذكرة موزعة على 300 صفحة بواقع 100 عنصر في كل صفحة، وحد صارم لواجهة التصفية (filter API) قدره 300 نتيجة إجمالاً. وعملية الدعم التي تقف خلفها سنوات من سجل التذاكر تصطدم بأدنى هذه السقوف أولاً.
الحل البديل: تجاوزوا السقف بتصدير تدريجي باستخدام المعامل updated_since بدلاً من سحب كل شيء دفعة واحدة، وأضيفوا منطق تراجع وإعادة محاولة (backoff and retry) كي يوقف بلوغ حد المعدل عملية الاستخراج بدلاً من إسقاط السجلات بصمت.
اقتطاع أوصاف التذاكر الطويلة
وصف التذكرة أو الملاحظة الطويلة التي استوعبتها Freshdesk بما يتجاوز 65,000 حرف تصطدم مباشرة بحد HubSpot الأدنى في الطرف الآخر، ولذلك يجب تقسيم ما بلغ هذا الطول تقسيماً ذكياً بدلاً من قطعه ببساطة عند السقف.
الحل البديل: الحل هو منطق تقسيم مصمم لهذا الغرض يحافظ على السياق عبر نقطة القطع وينشئ ملاحظة تكميلية لما لا يتسع، بدلاً من اقتطاع عام يُسقط ذيل السجل.
قيود التعامل مع المرفقات
لا يحمل طلب HubSpot API الواحد أكثر من ملف واحد في المرة، ويحدد File Manager نفسه سعة التخزين بـ 2GB في الحساب المدفوع و20MB في الباقة المجانية، ويُحدَّ أي سجل واحد بـ 10,000 تفاعل (engagement) إجمالاً. ثلاثة سقوف منفصلة قد يبلغها سجل تذاكر مثقل بالمرفقات، من وثائق مناقصات وعقود موقعة ولقطات شاشة، أسرع مما يُتوقع.
الحل البديل: ارفعوا كل ملف على حدة عبر نقطة النهاية /files/v3/files، ثم اربطوه بتذكرته باستخدام hs_attachment_ids: لا يوجد مسار دفعي يتجاوز حد الملف الواحد، بل طابور أطول من الاستدعاءات الفردية فقط.
إخفاقات الربط وإسقاط البيانات بصمت
إخفاقان هنا لا يصدران أي تحذير. فقد لا تظهر في واجهة HubSpot ملاحظة أُنشئت مرتبطة بتذكرة رغم نجاح استدعاء API، وتُسقَط قيمة الحقل المخصص بصمت إذا لم تكن الخاصية المقابلة موجودة في HubSpot لحظة الاستدعاء: لا خطأ يُعاد، بل بيانات مفقودة بهدوء.
الحل البديل: أنشئوا كل خاصية مخصصة في HubSpot قبل نقل أي سجل، ونفّذوا سكربت تحقق بعد الاستيراد للتأكد من وصول الروابط بدلاً من الوثوق باستجابة API ناجحة، فنجاح الاستدعاء وظهور السجل ليسا الضمان نفسه هنا.
ثلاث ميزات في Freshdesk لا يستطيع HubSpot تعويضها
لا يوجد حل بديل يسدّ هذه الفجوات. كل بند منها قدرة ستتخلون عنها، فحدّدوا من في المؤسسة يمكنه الاستغناء عنها قبل الالتزام بموعد.
المنتديات المجتمعية (Community Forums)
لا يوفر HubSpot منتدى مجتمعياً أصلياً. يلزم حل من طرف ثالث (Discourse أو Vanilla Forums وغيرهما).
كاشف رسائل الشكر Freddy Thank You Detector
العميل الذي يرد بالشكر فقط سيعيد فتح التذكرة في HubSpot كأي رد آخر، إذ لا يوجد كشف أصلي يلتقط هذه الرسائل ويكتمها كما يفعل Freddy: ويلزم بناء workflow مخصص بخطوة ذكاء اصطناعي أو بمطابقة كلمات مفتاحية لإعادة إنتاج هذا المرشّح.
إدارة الخدمة الميدانية (Field Service Management)
لا مكان أصلياً في HubSpot لجدولة الفنيين الميدانيين وإيفادهم وإسناد المهام إليهم: ويلزم أن يتولى هذه الوظيفة تكامل من طرف ثالث، مثل ServiceMax أو Salesforce Field Service، إلى جانب HubSpot.
أمر واحد لا يعيد الترحيل بناءه
هذا من شيفرة Freshdesk أو منتجاتها نفسها، ولن ينقله ترحيل HubSpot: فلا ساعات له في التقدير. ومع ذلك يحتاج إلى قرار قبل التحويل (cutover)، لأنكم أنتم من يتخلى عن شيء.
التطبيقات المخصصة (Custom Apps)
تتطلب التطبيقات المخصصة إعادة كتابة كاملة لمنصة HubSpot. ويحتاج كل تطبيق إلى تقييم مستقل.
العناصر الـ33 التي تُعاد يدوياً
هذه القائمة هي ما يفرّق بين عرض سعر يصمد وآخر ينهار.
البيانات والكائنات
مسارات التذاكر وحالاتها
مجموعة الحالات التي تمر بها التذكرة في Freshdesk والانتقال بينها تحتاج إلى مسار (pipeline) خاص في HubSpot يُبنى قبل وصول أي شيء آخر.
HubSpot: Ticket pipelines وstages
اضبطوا هذا قبل تشغيل الاستيراد. وإن تجاوزتموه حطّت كل تذكرة منقولة في المرحلة الافتراضية بصرف النظر عن موقعها الفعلي، وتنظيف ذلك أكبر بكثير من إعداد المسار الصحيح من أول مرة.
حقول التذاكر المخصصة
كل حقل أُضيف إلى نموذج التذكرة في Freshdesk على مر السنين يحتاج إلى خاصية مخصصة مقابلة تُبنى في HubSpot قبل أن يجد مكاناً يستقر فيه.
HubSpot: Custom ticket properties
عرّفوا كل واحدة منها مسبقاً بدلاً من ترك الاستيراد ينشئها أثناء التنفيذ: فالخاصية التي تُنشأ أثناء الاستيراد تصل نصاً عادياً مجرداً من النوع وخيارات القائمة المنسدلة (picklist) التي كانت تحملها في Freshdesk.
الوسوم (Tags)
الوسوم المستخدمة في Freshdesk لتجميع التذاكر، وأحياناً لتشغيل أتمتة مباشرة، لا يوجد لها كائن مقابل ينتظرها في HubSpot.
HubSpot: خاصية تذاكر متعددة الاختيار (multi-select)
لا تحمل تذاكر HubSpot حقل وسوم أصلياً على الإطلاق: والخاصية متعددة الاختيار هي أقرب بديل، وحيثما كان الوسم يشغّل أتمتة فعلاً يجب أن يصبح حقلاً حقيقياً يقرؤه الـ workflow بدلاً من ملصق يُترك على السجل للاطلاع فقط.
متابعو التذاكر والنسخ الكربونية (CC)
كل من كان يتابع تذكرة دون أن يملكها، وهو ما تسميه Freshdesk watcher أو CC، لا يجد موقعاً مطابقاً في الطرف الآخر.
HubSpot: لا مقابل مباشر
أقرب بديل هو ملاحظة أو خاصية مخصصة تسجل من كان يتابع. وإذا كان الفريق يعتمد فعلاً على هذه الرؤية يومياً فاتفقوا على ما يحل محل هذه العادة قبل الإطلاق الفعلي (go-live)، وليس بعد أن تمر أول تذكرة كان ينبغي أن يراها شخص ما دون أن ينتبه.
بيانات تتبع الوقت
الوقت الذي سجّله موظفو الدعم على تذكرة لا ينتقل مع التذكرة التي سُجّل عليها.
HubSpot: خصائص مخصصة، أو أداة خارجية لتتبع الوقت
حيثما كان هذا الوقت المسجَّل يحدد الفوترة فعلاً، فالخاصية المخصصة حل مؤقت وليست إجابة حقيقية: أثيروا هذا مبكراً في نقاش تحديد النطاق، لأنه يحتاج عادةً إلى أداة مخصصة لتتبع الوقت بدلاً من حقل يُلصق على سجل التذكرة.
الردود الجاهزة (Canned Responses)
نصوص الردود المحفوظة التي يُدرجها موظفو الدعم في التذكرة دون إعادة كتابتها يجب إعادة بنائها كـ snippets في HubSpot، واحداً تلو الآخر.
HubSpot: Snippets
هي إعادة بناء يدوية، فاحرصوا على فرز القائمة أولاً: فمعظم حسابات Freshdesk راكمت عبر السنين ردوداً جاهزة تفوق بكثير ما لا يزال موظفو الدعم يستخدمونه فعلاً، وإعادة بناء غير المستخدم منها جهد يضيع هباءً.
سجل دمج جهات الاتصال
سجل أي جهة اتصال في Freshdesk دُمجت في أي جهة أخرى لا ينتقل إطلاقاً.
HubSpot: لا مقابل
يزيل HubSpot التكرار بالاعتماد على عنوان البريد الإلكتروني وحده، ولذلك قد تنفصل بصمت عند الاستيراد جهتا اتصال دمجتهما Freshdesk قبل سنوات تحت عنوانين مختلفين، وهو نمط شائع حين يُسجَّل الاسم مرة بالإنجليزية ومرة بنقل حرفي من العربية. راجعوا قائمة الدمج قبل تشغيل الاستيراد، لأن إعادة بنائها لاحقاً تعني العمل عكسياً انطلاقاً من أن خللاً ما قد ظهر بالفعل.
الأتمتة
قواعد التوزيع (Dispatch Rules)
كل ما يسند التذكرة ويصنّفها لحظة وصولها لا مسار له عبر الموصّل ويحتاج إلى كتابة من الصفر.
HubSpot: Workflows وقواعد التوجيه (routing rules)
توقعوا إعادة العمل قاعدة بقاعدة لا ككتلة واحدة، وإعادة هيكلة أي سلسلة قواعد متعاقبة أثناء ذلك: فـ Freshdesk تقيّم قواعد التوزيع بترتيب محدد، أما محرك workflows في HubSpot فلا يفعل، ولذلك تحتاج القاعدة التي افترضت أن سابقتها نُفذت إلى تصميم مختلف وليس مجرد نسخة.
الأتمتة المُشغَّلة بالأحداث وبالوقت
كل ما ينطلق عند حدث في التذكرة، أو بعد أن تصمت التذكرة مدة من الزمن، يحتاج إلى إعادة البناء من الأساس نفسها.
HubSpot: Workflows مبنية على التذاكر مع فترات تأخير (delays)
اختبروا سلوك التأخير على تذاكر حقيقية قبل أن تأتمنوه على أي شيء يغلق الحالة تلقائياً: فأسبوع العمل الذي يمتد من الأحد إلى الخميس في سوق ويختلف في سوق آخر هو بالضبط الموضع الذي ينكسر فيه افتراض التوقيت بصمت.
أتمتة السيناريوهات (Scenario Automations)
حزمة الإجراءات بنقرة واحدة التي يطبقها موظف الدعم على التذكرة، من تغييرات عدة في الحقول مع رد يُرسل معاً، لا مقابل ينتظرها هي الأخرى.
HubSpot: Workflows تُشغَّل يدوياً أو بواسطة خاصية
لا يملك HubSpot حزمة بنقرة واحدة تستقبلها: فتصبح كل واحدة workflow يشغّله موظف الدعم يدوياً أو بتعيين خاصية، وهي إعادة بناء حقيقية وليست إعداداً أُعيدت تسميته.
سياسات اتفاقية مستوى الخدمة (SLA Policies)
أهداف الاستجابة والحل المحددة لكل نوع تذكرة أو لكل حساب لا تنتقل مع أي شيء آخر: فسياسات SLA تحتاج إلى ضبط من جديد من الصفر، بما يطابق الالتزام المكتوب فعلاً في العقد لا ما يُستعاد من الذاكرة.
HubSpot: إعدادات SLA وworkflows التذاكر
اضبطوا ساعات العمل (business hours) قبل تفعيل أي سياسة SLA، وإلا قيس كل هدف على ساعة مسطحة من 24 ساعة بصرف النظر عن أوقات عمل المكتب الفعلية. وهذه الخطوة أشد أهمية لعملية خليجية تدير مركز دعم واحداً عبر عدة أسواق بأسابيع عمل مختلفة، إذ إن اليوم الذي يكون عطلة في بلد يكون يوم عمل في آخر، ويجب أن يعرف عدّاد SLA أيهما.
الردود الجاهزة والماكرو (Canned Responses and Macros)
الماكرو (macro)، أي نص الرد المحفوظ مقترناً بما يصاحبه من تغييرات في الحقول، لا ينتقل ككيان واحد.
HubSpot: Snippets وtemplates وworkflows
يجب تفكيكه عند إعادة البناء: فيصبح نص الرد snippet، وتصبح تغييرات الحقول التي كان يطلقها workflow منفصلاً، أي كائنان في HubSpot يحلان محل ماكرو Freshdesk الواحد.
نماذج Freddy للذكاء الاصطناعي
الردود المقترحة من Freddy والفرز الآلي لا ينتقلان بأي صيغة إطلاقاً.
HubSpot: أدوات الذكاء الاصطناعي في HubSpot نفسها
لا يوجد مسار ترحيل فعلاً: فهذه النماذج دُرّبت على سجل التذاكر الموجود داخل Freshdesk وتبقى فيه عند إغلاق الحساب. تعاملوا مع ما تقدمه أدوات الذكاء الاصطناعي في HubSpot كإعداد جديد يبدأ من الصفر، وضبطوا توقعات الفريق وفق ذلك، فجودة الاقتراحات في اليوم الأول ستبدو أسوأ بوضوح مما تعلّمه Freddy على مدى سنوات من الطابور نفسه.
قواعد الإشعارات والتصعيد
من يُبلَّغ بماذا، والنقطة التي تُصعَّد عندها التذكرة إلى شخص آخر، كلاهما يحتاج إلى إعادة بناء من الصفر.
HubSpot: Notification settings وworkflows
يوزع HubSpot هذا المنطق على موضعين منفصلين، إعدادات الإشعارات وworkflows، ما يجعل من السهل إعادة بناء نصفه فقط دون الانتباه. راجعوا الموضعين معاً قبل إعلان انتهاء العمل.
التقارير
تقارير Freshdesk Analytics
مجموعة Freshdesk Analytics بأكملها المبنية فوق بيانات التذاكر لا مسار استيراد لها وتحتاج إلى إعادة بناء تقريراً بتقرير.
HubSpot: Custom reports
أعيدوا بناء كل تقرير انطلاقاً من السؤال الذي كان يجيب عنه فعلاً وليس من تخطيطه، وتوقعوا أن بعض المقاييس لا نظير له في HubSpot إطلاقاً. وقولوا ذلك مبكراً في نقاش تحديد النطاق: فمثل هذه الفجوة مشكلة أصغر بكثير حين تُثار قبل التوقيع مما لو اكتُشفت عند التسليم.
لوحات المعلومات المخصصة
أي تخطيطات لوحات محفوظة للتقارير الدورية تحتاج إلى بناء جديد من الصفر.
HubSpot: Dashboards
ابنوا اللوحات بعد أن تكون التقارير التي تقوم عليها موجودة فعلاً في HubSpot وليس بالتوازي معها: فاللوحة التي تُجمَّع قبل اكتمال تقاريرها تحتاج عادةً إلى إعادة.
تقارير الالتزام باتفاقية مستوى الخدمة (SLA)
التقارير التي توضح أهداف SLA التي تحققت وتلك التي فاتت يجب إعادة بنائها في الطرف الجديد أيضاً.
HubSpot: SLA reporting
يعتمد هذا كلياً على إعداد SLA الموصوف أعلاه، فرتّبوا بناء التقارير بعد انتهاء ذلك العمل وليس بالتوازي معه.
مقاييس أداء موظفي الدعم وإنتاجيتهم
التقارير عن حجم ما عالجه كل موظف دعم وسرعة حله له تحتاج إلى إعداد جديد في أدوات HubSpot نفسها.
HubSpot: Service analytics
يجب ربط كل موظف دعم بمستخدم حقيقي في HubSpot لحظة الاستيراد، وإلا نُسب النشاط الذي عالجه إلى لا أحد بعد إعادة بناء المقاييس، وهي فجوة أرخص بكثير سدّها قبل الإطلاق الفعلي (go-live) من إعادة بنائها لاحقاً من سجل التذاكر وحده.
تقارير استبيانات رضا العملاء (CSAT)
نتائج CSAT التاريخية والاتجاه المبني عليها لا تنتقل كمجموعة بيانات واحدة متصلة.
HubSpot: Customer feedback surveys
تنطلق الاستبيانات الجديدة من HubSpot منذ اليوم الأول، بينما تبقى الدرجات التاريخية محفوظة في خاصية مخصصة، فيضطر أي تقرير اتجاه إلى السحب من مصدرين منفصلين معظم السنة الأولى بدلاً من خط واحد نظيف.
إعدادات المبيعات والتسويق
نماذج الدعم ورفع التذاكر
كل نموذج يستخدمه العملاء فعلاً لرفع تذكرة يجب إعادة بنائه كنموذج في HubSpot.
HubSpot: Forms
استبدلوا كل نموذج مدمج في يوم التحويل (cutover) نفسه وليس بعده بوقت: فترك صفحة واحدة تشير إلى النموذج القديم يعني أن طلبات الدعم تظل تصل إلى نظام لا يراقبه أحد.
أدوات Freshchat
أداة الدردشة في الموقع التي يراها العملاء فعلاً تحتاج إلى استبدال وليس مجرد إعادة ضبط.
HubSpot: Live chat
استبدال الأداة نفسها هو الجزء السهل؛ أما العمل الحقيقي فهو إعادة بناء قواعد التوجيه والتوفر خلفها، أي المنطق الذي يقرر من يستلم المحادثة ومتى، خصوصاً حيث يعمل المكتب عبر أكثر من أسبوع عمل.
روبوتات الدردشة (Chatbots)
أي مسار دردشة آلي كان يعالج الأسئلة الشائعة يجب إعادة بنائه مساراً بمسار داخل منشئ روبوتات الدردشة (chatbot builder) في HubSpot.
HubSpot: The chatbot builder
لا شيء من سجل أداء الروبوت ينتقل معه، فيبدأ الجديد من صفحة بيضاء: وما اكتسبه المسار القديم من ضبط عبر أشهر من المحادثات الحقيقية يجب اكتسابه من جديد لا وراثته.
مقالات قاعدة المعرفة
لمقالات المساعدة المنشورة أصلاً في Freshdesk مسار استيراد فعلي، بخلاف معظم ما في هذه القائمة.
HubSpot: Knowledge base
يقرأ مستورد قاعدة المعرفة في HubSpot نفسه بيانات Freshdesk مباشرة، ما يجعل هذا البند من أرخص البنود نقلاً في القائمة كلها. ويعمل على دفعات، ولا يصمد أي تنسيق للجداول داخل المقال عند الاستيراد، فخصصوا جولة تنسيق بعده، وتستحق عناية خاصة في المقالات الموجودة بنسختين عربية وإنجليزية، لأن الجدول المكسور يبدو عملاً غير مكتمل بأي من اللغتين.
مركز المساعدة وبوابة العملاء
موقع المساعدة العام وبوابة العملاء التي تتطلب تسجيل الدخول خلفه عملان منفصلان عن استيراد المقالات أعلاه، وليسا من مخرجاته الجانبية.
HubSpot: Knowledge base وcustomer portal
الصلاحيات والهوية البصرية عمل قائم بذاته هنا ويستحق أن يُخطَّط له على هذا الأساس: فعرض بوابة بالعربية بشكل صحيح من اليمين إلى اليسار قرار تصميمي، لا شيء يحسمه استيراد المقالات من تلقاء نفسه.
قوالب البريد الإلكتروني (Email Templates)
كل قالب رد قياسي يستخدمه موظفو الدعم يُعاد بناؤه من الصفر ولا ينتقل بتنسيقه سليماً.
HubSpot: Email templates وsnippets
العمل يدوي، قالباً بقالب، وتحمل رموز التخصيص (personalisation tokens) داخل كل قالب أسماء مختلفة في HubSpot ولن تنتقل تلقائياً، فيجب إعادة فحص كل merge field بدلاً من الوثوق به بمجرد النظر.
استبيانات الرضا
الاستبيان الذي يُرسل تلقائياً عند إغلاق التذكرة يحتاج إلى إعادة بناء كإعداد مستقل.
HubSpot: Customer feedback surveys
أعيدوا بناء المشغّل (trigger) مع الاستبيان نفسه وليس الأسئلة فقط: فالإرسال في HubSpot يحركه workflow وليس إعداداً بسيطاً في التذكرة، وخطأ المشغّل يعني أن الاستبيان لن يُرسل أبداً أو سيُرسل في لحظة خاطئة.
المستخدمون والصلاحيات
أدوار موظفي الدعم وصلاحياتهم
مستوى الوصول المرتبط بكل موظف دعم في Freshdesk يحتاج إلى إعادة إنشاء متعمدة في نموذج الصلاحيات في HubSpot، ولا يصح افتراض أنه ينتقل.
HubSpot: Users وpermission sets
ترتيب الوكيل العرضي (occasional agent) في Freshdesk، أي مقعد أخف لمن يتعامل مع التذاكر بين الحين والآخر، لا نظير مطابقاً له في الطرف الآخر. قرروا شخصاً شخصاً هل يحتاج فعلاً إلى مقعد كامل قبل إدراج عدد التراخيص في الميزانية، فالتخمين في أي اتجاه مكلف.
مجموعات موظفي الدعم
الطريقة التي جُمع بها موظفو الدعم لأغراض التوجيه تحتاج إلى مقابل خاص بها يُبنى في HubSpot.
HubSpot: Teams
انقلوا الغاية من التجميع القديم لا هيكله حرفياً: فالمجموعة التي نشأت حول عادات شخص واحد نادراً ما تستحق أن تُستنسخ كما هي.
ساعات العمل والجداول
ساعات التشغيل وتقويم العطلات اللذان كانا يحركان عدّادات SLA في Freshdesk كلاهما يحتاج إلى إعداد جديد من الصفر.
HubSpot: Business hours settings
اضبطوا هذا قبل بناء أي SLA وليس بعده: فبالنسبة لمكتب يغطي أكثر من سوق خليجي بأسبوع عمل مختلف في كل منها، ساعات العمل هي الإعداد الذي يقرر هل يعني عدّاد SLA أي شيء أصلاً.
توقيعات موظفي الدعم
توقيع البريد الإلكتروني الخاص بكل موظف دعم في رد التذكرة يحتاج هو الآخر إلى إعداد فردي في HubSpot.
HubSpot: User email signatures
يُضبط لكل مستخدم على حدة وليس مرة واحدة مركزياً، فهو مهمة قصيرة تتكرر على الفريق كله، وتستحق أن تُدرج بنداً في قائمة المهام بدلاً من افتراض حدوثها تلقائياً أثناء التهيئة.
التكاملات
إعدادات تطبيقات الـ Marketplace
أي تطبيق كان يوسّع واجهة موظف الدعم في Freshdesk يجب إعادة ربطه أو استبداله في HubSpot؛ ولا شيء من الإعدادات ينتقل من تلقاء نفسه.
HubSpot: تكاملات App Marketplace، أو Zapier وMake
احصروا ما يُستخدم يومياً فعلاً قبل تسعير البدائل: فالتطبيق الذي ثُبّت قبل سنوات ثم هُجر بصمت لا يحتاج إلى البحث له عن مقابل في HubSpot.
تكاملات Freshworks Suite
حيث تعمل Freshdesk إلى جانب Freshsales أو Freshchat أو Freshcaller داخل حساب Freshworks نفسه، فهذه ليست تكاملات منفصلة يُعاد ربطها؛ بل منتجات متجاورة بُنيت حولها المنظومة كلها.
HubSpot: الـ hubs والأدوات المقابلة في HubSpot
تبدو هذه كتكاملات لكنها تعمل كمنتجات متجاورة مبنية على المنصة نفسها. وإذا كانت مؤسستكم تشغّل عدة منها معاً، فهذا المشروع أوسع من مركز الدعم وحده، ويجب تحديد نطاقه على أنه انتقال منظومة Freshworks كلها وليس ركناً واحداً منها.
تكاملات القنوات
كل قناة تغذّي الطابور، من بريد وهاتف وقنوات التواصل الاجتماعي والمراسلة المصاحبة لها، تحتاج إلى إعادة ربط فردية في HubSpot ولا يصح افتراض أنها تتبع بيانات التذاكر من تلقاء نفسها. وحيث يكون WhatsApp فعلاً القناة التي يلجأ إليها العملاء أولاً في هذه السوق، فامنحوه عناية إعادة الربط نفسها التي تمنحونها للبريد بدلاً من معاملته كأمر ثانوي.
HubSpot: Connected channels
تحققوا من أن كل قناة لا تزال تنشئ تذكرة فعلاً بعد إعادة الربط وليس مجرد إرسال إشعار: فهذا التراجع الصامت من إنشاء التذاكر إلى الإشعار فقط انتكاسة شائعة، وهو من الفجوات التي لا تظهر إلا حين يشتكي أحد من أن لا أحد ردّ.
التسلسل
المزامنة أولاً، ثم الترحيل
الترتيب هنا هو جوهر المحتوى. هذه الخطوات سلسلة متعاقبة يعتمد كل منها على ما قبله، وتنفيذها خارج تسلسلها من الأسباب الموثّقة لفشل هذا النوع من الترحيل.
- 1
التدقيق
احسبوا حجم التذاكر، وفهرسوا كل حقل مخصص، واحصروا الأتمتة، وعدّوا مقالات قاعدة المعرفة قبل التخطيط لأي شيء آخر
- 2
ابنوا الوجهة أولاً
مسارات HubSpot والخصائص المخصصة والفرق مهيأة لتحاكي بنية Freshdesk، وجاهزة قبل وصول أي تذكرة
- 3
أنشئوا كل خاصية مخصصة في HubSpot قبل النقل، لأن الخاصية غير الموجودة مسبقاً تُسقَط قيمتها الواردة بصمت دون تنبيه
أنشئوا كل خاصية مخصصة في HubSpot قبل النقل، لأن الخاصية غير الموجودة مسبقاً تُسقَط قيمتها الواردة بصمت دون تنبيه
- 4
أعيدوا يدوياً بناء ما لن يُزامَن
الأتمتة كـ workflows، والردود الجاهزة كـ snippets، وSLA تُضبط مباشرة في HubSpot
- 5
جمّدوا إعدادات Freshdesk أثناء النقل
لا تغييرات في البنية (schema)، مع استمرار العمليات اليومية كالمعتاد
- 6
الترحيل المجمّع، من T-7 إلى T-3
انقلوا البيانات التاريخية والتذاكر المغلقة والمرفقات القديمة بالتسلسل: Contacts ← Companies ← Tickets ← Notes ← Files، فالترتيب هو ما يحفظ الروابط سليمة
- 7
نزّلوا كل صورة مضمّنة وأعيدوا استضافتها قبل إيقاف Freshdesk وليس بعده
لا يبقى ما يمكن استرداده بمجرد انتهاء الاشتراك
- 8
استوردوا مقالات قاعدة المعرفة عبر مستورد KB الخاص بـ HubSpot، على دفعات بحسب حده البالغ 400 مقال في كل تشغيل
استوردوا مقالات قاعدة المعرفة عبر مستورد KB الخاص بـ HubSpot، على دفعات بحسب حده البالغ 400 مقال في كل تشغيل
- 9
ضبط الجودة قبل التحويل، من T-2 إلى T-1
تحققوا من عينة حقيقية، وافحصوا الترتيب والروابط وليس أعداد السجلات وحدها
- 10
المزامنة التفاضلية (Delta Sync) عند T-0
التقطوا كل تذكرة أُنشئت أو حُدّثت منذ بدء الترحيل المجمّع، كي لا يبقى خلفكم شيء ورد أثناء النقل نفسه
- 11
بدّلوا المسارات
وجّهوا البريد والدردشة والنماذج إلى HubSpot وعطّلوا قنوات Freshdesk في الخطوة نفسها، كي لا يستمر وصول أي شيء إلى الطرفين في آن واحد
- 12
راقبوا من T+1 إلى T+3
ركّزوا على السجلات اليتيمة والروابط المعطلة، وهما نمطا الإخفاق الأكثر تكراراً في هذا النوع من الترحيل
عادةً خططوا لنطاق 2-6 أسابيع، مع أن المسار الذي تختارونه يغيّر هذا الرقم أكثر مما يغيّره الحجم وحده. يستغرق التصدير عبر CSV أياماً؛ وتغطي أداة ترحيل SaaS ما بين 1K-50K تذكرة في 2-4 أسابيع؛ وتستغرق السكربتات المنفذة ذاتياً (DIY) لما يزيد على 50K تذكرة 4-8 أسابيع؛ أما الخدمة الاحترافية فتعود إلى 2-4 أسابيع أياً كان الحجم، من البداية إلى النهاية، بحسب حجم ما يُستخدم فعلاً من إعدادات النظام المصدر.
مقدّر الجهد
ما حجم هذا الترحيل؟
بضعة أسئلة فقط ودون الحاجة إلى تسجيل. النطاقات مستمدة من البحث أعلاه: كل ميزة وثّقناها لها رقم جهد، والحاسبة تجمع ما ينطبق منها على نسختكم.
الجهد التقديري
أجب عن سؤالين ليظهر هنا نطاق الساعات.
مبني على أبحاثنا حول 59 ميزة في Freshdesk. إنه نطاق تقديري وليس عرض سعر.
نطاق تخطيطي وليس عرض سعر. يشمل جهد التنفيذ فقط دون بند لإدارة المشروع. وأكثر ما يغيّره في الواقع هو جودة البيانات.
أكثر ما يتعثر في هذه العمليات
الإخفاقات التي تتكرر مشروعاً بعد آخر، مرتبة تقريباً بحسب موعد ظهورها.
التكامل الأصلي أداة مزامنة وليس أداة ترحيل، ومعاملته كأداة ترحيل هي الخطأ الأكثر شيوعاً
فهو يترك خلفه ما يزيد على 120 يوماً من السجل، مع كل سلسلة محادثة جرت يوماً على أي تذكرة
الصور المضمّنة تنكسر نهائياً لحظة إيقاف Freshdesk، ولذلك يجب إعادة استضافتها قبل التحويل (cutover) وليس كمهمة تنظيف بعده
الصور المضمّنة تنكسر نهائياً لحظة إيقاف Freshdesk، ولذلك يجب إعادة استضافتها قبل التحويل (cutover) وليس كمهمة تنظيف بعده
يحدد Freshdesk API ترقيم الصفحات بسقف 30,000 تذكرة، ولذلك تحتاج أي مجموعة بيانات أكبر إلى المعامل updated_since بدلاً من سحب واحد
يحدد Freshdesk API ترقيم الصفحات بسقف 30,000 تذكرة، ولذلك تحتاج أي مجموعة بيانات أكبر إلى المعامل updated_since بدلاً من سحب واحد
يُسقط HubSpot قيمة الحقل المخصص بصمت إذا لم تكن الخاصية المقابلة موجودة مسبقاً، ولذلك فإنشاء كل خاصية مسبقاً ليس تحضيراً اختيارياً بل هو ما يمنع اختفاء البيانات بهدوء
يُسقط HubSpot قيمة الحقل المخصص بصمت إذا لم تكن الخاصية المقابلة موجودة مسبقاً، ولذلك فإنشاء كل خاصية مسبقاً ليس تحضيراً اختيارياً بل هو ما يمنع اختفاء البيانات بهدوء
إخفاق الربط لا يظهر دائماً في صورة خطأ
قد تبدو الملاحظة وكأنها أُنشئت بنجاح ثم لا تظهر على التذكرة داخل واجهة HubSpot
الاتساق النهائي (eventual consistency) في HubSpot يعني أن القراءة المنفذة فور الكتابة قد تفشل تماماً أو تعود ناقصة، وهذا يستحق أن يُبنى في أي سكربت تحقق بدلاً من معاملته كخلل حين يقع
الاتساق النهائي (eventual consistency) في HubSpot يعني أن القراءة المنفذة فور الكتابة قد تفشل تماماً أو تعود ناقصة، وهذا يستحق أن يُبنى في أي سكربت تحقق بدلاً من معاملته كخلل حين يقع
لا يدعم استيراد HubSpot تنسيق الجداول داخل مقال قاعدة المعرفة، ولذلك يحتاج كل جدول إلى إعادة تنسيق يدوية في الطرف الآخر
لا يدعم استيراد HubSpot تنسيق الجداول داخل مقال قاعدة المعرفة، ولذلك يحتاج كل جدول إلى إعادة تنسيق يدوية في الطرف الآخر
المزامنة التفاضلية (Delta Sync) هي ما يجعل التحويل دون توقف ممكناً أصلاً
فبدونها إما أن يتوقف إنشاء التذاكر طوال الفجوة أو تضيع بعض البيانات فيها بصمت
أسئلة
من Freshdesk إلى HubSpot: إجابات عن أسئلتكم
نعم. مزامنة بيانات ثنائية الاتجاه تشمل 3 كائنات. والنقل الذكي (Smart transfer) مدعوم. لكنها لا تعيد بناء إعداداتكم: تلك هي العناصر الـ33 الواردة أدناه.
عادةً خططوا لنطاق 2-6 أسابيع، مع أن المسار الذي تختارونه يغيّر هذا الرقم أكثر مما يغيّره الحجم وحده. يستغرق التصدير عبر CSV أياماً؛ وتغطي أداة ترحيل SaaS ما بين 1K-50K تذكرة في 2-4 أسابيع؛ وتستغرق السكربتات المنفذة ذاتياً (DIY) لما يزيد على 50K تذكرة 4-8 أسابيع؛ أما الخدمة الاحترافية فتعود إلى 2-4 أسابيع أياً كان الحجم. يتحدد التعقيد بعمق الأتمتة والتقارير وليس بعدد السجلات: فالموصّل ينقل السجلات، ولذلك لا تطيل قاعدة البيانات الكبيرة وحدها المدة.
من بين 59 ميزة وثّقناها، تنتقل 26 ميزة (44%) مباشرة، وتنتقل 30 (51%) جزئياً، أي أن شيئاً منها يضيع أو يتغير شكله في الطريق. و3 ميزات ليس لها مقابل في HubSpot في أي باقة، وهذا يستحق إثارته قبل التوقيع وليس بعده.
يجب إعادة بناء 33 عنصراً يدوياً، و9 قيود موثّقة لا يُظهرها الموصّل إطلاقاً. القائمتان كاملتان في هذه الصفحة لمن يتولى تحديد نطاق العمل.
مجاني للمزامنة الأساسية. وData Hub Starter فما فوق لربط الحقول المخصصة.
3: Community Forums وFreddy Thank You Detector وField Service Management. إذا كان فريقكم يعتمد على إحداها فاحسموا أمرها قبل التوقيع بدلاً من اكتشافها لحظة التحويل (cutover)، حين لا يبقى بديل سوى التطوير المخصص.
لا. بند واحد (1) في هذه الصفحة من شيفرة Freshdesk أو منتجاتها نفسها، ولا ينقله ترحيل HubSpot ولا ساعات له في أي تقدير يُعطى لكم. ومع ذلك يحتاج إلى قرار قبل التحويل (cutover)، لأنكم أنتم من يتخلى عن شيء.
في اتجاه واحد فقط. المزامنة هنا ليست ثنائية الاتجاه، لذا يعني تشغيل النظامين معاً اختيار نظام سجل مرجعي منذ البداية وقبول تباعد البيانات في النظام الآخر.
هل أنت مستعد للبدء؟
خطّط لعملية الترحيل
أخبرنا بالمنصة التي تنتقل منها، وحجم التخصيص فيها، والموعد الذي تحتاج فيه إلى العمل على HubSpot. وسنوضح لك ما ينتقل مباشرة، وما يحتاج إلى إعادة بناء، والمدة التي يستغرقها الانتقال فعلياً.