مرجع الترحيل
ترحيل Zendesk Support إلى HubSpot
ما الذي ينتقل فعلًا، وما الذي لا ينتقل دون أن يظهر ذلك، وما الذي يجب إعادة بنائه يدويًا.
طابقنا Zendesk Support مع HubSpot ميزةً بميزة: 75 ميزة، و4 كائنات تُزامَن، و9 فخاخ موثقة، و26 بندًا يجب إعادة بنائه. الخريطة كاملة في هذه الصفحة، دون أي نموذج تسجيل.
ملف PDF هو المرجع نفسه، بصيغة تناسب ملف المشتريات.
احصل على المرجع والحاسبة
مرجع Zendesk Support إلى HubSpot كاملًا بصيغة PDF، مع حاسبة Excel التي نعتمدها في تحديد نطاق هذه الترحيلات: كل ميزة من الميزات الـ 75 في صف مستقل، تُدخل أعدادك فتحصل على عدد الساعات.
ثلاثة ملفات: المرجع بصيغة PDF، والمرجع نفسه بصيغة Markdown لأداة الذكاء الاصطناعي لديك، وحاسبة الجهد الكاملة بصيغة Excel.
ترحيل Zendesk Support إلى HubSpot ترحيل متوسط إلى مرتفع التعقيد، وتستغرق مدته عادةً من 2-5 أسابيع، ويتأثر هذا الرقم بحجم البيانات والحقول المخصصة وتعقيد الأتمتة. تنتهي Smart Transfer نفسها خلال أيام بعد أن تبدأ؛ أما ما يطيل الجدول الزمني فهو مسار السكربت المخصص عند 100K+ تذكرة، إذ يستغرق التنفيذ 3-5 أيام، لكن بعد 1-2 أسبوع من أعمال التحضير تسبقه. من بين الميزات الـ 75 التي طابقناها، تنتقل 26 ميزة كما هي، وتصل 43 ميزة منقوصة بشيء ما: أما البنود الـ 26 التي لا ينقلها أي شيء نيابةً عنك فهي التي ستحدد جدولك الزمني فعلًا، لا المزامنة.
بطاقة تقييم الترحيل
- تعقيد الترحيل
- متوسط إلى مرتفع
- الجدول الزمني المعتاد
- من 2-5 أسابيع، ويتأثر هذا الرقم بحجم البيانات والحقول المخصصة وتعقيد الأتمتة. تنتهي Smart Transfer نفسها خلال أيام بعد أن تبدأ؛ أما ما يطيل الجدول الزمني فهو مسار السكربت المخصص عند 100K+ تذكرة، إذ يستغرق التنفيذ 3-5 أيام، لكن بعد 1-2 أسبوع من أعمال التحضير تسبقه.
- الطريقة الموصى بها
- Smart Transfer هي الأداة المناسبة للترحيل البسيط، أي ما دون 5K تذكرة. وما بعد ذلك، أي حين تتعامل مع 50K+ تذكرة، أو صور مضمّنة، أو Side Conversations، أو متطلب سلامة صارمة للبيانات، فالجواب الصريح هو سكربتات API مخصصة بدلًا منها: لم تُصمَّم Smart Transfer لهذا الطرف من النطاق.
- المزامنة الأصلية
- مزامنة بيانات، في الاتجاهين
- Smart Transfer
- مدعومة
- اشتراك HubSpot
- مجاني للمزامنة الأساسية. Data Hub Starter+ لمطابقة الحقول المخصصة.
تكافؤ الميزات عبر 75 قدرة
- يقابله مباشرة: 26 (35%)
- يقابله جزئياً: 43 (57%)
- لا مقابل له: 6 (8%)
4
كائنات تُزامَن أصليًا
9
قيود وفخاخ
26
بنود إعادة بناء يدوية
2
إصدارات المصدر المشمولة
مصدر هذه المعلومات: مجموعة أبحاثنا الخاصة، جرى التحقق منها بتاريخ 2026-07-31، وهي أساس كل رقم في هذه الصفحة.
الكائنات الأربعة التي تُزامَن أصليًا
ما ينقله الموصل نيابةً عنك، واتجاه تدفق كل كائن.
Users
في الاتجاهينيصبح Contacts
تعتمد المطابقة على عنوان البريد الإلكتروني، والتطبيق الذي بنته Zendesk لعرض الجدول الزمني (timeline app) لا ينقل هذا العنوان إلا لحظة إنشاء سجل المستخدم أول مرة، ولا ينقل الاسم الأول ولا الاسم الأخير: فهذان لا يصلان إلا عبر تطبيق Data Sync المنفصل. وقد يكفي صندوق بريد مشترك أو عنوان جرى تغييره لكسر المطابقة في أي من التطبيقين، وصناديق البريد المشتركة شائعة بما يكفي في مكاتب الدعم الإقليمية بحيث ينبغي التحقق منها قبل الإطلاق لا بعده.
Organizations
في الاتجاهينيصبح Companies
يُطابَق كائن Organizations في Zendesk مع Companies في HubSpot على أساس النطاق (domain) أو الاسم، أيهما تعتمده المطابقة الافتراضية، وهي القاعدة نفسها التي تجمع شركة قابضة وكياناتها في المناطق الحرة خلف نطاق واحد مشترك. حدّد قبل تشغيل المزامنة الأولى، لا بعدها، أي الكيانات يجب أن تبقى منفصلة فعلًا لأغراض التقارير على مستوى الكيان.
Tickets
إلى HubSpotيصبح Tickets
تنتقل التذاكر في اتجاه واحد، من Zendesk إلى HubSpot، ولا تنتقل المؤرشفة منها إطلاقًا. يضع التطبيق الذي بنته Zendesk بيانات التذكرة على الجدول الزمني لجهة الاتصال؛ أما تطبيق Data Sync المنفصل فهو الذي ينشئ فعليًا سجلات التذاكر في HubSpot، ولا يتيح أي منهما تخصيص المعلومات المعروضة. وفي الحالتين تظهر التذكرة على الجدول الزمني لجهة الاتصال وحدها: فلن تظهر على الجدول الزمني للشركة ولا على صفقة، وهذا مهم حيثما كان الشخص الذي يرفع الحالة والحساب الذي يدفع ثمنها سجلين مختلفين داخل هيكل موزِّع أو مجموعة شركات.
Ticket Events
إلى HubSpotيصبح Timeline Activities
يدفع التطبيق الذي بنته Zendesk، HubSpot for Zendesk Support، هذه الأحداث إلى الجدول الزمني لجهة الاتصال المطابقة بوصفها نشاطًا ثابت الشكل، ولا يمكن تخصيص حمولة JSON الكامنة وراء هذا النشاط: يظهر ما قرر التطبيق إظهاره لا أكثر.
تسعة أمور لا تخبرك بها المزامنة
كل أمر منها موثق، وكل أمر منها أنهى ترحيلًا في أسبوع سيئ.
مزامنة التذاكر في اتجاه واحد فقط
إذا أنشأ أحد من جهة الحسابات حالة أو حدّثها من داخل HubSpot لا من مكتب الدعم نفسه، فلن تصل إلى Zendesk من تلقاء نفسها: المزامنة الأصلية تعمل في اتجاه واحد فقط، من Zendesk إلى HubSpot، ولا يوجد مسار عكسي مدمج. وسدّ هذه الفجوة يتطلب Zapier أو Make أو وسيطًا (middleware) مخصصًا يُبنى لهذا الغرض.
الحل البديل: بناء التدفق العكسي بـ Zapier أو Make مشروع أتمتة صغير قائم بذاته، لا إعدادًا يكفي تفعيله: احسب له ميزانية بوصفه عملًا حقيقيًا حيثما كان مطلوبًا من فريق الحسابات رفع تذكرة Zendesk من داخل HubSpot.
التذاكر المؤرشفة لا تُزامَن
إذا أرشفت تذكرة في Zendesk خرجت كليًا من مسار Data Sync: لا يصل أي من هذا التاريخ إلى HubSpot عبر التكامل الأصلي. وحيثما كان سجل محادثة WhatsApp مع سجل التذكرة معًا هو الملف الذي تُحسَم منه نزاعات SLA، فإن هذا التاريخ المغلق والمؤرشف هو بالضبط ما ستبحث عنه أي مراجعة لاحقة.
الحل البديل: Smart Transfer أو سكربت API مخصص هما الطريقان لإعادة هذا التاريخ المؤرشف، ويجب أن يُنفَّذ أيٌّ منهما خطوةً مقصودة ومخططًا لها، لا فكرةً لاحقة حين يسأل أحدهم أين ذهبت حالة قديمة.
سلاسل المحادثات لا تُحفَظ في عرض Help Desk
توقع أن يُقرأ التاريخ المستورد كمجموعة ملاحظات على الجدول الزمني لا كمحادثة: لا يعيد HubSpot Help Desk بناء تبادل متسلسل من تذكرة مستوردة. وعميل يدخل إلى portal ليراجع حالة سابقة لن يجد هناك شيئًا، وكذلك الموظف الذي يتلقى مكالمته التالية.
الحل البديل: لا يوجد حل هنا، بل قرار يجب اتخاذه وإبلاغه: اقبل صيغة ملاحظات الجدول الزمني للمحادثات التاريخية، وأبلغ الفريق بذلك بوضوح قبل الإطلاق، بدل أن يكتشفه أحدهم في منتصف مكالمة مع عميل.
المطابقة بالبريد الإلكتروني وحده تُنتج مخاطر التكرار
تعتمد كل مطابقة لجهة اتصال على عنوان البريد الإلكتروني وحده، فقد يتسبب صندوق بريد مشترك أو عنوان جرى تغييره أو جهة اتصال مدموجة سابقًا في سجل مكرر أو في إخفاق المطابقة. وحيثما كان طابور الدعم يتغذى من WhatsApp بقدر ما يتغذى من البريد، فإن نسبة معتبرة من Users في Zendesk قد تحمل أصلًا عنوانًا مشتركًا أو عامًا، وهنا يتركز التكرار.
الحل البديل: حدّد قواعد إزالة التكرار قبل أن ينتقل أي سجل، ثم نفّذ تدقيق ما بعد المزامنة وجولة الدمج في كل الأحوال: وتوقع أن تكشف تكرارات أكثر مما تتنبأ به قاعدة مطابقة البريد وحدها.
مطابقة الحقول المخصصة تتطلب Data Hub
المطابقة التي يوفرها HubSpot افتراضيًا تغطي الاسم والبريد الإلكتروني والهاتف والنطاق، وتتوقف عند ذلك؛ وأي حقل أضيف بعدها، مثل رقم الرخصة التجارية أو حقل الإمارة أو مرجع العقد، يحتاج إلى اشتراك Data Hub Starter أو أعلى قبل أن يُطابَق أصلًا.
الحل البديل: Data Hub Starter بسعر 20 دولارًا شهريًا هو الفئة التي تتيح مطابقة الحقول المخصصة، ومكانه في طلب الميزانية الأصلي: فاكتشاف بند متكرر بعد الاعتماد هو ما يحوّل خطوة قصيرة إلى دورة موافقات طويلة في هذه السوق.
الصور المضمّنة تتعطل بعد إلغاء Zendesk
إذا ألغيت اشتراك Zendesk توقفت كل صورة مضمّنة داخل تعليق تذكرة عن التحميل، وبشكل دائم، لأن هذه الصور تقيم على CDN الخاص بـ Zendesk ولا تنتقل مع التذكرة. ونقلها قبل ذلك يعني تنزيل كل صورة وإعادة رفعها إلى HubSpot File Manager وإعادة كتابة الرابط داخل HTML.
الحل البديل: يجب أن يتولى سكربت مخصص التنزيل وإعادة الرفع إلى HubSpot وإعادة كتابة الرابط، ويجب أن ينتهي قبل أن ينتهي اشتراك Zendesk: لا سبيل إلى إصلاح رابط صورة معطّل بعد زوال حساب المصدر.
Side Conversations ليس لها مقابل في HubSpot
Side Conversations، وهي السلاسل الموازية التي تديرها Zendesk مع مورّد أو إدارة أخرى أو زميل داخلي عبر البريد أو Slack أو Teams بجانب التذكرة الرئيسية، ليس لها ما تنزل عليه في HubSpot: لا يوجد كائن مقابل. ويجب تسطيح كل سلسلة يدويًا إلى ملاحظة خاصة (private note) تُكتب في متنها أسماء المشاركين والطوابع الزمنية وبيانات القناة. وفي مكتب دعم مشترك بين أكثر من سوق خليجية، كثيرًا ما تكون هذه القناة الجانبية هي المكان الذي يقوم فيه التنسيق بين فرق الدول فعلًا، فيفقد ضياع بنية السلسلة سجل التنسيق معها.
الحل البديل: حوّل كل سلسلة Side Conversation إلى ملاحظة تحمل المشاركين والطوابع الزمنية والقناة قبل أن تنتقل التذكرة، وعامل ذلك بوصفه عمل إنتاج مُحدَّد النطاق بتقدير زمني خاص به، لا حاشية على ترحيل التذكرة.
أولوية 'Urgent' في Zendesk ليس لها مقابل أصلي في HubSpot
تعتمد Zendesk أربعة مستويات للأولوية: Low وNormal وHigh وUrgent؛ أما HubSpot فثلاثة: Low وMedium وHigh، دون شيء فوق High. وأي تذكرة تحمل علامة Urgent، من النوع الذي يتعامل معه عقد مرتبط بـ SLA بوصفه فئة قائمة بذاتها، تفقد هذا التمييز لحظة وصولها ما لم يُبنَ شيء يحتفظ به.
الحل البديل: حوّل Urgent إلى High واحمل التمييز الأصلي في خاصية مخصصة أو وسم: فبند SLA مكتوب حول مستوى Urgent يحتاج إلى أن تبقى هذه العلامة موجودة في مكان يمكن إعداد تقارير عنه بعد الترحيل.
فخ الطابع الزمني في Incremental Export
يتحقق Incremental Export في Zendesk من generated_timestamp للتذكرة مقابل start_time لديك، لا من قيمة updated_at، وبناء مزامنة delta حول updated_at بدلًا منه سيفقد سجلات أو يكررها دون أن يظهر ذلك. يبدو الحقلان قابلين للتبادل إلى أن يعمل التصدير على طابور كبير أو مزدحم، وهنا بالضبط يظهر الفرق.
الحل البديل: تتبّع كل مزامنة delta مقابل generated_timestamp، لا updated_at أبدًا، ودوّن هذه القاعدة في مكان سيراه فعلًا من يشغّل التصدير التزايدي التالي.
ست ميزات في Zendesk Support لا يستطيع HubSpot تعويضها
لا يوجد حل بديل يسد هذه الفجوات. كل واحدة منها قدرة ستتخلى عنها، فحدّد من في الشركة يستطيع الاستغناء عنها قبل أن تلتزم بموعد.
مشاركة التذاكر (Multi-Instance)
لا يوفر HubSpot مشاركة تذاكر أصلية بين عدة نسخ (multi-instance). وهذا يتطلب تكاملًا مخصصًا أو اعتماد portal مشترك.
ترتيب تنفيذ Business Rules
لا يملك HubSpot ما يطابق التنفيذ المرتّب للـ triggers في Zendesk: تعمل الـ workflows مستقلة عن بعضها، بالتوازي، دون تسلسل مضمون بينها. وحيثما تعاملت عدة workflows مع التذكرة نفسها، فإن غياب الترتيب هو موضع ظهور التعارضات فعلًا، فخطّط له بدلًا من افتراض أن HubSpot سيحسم الأمر بالطريقة نفسها التي كانت تحسمه بها فئات الـ triggers في Zendesk.
Sunshine Conversations (المراسلة الموحدة)
لا شيء في HubSpot يعوّض طبقة مراسلة واحدة تمتد عبر 30 قناة وأكثر كما تفعل Sunshine Conversations: توجد اتصالات قنوات فردية قائمة بذاتها، لكن لا توجد منصة موحدة تربطها، فالنطاق الحقيقي هنا هو إعادة بناء قناة بقناة، لا استبدالًا متكافئًا.
منتديات المجتمع (Gather)
لا مكان أصليًا لمنتديات المجتمع داخل HubSpot Service Hub: يجب أن يتولى هذه الوظيفة منتج طرف ثالث مثل Discourse أو Vanilla Forums، أو منصة المجتمع الخاصة بـ HubSpot، وجدير بالذكر أنها منتج منفصل لا يتكامل بدوره مع Service Hub.
Content Blocks (كتل المحتوى)
مقال قاعدة المعرفة الذي يُكتب مرة ويُعاد استخدامه في مقالات أخرى لا مسار له في KB الخاص بـ HubSpot: نظام كتل المحتوى القابلة لإعادة الاستخدام الذي تسميه Zendesk Content Blocks غير موجود ببساطة. أما Content Hub ففيه وحدات محتوى عامة (global content modules)، لكنها لا تمتد إلى مقالات KB، فتبقى هذه الفجوة حتى في الفئة الأعلى.
لوحة متابعة الوكلاء المباشرة (Live Agent Dashboard)
من يدير أرضية الدعم لديك يفقد هنا الرؤية الفورية لحالة الوكلاء وعمق الطابور والمحادثات المباشرة: تعطي Inbox overview في HubSpot إحساسًا ببعض النشاط، لكنها ليست مبنية للمراقبة التشغيلية الفورية كما هي لوحة متابعة الوكلاء المباشرة. وعلى أداة من طرف ثالث أو لوحة مبنية خصيصًا أن تسد هذه الفجوة لقائد الفريق الذي يحتاج إلى رؤية ما يجري لحظة بلحظة.
البنود الـ 26 التي تُعاد بناؤها يدويًا
هذه هي القائمة التي تفرّق بين عرض سعر يصمد وعرض لا يصمد.
البيانات والكائنات
Ticket Pipelines والحالات (Statuses)
مسار التذاكر (ticket pipeline) هو تسلسل الحالات الذي تمر به الحالة فعلًا في Zendesk، ويحتاج HubSpot إلى نسخته الخاصة منه قبل أن يعتمد عليها أي شيء.
في HubSpot: Ticket pipelines and stages
اضبط الـ pipeline قبل بدء الاستيراد: أي تذكرة تصل قبل وجوده تصل إلى المرحلة الافتراضية أيًا كان موضعها في Zendesk، وإعادة فرز مئات التذاكر يدويًا بعد ذلك ليست خطوة تستحق أن تستدعيها.
حقول التذاكر المخصصة
حقل التذكرة المخصص هو أي تفصيل صُمّم نموذج التذكرة لالتقاطه فوق الحقول الافتراضية، ويجب إعادة إنشاء كل واحد منها خاصيةً (property) مستقلة في HubSpot.
في HubSpot: Custom ticket properties
أنشئ كل حقل مسبقًا قبل تشغيل الاستيراد: أي حقل ينشأ أثناء الاستيراد يصل نصًا عاديًا، فيفقد نوعه وقائمة خياراته، وهذا بالضبط ما يصيب حقلًا يحمل قيم الإمارة أو الجنسية أو نوع العقد المدخلة يدويًا على مدى سنوات.
الوسوم (Tags)
الوسم (tag) هو ما يجمع التذاكر ذات الصلة في Zendesk، وهو في كثير من الإعدادات ما يراقبه الـ trigger فعلًا، ولذلك يجب فهم دوره قبل أن يمكن إعادة بنائه.
في HubSpot: A multi-select ticket property
لا تحمل تذاكر HubSpot كائن وسوم أصليًا، فيتحول كل وسم في Zendesk إلى قيمة داخل خاصية واحدة متعددة الاختيار (multi-select). وحيثما كان وسم يحرّك trigger بصمت، يجب أن تصبح هذه القيمة حقلًا حقيقيًا يستطيع الـ workflow قراءته، وإلا توقفت الأتمتة التي يغذيها عن العمل دون أن يلاحظ أحد حتى تفوت تذكرة.
تقييمات الرضا (Satisfaction Ratings)
تقييم الرضا هو درجة CSAT والتعليق المسجلان على تذكرة جرى حلها، ويحتاج هذا التاريخ إلى مكان في HubSpot قبل أن يمكن إعداد تقارير عنه مجددًا.
في HubSpot: A custom property, with feedback surveys going forward
لا يوفر HubSpot حقل CSAT أصليًا على التذكرة، فتنزل الدرجات التاريخية في خاصية مخصصة، بينما يأتي كل تقييم يُجمع بعد ذلك عبر أداة الاستبيانات. وهذا يترك مؤشرًا واحدًا في مكانين، وعلى أي لوحة تقيس الرضا أن تُبنى لتقرأ المكانين معًا بدل أن تختار أحدهما وتُسقط الآخر بصمت.
Side Conversations (المحادثات الجانبية)
Side Conversations هي السلاسل الموازية التي تحملها التذكرة مع مورّد أو طرف آخر خارج علاقة مقدّم الطلب تمامًا، وتُحفَظ بجانب السجل الرئيسي، ولا توجد هذه البنية في HubSpot لتستقبلها.
في HubSpot: Private notes on the ticket
تُسطَّح إلى ملاحظات، مع كتابة المشاركين والطوابع الزمنية في المتن مباشرة، لأن HubSpot لا يعرف مفهوم السلسلة الموازية لتنزل فيها بدلًا من ذلك. نفّذ ذلك يدويًا للسلاسل المهمة بدلًا من تصدير شامل: فسلسلة جانبية خاصة بمناقصة أو مورّد تستحق العناية اليدوية، أما متابعة داخلية روتينية فلا تستحقها عادةً.
المجموعات (Groups)
تحدد المجموعة في Zendesk أي الوكلاء يرون تذكرة معينة أصلًا، ويُنظّم HubSpot هذه المسؤولية بطريقة مختلفة.
في HubSpot: Teams
يعامل HubSpot عضوية الفريق وملكية التذكرة أمرين منفصلين، فمطابقة مجموعة Zendesk مع Team في HubSpot لا تُسند بحد ذاتها تذكرة واحدة إلى أحد. وهذه الفجوة تفاجئ معظم الفرق في اليوم الأول، وأوضح ما تكون حيثما غطّى مكتب مشترك واحد طابور أكثر من دولة وافتُرض أن مطابقة الفريق وحدها ستفرز التذاكر حسب السوق.
الأتمتة
Triggers (المشغِّلات)
الـ trigger يُنفَّذ لحظة إنشاء تذكرة أو تغييرها، ويجب إعادة إنشاء كل قاعدة منها داخل HubSpot: لا ينتقل أي منها تلقائيًا.
في HubSpot: Workflows and routing rules
أعد بناءها قاعدةً قاعدة لا دفعةً واحدة بالاستيراد، لأن triggers في Zendesk تُنفَّذ بترتيب محدد، بينما لا تقدم workflows في HubSpot ضمانًا كهذا: فسلسلة triggers تعتمد على ذلك الترتيب يجب إعادة هيكلتها لا نسخها، وإلا انكسر بصمت التسلسل الذي تعتمد عليه عملية الدعم.
Automations (القواعد الزمنية)
الـ automation في Zendesk هي القاعدة المبنية على الزمن، من النوع الذي يُنفَّذ بعد ساعات أو أيام من استمرار شرط معين، وليس لها مسار استيراد مباشر إلى HubSpot كذلك.
في HubSpot: Ticket-based workflows with delays
تقيس المنصتان الزمن بطريقتين مختلفتين في العمق، فاختبر سلوك التأخير على تذاكر حقيقية، بما فيها تذاكر فُتحت قبيل عطلة رسمية أو تغيير ساعات العمل في رمضان، قبل أن تُترك قاعدة الإغلاق التلقائي تعمل دون إشراف.
Macros (الإجراءات المختصرة)
الـ macro هو النقرة الواحدة التي يضبط بها الوكيل عدة حقول ويدرج ردًا في آن واحد، وليس له مقابل واحد لواحد في HubSpot يُرحَّل إليه.
في HubSpot: Snippets, templates, workflows and help desk macros
ينقسم الـ macro الواحد إلى عدة كائنات في HubSpot: نص الرد يصبح snippet أو template، وتغييرات الحقول تصبح workflow. كما يضع HubSpot حدًا لعدد macros مكتب الدعم (help desk macros) أقل بكثير مما يتراكم في حساب ناضج على مدى سنوات، فاختر منها ما يستخدمه الوكلاء فعلًا بدلًا من نقل المكتبة كاملة، بما فيها macros الردود باللغة العربية، لأنها عادةً آخر ما يتذكر أحد فحصه.
سياسات SLA
تحدد سياسة SLA أهداف الاستجابة والحل بحسب نوع التذكرة أو بحسب من رفعها، ولا مسار تلقائيًا لهذه الأهداف إلى HubSpot كذلك.
في HubSpot: SLA settings and ticket workflows
أعد بناء الأهداف قبل معالجة الإخلال بها، واضبط ساعات العمل قبل الاثنين: وإن تخطيت ذلك قاست كل SLA على ساعة مسطحة من 24 ساعة، وهي الساعة الخاطئة منذ اللحظة التي يعمل فيها المكتب من الأحد إلى الخميس أو يقلّص ساعاته في رمضان. فالتزام بالاستجابة خلال أربع ساعات مقاسًا على أسبوع العمل الفعلي وعد مختلف عن وعد مقاس على ساعة لا تتوقف.
طرق العرض (Views)
الـ view هو الطابور المحفوظ الذي يعمل منه الوكيل طوال اليوم، ويحتاج إلى إعادة بنائه في HubSpot لا افتراض انتقاله.
في HubSpot: Saved ticket views
إعادة بنائه رخيصة ويستحق إنجازه قبل الإطلاق في كل الأحوال: فهو الشاشة التي يحدّق فيها الوكيل طوال مناوبته، وطابور لا يطابق طريقة فرز الفريق فعلًا بحسب السوق أو اللغة أو الكيان يكلّف احتكاكًا يوميًا أكثر من كلفة إعادة البناء نفسها.
التوجيه الدوري (Round-robin) والتوجيه بحسب المهارة
تحدد قواعد التوجيه أي وكيل تصل إليه التذكرة، بحسب التوفر أو المهارة، ولا ينتقل أي منهما تلقائيًا.
في HubSpot: Help desk routing rules
يجب أن يكون المستخدمون (Users) والفرق موجودين في HubSpot قبل أن تشير إليهم قواعد التوجيه، ولا يكشف الإعداد وحده ما إذا كانت القاعدة عادلة: اختبرها على تذاكر حقيقية، فالقاعدة التي تبدو متوازنة على الورق كثيرًا ما تكدّس طابور اللغة العربية على أي وكيل يتصادف أنه ثنائي اللغة.
التقارير
تقارير Zendesk Explore
Explore هي حزمة التقارير المبنية مباشرة فوق بيانات التذاكر في Zendesk، ولا ينتقل أي من تقاريرها كما هو مُعدّ.
في HubSpot: Custom reports
أعد بناء كل تقرير انطلاقًا من السؤال الذي كان يجيب عنه فعلًا لا من تخطيطه الدقيق، لأن Explore يعرض مؤشرات لا يسجلها HubSpot أصلًا. وقل بوضوح ومبكرًا أي التقارير لا يمكن إعادة إنتاجه إطلاقًا: فمجلس الإدارة الذي يتوقع تسليمًا مطابقًا يستحق أن يسمع ذلك قبل الإطلاق، لا أن يكتشفه في أول مراجعة بعده.
لوحات المتابعة المخصصة (Custom Dashboards)
لوحة المتابعة المخصصة تخطيط محفوظ لتقارير متكررة، ويلزم تجميعها من جديد بعد أن تصبح التقارير الأساسية موجودة في HubSpot.
في HubSpot: Dashboards
ابنِ اللوحة بعد التقارير لا قبلها: فالعكس يميل إلى تثبيت تخطيط لا تستطيع بيانات HubSpot المتاحة ملأه فعلًا، وهذا أمر محبط اكتشافه أول مرة يعرض فيها أحدهم اللوحة على الإدارة العليا.
تقارير الالتزام بـ SLA
تقرير الالتزام بـ SLA هو سجل الأهداف التي تحققت والتي فاتت، ويعتمد كليًا على أن تتم إعادة بناء SLA بالشكل الصحيح أولًا.
في HubSpot: SLA reporting
يعتمد هذا كليًا على أن تكون سياسات SLA وساعات العمل مضبوطة بشكل صحيح، فرتّبه بعد ذلك العمل بصرامة لا بالتوازي معه: فتقرير SLA مبني على ساعات عمل غير مضبوطة سيعرض إخلالات لم تحدث قط.
مقاييس أداء الوكلاء
تتتبع مقاييس أداء الوكلاء الحجم والحل وزمن الاستجابة لكل وكيل، ولا معنى للأرقام إلا حين يكون كل وكيل ممثَّلًا بشكل صحيح في HubSpot.
في HubSpot: Service analytics
يجب أن يُطابَق كل وكيل مع مستخدم حقيقي في HubSpot وقت الاستيراد، وإلا نُسبت المقاييس إلى لا أحد: تأكد من المطابقة لقادة الدول ووكلاء المكاتب المشتركة تحديدًا، لأن هذه الحسابات هي الأرجح أن تفتقر إلى مطابقة نظيفة واحد لواحد.
إعدادات المبيعات والتسويق
نماذج طلبات الدعم
نموذج طلب الدعم هو الطريقة التي يفتح بها العميل حالة فعلًا، ويجب إعادة بنائه في HubSpot قبل أن يُسحب النموذج القديم.
في HubSpot: Forms
أعد بناءه، واستبدل كل تضمين في الموقع لحظة التحويل النهائي: فإن تُركت صفحة واحدة تشير إلى النموذج القديم استمرت الطلبات في الوصول إلى نظام لم يعد أحد يراقبه. وابنِ النسخة العربية نموذجًا مستقلًا مصممًا من اليمين إلى اليسار، لا نموذجًا إنجليزيًا أُسقطت فيه تسميات حقول مترجمة.
تدفقات الدردشة وأدواتها (Chat Flows and Widgets)
تشمل تدفقات الدردشة وأدواتها تجربة الدردشة على الموقع نفسها ومنطق التوجيه الكامن وراءها، وواحد فقط من الاثنين يُستبدل سريعًا.
في HubSpot: Live chat and the chatbot builder
تُستبدل الأداة نفسها بسهولة؛ أما منطق المحادثة الكامن وراءها فهو العمل الحقيقي، ومن الأجدى إعادة بناء التوجيه قبل إنفاق الوقت على التصميم. وابنِ مسارًا يمكن أن ينتهي بتحويل إلى WhatsApp، لأنه كثيرًا ما يكون المكان الذي يرتاح العميل الخليجي لمواصلة الحديث فيه أكثر من دردشة مضمّنة في الموقع.
مركز المساعدة وبوابة العملاء
مركز المساعدة هو قاعدة المعرفة العامة؛ وبوابة العملاء هي المكان المنفصل بتسجيل الدخول الذي يتتبع فيه العميل حالاته الخاصة، ويجب التعامل معهما مشروعين مختلفين.
في HubSpot: Knowledge base and customer portal
عامِلهما منتجين لا منتجًا واحدًا. يمكن نقل محتوى المقالات بشكل مباشر نسبيًا، بنسختيه العربية والإنجليزية، أما صلاحيات البوابة وهويتها البصرية فبناء منفصل تمامًا، وهنا بالذات يجب أن تُصمَّم تجربة قراءة ثنائية اللغة من اليمين إلى اليسار لا أن تُفترض.
قوالب الرد على التذاكر
قالب الرد على التذكرة هو أي رد قياسي يرسله الوكلاء، ولا ينجو أي منه من النقل دون أن يُعاد بناؤه يدويًا.
في HubSpot: Email templates and snippets
أعد بناء كل واحد يدويًا: تحمل رموز التخصيص (personalisation tokens) أسماء مختلفة بين المنصتين ولن تنتقل ببساطة. واحتفظ بالنسختين العربية والإنجليزية قالبين منفصلين لا قالبًا واحدًا بمفتاح لغة، لأن التحية واللقب الاحترامي وخاتمة الرسالة تختلف بينهما بما يكفي ليبدو القالب المشترك خاطئًا في إحداهما عادةً.
المستخدمون والصلاحيات
أدوار المستخدمين وصلاحياتهم
تغطي أدوار المستخدمين وصلاحياتهم مستويات الوصول التي تقدمها Zendesk: وكيل ومشرف ووكيل خفيف (light agent)، ونموذج HubSpot نفسه ليس انعكاسًا لها.
في HubSpot: Users and permission sets
لا يوجد لوكيل Zendesk الخفيف مقابل مطابق تمامًا في HubSpot، فاقرر شخصًا بشخص ما إذا كان كل منهم يحتاج فعلًا إلى مقعد كامل قبل احتساب التراخيص وتسعيرها: الخطأ هنا إما إنفاق زائد على مقاعد لا تُستخدم كاملة، أو فجوة تُكتشف حين يفقد أحدهم الوصول في منتصف مناوبته.
مجموعات الوكلاء وإسنادات الفرق
تحدد مجموعات الوكلاء وإسنادات الفرق كيف يُجمَّع الوكلاء للتوجيه وللرؤية معًا، وتحتاج هذه البنية إلى إعادة بناء مدروسة لا نسخ حرفي.
في HubSpot: Teams
طابِق الغاية من البنية القديمة بدل نسخها حقلًا بحقل: النسخ الحرفي يفرط عادةً في التقييد، وأوضح ما يكون ذلك في مجموعة متعددة الكيانات يجد فيها وكيل مركز دبي نفسه عاجزًا عن رؤية سجل عميل سعودي تسمح له السياسة برؤيته فعلًا.
ساعات العمل والجداول
ساعات العمل والجداول هي ساعات التشغيل وتقويم العطلات اللذان تقيس عليهما كل ساعة SLA، ولذلك لا يوثق بشيء من تقارير SLA قبل ضبط هذا بشكل صحيح.
في HubSpot: Business hours settings
هذه مهمة إعداد صغيرة لكن أثرها كبير جدًا: كل SLA يُقاس عليها، فاضبطها قبل سياسات SLA نفسها لا بعدها. ابنِها حول أسبوع العمل الذي يلتزم به المكتب فعلًا، من الأحد إلى الخميس في معظم دول الخليج، مع ساعات رمضان وعطلات كل سوق الرسمية، لأن جدولًا يفترض أسبوعًا من الاثنين إلى الجمعة سيخطئ في تقدير كل ساعة SLA تعمل في المنطقة.
التكاملات
إعدادات تطبيقات Marketplace
تطبيقات Marketplace هي ما يوسّع مساحة عمل وكيل Zendesk إلى ما بعد المنتج الأساسي، ويحتاج كل منها قرارًا خاصًا لا نقلًا شاملًا.
في HubSpot: App Marketplace integrations, or Zapier and Make
أحصِ ما هو مستخدم فعلًا قبل أن تقرر ما يُعاد بناؤه: معظم حسابات Zendesk الناضجة تحمل تطبيقات لم يفتحها أحد في الفريق الحالي منذ عام، ولا مبرر لدفع كلفة إعادة بناء لأي منها.
تكاملات القنوات
تكاملات القنوات هي ما يغذي الطابور أو ينبهه، ومنها Slack وTeams وقنوات التواصل الاجتماعي، ويحتاج كل اتصال إلى إعادة وصله على حدة لا ترحيلًا كمجموعة.
في HubSpot: Connected channels and integrations
أعد وصل كل قناة بمفردها، وتحقق بعد ذلك من أنها ما زالت تنشئ تذكرة لا مجرد إرسال إشعار: هذا التراجع الصامت شائع، وهو النوع نفسه من الفجوات الذي يظهر في رسالة WhatsApp أو رسالة اجتماعية لم يرها أحد في الطابور قط.
تكاملات الهاتف والصوت
تكامل الهاتف والصوت هو مزوّد الاتصالات الذي يقف خلف الدعم الصوتي، ويجب التأكد من توافقه مع HubSpot قبل أن يعتمد عليه أي شيء آخر في الخطة.
في HubSpot: HubSpot calling providers
تأكد من أن لدى المزوّد تكاملًا عاملًا مع HubSpot قبل توقيع العقد لا بعده: فقد يختلف سلوك تسجيل المكالمات وتوثيقها حتى مع بقاء المزوّد نفسه، ويهم هذا الاختلاف حيثما تُحفظ التسجيلات ضمن سجل SLA أو سجل الامتثال.
التسلسل
زامِن أولًا، ثم رحّل
الترتيب هو المضمون هنا. هذه الخطوات سلسلة اعتماد متبادل، وتنفيذها خارج التسلسل طريقة موثقة يفشل بها هذا النوع من الترحيل.
- 1
دقّق أعداد كائنات Zendesk وحقولها المخصصة وجرد الأتمتة، مع تخصيص مراجعة مستقلة لحقول التذاكر ثنائية اللغة وmacros اللغة العربية حتى لا يفوت شيء بُني للمنطقة بسبب جرد يُجرى بالإنجليزية وحدها
دقّق أعداد كائنات Zendesk وحقولها المخصصة وجرد الأتمتة، مع تخصيص مراجعة مستقلة لحقول التذاكر ثنائية اللغة وmacros اللغة العربية حتى لا يفوت شيء بُني للمنطقة بسبب جرد يُجرى بالإنجليزية وحدها
- 2
ابنِ pipelines والخصائص المخصصة والـ Teams في HubSpot لتعكس بنية Zendesk، وقرر في هذه المرحلة لا لاحقًا ما إذا كان المكتب الإقليمي المشترك يحتاج إلى فريق واحد لكل سوق أو فريق واحد يغطي عدة أسواق
ابنِ pipelines والخصائص المخصصة والـ Teams في HubSpot لتعكس بنية Zendesk، وقرر في هذه المرحلة لا لاحقًا ما إذا كان المكتب الإقليمي المشترك يحتاج إلى فريق واحد لكل سوق أو فريق واحد يغطي عدة أسواق
- 3
أضف حقولًا مخصصة لمعرّف المصدر (source ID) لتتبع مزامنة delta والمطابقة، وهي السجل المطلوب إذا سأل نزاعٌ لاحقًا عن اللحظة التي انتقلت فيها تذكرة بعينها
أضف حقولًا مخصصة لمعرّف المصدر (source ID) لتتبع مزامنة delta والمطابقة، وهي السجل المطلوب إذا سأل نزاعٌ لاحقًا عن اللحظة التي انتقلت فيها تذكرة بعينها
- 4
أعد بناء macros يدويًا على هيئة snippets وtemplates، وtriggers على هيئة workflows، وSLAs داخل HubSpot، مع ضبط ساعات العمل بحسب أسبوع العمل الإقليمي الفعلي قبل تحديد أي هدف SLA
أعد بناء macros يدويًا على هيئة snippets وtemplates، وtriggers على هيئة workflows، وSLAs داخل HubSpot، مع ضبط ساعات العمل بحسب أسبوع العمل الإقليمي الفعلي قبل تحديد أي هدف SLA
- 5
أنشئ مستخدمي HubSpot مطابقين لوكلاء Zendesk بحسب عنوان البريد الإلكتروني، وأكّد المطابقة مع كل قائد دولة لا مع قائمة المستخدمين وحدها، لأن الشخص نفسه قد يحمل عنوانين أو ثلاثة عبر مجموعة متعددة الكيانات
أنشئ مستخدمي HubSpot مطابقين لوكلاء Zendesk بحسب عنوان البريد الإلكتروني، وأكّد المطابقة مع كل قائد دولة لا مع قائمة المستخدمين وحدها، لأن الشخص نفسه قد يحمل عنوانين أو ثلاثة عبر مجموعة متعددة الكيانات
- 6
ثبّت تطبيقي التكامل معًا: التطبيق الذي بنته Zendesk لعرض الجدول الزمني وتطبيق HubSpot Data Sync، لأن كلًا منهما ينقل نصفًا مختلفًا من البيانات
ثبّت تطبيقي التكامل معًا: التطبيق الذي بنته Zendesk لعرض الجدول الزمني وتطبيق HubSpot Data Sync، لأن كلًا منهما ينقل نصفًا مختلفًا من البيانات
- 7
نفّذ الترحيل الجماعي بالترتيب: Contacts، ثم Companies، ثم Tickets مع روابطها (associations)، ثم الملاحظات، ثم الملفات، لأن تنفيذه خارج الترتيب هو الموضع الذي تفشل فيه الروابط في الارتباط دون أن يظهر ذلك
نفّذ الترحيل الجماعي بالترتيب: Contacts، ثم Companies، ثم Tickets مع روابطها (associations)، ثم الملاحظات، ثم الملفات، لأن تنفيذه خارج الترتيب هو الموضع الذي تفشل فيه الروابط في الارتباط دون أن يظهر ذلك
- 8
نفّذ مزامنة delta بعد ذلك لالتقاط كل ما أُنشئ أو حُدّث في Zendesk خلال نافذة الترحيل الجماعي نفسها
نفّذ مزامنة delta بعد ذلك لالتقاط كل ما أُنشئ أو حُدّث في Zendesk خلال نافذة الترحيل الجماعي نفسها
- 9
صدّر مقالات Knowledge Base واستوردها، وهو ما يدعمه HubSpot استيرادًا مباشرًا من Zendesk، مع التحقق من أن المقالات العربية تحمل تنسيقها من اليمين إلى اليسار بدلًا من أن تصل نصًا عاديًا بلا تنسيق
صدّر مقالات Knowledge Base واستوردها، وهو ما يدعمه HubSpot استيرادًا مباشرًا من Zendesk، مع التحقق من أن المقالات العربية تحمل تنسيقها من اليمين إلى اليسار بدلًا من أن تصل نصًا عاديًا بلا تنسيق
- 10
حوّل توجيه الوكلاء إلى HubSpot وعطّل إشعارات Zendesk وtriggers، حتى لا تُشغّل التذكرة نفسها نظامين في آن واحد
حوّل توجيه الوكلاء إلى HubSpot وعطّل إشعارات Zendesk وtriggers، حتى لا تُشغّل التذكرة نفسها نظامين في آن واحد
- 11
أبقِ Zendesk مفتوحًا بوضع القراءة فقط لمدة 30 يومًا مرجعًا، وهي مدة تكفي للإجابة عن الجولة الأولى من الأسئلة التي يُرجَّح أن تثيرها مراجعة إقليمية أو نزاع حول SLA
أبقِ Zendesk مفتوحًا بوضع القراءة فقط لمدة 30 يومًا مرجعًا، وهي مدة تكفي للإجابة عن الجولة الأولى من الأسئلة التي يُرجَّح أن تثيرها مراجعة إقليمية أو نزاع حول SLA
- 12
التحقق من النتيجة
تحقق من الروابط (associations) والصور المضمّنة والطوابع الزمنية وكل workflow أُعيد بناؤه، مع أخذ عينات متعمدة من التذاكر المكتوبة بالحرف العربي والأسماء المركبة بدلًا من الوثوق بعينة مبنية من السجلات الإنجليزية وحدها
عادةً من 2-5 أسابيع، ويتأثر هذا الرقم بحجم البيانات والحقول المخصصة وتعقيد الأتمتة. تنتهي Smart Transfer نفسها خلال أيام بعد أن تبدأ؛ أما ما يطيل الجدول الزمني فهو مسار السكربت المخصص عند 100K+ تذكرة، إذ يستغرق التنفيذ 3-5 أيام، لكن بعد 1-2 أسبوع من أعمال التحضير تسبقه. وذلك من البداية إلى النهاية، بحسب مقدار ما يُستخدم فعلًا من إعدادات المصدر.
مقدّر الجهد
ما حجم هذا الترحيل؟
مجموعة أسئلة قليلة، دون حاجة إلى تسجيل. تأتي النطاقات من البحث أعلاه: لكل ميزة طابقناها رقم جهد، وهذه الأداة تجمع الميزات التي تنطبق على نسختك.
الجهد التقديري
أجب عن سؤالين ليظهر هنا نطاق الساعات.
مبني على أبحاثنا حول 75 ميزة في Zendesk Support. إنه نطاق تقديري وليس عرض سعر.
نطاق للتخطيط وليس عرض سعر. وهو جهد التنفيذ فقط، دون بند لإدارة المشروع. وأكثر ما يحرّكه عمليًا هو جودة البيانات.
ما الذي يسوء في أغلب الأحيان
الإخفاقات التي تتكرر مرة بعد مرة، بترتيب ظهورها تقريبًا.
الصور المضمّنة تتعطل لحظة إلغاء اشتراك Zendesk
يجب إعادة استضافة كل صورة قبل التحويل النهائي لا بعده، إذ لا سبيل إلى إصلاح رابط ميت بعد زوال حساب المصدر
تضبط واجهة Zendesk Ticket Comments API القيمة include_inline_images على false افتراضيًا، فيجب تفعيلها صراحةً، وإلا فسيفتقد تصدير يبدو مكتملًا كل صورة مضمّنة دون أن يظهر ذلك
تضبط واجهة Zendesk Ticket Comments API القيمة include_inline_images على false افتراضيًا، فيجب تفعيلها صراحةً، وإلا فسيفتقد تصدير يبدو مكتملًا كل صورة مضمّنة دون أن يظهر ذلك
لا ترتبط الـ associations إلا بعد وجود الـ Contacts والـ Companies التي تشير إليها
أنشئها بترتيب خاطئ يفشل الربط بصمت، دون أن يظهر في السجل ما ينبه إليه لاحقًا
إذا أُغفل تاريخ النشاط (Activity date) في سجل مستورد فإن طابعه الزمني يأخذ افتراضيًا لحظة الاستيراد لا لحظة وقوعه فعلًا، وهذا يدمّر بصمت الدقة الزمنية التي تعتمد عليها مراجعة SLA أو النزاع
إذا أُغفل تاريخ النشاط (Activity date) في سجل مستورد فإن طابعه الزمني يأخذ افتراضيًا لحظة الاستيراد لا لحظة وقوعه فعلًا، وهذا يدمّر بصمت الدقة الزمنية التي تعتمد عليها مراجعة SLA أو النزاع
يتوقف HubSpot CRM Search API عند 5 طلبات في الثانية، وحلقة ترحيل من نوع «ابحث ثم أنشئ» تختنق عند هذا الحد قبل وقت طويل من اقترابها من حد الذروة البالغ 190 طلبًا في الثانية (rps) الذي يخطط الجميع حوله بدلًا من ذلك
يتوقف HubSpot CRM Search API عند 5 طلبات في الثانية، وحلقة ترحيل من نوع «ابحث ثم أنشئ» تختنق عند هذا الحد قبل وقت طويل من اقترابها من حد الذروة البالغ 190 طلبًا في الثانية (rps) الذي يخطط الجميع حوله بدلًا من ذلك
افتراض غير ذلك هو ما يجعل مجموعة جزئية من التذاكر لا تصل أبدًا دون أن يظهر ذلك. تتبّع objectWriteTraceId لكل دفعة بدل افتراض نتيجة إما كلية أو معدومة، لأن استيراد الدفعات قد يفشل جزئيًا لا دفعة واحدة
افتراض غير ذلك هو ما يجعل مجموعة جزئية من التذاكر لا تصل أبدًا دون أن يظهر ذلك. تتبّع objectWriteTraceId لكل دفعة بدل افتراض نتيجة إما كلية أو معدومة، لأن استيراد الدفعات قد يفشل جزئيًا لا دفعة واحدة
دمج سجلين داخل HubSpot بعد الترحيل قد يكسر رابط المزامنة خلف أيٍّ منهما وينشئ مكانه سجلًا مكررًا جديدًا، فعامل الدمج بعد الترحيل أمرًا يُفحص لا خطوة تنظيف روتينية
دمج سجلين داخل HubSpot بعد الترحيل قد يكسر رابط المزامنة خلف أيٍّ منهما وينشئ مكانه سجلًا مكررًا جديدًا، فعامل الدمج بعد الترحيل أمرًا يُفحص لا خطوة تنظيف روتينية
أولوية Urgent في Zendesk ما زال ليس لها مقابل في HubSpot في هذه المرحلة من الخطة أيضًا، فتأكد من أن المطابقة المخصصة التي بُنيت سابقًا فعّالة فعلًا قبل أن تضعها أول تذكرة Urgent أمام اختبار حقيقي
أولوية Urgent في Zendesk ما زال ليس لها مقابل في HubSpot في هذه المرحلة من الخطة أيضًا، فتأكد من أن المطابقة المخصصة التي بُنيت سابقًا فعّالة فعلًا قبل أن تضعها أول تذكرة Urgent أمام اختبار حقيقي
الأسئلة
Zendesk Support إلى HubSpot: أسئلة وأجوبة
نعم. مزامنة بيانات في الاتجاهين تغطي 4 كائنات، وSmart Transfer مدعومة. ما لن تفعله هو إعادة بناء إعداداتك: وهذه هي البنود الـ 26 أدناه.
عادةً من 2-5 أسابيع، ويتأثر هذا الرقم بحجم البيانات والحقول المخصصة وتعقيد الأتمتة. تنتهي Smart Transfer نفسها خلال أيام بعد أن تبدأ؛ أما ما يطيل الجدول الزمني فهو مسار السكربت المخصص عند 100K+ تذكرة، إذ يستغرق التنفيذ 3-5 أيام، لكن بعد 1-2 أسبوع من أعمال التحضير تسبقه. ويحدد التعقيد عمق الأتمتة والتقارير لا عدد السجلات: فالموصل ينقل السجلات، ولذلك لا تطيل قاعدة بيانات كبيرة بحد ذاتها الجدول الزمني.
من بين 75 ميزة طابقناها، تنتقل 26 ميزة (35%) مباشرة وتُطابَق 43 ميزة (57%) جزئيًا، أي يضيع شيء منها أو يُعاد تشكيله في الطريق. و6 ميزات ليس لها مقابل في HubSpot في أي فئة، وهذا يستحق طرحه قبل التوقيع لا بعده.
يجب إعادة بناء 26 بندًا يدويًا، و9 قيود موثقة لا يُظهرها الموصل إطلاقًا. القائمتان في هذه الصفحة كاملتين لمن يحدد نطاق العمل.
مجاني للمزامنة الأساسية. Data Hub Starter+ لمطابقة الحقول المخصصة.
6: مشاركة التذاكر (Multi-Instance)، وترتيب تنفيذ Business Rules، وSunshine Conversations، ومنتديات المجتمع (Gather)، وContent Blocks، ولوحة متابعة الوكلاء المباشرة (Live Agent Dashboard). إذا كان فريقك يعتمد على واحدة منها فاحسم الأمر قبل التوقيع بدل اكتشافه عند التحويل النهائي، حين يكون البديل بناءً مخصصًا.
في اتجاه واحد فقط. المزامنة هنا ليست في الاتجاهين، فتشغيل النظامين معًا يعني اختيار نظام السجل المرجعي (system of record) منذ البداية وقبول انحراف البيانات في الآخر.
هل أنت مستعد للبدء؟
خطّط لعملية الترحيل
أخبرنا بالمنصة التي تنتقل منها، وحجم التخصيص فيها، والموعد الذي تحتاج فيه إلى العمل على HubSpot. وسنوضح لك ما ينتقل مباشرة، وما يحتاج إلى إعادة بناء، والمدة التي يستغرقها الانتقال فعلياً.