Pillar article

مشكلة إسناد البيع المشترك التي لا يتحدث عنها أحد

25 أكتوبر 20257 min read

مشكلة إسناد البيع المشترك التي لا يتحدث عنها أحد

اسأل مدير تحالفات كم من الإيرادات أثّر فيها الشركاء الربع الماضي. ستحصل على إحدى إجابتين: رقم واثق لا يصدقه أحد في المالية، أو هزة كتفين. كلاهما يأتي من نفس المكان. إسناد البيع المشترك، أي القدرة على إسناد الفضل للشركاء بعدالة عن الدور الذي لعبوه في صفقة، مكسور في معظم مؤسسات إيرادات B2B، وقليل من الناس يريدون قول ذلك في اجتماع.

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

نظام إدارة علاقات العملاء لا يستطيع رؤية الشريك

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

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

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

يفشل في كلا الاتجاهين

الإسناد المكسور لا ينحاز في اتجاه واحد فقط. عادة تُفرِط شركة في الإسناد وتُقلل منه في نفس الوقت.

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

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

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

التوقيت والتسليمات تكسر المسار

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

التسليم هو حيث ينقطع أكثر. عندما يُسلّم شريك عميلاً محتملاً لفريق مبيعاتك، السياق (من هو النصير، ما الألم الذي بدأ المحادثة، ما الذي وعد به الشريك بالفعل) يعيش عادة في بريد إلكتروني أو محادثة Slack لا تصل أبدًا إلى نظام إدارة علاقات العملاء. تُنشأ الفرصة من جديد، بلا مصدر مرفق، وبصمات الشريك تختفي قبل أن تبدأ الصفقة بالتحرك. يحدث هذا بشكل موثوق كفاية لدرجة أننا خصصنا له منشورًا خاصًا: لماذا تتعثر الشراكات عند التسليم، وكيف تصلحها.

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

ما يبدو عليه الإصلاح الحقيقي

لوحة معلومات أكبر لن تفعلها. تفتقر معظم المؤسسات لثلاثة أشياء.

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

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

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

كل الثلاثة تتعلق فعلاً بربط الإشارات عبر نظام إدارة علاقات العملاء، وبوابات الشركاء، والأسواق، والأدوات حيث تحدث المحادثات، بحيث يعكس الفضل ما حدث فعلاً. المنصات المبنية لـتنسيق الإيرادات تعامل الإسناد كمشكلة بيانات مستمرة ومتعددة الأطراف بدلاً من حقل يُملأ عند الإغلاق. من واقع خبرتنا هذه الطريقة الوحيدة التي تبدأ فيها الأرقام بالتوافق أبدًا.

أبرز النقاط

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

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

See revenue orchestration in action

Unify your revenue data, signals, and plays on one AI-native platform.