العمل مع مؤسسة: كيف لم نصنع نظام تحليلات لخدمة SaaS

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

حول المشروع

منتج العميل هو SaaS في مجال B2B ، والذي يعمل على شكل رسوم اشتراك. يقوم المستخدم بتسجيل وتمرير الإذن وتجديد حسابه واستخدام الخدمة.

مهمتنا هي مساعدة العميل على "جمع" التحليلات. للقيام بذلك ، كان من الضروري بناء عمليات مركز الاتصال ، وتنفيذ CRM و "الجمع" بين التحليلات الشاملة من خلال المؤشرات الرئيسية.

هيكل العملية

قبل إجراء التحليلات ، تحتاج إلى إعداد منظر طبيعي لتجميعه: هيكلة عمليات المبيعات وإعداد عمليات التكامل مع الخدمات. وجدنا عدة مشاكل في العمليات:

1. تم تشتيت انتباه المديرين بسبب المراحل غير الضرورية في قمع المبيعات ، ولم تتم مراقبة عملهم بأي شكل من الأشكال ؛
2. تم تنزيل تقارير المبيعات يدويًا من لوحة الإدارة كل يوم ؛
3. كان هناك عدد قليل من أحداث التحويل لجمع التحليلات.

بعد ذلك ، قمنا بعمل خريطة بهيكل تفاعل جميع الأنظمة. إنه يوضح المنطق الذي يجب أن تتبعه الأحداث وفي أي مراحل يمر المحلل. نأخذ البيانات الرئيسية من CRM ونربطها بالبيانات المتعلقة بالإعلانات والتحويلات. تجميعها في myBI وجعلها في Power BI.

قمع المبيعات

تم إجراء مبيعات العملاء في Enybox CRM ، وقمنا بنقلها إلى amoCRM لسهولة التكامل. تمكنا من جمع منطق المبيعات في ثلاثة مسارات.





_{ثلاث مسارات متتالية}



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

كيف كان من المفترض أن تعمل التحليلات

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

عرض البيانات

_{مثال على لوحة القيادة}



بعد جمع البيانات حول التحويلات ، كان من الضروري عمل تقرير منها. أداة تصور البيانات الرئيسية هي Microsoft Power BI.



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

اقتصاديات الوحدة. احتفاظ

_{يوضح الرسم البياني المستمر للاحتفاظ بالخدمة من 1 إلى 12 شهرًا من}



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

التحويل لأول إيداع

كان التحويل يعتمد بشكل كبير على عدد العملاء الجدد وبدء مدفوعاتهم. في الأشهر التسعة الأولى تلقينا حوالي 430 تسجيلًا جديدًا و 90 دفعة من مستخدمين جدد كل شهر. بلغت نسبة التحويل إلى الشراء في شهر التسجيل 20٪ بحسب بيانات 12 شهرًا.

بالإضافة إلى المؤشرات القياسية

كان من الممكن رؤية التحليلات على لمسة العميل في كل من لحظة الانتقال البسيط إلى الموقع ، ووقت التسجيل والمدفوعات الأخرى. قمنا بتجميع البيانات للعثور على معظم سلاسل التحويل:



شاهد المستخدم الإعلان ← ذهب إلى الموقع ← بعد فترة جاء وبحث في السياق ← مسجل ، لكن لم يدفع ← تم تسخينه بحرف ← عرض محرك اختبار ← تم اختباره ← OP "استسلم" للدفع الأول ← 3 سنوات مدفوعات مستقرة.

هناك خطأ ما

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

تطور بطيء

كانت الثغرات في التطوير بسبب هيكل عمل العميل. لقد عملنا مع فريق العميل ولم يكن من الممكن تنفيذ بعض المهام إلا من جانبه نظرًا للأمان الشديد للعمليات.

غاب عن سباقين - فقد شهر

عمل جميع المديرين والمطورين من جانبهم في تكرارات لمدة أسبوعين. لكنهم وضعوا مشروعنا دائمًا في المرتبة الأخيرة ، وغالبًا ما لم تقع مهامنا في "العدو".

ضعف التواصل وقلة الخبرة

خلال المشروع ، تم تغيير مدير العميل (صاحب المصلحة) خمس مرات. ربما يعرف الجميع هذا الشعور عندما يصبح المشروع الذي تعمل عليه فجأة غير مثير للاهتمام للعميل. ولكن حتى هذا يمكن حله.



كان من الصعب التعامل مع عدم كفاءة أصحاب المصلحة. كان أحدهم مديرًا تنفيذيًا رائعًا يعرف منتجه جيدًا. لكنه لم يفهم حتى المبادئ الأساسية لبناء عمليات البيع. لقد أمضينا عدة اجتماعات لإقناعه بإزالة المرحلة التي تظهر عليها الحالة "كيف حالك؟" من قمع المبيعات.



تخيل قمع مبيعات مثل الصورة أعلاه. في إحدى المراحل ، يحتاج المديرون إلى معرفة "كيف يعمل العميل". ما رأيك سيحدث لتحليلات التحويل لهذا المسار؟



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

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

Fakapas من جانبنا

لم نأخذ في الاعتبار عرض النطاق الترددي للنظام. لحدث منصة واحدة في الذروة ، أرسلنا ما يصل إلى 10 طلبات إلى amoCRM لتنفيذ منطق العمليات التجارية.



100،000 حدث يوميًا * 10 طلبات إلى amoCRM = 1،000،000 طلب يوميًا



1،000،000 طلب يوميًا / 10 طلبات في الثانية (حد AMO) = 100،000 ثانية = ± 27 ساعة



النتيجة: لن تنتهي المزامنة أبدًا



amoCRM المحدد مبدئيًا ، كـ "تمرير" حد الطلبات إلى النظام. ولكن على مدار تطوير المشروع ، زادت المتطلبات والوظائف و "واجهنا" الحد الأقصى.

لقد اخترنا الأداة الخاطئة. AmoCRM غير مناسب فعليًا للتعامل مع عدد كبير من الطلبات.

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

كل شيء مكسور مرة أخرى

هذه الحالة هي مثال آخر لمشروع تم دفنه في الموافقات وكومة من الإدارة غير المبررة.



كنا نفتقر إلى الخبرة الفنية. للعميل - الاستقرار في الإدارة والرغبة في إنجاز المشروع.



لكن هذه تجربة. بفضله ، تبدو هذه المهام الآن تافهة قدر الإمكان ، وقد أعدنا بالفعل إنتاج حل مماثل في مشروع آخر.

كيف يمكن تجنب الفشل

من أجل عدم تكرار مثل هذه الحالات في المستقبل ، قمنا بتسليط الضوء على الجوانب التي يجب مراعاتها عند العمل مع عملاء المؤسسة.

1. : ; . , .
2. . — . — . . .
3. . KPI — .
4. فكر للامام. حتى عند تطوير MVP ، فأنت بحاجة إلى إلقاء نظرة على الاختناقات التي قد تنشأ في المستقبل. يتوسع المشروع دائمًا ومن المهم توفير هيكل حتى لا يتم إعادة كتابة جميع الكود من البداية.

---

مؤلف المقال هو Fedor Anisimov ، مسوق LAND PRO.