Skip to content

Alakris — Sales Playbook 2026

الإصدارv1.0
التاريخ2026-07-12
الحالةAPPROVED — منشور بتاريخ 2026-07-12
العقدMKT-030-4 (PARENT: MKT-030)
يحل/يوسعsales_playbook_pricing_and_qualification_2026.md (SUPERSEDED لقطاع self-service — راجع banner في هذا الملف)
يشير إلىPricing Book (pricing-book-2026.md، MKT-030-3)، Demo Playbook (MKT-030-5)، Qualification Guide (MKT-030-6)، Objection Handling (MKT-030-7)

0. لماذا يحل هذا المستند محل Playbook القديم

يستهدف sales_playbook_pricing_and_qualification_2026.md (الحالة: Active) فقط ICP عالي القيمة: إيرادات ≥$1M، حركة مرور مدفوعة نشطة، CRM متاح، ميزانية تسويق ≥$10K/شهر — هذا هو نفس القطاع الذي تغطيه قائمة الأسعار القديمة Alakris_Price_List_2026.pdf (Growth/Scale/Performance). في وقت كتابته، لم تكن باقات self-service (Lite $30 / Self-Service $129 / Managed $349) موجودة.

يغطي هذا المستند الطيف الكامل — Lite → Enterprise. لا يُحذف المستند القديم، ويُعلّم كـSUPERSEDED ويظل مرجعًا صالحًا بالتحديد لقطاع Enterprise (الأقسام 5–14 من المستند القديم — تأطير ROI، مصفوفة تأهيل الصفقات، قاعدة مكالمة المؤسس — تظل ذات صلة بمكالمات الاستكشاف في Growth/Scale/Performance، راجع القسم 6 أدناه).


1. مراحل البيع (نظرة عامة)

الاتصال الأول → Discovery-call → التأهيل → Demo → اقتراح الالباقة
  → معالجة الاعتراضات → التوافق على الشروط → الإغلاق → Onboarding
المرحلةمستند هذا الـEpicالمسؤولالمدة
Discovery-callهذا المستند، القسم 2مدير المبيعاتالاتصال 1، حتى 30 دقيقة
التأهيلQualification Guide (MKT-030-6)مدير المبيعاتأثناء/مباشرة بعد discovery
DemoDemo Playbook (MKT-030-5)مدير المبيعاتخلال 3 أيام عمل بعد discovery
اقتراح الالباقةPricing Book (MKT-030-3) + شجرة الباقات (القسم 3 أدناه)مدير المبيعاتمباشرة بعد demo
معالجة الاعتراضاتObjection Handling Guide (MKT-030-7)مدير المبيعاتأثناء المحادثة
التوافق على الشروطEnterprise Pricing Policy (Pricing Book، قسم «Enterprise") — فقط لصفقات Enterpriseمدير المبيعات → المالك (approval matrix)حتى 5 أيام عمل
الإغلاقهذا المستند، القسم 7مدير المبيعات
OnboardingCustomer Journey (MKT-030-10)متخصص onboardingمن لحظة الدفع

قاعدة الخطوات التالية (next steps): بعد كل مرحلة يُسجّل إجراء محدد مع مسؤول وتاريخ في CRM (Marina، مديرة مبيعات الذكاء الاصطناعي — بطاقة العميل المحتمل). صيغة "سنناقش لاحقًا" محظورة — إما تاريخ مكالمة، إما حالة صريحة "متوقفة، السبب X، متابعة بتاريخ Y".


2. Discovery-call — بنية الاجتماع الأول

قائمة مرجعية خطية موحدة (لا تُثقل بالمنهجيات): افتتاح ACE → أسئلة SPICED → الخطوات التالية. العمود الفقري للتأهيل هو MEDDPICC-lite (القسم 2.2)، لكن المحاور يسأل وفق منطق SPICED، ولا يقرأ MEDDPICC كاستبيان.

2.1. توقيت المكالمة (30 دقيقة)

الكتلةالوقتالهدف
افتتاح ACE3 دقائقجدول الأعمال، السياق، التوقعات — ما الذي نناقشه، لماذا العميل هنا، ما الذي سيحصل عليه في نهاية المكالمة
Situation5 دقائقالوضع الحالي: قنوات المبيعات، حجم الحركة/العملاء المحتملين، هل يوجد CRM، من يجيب العملاء حاليًا
Pain10 دقائقأين تُفقد الأموال/الوقت: طلبيات الليل دون رد، التأهيل البطيء، الدعم المثقل، لا يوجد حركة SEO
Impact5 دقائقترجمة الألم إلى أموال/ساعات: "كم طلبية ليلية تُفقد شهريًا؟"، "كم ساعة أسبوعيًا تذهب لتأهيل العملاء المحتملين يدويًا؟"
Decision4 دقائقمن يتخذ القرار، هل توجد ميزانية، ما المواعيد
Next steps3 دقائقإجراء تالي محدد + تاريخ

2.2. MEDDPICC-lite (ما يجب إغلاقه بحلول نهاية discovery)

الحرفالسؤالأين يُسجّل
Metricsأي مقياس يريد العميل تحسينه وبكم (بأرقام، وليس "سيكون أفضل")CRM، حقل Impact
Economic Buyerمن يوقع الفاتورة فعليًا — ليس دائمًا الشخص الموجود في المكالمةCRM، إذا لم يكن هو — راجع القسم 2.4
Decision Criteriaوفق أي معايير سيقارن العميل الخيارات (السعر / سرعة التنفيذ / التكاملات)CRM
Decision Processكم خطوة حتى التوقيع، من المشاركين آخرينCRM
Identify Painألم محدد من قسم Pain أعلاهCRM
Championمن على جانب العميل سيدفع الصفقة داخليًاCRM
Competitionهل ينظر العميل إلى بدائل (لا يجب طرحه مباشرة — إذا ظهر، سجّله)CRM، اختياري

2.3. 6–8 أسئلة مفتوحة (نموذج، مائل نحو Pain/Impact)

  1. كيف تُعالج الطلبيات/الاتصالات الواردة من العملاء خارج ساعات العمل حاليًا؟
  2. كم اتصالًا تقريبًا يأتي شهريًا عبر الموقع/الرسائل الفورية؟
  3. ماذا يحدث للطلبية إذا لم يتمكن المدير من الرد سريعًا؟
  4. كيف يبدو قمعك الحالي — ما الذي تستخدمونه لإدارة العملاء المحتملين (CRM، جداول، لا شيء)؟
  5. إذا لم تُفقد طلبيات الليل و"البطيئة" — كم كان سيعطي ذلك من الأموال شهريًا؟ (سؤال Impact كمي)
  6. كم وقتًا يقضي الفريق في تأهيل العملاء المحتملين الواردين يدويًا؟
  7. من في الشركة يتخذ قرار مثل هذه الأدوات وما الميزانية التي خُططت لها؟
  8. ما المواعيد — متى ترغبون في رؤية النتيجة؟

2.4. حالة الحافة — لا يوجد Economic Buyer في المكالمة

إذا كان الحاضر في discovery-call فقط Champion (مسوّق، مدير، لكن ليس من يوقع الفواتير):

  1. لا تنتقل إلى مناقشة السعر قبل ظهور Economic Buyer في المحادثة (شفهيًا أو في المكالمة التالية).
  2. اسأل Champion صراحةً: «من في الشركة يوافق نهائيًا على مثل هذه المصاريف؟» — وسجّل الاسم/الدور في CRM.
  3. اتفق على مكالمة مشتركة مع Economic Buyer قبل إرسال العرض التجاري — لا ترسل السعر "في الهواء" لشخص ليس لديه صلاحية القرار.
  4. Champion في هذه الحالة يحصل على دور "البائع الداخلي" — زوّده بالمواد (Pricing Book، الحالات) للعرض الداخلي أمام الرئيس، إذا لم يكن تنظيم المكالمة المشتركة ممكنًا فورًا.

3. شجرة اتخاذ القرار — حاجة العميل → الباقة

نص داخلي للمدير (يُستخدم كقائمة مرجعية في المكالمة، وليس اختبارًا عامًا على الويب). محرّك القيمة في الفروع — عدد العمليات التجارية المؤتمتة / موظفي الذكاء الاصطناعي (راجع ai-employee-catalog-2026.md)، وليس عدد المستخدمين البشر.

السؤالالإجابة→ الباقة الموصى بها
Q1. ما القنوات المطلوبة؟فقط الدردشة على الموقعLite / Self-Service
موقع + دردشة + e-commerce (CRM، رسائل فورية)Self-Service / Managed
Q2. كم عملية تجارية نؤتمت؟1 عمليةSelf-Service
2–4 عملياتManaged
Q3. شبكة/امتياز/multitenant/تكاملات معقدة؟نعمEnterprise (يُعيد تعريف Q1/Q2 — راجع قاعدة الأولوية أدناه)

3.1. كيفية استخدام الشجرة في المكالمة

  1. اطرح Q1 → Q2 → Q3 بهذا الترتيب بالتحديد.
  2. إذا كانت إجابة Q3 — "نعم" (شبكة، امتياز، multitenant، تكامل مخصص معقد) — فهذا يُعيد تعريف إجابات Q1/Q2، حتى لو بدا العميل من حيث حجم القنوات/العمليات كـSelf-Service. تعقيد التكامل أهم من عدد العمليات.
  3. تُعلن التوصية النهائية للتير للعميل مع تحفظ صريح: «هذا مؤشر بناءً على ما قلتموه — الحدود والسعر الدقيق نراجعها معًا في Pricing Book» (لا تُعطِ التوصية كسعر نهائي قبل القسم 4).
  4. للحالات الحدودية (على سبيل المثال، بالضبط على حد Managed/Enterprise) — راجع حالة الحافة "بين Managed وEnterprise" في Pricing Book (MKT-030-3، قسم Enterprise Pricing Policy).

3.2. حالة الحافة — العميل لا يناسب بوضوح أي سيناريو

مثال: العميل يريد فقط الدردشة (Q1 → Lite/Self-Service)، لكن لديه شبكة فروع (Q3 → Enterprise). قاعدة الأولوية: Q3 دائمًا يفوز — تعقيد التكامل/multitenancy أهم من عدد العمليات أو القنوات. حتى أصغر طلب وظيفي من شبكة/امتياز يُوجه إلى Enterprise-discovery، وليس إلى تير self-serve — لأن البنية المتعددة المستأجرين، الفوترة حسب الفرع، وتقسيم الوصول يتطلبان إعدادًا فرديًا بغض النظر عما يريد الفرع تأتمته في اللحظة.


4. الانتقال إلى الالباقة والسعر

بعد شجرة القرارات (القسم 3) — الانتقال إلى التير المحدد عبر Pricing Book (MKT-030-3):

  • يُعلن التير والسعر فقط AFTER أن يُترجم Impact (القسم 2.1) إلى أموال — وليس قبل. تبقى قاعدة Playbook القديمة سارية: «No pricing discussion without qualification.»
  • إذا كان التير الموصى به Enterprise، الانتقال إلى عملية Enterprise Pricing Policy (Pricing Book، القسم المقابل): أسئلة discovery → custom quote → SLA → التنفيذ. لا يُذكر السعر كرقم ثابت في هذه المرحلة — فقط نطاق التير الفرعي (Growth/Scale/Performance) وشرح أن الرقم الدقيق نتيجة discovery منفصل.
  • Anchor على ROI عند أي سعر (راجع القسم 6 — ROI framing model، محفوظ من Playbook القديم كأداة عمل).

5. التموضع (ما نقوله وما لا نقوله)

محفوظ من الممارسة الحالية (SALES-RUNBOOK-2026.md، مُحدّث للباقات):

على السؤال «ما الذي تفعلونه؟»:

نجعل الأعمال لا تفقد العملاء المحتملين وترفع التحويل بمساعدة موظفي AI الذين يعملون 24/7 — من AI-مستشار على الموقع إلى فريق كامل من الموظفين الرقميين (مبيعات، تسويق، تحليلات، SEO).

لا تقول:

  • «نصنع chatbots»
  • «نبيع AI-وكلاء»
  • «نؤتمت الرسائل»

دائمًا:

  • بيع موظفي AI بمنصب ومنطقة مسؤولية (راجع ai-employee-catalog-2026.md)، وليس "وظيفة" مجردة
  • ربط المحادثة بالنتيجة (العملاء المفقودون، ساعات العمل اليدوي، التحويل)، وليس بالتفاصيل التقنية
  • لباقات self-serve (Lite/Self-Service) — التركيز على سرعة الإطلاق («من التسجيل إلى أداة دردشة مفعّلة في جلسة واحدة»)، وليس على حساب ROI من القسم 6 (هذا — لـdiscovery في Managed+/Enterprise حيث قيمة الصفقة أعلى والقرار يتطلب دراسة أعمق)

6. ROI Framing Model (لصفقات Managed/Enterprise)

محفوظ من sales_playbook_pricing_and_qualification_2026.md (القسم 6) — أداة عمل للصفقات ذات الشيك الكافي ليكون حوار ROI مناسبًا (Managed $349+ وما فوق، خاصة Enterprise):

مثال: إيرادات العميل $1M/سنة ≈ $83K/شهر.

«إذا رفعنا تحويلكم بنسبة 5% — ماذا يعني ذلك بالأموال؟»

توصيل العميل إلى أن يسمي الرقم بنفسه (5% uplift ≈ +$4K/شهر في هذا المثال)، ثم:

«نظامنا عادةً يكلف أقل من الإيرادات الإضافية التي يخلقها.»

لا تتجادل حول السعر مباشرةً — أعد المحادثة إلى ROI. بالنسبة لباقات self-serve هذه الأداة زائدة (راجع القسم 5) — هناك العميل يقرر بنفسه في دقائق، بدون حجة مالية معقدة.


7. إغلاق الصفقة

نوع الصفقةكيف يُغلق
Lite / Self-Serviceالدفع الذاتي من العميل عبر onboarding المحادثي — مدير المبيعات لا يشارك في إتمام الطلب، بل فقط يوجه العميل ويزيل الاعتراضات (Objection Handling، MKT-030-7).
ManagedDemo (MKT-030-5) → عرض → التوافق على التفاصيل (متخصص مخصص، تكاملات) → دفع بالبطاقة، كما في self-serve.
EnterpriseDiscovery → custom quote (approval matrix، Pricing Book) → SLA → توقيع عقد فردي → متخصص onboarding يُسلم العميل إلى Customer Journey (MKT-030-10).

Next step بعد إغلاق أي صفقة: تسليم العميل إلى onboarding مع owner محدد (متخصص onboarding لـManaged/Enterprise، flow تلقائي لـLite/Self-Service) — راجع Customer Journey (MKT-030-10).


8. استبعاد العملاء المحتملين (محفوظ من Playbook القديم، مُحدّث)

لا تحدد مكالمة مع المؤسس/senior sales إذا كان:

  • لا توجد ميزانية على الإطلاق بوضوح (لا تخلط بين "الميزانية أقل من Managed" — هذا ليس سبب رفض، لهؤلاء يوجد Lite/Self-Service)
  • «نريد فقط chatbot رخيص» دون استعداد للتعمق في أتمتة العمليات التجارية
  • لا توجد أهداف تجارية واضحة حتى بعد أسئلة Pain/Impact في القسم 2

الفرق المهم عن Playbook القديم: عتبة الإيرادات ≥$1M لم تعد معيار استبعاد عامًا — كان هذا صحيحًا فقط للنموذج القديم high-ticket-only. باقات self-serve (Lite/Self-Service/Managed) مُصممة خصيصًا للعملاء دون هذه العتبة. عتبة الإيرادات ≥$1M تبقى ذات صلة ONLY كمؤشر لتجزئة Enterprise (التير الفرعي Growth يبدأ من $1M، راجع Pricing Book).


يُدار هذا المستند بمهمة منفصلة MKT-030-4. تغيير شجرة الباقات — فقط تبعًا لتحديث Pricing Book (MKT-030-3)، وليس بشكل مستقل.

Released under the MIT License.