21 KiB
استراتيجية الابتكار — Dealix «Autonomous Growth Factory»
الموقع في المنتج: ليس CRM ولا بوت واتساب فقط، بل Saudi B2B Revenue OS: من إشارة السوق → Why Now → رسالة → موافقة → متابعة → إثبات عائد.
الترابط مع ما بُني: Market Radar (v3) + Arabic Personal Operator + Approval-first flow + Revenue / Project Memory + Proof Pack + Compliance OS — انظرGTM_PLAYBOOK.md،WHATSAPP_OPERATOR_FLOW.md،ROI_PROOF_PACK.md،SECURITY_PDPL_CHECKLIST.md.
قالب كل فكرة (يُطبَّق على العناصر أدناه)
لكل رقم: ما هي؟ | لماذا للشركات؟ | الفرق عن HubSpot / Gong / Salesforce / أدوات واتساب؟ | MVP في الريبو الآن | ما يُؤجَّل | metrics | risks | required data | required endpoints
1. Dealix Growth Twin
ما هي؟ نسخة رقمية لنمو الشركة: ICP، قطاعات، مدن، عروض، رسائل ناجحة، اعتراضات، قنوات، حدود امتثال، أنماط قرار.
لماذا؟ الـ AI العام لا يكفي؛ السياق السعودي والقطاعي يقلل الهذيان ويرفع التحويل.
الفرق؟ منصات عالمية تعطي «context advantage» عاماً؛ Dealix يضيف Growth Context سعودي/GCC مربوطاً بذاكرة إيرادات وموافقات.
MVP الآن: وثائق + مهام تجريبية في API الابتكار (/api/v1/innovation/growth-missions)؛ لا نموذج تعلّم ثقيل بعد.
يُؤجَّل: تعلم فعلي من سلوك المستخدم؛ ربط Deep Twin بكل جداول الإنتاج.
metrics: time-to-first-campaign، موافقة/رفض، reply→meeting.
risks: overfitting على عميل واحد؛ تخزين بيانات حساسة بدون DPA.
required data: ICP، تاريخ رسائل معتمدة، قطاع، مدينة.
required endpoints: GET .../innovation/growth-missions؛ لاحقاً POST .../twin/sync.
2. Saudi Revenue Graph
ما هي؟ رسم بيانات يربط Company، Contact، Sector، Signal، Message، Meeting، Deal، Outcome، Compliance… بعلاقات قابلة للاستعلام.
لماذا؟ «سبب + علاقة + رسالة + احتمال + خطوة» بدل مجرد صف lead.
الفرق؟ CRM يعرض جداول؛ Dealix يضيف Why + graph reasoning فوق البيانات (عند النضج).
MVP الآن: وصف في هذه الوثيقة؛ لا مخطط Neo4j في الريبو.
يُؤجَّل: graph DB أو طبقة Cypher-like؛ استخراج علاقات من المحادثات.
metrics: precision الاقتراحات، مسارات won/lost المفسرة.
risks: تعقيد البيانات؛ صيانة الرسم.
required data: معرفات كيانات موحّدة، أحداث موقّتة.
required endpoints: لاحقاً /api/v1/revenue-graph/... موازية لـ revenue_graph الداخلية.
3. Growth Missions
ما هي؟ وحدات نتيجة جاهزة: «احجز 3 اجتماعات»، «أصلح تسريبات»، «توسع قطاع» — بدل قائمة features.
لماذا؟ تبيع نتيجة وتقيّم بوضوح.
الفرق؟ dashboards عامة؛ Missions = مسارات مغلقة بخطوات وproof.
MVP الآن: list_growth_missions() + GET /api/v1/innovation/growth-missions.
يُؤجَّل: تشغيل آلي كامل للمهمة؛ ربط calendar حقيقي.
metrics: completion rate، أيام حتى أول اجتماع.
risks: توقعات زائدة بدون بيانات.
required data: هدف العميل، قطاع، حدود الموافقة.
required endpoints: أعلاه + Personal Operator للخطوات اليومية.
4. Arabic Relationship Operator
ما هي؟ طبقة فوق Personal Operator: علاقة → مدخل → رسالة → Accept/Skip → متابعة post-meeting → Relationship-to-Revenue Memory.
لماذا؟ B2B السعودي يعتمد على الثقة والعلاقات وليس البارد فقط.
الفرق؟ أدوات outreach عامة؛ العربية + الامتثال + الموافقة متأصلة.
MVP الآن: يعتمد على personal_operator الموجود؛ الابتكار يوثّق الرؤية.
يُؤجَّل: ذاكرة علاقة منفصلة في DB؛ نماذج تصنيف علاقة.
metrics: قبول المسودات، meetings booked، re-engagement.
risks: ضغط «relationship spam» — يُعالَج بـ Compliance Shield.
required data: جهات الاتصال، opt-in، تاريخ التفاعل.
required endpoints: موجودة جزئياً؛ لاحقاً /relationship/....
5. Why Now Engine
ما هي؟ كل فرصة تُرفق بإشارات (توظيف، فرع، إطلاق، reviews…) + زاوية رسالة + مخاطر امتثال + ثقة.
لماذا؟ بدون «لماذا الآن» الرسالة تبدو عشوائية.
الفرق؟ prospecting agents عالمية؛ التخصيص السعودي والقنوات المحلية هنا.
MVP الآن: market_radar + بطاقات في command feed demo.
يُؤجَّل: مصادر إشارات مستمرة ومصنّفة بالكامل.
metrics: lift في الردود عند وجود why_now مقابل بدونه.
risks: إشارات قديمة؛ تحتاج تفسير زمني.
required data: مصادر إشارات موثوقة؛ سياسات استخدام.
required endpoints: v3/market-radar؛ ابتكار demo feed.
6. Saudi Objection Intelligence
ما هي؟ مكتبة اعتراضات شائعة («بعد العيد»، «عندنا مزود»…) → تصنيف تأجيل/رفض → رد قصير/رسمي → متابعة.
لماذا؟ تحويل النص إلى إجراء قابل للتتبع.
الفرق؟ Gong على المحادثة؛ Dealix على الاعتراض العربي + الإجراء.
MVP الآن: وثائق؛ يمكن ربط لاحق بـ objection_library في revenue_graph.
يُؤجَّل: تعلم من أداء الردود الفعلية.
metrics: recovery rate بعد اعتراض.
risks: تعميم ثقافي خاطئ؛ مراجعة إنسانية في البداية.
required data: تسميات اعتراضات من العملاء.
required endpoints: لاحقاً /objections/....
7. AI Sales Simulation Lab (Message Lab)
ما هي؟ قبل الإرسال: محاكاة مخاطر، اعتراضات متوقعة، تقييم «spam-like»، اقتراح أفضل نسخة.
لماذا؟ يقلل فشل الحملات ويرفع الثقة.
الفرق؟ لا يوجد معيار سعودي جاهز في الأدوات العالمية كمنتج موحّد.
MVP الآن: وثائق فقط؛ لا استدعاء LLM إضافي في الطبقة الابتكارية الأولى.
يُؤجَّل: نموذج تقييم + eval set عربي.
metrics: انخفاض complaints؛ تحسن reply quality score.
risks: محاكاة لا تعكس السوق الحقيقي.
required data: مجموعة رسائل معتمدة/مرفوضة تاريخياً.
required endpoints: لاحقاً POST .../simulation/run.
8. Proof Ledger
ما هي؟ سجل أحداث إثبات: فرصة، رسالة معتمدة، رد، اجتماع، صفقة، خسارة، revenue influenced، منع مخاطرة.
لماذا؟ يقلل churn ويوضح القيمة شهرياً.
الفرق؟ Proof Pack لحظي؛ Ledger زمني تراكمي.
MVP الآن: build_demo_proof_ledger() + GET .../proof-ledger/demo.
يُؤجَّل: جدول دائم + تقارير PDF أسبوعية.
metrics: MRR influenced، وقت موفر، عمليات منعت.
risks: أرقام غير دقيقة — تصنيف كـ estimates حتى التكامل المحاسبي.
required data: أحداث من CRM/outreach يدوياً ثم آلياً.
required endpoints: demo؛ لاحقاً /proof-ledger/events.
9. Compliance Shield (Dealix Trust Shield)
ما هي؟ منتج بيع: safe/blocked/needs_review، opt-out، approval log، campaign risk، RoPA أدلة، منع أسرار في embeddings.
لماذا؟ الخوف من أتمتة واتساب/البريد يوقف المبيعات.
الفرق؟ checkbox عام؛ هنا سياسات مدمجة في مسار الإرسال.
MVP الآن: compliance_os + شرح في الوثيقة؛ بطاقة في command feed.
يُؤجَّل: واجهة «Shield dashboard» كاملة.
metrics: حوادث إرسال غير مصرّح = 0؛ وقت المراجعة.
risks: تعطيل المستخدم إذا فرض شديد جداً — توازن عبر سياسات.
required data: موافقات، قوائم قمع، سياسة قطاع.
required endpoints: v3/compliance/*؛ ابتكار يعرض ملخصاً في الـ feed.
10. AEO Radar (Answer Engine Opportunity)
ما هي؟ قياس ظهور الشركة في إجابات أنماط ChatGPT/Perplexity (محلياً: أسئلة سوق سعودية) وربط الفجوات بحملات ومحتوى.
لماذا؟ ربط تسويق عصر AI بالمبيعات.
الفرق؟ HubSpot AEO عالمي؛ Dealix أسئلة بالعربية والقطاعات المحلية.
MVP الآن: وثائق + إشارة في مهام الابتكار؛ لا بحث حي.
يُؤجَّل: استعلامات خارجية، تقارير دورية.
metrics: نسبة تغطية الأسئلة الحرجة، تحسن الزيارات/الاستفسارات.
risks: اعتماد على نماذج خارجية متقلبة؛ تعريف reproducibility.
required data: قائمة أسئلة ذات صلة بالقطاع.
required endpoints: لاحقاً GET .../aeo/radar/demo.
11. Agentic Revenue Rooms (Deal Room Operator)
ما هي؟ غرفة لكل صفقة كبيرة: ملخص، أصحاب قرار، اعتراضات، drafts، approval، مخاطر، توقع.
لماذا؟ يقترب من Smart Deal Progression لكن بسياق عربي وWhatsApp-first.
الفرق؟ أدوات عالمية enterprise-heavy؛ هنا خفيف وسريع للـ SMB/Saudi founder.
MVP الآن: analyze_deal_room(payload) + POST .../deal-room/analyze.
يُؤجَّل: تكامل CRM ثنائي الاتجاه؛ مستخدمين متعددين حسب دور.
metrics: أيام المرحلة، velocity الصفقة.
risks: اعتماد على بيانات ناقصة في الجسم — يُصرَّح في الاستجابة.
required data: مراحل الصفقة، ملاحظات، مستندات (لاحقاً).
required endpoints: أعلاه.
12. Revenue Leak Insurance (Autonomous Follow-up)
ما هي؟ مراقبة تسريبات: لا رد، لا متابعة بعد اجتماع، proposal بلا next step، عميل at-risk.
لماذا؟ وعد تشغيلي قوي يقلل الفقدان.
الفرق؟ تذكيرات CRM خامدة؛ هنا اقتراح إجراء + موافقة.
MVP الآن: بطاقة leak في command feed demo.
يُؤجَّل: اتصال فعلي بـ pipelines؛ جدولة مجدولة.
metrics: recovered pipeline value؛ عدد التسريبات المغلقة.
risks: إزعاج المستخدم بتنبيهات كثيرة — thresholds.
required data: طوابع زمنية للمراحل؛ صندوق بريد/تقويم (لاحقاً).
required endpoints: لاحقاً /leaks/scan.
13. Dealix Agent Store (داخلي)
ما هي؟ كتل agents مع contracts: input/output، guardrails، evals، تكلفة، موافقة، trace tags.
لماذا؟ قابلية توسع بدلاً من ملف واحد ضخم.
الفرق؟ Salesforce Agentforce كمنظومة؛ هنا مجموعة مركّزة على الإيراد العربي.
MVP الآن: جدول في الوثيقة؛ يُرمّز لاحقاً كـ registry Python أو YAML.
يُؤجَّل: marketplace خارجي؛ dynamic loading.
metrics: تكلفة/مهمة، جودة، وقت الموافقة.
risks: تشتت إصدارات الـ prompts — إدارة إصدارات.
required data: تعريف كل agent؛ نتائج eval.
required endpoints: غير مطلوب في MVP الأول.
14. Human Approval OS
ما هي؟ حلقة: اقتراح → موافقة بشرية → تنفيذ محدود → مراقبة → تعلم تفضيلات.
لماذا؟ يبني «يعرف سامي» من قرارات حقيقية لا من prompt ثابت.
الفرق؟ أزرار موافقة منفصلة؛ هنا نظام سياسات وذاكرة قرار.
MVP الآن: مسارات موجودة (واتساب payload، outreach queue)؛ الوثيقة توحّد الرؤية.
يُؤجَّل: تخزين تفضيلات منظم في DB؛ نماذج توصية.
metrics: معدل الموافقة؛ زمن القرار؛ جودة بعد التعديل.
risks: تعطيل التشغيل إذا كل شيء يحتاج موافقة — مستويات ثقة.
required data: سجل قرارات؛ هوية المستخدم.
required endpoints: موجود جزئياً تحت admin/outreach.
15. Dealix Command Feed
ما هي؟ واجهة أساسية على شكل بطاقات: فرصة، قرار، تسريب، مخاطرة، proof… مع أزرار ومخاطر وأثر متوقع.
لماذا؟ أقوى من جداول CRM للمؤسس المشغول.
الفرق؟ feeds إشعارات عامة؛ هذا قرارات إيراد.
MVP الآن: build_demo_command_feed() + GET .../command-feed/demo.
يُؤجَّل: تخصيص حسب دور؛ push حقيقي.
metrics: cards acted/day؛ time to decision.
risks: إرهاق من كثرة البطاقات؛ أولوية ذكية لاحقاً.
required data: مصادر البطاقات من النظام الفعلي.
required endpoints: demo؛ لاحقاً GET /command-feed/live.
16. Revenue Experiments Engine
ما هي؟ كل شهر اقتراح تجارب (قطاع، طول رسالة، توقيت متابعة…) وقياس reply/meeting/cost.
لماذا؟ تحويل النمو إلى منهج تجارب لا حملات عشوائية.
الفرق؟ BI ثابت؛ هنا hypothesis-driven loop.
MVP الآن: recommend_experiments(context) + POST .../experiments/recommend.
يُؤجَّل: تخصيص إحصائي من بيانات عميل؛ حجز أسماء تجارب.
metrics: uplift لكل تجربة؛ وقت الدورة.
risks: تجارب متزاحمة؛ يحتاج حد أقصى متزامن.
required data: تاريخ تجارب سابقة؛ أهداف ربع سنوية.
required endpoints: أعلاه.
17. Saudi Vertical Operating Systems
ما هي؟ كل قطاع (عيادات، عقار، وكالات، تدريب…) له playbooks، اعتراضات، رسائل، مقاييس، تحذيرات امتثال.
لماذا؟ عمق القطاع يغلب اتساع عام SaaS في السوق المحلي.
الفرق؟ landing verticals فقط؛ هنا OS تشغيلي.
MVP الآن: vertical_os ووثائق VERTICAL_OS_STRATEGY.md.
يُؤجَّل: packs مدفوعة لكل قطاع؛ محتوى مرخص.
metrics: win rate حسب قطاع؛ وقت التشغيل.
risks: صيانة المحتوى؛ تحديث تنظيمي.
required data: شركات مرجعية لكل قطاع.
required endpoints: موجود جزئياً تحت revenue-os verticals.
18. First 10 Customers Autopilot
ما هي؟ من موقع الشركة → ICP مقترح → 10 عملاء محتملين → رسائل → جدول متابعة → proof template.
لماذا؟ منتج دخول للمؤسسين؛ يغذي الـ kill feature.
الفرق؟ أدوات بحث عامة؛ هنا مسار مغلق Dealix.
MVP الآن: مهمة ضمن growth missions + محاذاة مع first_10 business API.
يُؤجَّل: استخراج تلقائي من موقع حقيقي بدون مراجعة قانونية.
metrics: conversion إلى pilot؛ وقت حتى أول اجتماع.
risks: جودة الاستنتاج؛ تحقق بشري إلزامي.
required data: URL، قطاع، مدينة، عرض.
required endpoints: /api/v1/business/gtm/first-10؛ ابتكار missions.
19. Strategic Board Brief
ما هي؟ ملخص أسبوعي للإدارة/المستثمر: ماذا حدث، ماذا تعلمنا، أين المال، أين الخطر، القرار المطلوب.
لماذا؟ يدخل Dealix اجتماع الإدارة لا فقط ops المبيعات.
الفرق؟ تقارير CRM؛ هذا ملخص استراتيجي من آلة الإيراد.
MVP الآن: يمكن تجميعه من Personal Operator + proof ledger لاحقاً؛ الوثيقة فقط في هذه المرحلة.
يُؤجَّل: PDF/HTML مؤتمت؛ مقارنة أسبوع/أسبوع.
metrics: حضور الإدارة للتقرير؛ قرارات متخذة.
risks: مبالغة بالنتائج — حاجز جودة وبيانات.
required data: مؤشرات موحدة؛ أحداث الأسبوع.
required endpoints: لاحقاً GET /board-brief/week.
20. AI-to-Human Partner Marketplace
ما هي؟ عندما تحتاج الفرصة إنساناً (closer، كاتب، وكالة…) تحويل إلى طلب شريك ورسوم إحالة لاحقاً.
لماذا؟ شبكة خدمات حول المنصة بدون بناء كل شيء داخلياً.
الفرق؟ سوق عام؛ هنا مُصفّى ومتوافق مع سياسة الإحالة.
MVP الآن: وثائق فقط؛ لا marketplace.
يُؤجَّل: عقود الشركاء؛ حوكمة جودة؛ دفع.
metrics: إحالات، revenue share، NPS.
risks: ضرر بالسمعة إذا شريك ضعيف؛ امتثال وسيط.
required data: ملفات شركاء؛ تقييمات.
required endpoints: لاحقاً /partners/request.
مقارنة موجزة مع السوق العالمي (Gong / Clari / People.ai)
اتجاه السوق (RAO — Revenue Action Orchestration): دمج أدوات الإشراف على الأنابيب، ذكاء المحادثة، والتنفيذ في منصات أقل عدداً وأعمق لتقليل تشتت الـ stack. Gong يتمركز على Conversation Intelligence و«Revenue Graph» من التفاعلات؛ Clari قوي في رؤية الأنابيب والتنبؤ لكن غالباً لا يغلق وحدها حلقة «لماذا حدث» + «ماذا نفعل الآن» بلغة محلية؛ People.ai يميّز بطبقة التقاط النشاط وربطه بالصفقات في CRM نظيف.
أين Dealix لا يحاول المنافسة: ليس استنساخ Gong للمكالمات الإنجليزية ولا Clari لمجالس الإدارة متعددة المئات من المندوبين بنفس نضج التنبؤ على بيانات CRM ضخمة.
أين Dealix يتميّز: Saudi / GCC Revenue OS — إشارات سوق (Market Radar) + Why Now عربي + مسودات بموافقة إلزامية + Compliance / PDPL + قنوات واتساب/بريد بحدود سياسة + Proof Ledger لإثبات الأثر التشغيلي. المنتج يُباع كـ «قرار إيراد محكوم» لا كـ dashboard عام أو إرسال بارد غير مضبوط.
Kill Feature المركزية
«10 فرص في 10 دقائق»: إدخال شركة + قطاع + مدينة + عرض + هدف → قائمة 10 فرص مع Why Now + مسودات عربية بحالة pending_approval (لا إرسال تلقائي) — POST /api/v1/innovation/opportunities/ten-in-ten؛ وصف المهمة والحقول في GET /api/v1/innovation/growth-missions. التوسع والجاهزية في DEALIX_100_PERCENT_LAUNCH_PLAN.md.
ما لا يُبنى الآن (تثبيت صريح)
Marketplace كامل، swarm متعدد بدون حالات، حملات auto-send، scraping واسع بدون مراجعة قانونية، success-fee معقد، تطبيق جوال، SSO enterprise، MCP مفتوح، إنتاج LLM محلي (vLLM/Ollama)، عشرات الـ verticals دفعة واحدة — وفق تعليمات الـ Master Prompt الأصلية.