نظام CRM مدعوم من HubSpot داخل Gmail غيّر طريقة متابعة أحد فرق المبيعات
استخدم أحد قادة المبيعات Manus لبناء سير عمل مخصص يضع تفاصيل HubSpot في الأماكن التي يعمل فيها الفريق بالفعل: Gmail و Slack. كان الهدف بسيطًا. عندما يرسل عميل محتمل بريدًا إلكترونيًا للفريق، لا ينبغي أن يضطر المندوب إلى مغادرة صندوق الوارد لمعرفة من هو هذا الشخص، أو ما إذا كانت الشركة موجودة بالفعل في HubSpot، أو ما إذا كانت المحادثة مهمة لصفقة مفتوحة.
باستخدام Manus، قام قائد المبيعات ببناء سير عمل ينقل تفاصيل HubSpot الصحيحة إلى البريد الإلكتروني. جمع النظام النهائي بين HubSpot و Gmail و Slack في سير عمل واحد. كان بإمكانه تصنيف رسائل Gmail عند وجود معلومات في HubSpot، وعرض معلومات الحساب المفيدة داخل Gmail، وإشعار الفريق في Slack عندما يحتاج عميل محتمل من فئة المؤسسات إلى الاهتمام.
بدأ المشروع بمشكلة مبيعات يومية واحدة
بدأ المشروع بسؤال مبيعات عملي: ما الذي يجب أن يعرفه المندوب قبل الرد على بريد إلكتروني؟
على سبيل المثال، إذا أرسلت Priya من acme.com بريدًا إلكترونيًا للفريق، يحتاج المندوب إلى فهم سريع لما إذا كانت موجودة بالفعل في HubSpot، وما إذا كانت Acme حسابًا مستهدفًا، وما إذا كانت هناك صفقة مفتوحة، ومن يملك العلاقة. تحدد هذه الإشارات ما إذا كان يجب أن يكون الرد سريعًا، أو موجهًا، أو يُتعامل معه بشكل مختلف.
ساعد Manus في ترجمة هذا السؤال إلى طبقة بيانات قابلة للاستخدام. يقوم HubSpot بالفعل بتخزين هذه المعلومات عبر جهات الاتصال والشركات والصفقات وسجلات الملكية. كان التحدي هو تحديد الحقول التي تهم فعلاً في لحظة الرد، وجعلها متاحة داخل Gmail.
أدى ذلك إلى تقليص المشكلة إلى مجموعة بسيطة من الإشارات: من أرسل البريد الإلكتروني، وإلى أي شركة ينتمي، وما إذا كانت الشركة معروفة، وما إذا كانت هناك صفقة نشطة، ومن يملك الحساب. أصبح هذا الأساس لسير عمل Gmail.
ملحق المتصفح والتصنيف داخل Gmail
جعل قرار صغير في المنتج سير العمل أسهل على المندوبين لفهمه. لم يُستخدم تصنيف Gmail كنظام تسجيل نقاط معقد. بل استُخدم كإشارة بسيطة.
في هذا النموذج التخيلي، التصنيف هو الإشارة. عندما ينقر عليه المندوب، يفتح ملحق المتصفح مع التفاصيل الأساسية للعميل المحتمل أو العميل اللازمة قبل الرد.
على سبيل المثال، إذا أرسلت Priya من Acme بريدًا إلكترونيًا للفريق وكانت Acme موجودة بالفعل في HubSpot، فسيتم تصنيف البريد الإلكتروني وفقًا لذلك. إذا كان المرسل عميلاً بالفعل، فقد يرد المندوب مع مزيد من تاريخ الحساب. إذا كان المرسل مرتبطًا بصفقة مؤسسية مفتوحة، فقد يعطي المندوب الأولوية للرد. إذا كان المرسل ينتمي إلى شركة بدون مالك، فقد يحتاج الفريق إلى تعيين شخص ما قبل الرد.
بمجرد تصنيف رسائل البريد الإلكتروني، يمكن لمندوب المبيعات النقر على التصنيف وفتح الملحق مع تفاصيل HubSpot ذات الصلة داخل صندوق الوارد.
ساعد Slack الفريق على التصرف بشأن العملاء المحتملين المهمين
ساعد Gmail مندوبًا واحدًا على الرد بمعلومات أفضل. وساعد Slack الفريق على التنسيق عندما يحتاج عميل محتمل مهم إلى الاهتمام.
في سير العمل هذا، أنشأ Manus بوت Slack لإرسال إشعارات Slack للعملاء المحتملين الواردين من فئة المؤسسات من HubSpot. يمكن لرسالة Slack أن تخبر الفريق بأن شركة عالية الملاءمة قد تواصلت معهم، وتشمل اسم الشركة، وتعرض المالك المحتمل، وتوجه الأشخاص إلى سلسلة البريد الإلكتروني أو السجل ذي الصلة.
على سبيل المثال، إذا أرسل عميل محتمل من فئة المؤسسات بريدًا إلكترونيًا من حساب مستهدف ولم يكن هناك مالك معين، يمكن لـ Slack تنبيه الفريق. هذا يجعل العميل المحتمل مرئيًا للمجموعة بدلاً من تركه مدفونًا في صندوق وارد شخص واحد.
جعل Slack معلومات العميل المحتمل ذاتها مرئية للفريق الأوسع. يمكن رؤية العميل المحتمل عالي الملاءمة وتعيينه ومتابعته قبل أن يضيع بين الثغرات.
ما يمكن للفرق الأخرى تعلمه من هذه العملية
نجح المشروع لأنه تم التعامل مع HubSpot وGmail وSlack كطبقات منفصلة. تم بناء كل طبقة على حدة، واختبارها بمفردها، ثم دمجها في سير عمل يناسب حركة المبيعات القائمة لدى الفريق.
كانت الطبقة الأولى هي نموذج بيانات HubSpot. كان على الفريق أن يقرر أي الحقول مفيدة فعلاً في لحظة المتابعة، مثل هوية جهة الاتصال ومطابقة الشركة والمالك وحالة الصفقة ومصدر العميل المحتمل والخطة والخطوة التالية. تم استخدام Manus لتحديد حقول HubSpot القيمة وإنشاء قاعدة بيانات متزامنة يمكن لبقية سير العمل استخدامها
اعتمدت الطبقة الثانية على الوصول. في هذه الحالة، كان الفريق يستخدم Google Workspace، لذا كان من الممكن أن يتم تفويض Gmail عبر مصادقة Google. كان ذلك مهماً لأن سير العمل احتاج إلى إذن لقراءة الرسائل ومقارنة المرسلين بقاعدة البيانات المشتقة من HubSpot وتطبيق التصنيفات بناءً على قواعد مخصصة. ثم تم استخدام Manus لوسم رسائل البريد الإلكتروني تلقائياً وفقاً لتلك القواعد.
كانت الطبقة الثالثة هي التجربة المواجهة لـ Gmail. بعد أن نجحت التصنيفات، تم استخدام Manus لبناء امتداد المتصفح الذي يعرض أيقونات بنمط HubSpot ويحمّل تفاصيل العميل المحتمل أو العميل ذات الصلة داخل Gmail. تطلب البناء نفسه أيضاً قطعاً داعمة: مكونات الاستضافة، وموقع تسجيل الدخول، وتدفق تفويض المستخدم. تمت معالجة هذا العمل كطبقة منفصلة في Manus قبل دمجه مع بقية النظام.
النصيحة العملية لبناء ذلك للفرق الأخرى هي البدء بالتحقق من مستويات الوصول، ثم تحديد الحد الأدنى من الحقول المفيدة، واختبار منطق التصنيف، وبناء الواجهة المرئية. إذا كانت أي طبقة واحدة مفقودة، تصبح التجربة إما غير موثوقة للمندوب أو صعبة جداً ليتبناها الفريق.
