لماذا يضم نظام CRM لديك إحدى عشرة أداة لبناء الفلاتر

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

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

كيف يحدث ذلك

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

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

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

• يعامل عرض القائمة النص الفارغ والحقل الذي لا قيمة له كشيء واحد. أما أداة بناء الشرائح فلا.
• يستطيع عرض القائمة الفلترة على حقل في سجل مرتبط. أما أداة بناء التقارير فلا تفلتر إلا على الكائن المعروض أمامها.
• يحسب شرط الأتمتة التواريخ بتوقيت UTC. ويحسبها العرض بمنطقتك الزمنية. لكلٍّ منهما ما يبرره؛ لكنهما معًا خلل ستقضي نصف يوم في تتبّعه.
• إحدى الأدوات فيها «أيٌّ من». وأخرى فيها «يساوي» فقط، فتضطر إلى بناء ثلاث قواعد يربط بينها «أو».

والنتيجة أن الإجابة عن سؤال «هل أستطيع الفلترة على هذا؟» ليست نعم أو لا أبدًا. بل هي «في أي شاشة أنت؟»

ما الذي يكلّفك إياه ذلك فعلًا

ثلاثة أمور، مرتبة من الأقل أهمية إلى الأكثر.

تتعلّم الفلترة عدة مرات

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

يُعاد إدخال المنطق بدل إعادة استخدامه

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

القدرات تصل بشكل غير متساوٍ، وإلى الأبد

وهذا الأمر يتراكم مع الوقت. حين يضيف المنتج عاملًا جديدًا، يصل إلى الأداة التي يتولاها الفريق المسؤول عنها فقط. خمس سنوات على هذا المنوال، وتصبح الفجوة بين أقوى شاشة فلترة لديك وأضعفها هائلة، ويتحوّل كل طلب في خارطة الطريق إلى سؤال: «في أي الخمس تريده أولًا؟»

العرض المحفوظ، والشريحة التسويقية، وشرط سير العمل، وفلتر التقرير، والسؤال الذي تكتبه للذكاء الاصطناعي، يجب أن تكون كلها الكائن نفسه الذي يمر عبر المُصرِّف نفسه.

البديل، وما يتطلّبه

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

هذا ليس بلا ثمن. فهو يتطلّب انضباطًا مزعجًا فعلًا:

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

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

الجزء الذي فاجأنا

توقعنا أن يكون المكسب كفاءة هندسية. لكن المكسب الأكبر سيكون في الذكاء الاصطناعي.

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

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

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

القرار المعماري الذي بدا مجرد ترتيب داخلي هو ما سيجعل البحث بالذكاء الاصطناعي جديرًا بالثقة بدل أن يكون للزينة. وهذا عادةً حال الأساسات: السبب الذي يجعلك سعيدًا لأنك بنيتها نادرًا ما يكون السبب الذي بنيتها من أجله.

كيف تتحقق من ذلك بنفسك

لست مضطرًا لتصديق أي ادعاء عن البنية التقنية دون دليل. في فترة تجربة أي نظام CRM، خصّص عشر دقائق لما يلي:

1. أنشئ فلترًا معقدًا بعض الشيء في عرض القائمة، فلترًا يتضمن سجلًا مرتبطًا وقيمة فارغة.
2. حاول بناء الفلتر نفسه تمامًا كجمهور لحملة.
3. حاول مجددًا كشرط في أتمتة، ومرة أخرى كفلتر في تقرير.
4. اسأل الذكاء الاصطناعي سؤالًا يُفترض أن يُنتج الفلتر نفسه، وانظر هل تستطيع فحص ما نفّذه.

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