المظهر
Alakris — دليل العرض التوضيحي 2026
| الإصدار | v1.0 |
| التاريخ | 2026-07-12 |
| الحالة | APPROVED — منشور بتاريخ 2026-07-12 |
| العقد | MKT-030-5 (PARENT: MKT-030) |
| يشير إلى | AI Employee Catalog (ai-employee-catalog-2026.md، MKT-030-1)، Pricing Book (pricing-book-2026.md، MKT-030-3)، Sales Playbook (sales-playbook-2026.md، MKT-030-4) |
مبدأ العرض التوضيحي: problem-agitate-solve
يبدأ العرض التوضيحي بصياغة ألم العميل صراحةً («هذا ما سمعته في الاجتماع السابق — وهذا ما يُعدّ أولوية بالنسبة إليكم»)، لا بجولة في المنتج. يُعرض فقط ما يحلّ أولوية الألم الرئيسية للعميل — وليس جولة كاملة على جميع الوحدات. يجب أن يرتبط كل شاشة مُعروضة بالألم الذي تم ذكره في مكالمة الاكتشاف (Sales Playbook، القسم 2).
أخطاء شائعة نتجنّبها في كل مرحلة:
- feature dump دون ربطه بألم العميل؛
- عرض توضيحي بلا ارتكاز على مرحلة الاكتشاف (كأن المحادثة الأولى لم تكن)؛
- غياب دعوة للعمل (CTA) صريحة في الختام (الفشل الأكثر شيوعًا بين فرق SaaS الموجهة نحو SMB)؛
- الانتقال المبكر إلى السعر قبل أن تتضح القيمة للعميل.
المرحلة 1 — التعارف
- الهدف: بناء الانسجام، وتأكيد جدول أعمال المكالمة، ومزامنة التوقعات من العرض التوضيحي (مدة الزمن، ما سنعرضه، ما يريد العميل رؤيته أولاً).
- ما يُعرض: لا شيء في المنتج بعد — فقط وجهك/صوتك، وعند الحاجة شريحة قصيرة بجدول الأعمال.
- ما يُقال (عبارات تقريبية):
«شكرًا لكم على تخصيص الوقت. لدينا 30 دقيقة — أريد أن أعرض خلالها بالتحديد ما يحلّ [الألم الذي تم ذكره في الاجتماع السابق]، وليس المنتج كاملًا. هل اتفقنا؟» «قبل أن نبدأ — ما الذي كان سيكون أثمن تأكيد لكم مما ستشاهدونه اليوم بأننا نناسبكم؟»
- ما يُتجنب: مقدمة طويلة عن الشركة وتاريخ Alakris؛ شرائح عامة «عنّا» تتجاوز 1 دقيقة — فالعميل حضر لحل ألمه، لا لتقديم عرض عن الشركة.
المرحلة 2 — كشف المشكلة (discovery-in-demo)
- الهدف: إعادة التحقق من الألم والأولوية اللذين تم تسجيلهما في الاجتماع الأول — فإذا مرّ وقت بين مكالمة الاكتشاف والعرض التوضيحي، قد تكون أولويات العميل قد تغيّرت.
- ما يُعرض: لا شيء في المنتج — هذه مرحلة حوارية.
- ما يُقال (عبارات تقريبية):
«في الاجتماع السابق قلتم إن [ألم محدد من بطاقة CRM، MEDDPICC Pain/Impact]. هل هذا لا يزال الأولوية الرئيسية، أم أن شيئًا ما تغيّر؟» «لو كان علينا حلّ أمر واحد فقط في مكالمة اليوم — ما هو؟»
- ما يُتجنب: تخطّي هذه المرحلة باعتبار أن مكالمة الاكتشاف كشفت كل شيء — فالأولويات تتغيّر، والعرض التوضيحي المبني على ألم قديم يبدو غير ذي صلة.
المرحلة 3 — عرض المنصة (tailored demo)
- الهدف: عرض المنصة ذاتها (لوحة إدارة التاجر Merchant Admin، شاشة إدارة موظفي الذكاء الاصطناعي) من خلال منظور ألم العميل المحدد، لا كجولة عامة.
- ما يُعرض: الشاشات ذات الصلة فقط. على سبيل المثال، إذا كان الألم هو «نفقد الطلبات الليلية»، نعرض أداة الدردشة Alex قيد التشغيل + بطاقة العميل المحتمل الملتقط في CRM لدى Marina، وليس لوحة Merchant Admin بأكملها.
- ما يُقال (عبارات تقريبية):
«انظروا — هكذا يبدو الحوار مع زائر الموقع في الساعة 3 صباحًا. يصل الرد خلال ثوانٍ، وليس في الصباح عندما يأتي مدير المبيعات إلى العمل.» «وهذا الطلب ذاته ينتقل تلقائيًا إلى قمع المبيعات — لا حاجة لنقله يدويًا من الدردشة إلى CRM.»
- ما يُتجنب: عرض وظائف لا تتعلق بالألم المذكور، «فقط لإظهار كل ما تستطيع المنصة فعله» — فهذا feature dump يُضعف تركيز العرض التوضيحي.
المرحلة 4 — عرض النتيجة
- الهدف: تحويل الوظيفة المُعروضة إلى نتيجة قابلة للقياس، يمكن للعميل إسقاطها على أعماله.
- ما يُعرض: لوحة تحليلات (Sofia، محلل الذكاء الاصطناعي) — مقاييس الطلبات الملتقطة، ووقت الرد الأول، والتحويل.
- ما يُقال (عبارات تقريبية):
«هذه لوحة تحليلات Sofia — هنا يمكن رؤية عدد الطلبات التي كانت ستُفقد بدون مستشار الذكاء الاصطناعي، وعدد ما تمّ التقاطه فعليًا.» «لديكم حاليًا [رقم من مرحلة الاكتشاف، بند Impact] تواصل شهريًا لا يحظى بردّ في الوقت المناسب — وهكذا يبدو الأمر عندما يلتقطها الوكيل.»
- ما يُتجنب: العبارات المجردة مثل «تُحسّن المنصة الكفاءة» دون أرقام محددة مرتبطة بما ذكره العميل بنفسه في مكالمة الاكتشاف (بند Impact، Sales Playbook).
المرحلة 5 — عرض موظفي الذكاء الاصطناعي
- الهدف: عرض موظفين رقميين محددين، ذوي صلة بالألم والباقة المُوصى بها للعميل — لا «وظائف الوكلاء» بشكل مجرد.
- ما يُعرض: الشخصيات من
ai-employee-catalog-2026.mdذات الصلة بحالة العميل — على سبيل المثال، بالنسبة لمتجر إلكتروني (e-commerce) يعاني من مشكلة الطلبات المهجورة: Alex (مستشار) + Marina (CRM)؛ أما العميل الذي يعاني من مشكلة المحتوى: Katya (مسؤولة التسويق بالمحتوى). - ما يُقال (عبارات تقريبية):
«هذا Alex — سيكون لديكم للإجابة على زوار الموقع 24/7. وهذه Marina — تدير قمع العملاء المحتملين بالكامل، حتى لا يضيع أي اتصال دافئ بين القنوات.» «في باقتكم متاح [N] موظف ذكاء اصطناعي في الوقت نفسه — وهؤلاء بالتحديد من يغطّون ألمكم الحالي.»
- ما يُتجنب: تسمية الوكلاء بمصطلحات تقنية («أداة الدردشة»، «نقطة نهاية CRM»، «وحدة») — فالعميل يوظّف موظفًا باسم ومنصب، ولا يشترك في API.
المرحلة 6 — عرض دراسة الحالة
- الهدف: تقديم proof — إثبات بأن ألمًا مشابهًا قد تم حله سابقًا، ويفضّل أن يكون مع مقياس.
- ما يُعرض: دراسة حالة (case study) مُعتمدة، إن كان هناك ما يناسب القطاع. إذا لم تكن هناك دراسات حالة منشورة لهذا القطاع/الباقة — يُقال ذلك بصراحة، دون اختلاق أرقام.
- ما يُقال (عبارات تقريبية)، إن كان هناك دراسة حالة:
«كانت هناك حالة مشابهة لعميل من [قطاع، دون الكشف عن تفاصيل سرية إذا كانت دراسة الحالة غير anonymized-approved] — بعد الإطلاق [مقياس النمو].»
- ما يُقال، إن لم تكن هناك دراسة حالة مناسبة:
«ليس لدينا حاليًا دراسة حالة منشورة بالتحديد لقطاعكم — وهذا صراحةً. لكن دعوني أريكم كيف تعمل المنطق المشابه على بيانات العرض التوضيحي، لتقيّموا أنتم مدى ملاءمتها.»
- ما يُتجنب: اختلاق أو تعميم مقاييس من قطاع آخر باعتبارها «نتيجة نموذجية» — إذا لم تكن هناك دراسة حالة، يُعترف بذلك صراحةً (نفس المبدأ في Pricing Book: «قيد التطوير»، لا مثال خيالي).
المرحلة 7 — الانتقال إلى الباقات
- الهدف: تأكيد الباقة التي تم تحديدها سابقًا في التأهيل (Sales Playbook، شجرة القرارات في القسم 3) — فالعرض التوضيحي لا «يخمّن» الباقة من جديد، بل يؤكّدها من خلال القيمة التي تم رؤيتها.
- ما يُعرض: بطاقة الباقة ذات الصلة من Pricing Book (الباقة المناسبة فقط بحسب شجرة القرارات — وليس جميع الباقات الـ4 دفعة واحدة، لتجنّب paradox of choice).
- ما يُقال (عبارات تقريبية):
«استنادًا إلى ما ذكرتموه في الاجتماع الأول — [N] قنوات، [M] عمليات — هذا يندرج ضمن باقة [اسم]. إليكم ما يتضمّنه.» إذا طلب العميل السعر مبكرًا (edge case، انظر أدناه): «تقديريًا هذا [نطاق/باقة] — لكنني أريد أن أعرض أولاً ما ستحصلون عليه بالضبط مقابل هذا السعر، حتى لا تبدو الرقم مجردًا.»
- ما يُتجنب: الانتقال إلى السعر قبل عرض المنصة/النتيجة/موظفي الذكاء الاصطناعي/دراسة الحالة (المراحل 3–6) — فالسعر بدون سياق القيمة يُفسَّر على أنه «مُرتفع» بغض النظر عن الرقم الفعلي.
Edge case — طلب العميل السعر في بداية العرض التوضيحي
تقديم مؤشر صادق (نطاق الباقة بحسب شجرة القرارات في Sales Playbook)، دون تجاهل السؤال أو التهرب منه، لكن مع تحديد صراحةً أن انتقال التسعير الكامل (pricing transition) (تفاصيل ما يتضمّنه) سيكون في نهاية العرض التوضيحي، بعد عرض القيمة:
«باختصار — استنادًا إلى ما وصفتموه، هذا تقديريًا [باقة/نطاق]. التفاصيل الدقيقة لما يتضمّنه وكيفية احتساب الرقم النهائي، سأعرضها في النهاية — ليكون الأمر موضوعيًا، لا مجردًا.»
Edge case — عرض توضيحي لعدة أصحاب مصلحة بأولويات ألم مختلفة
لا نحوّل العرض التوضيحي إلى feature dump لمجرد «إرضاء الجميع بشيء ما». القاعدة: مسبقًا (في المرحلة 2، discovery-in-demo) نسأل المجموعة صراحةً: أولوية ألم من هي الأساسية لاتخاذ قرار الشراء (عادةً — Economic Buyer)، ونبني العرض حولها، مع لمس آلام أصحاب المصلحة الآخرين بعبارات موجزة («وهذا أيضًا، بالمناسبة، يغلق ما تحدثتم عنه» — موجهة بالاسم)، دون كتل عرض توضيحي كاملة منفصلة لكل منهم.
المرحلة 8 — الختام
- الهدف: تحديد الخطوة التالية الصريحة والمحددة — وعدم إنهاء العرض التوضيحي بكلمات «فكّروا وأخبرونا».
- ما يُعرض: لا شيء جديدًا — ملخص نهائي لما تم رؤيته (1 شريحة/شفهيًا: «عرضنا اليوم X، Y، Z، التي تحلّ ألمكم A»).
- ما يُقال (عبارات تقريبية):
«الخطوة التالية — [إجراء محدد: أرسل العرض التجاري اليوم قبل نهاية اليوم / نحدد مكالمة مع [Economic Buyer] في [تاريخ] / تسجّلون عبر الرابط الآن، إذا كانت الباقة Lite/Self-Service]. هل اتفقنا؟»
- ما يُتجنب (حقل إلزامي، ليس خياريًا): إنهاء العرض التوضيحي بدون دعوة للعمل (CTA) صريحة. صياغات مثل «سأراسلكم» أو «فكّروا وأخبرونا» — محظورة كنتيجة وحيدة للمكالمة؛ يجب دائمًا تحديد تاريخ/إجراء مع مسؤول (owner) (انظر Sales Playbook، قاعدة next steps).
يتم صيانة هذا المستند عبر المهمة المنفصلة MKT-030-5. قائمة الشخصيات المعروضة — فقط من ai-employee-catalog-2026.md (MKT-030-1)، ولا تُختلق شخصيات جديدة هنا.