لوحتين بيعرضوا إجمالي مسار مختلف. سير عمل بيوزّع عميل محتمل كان سير عمل تاني لسه موزّعه من ساعة. ومحدّش متأكد التوقّع بيقرأ أنهي خاصية في الصفقة. لما ده يحصل، أغلب الفرق بتدوّر على العطل: إعداد غلط، أو فلتر، أو حد داس على حاجة غلط.
في أغلب الحسابات اللي بنشوفها، مفيش عطل واحد. الحساب كبر طلب ورا طلب، وكل طلب كان منطقي لوحده. بعد كام سنة، الأجزاء بطّلت تركّب على بعض. ده مش عطل، دي مشكلة بنية، ومهما دوست جوّه الأداة مش هتتحل.
البنية هي مجموعة القرارات اللي بتوصف شغلك جوّه HubSpot: كل سجل معناه إيه، وإيه المعلومات اللي بتحفظها عنه، والصفقة بتعدّي على مراحل إيه، وأنهي أتمتة بتشتغل على إيه، وإزاي بتقيس النتيجة. البنية الكويسة مملّة. الناس بتعرف إيه اللي هيحصل لما يغيّروا حاجة.
ليها خمس طبقات، وكل طبقة معتمدة على اللي تحتها.
المشاكل اللي بتشوفها فوق، في التقارير وسير العمل، تقريبًا دايمًا بتبدأ من تحت. تعالى ناخد الطبقات بالترتيب.
HubSpot بيدّيك جهات اتصال وشركات وصفقات وتذاكر، وفي الباقات الأعلى كائنات مخصّصة. كل كائن المفروض يجاوب عن سؤال واحد. جهة الاتصال شخص. الشركة جهة عمل. الصفقة فرصة بيع. التذكرة طلب خدمة. المشكلة بتبدأ لما فريق يطوّع كائن عشان يشيل حاجة ماتعملش ليها.
مثال معروف: تحفظ اسم الشركة كنص على جهة الاتصال بدل ما تعمل سجل شركة. بيمشي شهر. وبعدين عايز تشوف كل الناس في شركة واحدة، أو تطلّع الإيراد لكل شركة، ومش قادر. واحد من الحسابات اللي أعدنا بناءها كان فيه كده بالظبط، ومعاه حقل حالة العميل المحتمل شايل مهام ماتصمّمش ليها. اقرا إزاي صلّحناه في دراسة حالة كورسينيتي.
أسئلة تسألها عن نموذجك:
كل خاصية هي وعد إن حد هيملاها وحد تاني هيستخدمها. لو مفيش ده ولا ده، تبقى حشو، والحشو له تمن: الناس مش بتلاقي الحقول المفيدة، والحقول المكررة بتقسم بياناتك من غير ما حد ياخد باله. تلات عادات بتخلّي الخصائص سليمة.
المرحلة المفروض توصف تغيير في اللي بقى حقيقي عن الصفقة، مش مهمة حد لازم يعملها. لو المندوب مش قادر يفرّق بين مرحلتين جنب بعض، يبقى المراحل مش بتشتغل، والبيانات اللي فيها هتبقى غلط.
حساب اشتغلنا عليه، إيجاري، كان فيه أكتر من 15 مرحلة للصفقات، وفريق المبيعات وفريق التأهيل شغّالين على كائن الصفقات نفسه من غير تسليم واضح. العملاء المحتملين كانوا بيضيعوا وتقارير التقدّم مش دقيقة. أضفنا وحدة منفصلة لاستكشاف العملاء المحتملين، عشان يتدار العملاء في مكان واحد بعيد عن الصفقات ولكل عميل مالك واضح. وبعدين قلّلنا عدد المراحل وحوّلنا بعضها لحقول مخصّصة بتشتغل كبوابات لازم الصفقة تعدّي منها. القصة كاملة في دراسة حالة إيجاري.
ممكن غالبًا تستخدم خصائص إلزامية على المرحلة، فالصفقة متقدرش تتحرّك لقدّام قبل ما المعلومات تتسجّل. كده عمليتك بقت حاجة الأداة بتفرضها، مش حاجة الناس مطلوب منها تفتكرها.
الأتمتة بتضاعف اللي هي واقفة عليه. على نموذج نضيف، سير عمل واحد بيوفّر ساعات كل أسبوع. على نموذج مش مظبوط، بتعمل مشاكل أسرع من ما أي حد يلحق يصلّحها. في حساب راجعناه، أتمتة إنشاء التذاكر كانت زيادة عن اللزوم وطلّعت أكتر من 280,000 تذكرة غرّقت فريق الدعم. الأتمتة ماكانتش بايظة. عملت بالظبط اللي اتقالها، على بنية مش قادرة تشيلها.
التقارير هي آخر طبقة، وبترث كل ضعف تحتها. لو فريقين بيعرّفوا العميل المحتمل بشكل مختلف، أو الصفقة ممكن تتعمل بتلات طرق، يبقى تقريرين هيختلفوا وكل واحد فيهم صح. صلّح النموذج والخصائص والمراحل الأول، ولوحات المتابعة هتتظبط لوحدها في الغالب.
مش لازم تعيد بناء الحساب عشان تبدأ. اقعد ساعة مع الناس اللي بتستخدم الحساب وارسم صفحة واحدة: الكائنات عندك وإزاي بتتربط، وأهم عشر خصائص، ومراحل المسار ومعاها الحقيقة اللي لازم تتحقق عشان تدخل كل مرحلة، وأهم خمسة سير عمل. أي حتة في الصفحة رسمها صعب أو الناس مختلفة عليها، هي بالظبط مكان مشكلة البنية.
ولو الصفحة طلعت فيها أسئلة أكتر من إجابات، ده بالظبط دور مراجعة الحساب. قولّنا إيه اللي مش شغّال، ونقولك البنية بتقع فين.